Hvad skal kunden bruge rapporten til? Spørg, før I bestiller testen

Et krav om en pentestrapport fortæller, hvad kunden beder om, men ikke hvorfor. Netop formålet afgør, hvilken del af produktet testen skal dække, og hvilket dokument der i sidste ende skal sendes til kunden.

Spørg derfor kunden, hvad rapporten skal indgå i, før I bestiller noget. Et kort svar fra kundens indkøb eller sikkerhedsfunktion kan for eksempel vise, at et resumé er nok, at kun ét modul er interessant, eller at kunden i virkeligheden skal bruge noget helt andet end en test.

Kravet har altid en modtager

Bag et krav sidder en person, der skal bruge dokumentet til en beslutning eller en kontrol. Det kan være en indkøber, der skal afslutte en leverandørvurdering, en sikkerhedsansvarlig, der vil forstå risikoen ved at lægge data hos jer, eller en revisor, der gennemgår kundens egne kontroller.

Hver af dem læser med sit eget spørgsmål. Indkøberen vil se, at noget er gjort. Den sikkerhedsansvarlige vil se, hvad der blev fundet, og hvordan det blev håndteret. Revisoren vil kunne henvise til et dateret dokument. Kender I modtageren, kender I også det spørgsmål, rapporten skal kunne besvare.

Modtageren er ikke altid den, der skriver til jer. En indkøber kan videresende kravet fra en kollega i IT, som aldrig selv har været i kontakt med jer. Spørg derfor, om I kan tale direkte med den, der skal læse dokumentet. Et kort opkald med den person kan spare flere runder med mails, hvor kravet bliver gengivet lidt forskelligt hver gang.

Fem formål, der kan ligge bag

Godkendelse som leverandør · kunden skal have jer igennem en fast proces, før aftalen kan underskrives.
Kundens egen risikovurdering · kunden vil vurdere, om produktet kan bære de data eller processer, kunden lægger ind.
Kundens egne krav udefra · kundens revisor, certificering eller myndighed spørger til, hvordan kunden styrer sine leverandører.
Kundens forsikring · forsikringsselskabet spørger kunden til kritiske leverandører.
Et konkret projekt · kunden skal integrere med jeres API eller åbne produktet for egne kunder og vil vide, om den del holder.

Formålene kan overlappe, og kunden har ikke altid selv gjort sig klart, hvilket der vejer tungest. Et par spørgsmål kan hjælpe begge parter.

Formålet bestemmer, hvad der skal testes

Hvis kunden vil vurdere sin egen risiko, er det de dele af produktet, kunden bruger, der tæller: de moduler, kunden har købt, de roller, kundens medarbejdere får, og de integrationer, der forbinder produktet med kundens systemer. En test af en del, kunden aldrig rører, besvarer ikke spørgsmålet.

Er formålet en fast godkendelse, kan kravet være bredere, men også mere formelt. Her er det vigtigere, at testen dækker kernen af produktet og er udført af en uafhængig part, end at hvert modul er med. → Scope for et SaaS-produkt

Handler det om et integrationsprojekt, kan en afgrænset test af API’et og adgangen til det være det mest præcise svar. Spørger kundens revisor, kan det vigtigste være, at dokumentet har dato, testerens navn og en klar beskrivelse af omfanget, så det kan arkiveres som bevis for en kontrol hos kunden. → Produktets API i testen

Formålet bestemmer, hvilket dokument kunden får

En indkøber, der skal sætte et flueben, har ikke nødvendigvis brug for en lang liste over fund. Et resumé eller en erklæring om omfang, tidspunkt og håndtering kan være præcis det, der skal til. En sikkerhedsansvarlig, der skal vurdere risikoen, vil oftere bede om mere detaljer og måske se fundene og jeres plan for dem.

Når I kender formålet, kan I fortælle testeren det fra begyndelsen, så rapporten bygges op med et resumé, der kan stå alene, og et teknisk afsnit, der kun deles, hvor det er nødvendigt. → Bestil testen til kundebrug

Sådan spørger I uden at virke afvisende

Et spørgsmål om formålet kan blive læst som en undvigelse. Formulér det derfor som et forsøg på at give kunden det rigtige. Eksempler:

Hvem hos jer skal læse dokumentationen, og hvad skal den person tage stilling til?
Gælder ønsket hele produktet eller de moduler, I har købt?
Er der en standard, en kontrol eller et skema, svaret skal passe ind i?
Er et resumé eller en erklæring nok, eller skal fundene ses?
Hvornår skal I bruge det, og er der en dato, der ikke kan flyttes?

Tilpas listen til kunden. En lille kunde med et kort skema skal ikke have fem spørgsmål tilbage, mens en stor kunde med en formel proces kan forvente dem. Send spørgsmålene skriftligt og gem svaret. Det bliver jeres grundlag, hvis kunden senere mener, at dokumentet ikke passer. → Aftalen venter på en pentestrapport

Når kunden ikke selv ved det

Nogle krav er skrevet ind i en standardproces, uden at nogen hos kunden har tænkt over formålet. Så kan I selv foreslå en løsning: beskriv, hvad I kan levere, hvad det dækker, og spørg, om det opfylder kundens behov. Et konkret forslag er lettere for kunden at godkende end et åbent spørgsmål. Hold forslaget til det, I faktisk har eller allerede har planlagt, så I ikke binder jer til en ny opgave for at få en enkelt godkendelse igennem.

Notér også, hvis flere kunder har samme formål. Så kan ét testforløb og ét fast dokument dække dem alle. → Flere kunder stiller forskellige krav

Det skal I lade være med

At antage, at alle kunder vil have det samme · Formålet varierer, og det gør det rigtige dokument også.
At bestille bredt for en sikkerheds skyld · En bred test uden formål kan stadig overse det, kunden spurgte om.
At sende den fulde rapport, fordi den findes · Modtageren har måske kun brug for et resumé.
At lade spørgsmålet blive mundtligt · Et svar på skrift kan I henvise til, når kravet kommer igen.
At spørge så meget, at kunden mister tålmodigheden · Få, præcise spørgsmål virker bedre end et langt skema.

Hvad kan og ikke kan konkluderes

Når formålet er kendt, kan I vælge et omfang og et dokument, der passer til kundens beslutning. Det gør det mere sandsynligt, at kunden kan bruge svaret uden at spørge igen.

Formålet afgør ikke, om kunden accepterer resultatet. Det afhænger af, hvad testen viser, og af kundens egen vurdering.