Hvor ofte tester I? Sådan svarer I præcist på spørgsmålet

“Hvor ofte udføres penetrationstest af løsningen?” er et spørgsmål, et sikkerhedsspørgeskema kan indeholde, og svarmulighederne kan være faste: årligt, halvårligt, ved større ændringer eller aldrig. Det præcise svar hviler på jeres faktiske praksis, sådan som den har set ud og er planlagt, ikke på det tal, I tror, kunden helst vil se. Der findes ingen universel frekvens, som gælder for alle produkter, så svaret skal beskrive jeres egen rytme og det, der udløser en ekstra test.

Spørgsmålet ser ud til at handle om en kalender, men kunden vil reelt vide, om testen følger med produktet. Et produkt, der ændrer sig hver uge, og en test, der ligger halvandet år tilbage, giver kunden en anden oplevelse end samme produkt med en nylig test og en klar regel for, hvornår der testes igen.

Hvad kunden lægger i spørgsmålet

Kunden bruger frekvensen til at vurdere, hvor gammel den viden er, I har om produktets sikkerhed. Nogle kunder har en intern regel om, at leverandørers dokumentation skal være forholdsvis ny, og de læser jeres svar op imod den regel. Nogle kunder har i deres egne politikker hentet inspiration fra standarder med konkrete intervaller. → Kunden vil have en rapport, der er under et år gammel

Et eksempel på et sådant interval er PCI DSS for virksomheder, der behandler betalingskort. Ifølge krav 11.4.2 og 11.4.3, som Microsoft Learn gengiver dem, skal intern og ekstern penetrationstest udføres mindst én gang hver tolvte måned og efter enhver væsentlig opgradering eller ændring af infrastruktur eller applikation. Kravet gælder virksomheder inden for PCI DSS’s område, men formuleringen går igen i nogle kunders politikker, også hvor kortdata ikke er involveret.

Svar ud fra det, der faktisk er sket

Det mest troværdige svar beskriver jeres historik. Hvis produktet er testet i de seneste tre forår, så kan I svare årligt med god samvittighed. Hvis den seneste test er fra for to år siden, og en ny er planlagt, så er svaret ikke årligt, selv om det er hensigten. Skriv i stedet, hvornår den seneste test blev afsluttet, og hvornår den næste er planlagt.

Er I nye, og har I kun én test bag jer, så sig det. Skriv, at produktet blev testet på en bestemt dato, og at I har besluttet at teste fx årligt og ved større ændringer. Kunden kan så se både, hvad der er sket, og hvad I har forpligtet jer til. Undgå at vælge en hyppigere rytme i skemaet, end I har budget og kapacitet til. En rytme, I ikke kan holde, bliver et problem ved næste fornyelse, når kunden sammenligner svaret med datoen på den rapport, I sender.

Ændringer som udløser

En fast rytme fortæller kun halvdelen. Den anden halvdel er, hvad der får jer til at teste ud over rytmen. Det kan være en ny login-løsning, en ny måde at adskille kundernes data på, et nyt offentligt API eller en flytning til en anden hostingplatform. Beskriv de udløsende ændringer i svaret, så kunden ved, at en større ændring ikke venter til næste års test. → Ændringer, der kræver en ny test

Vær forsigtig med at skrive, at I tester “ved hver release”. Det lyder godt, men det er sjældent sandt for en manuel penetrationstest, og hvis det viser sig, at I kun mener automatiske test, har I svaret upræcist. → Test ved hver release eller én gang om året?

Hold rytmen og den løbende test adskilt

Det britiske NCSC skriver, at der ikke sjældent går et år eller mere mellem to penetrationstest, og at en planlagt test ikke betyder, at den almindelige løbende test skal stoppe. Den skelnen er nyttig i skemaet. Frekvensen for den manuelle penetrationstest er én oplysning. Automatiske scanninger i udviklingen og løbende sårbarhedsscanning af driften er en anden. Svar på dem hver for sig, også hvis skemaet stiller dem i samme spørgsmål. → Pipelinen og den manuelle pentest

Når de faste svarmuligheder ikke passer

Mange skemaer har en rullemenu med årligt, halvårligt og kvartalsvis. Passer ingen af dem, så vælg den, der er nærmest uden at være bedre end virkeligheden, og brug kommentarfeltet til at forklare. Et eksempel: I vælger årligt, og skriver i kommentaren, at seneste test blev afsluttet i marts, at næste er bestilt til samme måned næste år, og at et nyt modul til integrationer bliver testet særskilt før lancering.

Hvis skemaet kun tillader et valg uden kommentar, så skriv en kort mail til kunden med forklaringen. Det er bedre at gøre opmærksom på det end at lade et upræcist valg stå. Gem mailen sammen med skemaet, så forklaringen kan findes igen, når kunden læser svaret næste år.

Hold løftet over tid

Når I har skrevet årligt i et skema, er det et løfte. Hvis en kunde senere beder om den nyeste rapport, skal den passe til det, I har sagt. Læg derfor næste test i kalenderen, når den forrige er afsluttet, og lad en person have ansvaret for, at den bliver bestilt i god tid. → Et årshjul for sikkerhedstest

Står frekvensen i en kontrakt, er der mere på spil end i et skema. Sørg for, at den, der har ansvaret for testen, kender alle de kontrakter, der nævner et interval. → Kontrakten kræver årlig test

Det skal I lade være med

Svare årligt, fordi det er det, kunden forventer · svar med det, I faktisk gør.
Skrive ved hver release, når I mener automatiske scanninger · det er ikke en penetrationstest.
Udelade de ændringer, der udløser en ekstra test · de viser, at testen følger produktet.
Lade et upræcist valg i rullemenuen stå uden forklaring · brug kommentaren eller en mail.
Glemme at bestille næste test i tide · så holder svaret ikke.

Hvad kan og ikke kan konkluderes

Et præcist svar om frekvens viser, hvor gammel jeres viden om produktets sikkerhed højst bliver, og hvad der får jer til at teste igen. Det siger ikke noget om, hvor grundig hver test er, eller hvad den dækker. Et kort interval med et snævert omfang kan give kunden mindre end et længere interval med et bredt omfang.

Tjekliste til svaret om frekvens

☐ Stemmer svaret med datoerne for jeres faktiske test?
☐ Er næste test planlagt og nævnt med tidspunkt?
☐ Er de ændringer, der udløser en ekstra test, beskrevet?
☐ Er manuel penetrationstest og automatiske scanninger beskrevet hver for sig?
☐ Er et upræcist valg i rullemenuen forklaret?
☐ Har en person ansvaret for at bestille næste test i god tid?

Kilder

PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.2 og 11.4.3 om intern og ekstern penetrationstest mindst hver tolvte måned og efter væsentlige ændringer.
NCSC (UK): Penetration testing: der går ikke sjældent et år eller mere mellem to test, og den løbende test skal fortsætte.

Senest gennemgået: oktober 2026.