Pentestrapporten, der skal vises til kunder: hvad skal den indeholde?

En pentestrapport skrives først og fremmest til dem, der skal rette fundene, men i et softwarehus kan den ende på bordet hos kundens sikkerhedsfolk. De læser den med et andet spørgsmål: kan vi stole på produktet, og kan vi stole på testen? En rapport, der også skal bruges over for kunder, skal derfor gøre det let at se, hvad der blev testet, hvornår, af hvem, med hvilket udgangspunkt, og hvordan fundene er håndteret.

Det betyder ikke, at rapporten skal skrives til salg. Den skal være lige så præcis og ærlig som enhver anden testrapport. Forskellen er, at nogle afsnit får større vægt, fordi de er dem, en udenforstående læser bruger til at vurdere dokumentet. Hvordan man læser en pentestrapport som køber, forklares generelt på penetrationtest.dk.

Hvad kundens læser leder efter

Kundens sikkerhedsfolk har ikke altid tid til hele rapporten. De slår op i de afsnit, der afgør, om dokumentet kan bruges:

Afsender og uafhængighed · hvem der har udført testen, og om det er en ekstern part.
Testperiode og version · hvornår testen fandt sted, og hvilken udgave af produktet der blev testet.
Omfang og begrænsninger · hvilke dele, roller og grænseflader der var med, og hvad der var udeladt.
Udgangspunkt · om testeren havde login, og med hvilke roller.
Resultatet samlet · fordelingen af fund efter alvor og en kort vurdering.
Status · hvad der er rettet og efterprøvet siden.

Mangler et af punkterne, kan der komme et opfølgende spørgsmål. → Omfangsafsnittet

Rapportens faste dele

Der findes ingen fælles skabelon, men kilderne ligner hinanden. Det britiske NCSC skriver i sin vejledning om penetrationstest, at rapporten bør indeholde de fundne sikkerhedsproblemer, testholdets vurdering af risikoen ved hver sårbarhed og en måde at løse hvert problem på. OWASP’s testvejledning for webapplikationer foreslår en rapport med en indledning med omfang, begrænsninger og tidslinje, et ledelsesresumé uden teknisk sprog, et afsnit med fund og eventuelle bilag. Den skriver også, at rapporten skal kunne læses af både ledelse og teknikere.

Det er netop den opdeling, der gør en rapport brugbar over for kunder. Resuméet og indledningen kan læses af kundens sikkerhedsfolk uden at åbne de tekniske detaljer, mens afsnittet med fund og bilagene er til jeres udviklere. → Kunden vil se de tekniske bilag

Resumé, version og datoer

Resuméet kan være den eneste del, kunden får at se. Bed testeren skrive det, så det kan læses uden resten af rapporten: hvad var formålet, hvad var med, hvilken samlet vurdering giver testeren, og hvilke typer fund var der. Et resumé, der henviser til fund ved nummer uden at forklare dem, hjælper ikke en læser, der ikke har rapporten.

Resuméet må ikke lyde bedre, end rapporten er. Hvis der var alvorlige fund, skal de nævnes, også selv om de er rettet. Kunden vil hellere læse, at der var et alvorligt fund, som blev rettet og efterprøvet, end opdage det i et bilag senere.

Et SaaS-produkt ændrer sig hele tiden. En rapport, der ikke siger, hvilken version eller hvilket miljø der blev testet, er svær for kunden at bruge. Bed om, at rapporten angiver testperioden, miljøet og en version eller dato for udgivelsen, så kunden kan se forbindelsen til det, kunden bruger i dag. → Version og testdatoer

Tænk også på sproget. Har I kunder uden for Danmark, eller sidder kundens sikkerhedsfolk i en international koncern, kan en rapport på dansk betyde, at resuméet skal oversættes, før det kan bruges. En oversættelse, I selv laver, er ikke længere testerens tekst. Aftal derfor sproget med testeren, inden rapporten skrives, og overvej, om resuméet skal leveres på to sprog. → Rapport på dansk eller engelsk

