Spørgsmålet om, hvor gammel en pentestrapport må være, kommer typisk fra en kunde, en revisor eller et forsikringsselskab. Der findes ikke én gyldighedsperiode, der gælder alle rapporter. Svaret hviler på to forhold: hvad modtageren kræver, og hvor meget løsningen har ændret sig siden testen.
Hvis modtageren har et krav til alder eller interval, er det kravet, der afgør sagen. Hvis der ikke er et krav, må I selv vurdere, om rapporten stadig beskriver den løsning, modtageren spørger til. En nyere rapport kan være forældet efter en stor ændring, og en ældre kan stadig være dækkende for et system, der næsten ikke er rørt.
To spørgsmål afgør alderen
Det første spørgsmål er formelt: hvad står der i kontrakten, kravspecifikationen, forsikringens spørgeskema eller den standard, I skal leve op til? Find den præcise formulering. Krav kan være udtrykt som et fast interval, som en test inden for en bestemt periode før en dato, eller som test efter væsentlige ændringer.
Det andet spørgsmål er fagligt: svarer den testede løsning til den, der er i drift i dag? Her er testdatoen vigtigere end rapportens dato, og ændringerne siden testen vigtigere end antallet af måneder. Hvordan ændringer påvirker konklusionerne, er beskrevet i → Penetrationstesten er et øjebliksbillede
Begge spørgsmål skal besvares. En rapport, der opfylder et formelt interval, kan stadig være misvisende, hvis kundeportalen har fået et helt nyt login siden. Og en rapport, der fagligt er dækkende, hjælper ikke, hvis modtageren har et fast krav, den ikke opfylder.
Når modtageren har et krav
Krav til alder kommer fra mange kanter. En kunde kan have skrevet det i kontrakten, et forsikringsselskab kan spørge til datoen for seneste test, og nogle standarder har egne regler. PCI DSS krav 11.4 nævner for eksempel både et fast interval og test efter væsentlige ændringer for de miljøer, standarden omfatter. → Kontrakten med en kunde kræver sikkerhedstest
Læs også, hvad kravet regner fra. Det kan være testens udførelse, rapportens aflevering eller tidspunktet for en efterprøvning af rettelser. Hvis det ikke står klart, så spørg modtageren skriftligt. Et kort svar fra kunden om, hvilken dato der tæller, kan spare jer for en ny test, eller for at sende en rapport, der bliver afvist.
Hvis I har flere kunder med forskellige krav, så saml dem ét sted. Det strengeste krav for et system bestemmer i praksis, hvornår det skal testes igen.
Når der ikke er et krav
Uden et krav fra modtageren er alderen en vurdering, som I selv skal kunne forklare. Brug ændringerne som målestok. Spørg for det system, rapporten handler om:
- Er der kommet nye funktioner, moduler eller integrationer siden testen?
- Er login, roller eller adgangsveje ændret?
- Er hosting, platform eller driftsleverandør skiftet?
- Er løsningen åbnet for nye brugergrupper?
- Er de væsentlige fund fra testen rettet og efterprøvet?
Jo flere ja til de første fire spørgsmål, jo mindre siger rapporten om løsningen i dag. Et ja til det femte styrker rapporten, men kun for de fund, der blev kontrolleret. → Efter en større opdatering af systemet
Sådan svarer I modtageren
Et brugbart svar på spørgsmålet om rapportens alder indeholder mere end en dato. Det kan bestå af få linjer:
- Testperiode · hvornår testen faktisk blev udført.
- Scope · hvilke systemer og funktioner der indgik.
- Ændringer siden · væsentlige ændringer i det testede system og deres karakter.
- Status på fund · hvad der er rettet, efterprøvet eller accepteret.
- Næste test · hvornår den er planlagt, hvis den er det.
Svaret giver modtageren mulighed for selv at vurdere, om rapporten er tilstrækkelig. Det er bedre end et ja til, at rapporten stadig gælder, som modtageren ikke kan efterprøve. Fundenes status hentes fra jeres handlingsplan. → Fra rapport til handlingsplan
Når rapporten er for gammel
Hvis rapporten ikke opfylder kravet eller ikke længere beskriver løsningen, er der flere veje. Hvilken der passer, afhænger af, hvad modtageren har brug for, og hvor store ændringerne er.
- Ny test af hele scope · når løsningen er ændret bredt, eller kravet er et fast interval.
- Afgrænset test af det ændrede · når ændringerne er tydeligt afgrænsede, og modtageren accepterer det.
- Retest af åbne fund · når spørgsmålet primært handler om, hvorvidt fundene er rettet.
- Plan med dato · når en test er bestilt, og modtageren kan acceptere at vente.
En retest giver ikke en ny rapportalder for hele løsningen. Den dokumenterer kun de fund, den efterprøvede. Gør det klart over for modtageren, så resultatet ikke bliver læst bredere end grundlaget. → Næste test efter et alvorligt resultat
Gør alderen let at vurdere fra starten
Meget af arbejdet med rapportens alder kan klares, når testen bestilles. Bed om, at rapporten angiver testperioden, miljøet og versionen af de vigtigste systemer på forsiden eller i resuméet. Så kan en modtager se grundlaget uden at lede i bilagene.
Læg også testen, så den passer til de krav, I kender. Hvis en vigtig kunde fornyer aftalen på et bestemt tidspunkt, eller forsikringen spørger ved fornyelsen, kan testens placering i året spare jer for at stå med en rapport, der netop er blevet for gammel. → Hvornår på året skal testen ligge?
Endelig hjælper det at føre ændringerne løbende i stedet for at rekonstruere dem, når spørgsmålet kommer. Systemejeren kender ændringerne bedst og bør eje den oversigt.
Softwarehuse og SaaS-leverandører, der jævnligt får spørgsmål om rapportens alder fra kunder, kan finde mere på pentestrapport.dk.
Det skal I lade være med
- At love en fast gyldighedsperiode · Alderen afhænger af krav og ændringer, ikke af en standardperiode.
- At bruge rapportens dato som testdato · Modtageren har brug for testperioden.
- At sende en gammel rapport uden kommentar · Fortæl, hvad der er ændret siden.
- At lade en retest forny hele rapporten · Den gælder kun de efterprøvede fund.
- At gætte på modtagerens krav · Spørg, hvad der tæller, og få svaret skriftligt.
Hvad kan og ikke kan konkluderes
En rapport kan bruges, så længe den opfylder modtagerens krav og stadig beskriver den løsning, spørgsmålet handler om. Sammen med en oversigt over ændringer og status på fund kan den give modtageren et ærligt grundlag.
Alderen alene kan ikke afgøre, om rapporten er dækkende. En ung rapport kan være forældet, og en ældre kan være dækkende for et uændret system, hvis modtageren ikke har et krav, der siger noget andet.
Tjekliste, når nogen spørger til rapportens alder
- ☐ Kender I modtagerens krav og den dato, kravet regner fra?
- ☐ Står testperioden tydeligt i rapporten?
- ☐ Er væsentlige ændringer siden testen beskrevet?
- ☐ Er status på fund hentet fra handlingsplanen?
- ☐ Er det afklaret, om en retest, en afgrænset test eller en ny test er nødvendig?
- ☐ Er svaret til modtageren skriftligt og dateret?
Kilder
- PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4, hvor penetrationstest knyttes både til et fast interval og til væsentlige ændringer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Hvor ofte skal I teste? · Retest efter penetrationstest
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
