Kunden vil have en rapport, der er under et år gammel

Et krav om en rapport under et år gammel lyder enkelt, men for et softwarehus med mange kunder bliver det hurtigt et kalenderproblem. Hvis testen ligger forkert, vil der hvert år være en periode, hvor den nyeste rapport netop er for gammel til en eller flere kunder.

Svaret hviler på to ting. Først skal I vide, hvilken dato kunden regner fra, og om kravet også nævner ændringer i produktet. Dernæst skal testene placeres med så meget luft, at en ny rapport altid ligger klar, før den gamle passerer grænsen.

Hvilken dato tæller?

En pentestrapport har flere datoer: den periode, testen blev udført i, datoen for rapportens aflevering og eventuelt datoen for en efterprøvning af rettelser. Kunder bruger ordet alder om alle tre. Spørg, hvilken dato kunden regner fra, og få svaret skriftligt.

Forskellen kan have betydning. Hvis kunden regner fra testperioden, og rapporten afleveres et stykke tid efter, har I mindre tid at gøre godt med, end rapportens forside antyder. Sørg for, at testperioden står tydeligt i rapporten, så kunden ikke skal gætte. → Version og testdatoer

En efterprøvning af rettelser gør ikke hele rapporten yngre. Den dokumenterer de fund, den så på. Sig det til kunden, hvis kunden foreslår at regne fra efterprøvningen.

Hvor kravet kommer fra

Kravet kan komme fra kundens egen leverandørpolitik eller fra en standard, kunden selv skal leve op til. PCI DSS krav 11.4 nævner for eksempel penetrationstest mindst hver tolvte måned og efter væsentlige ændringer i infrastruktur eller applikation, for de miljøer standarden omfatter. Nogle kunder har valgt et år, fordi det passer til deres egen revision. I et spørgeskema kan kravet stå som en test inden for de seneste 12 måneder. Det er kundens eget krav og ikke en lovregel, så spørg gerne, hvor kravet stammer fra.

Det er nyttigt at kende kilden. Et krav, der stammer fra en standard, er som udgangspunkt ikke til forhandling. Et krav, kunden selv har valgt, kan måske tilpasses, hvis I kan vise en god grund. → Kunden henviser til en standard

Kravet kan også sige noget om ændringer. Læs efter ord som væsentlig ændring eller ny version, for de kan betyde, at en ny test kan blive nødvendig før året er gået.

Læg testen, så rapporten aldrig falder for grænsen

Hvis I tester samme måned hvert år, og testen en dag bliver forsinket, er rapporten for gammel, før den nye er klar. Planlæg derfor med luft: læg den næste test, så den nye rapport er afleveret, før den gamle rammer kundens grænse, også selv om testeren eller jeres eget team bliver forsinket.

Se samtidig på de datoer, hvor kunderne plejer at bede om dokumentation. Fornyelser, kundens revision og årlige spørgeskemaer kan have faste tidspunkter. Ligger flere af dem samme sted på året, kan testen lægges lige før. → Et årshjul for sikkerhedstest

Rettelserne skal også med i regnestykket. Hvis kunden forventer at se, at alvorlige fund er håndteret, skal der være tid til det mellem testen og den dato, hvor rapporten skal sendes.

Mange kunder, flere måder at tælle på

Har I mange kunder med samme krav, regner de ikke nødvendigvis ens. Én tæller fra testperioden, en anden fra rapportens dato, og en tredje vil se en rapport, der er under et år gammel på kontraktens årsdag. Notér for hver kunde, hvordan der tælles, og hvornår kunden typisk spørger.

Med de oplysninger samlet kan I finde det tidspunkt på året, hvor flest kunder er dækket med mindst mulig risiko for huller. Den kunde, der tæller strengest, bestemmer i praksis den seneste dato for næste test. Hvis det tidspunkt passer dårligt med jeres releaseplan, er det bedre at opdage det nu end i den uge, hvor kunden spørger. → Flere kunder stiller forskellige krav

Releases mellem to test

Et SaaS-produkt står ikke stille et helt år. En rapport kan være under et år gammel og alligevel beskrive en version, kunden ikke længere bruger. Hvis kundens krav nævner væsentlige ændringer, bør I have en praksis for at vurdere, om en release kræver en ny test eller en afgrænset test af det nye.

Et nyt login, en ny rollemodel, et nyt modul eller en ny måde at adskille kundernes data på er typiske anledninger. Notér beslutningen, også når svaret er, at der ikke skal testes. Så kan I forklare kunden, hvorfor rapporten stadig er dækkende. → Meget er udgivet siden testen

Når rapporten er ved at blive for gammel

Det sker, at en kunde spørger, mens den nyeste rapport er tæt på grænsen, eller lige har passeret den. Så er et ærligt svar bedre end at sende rapporten uden kommentar. Det kan bestå af:

Den nuværende rapport · med testperiode og omfang.
Den næste test · med dato og navn på testeren.
Status på fund · hvad der er rettet og efterprøvet siden.
Ændringer · væsentlige ændringer i produktet siden testen.

Spørg kunden, om det kan dække behovet, indtil den nye rapport foreligger. Nogle kunder har en procedure for netop den situation, men det er kunden, der afgør, om den kan bruges. → Kontrakten skal fornyes

Et sådant svar virker bedst, når testen allerede er bestilt. En plan uden aftale med en tester er sværere for kunden at regne med. Har I endnu ikke bestilt, så gør det, før I svarer, eller skriv ærligt, at bestillingen er på vej, og hvornår den forventes på plads.

Det skal I lade være med

At gå ud fra rapportens dato · Kunden regner måske fra testperioden.
At teste uden luft i kalenderen · En forsinkelse giver en periode uden gyldig rapport.
At lade en efterprøvning forny hele rapporten · Den dækker kun de fund, den så på.
At ignorere releases · En rapport under et år kan stadig beskrive en gammel version.
At love en fast gyldighed · Kundens krav og ændringerne i produktet afgør sagen.

Hvad kan og ikke kan konkluderes

En rapport, der er under kundens grænse og beskriver den version, kunden bruger, kan opfylde et krav om alder. Med en fast plan for de næste test kan I svare ens hvert år.

Alderen alene siger ikke, om rapporten er dækkende. Hvis produktet har ændret sig væsentligt, kan kunden med rette spørge efter mere, selv om datoen er i orden. Den generelle forklaring om rapporters alder findes på penetrationtest.dk.

Tjekliste til kravet om et år

☐ Ved I, hvilken dato kunden regner fra?
☐ Står testperioden tydeligt i rapporten?
☐ Kender I kravets kilde, og om det nævner ændringer?
☐ Er næste test lagt med luft før grænsen?
☐ Er der tid til rettelser før dokumentationen sendes?
☐ Har I en praksis for at vurdere releases mellem to test?
☐ Har I et standardsvar, hvis rapporten er tæt på grænsen?

Kilder

PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.2 og 11.4.3 om penetrationstest mindst hver tolvte måned og efter væsentlige ændringer i infrastruktur eller applikation.

Senest gennemgået: oktober 2026.