Endelig skal testerens forbehold stå tydeligt: at testen er et øjebliksbillede af det aftalte omfang. Det er ikke en svaghed ved rapporten. Det er det, der gør den troværdig for en kyndig læser.

Fund og status på en måde, kunden kan følge

Fundene beskrives i rapporten, som testeren så dem på testtidspunktet. Kunden vil også vide, hvad der er sket siden. Det kan løses på to måder: en opdateret statusside, som testeren udsteder efter efterprøvning, eller et separat dokument fra testeren, der bekræfter, hvilke fund der er rettet. Uanset formen skal det være tydeligt, hvem der står bag statusoplysningen. → Åbne fund i rapporten til kunden

Hold fast i testerens alvorlighedsvurdering. Er I uenige om et fund, så notér jeres vurdering ved siden af, men lad testerens stå.

Det, der ikke hører hjemme i kundens udgave

Den fulde rapport kan indeholde oplysninger, der ikke skal ud til kunder: detaljerede fremgangsmåder for åbne fund, skærmbilleder med data, interne servernavne og navne på andre kunders testlejere. Aftal på forhånd, om testeren skal levere en udgave til kunder, hvor den slags er udeladt, eller om kunderne kun skal have resumé og erklæring. → Kundeversionen af rapporten

Spørg også testeren, hvordan udgaven til kunder mærkes, så modtageren kan se, at den bygger på den fulde rapport, med samme testperiode og samme omfang. En kundeudgave, der ligner et selvstændigt dokument, kan skabe tvivl om, hvad den egentlig dækker.

Et tænkt eksempel

Et softwarehus med et system til håndtering af kontrakter i juridiske afdelinger bestiller sin første test med kunderne i tankerne. I bestillingen beder det om et resumé på én side, der kan stå alene, et omfangsafsnit med roller og udeladte moduler, versionsnummer og testperiode på forsiden og en statusside efter efterprøvningen. Da den første kunde beder om dokumentation, sendes resumé, omfangsafsnit og statusside. Kundens sikkerhedsfolk stiller ét opfølgende spørgsmål om en rolle, der ikke var med, og ellers er dokumentationen nok.

Det skal I lade være med

Bede testeren pynte på resuméet · Det skal svare til fundene.
Udelade begrænsningerne · Kunden finder dem alligevel og mister tilliden.
Glemme version og miljø · Kunden skal kunne koble rapporten til produktet.
Selv skrive statusoplysninger ind i testerens rapport · Afsenderen skal være tydelig.
Sende hele rapporten, fordi resuméet ikke kan stå alene · Få resuméet rettet i stedet.

Hvad kan og ikke kan konkluderes

En rapport, der er bygget, så kundens læser hurtigt kan finde omfang, periode, afsender og status, gør det lettere at bruge testen over for kunder og giver færre opfølgende spørgsmål. Den gør ikke resultatet bedre, og den kan kun dokumentere det, testen faktisk omfattede, på det tidspunkt den blev udført. Om kunden accepterer dokumentationen, afgør kunden.

Tjekliste til rapporten, der skal bruges over for kunder

☐ Fremgår testerens navn og testperioden på forsiden?
☐ Er version og miljø angivet?
☐ Beskriver omfanget roller, moduler og grænseflader, også det udeladte?
☐ Kan resuméet læses uden resten af rapporten?
☐ Er det aftalt, hvordan status efter efterprøvning dokumenteres?
☐ Er det besluttet, hvilken udgave kunderne får?

Kilder

NCSC (UK): Penetration testing: hvad testrapporten bør indeholde, herunder fundne problemer, risikovurdering af hver sårbarhed og en måde at løse hvert problem på.
OWASP Web Security Testing Guide v4.2: Reporting: forslag til rapportens opbygning med indledning, ledelsesresumé, fund og bilag, til både ledelse og teknikere.

Senest gennemgået: oktober 2026.