Spørgsmålet om, hvor ofte den eksterne test skal gentages, får sjældent et enkelt svar, fordi der ikke findes én regel, der gælder alle virksomheder. Det bedste mål er, hvor meget internetsiden ændrer sig: nye tjenester, ny fjernadgang, flytning til cloud, skift af driftsleverandør eller ombygning af firewallen. Nogle virksomheder har desuden krav fra en standard eller fra kunder, der fastlægger et minimum. IT-afdelingens opgave er at kende begge dele og at bygge en rutine, der fanger ændringerne, før de bliver gamle.
Det generelle spørgsmål om testfrekvens for køberen er beskrevet på penetrationtest.dk. Her handler det om, hvordan driften selv kan se, hvornår internetsiden har flyttet sig nok til en ny test.
Krav, der sætter et minimum
Nogle virksomheder har et eksternt krav, der afgør intervallet. Det tydeligste eksempel er PCI DSS for miljøer med betalingskortdata. Kravet, som det er gengivet af Microsoft Learn, angiver ekstern penetrationstest mindst hver tolvte måned og efter enhver væsentlig opgradering eller ændring af infrastruktur eller applikation.
Kunder og samarbejdspartnere kan også stille krav i kontrakter, og nogle sikkerhedsspørgeskemaer spørger til datoen for seneste test. Læs de konkrete formuleringer. Et krav om en årlig test er et minimum, ikke et svar på, om internetsiden har ændret sig mere end det.
Har I ingen af den slags krav, er intervallet jeres eget valg. NCSC i Storbritannien anbefaler ikke en fast frekvens, men peger på, at der ofte går et år eller mere mellem test, og at sikkerheden bør afprøves løbende i mellemtiden.
Ændringer, der flytter internetsiden
For driften er det mest brugbare spørgsmål ikke, hvor lang tid der er gået, men hvad der er sket. Nogle ændringer har særlig stor betydning for det, der kan nås fra internettet.
- Ny eller ændret fjernadgang · en ny VPN-løsning, en ny portal eller nye måder for leverandører at logge ind på.
- Ombygning af firewall eller net · nyt udstyr, nye regelsæt eller samling af flere lokationer.
- Flytning til cloud · tjenester, der før stod bag firewallen, får nu deres egen adgang fra internettet.
- Nye webløsninger · kundeportaler, bookingsystemer eller integrationer, der åbnes for andre.
- Skift af driftsleverandør · ny leverandør, nye standardopsætninger og nye adgange.
- Opkøb og fusioner · andre virksomheders domæner og systemer bliver en del af jeres.
Den slags ændringer er værd at teste, når de er sat i drift, også selv om den seneste test ikke er ret gammel. → VPN og fjernadgangsportaler i dybden
Mindre ændringer, som en opdatering af et enkelt system eller et nyt certifikat, udløser sjældent en ny test. De bør i stedet fanges af den løbende kontrol.
Byg et flag ind i ændringsstyringen
Den mest pålidelige måde at opdage, at internetsiden har flyttet sig, er at spørge, hver gang en ændring registreres. Tilføj et enkelt spørgsmål til jeres ændringsstyring: ændrer dette, hvad der kan nås fra internettet? Ja-svarene samles op og gennemgås med jævne mellemrum.
Når der er samlet nok ændringer, eller en enkelt er stor nok, er det tid til at overveje en test. Det giver et grundlag for beslutningen, der bygger på driftens egne data og ikke på en dato i kalenderen. → Testen i jeres ændringsstyring
Sammenhold også flagene med jeres oversigt over internetvendte systemer. Er oversigten blevet væsentligt længere siden sidste test, er det et tegn i sig selv. → Overblik over jeres internetvendte systemer
Scanning udfylder tiden mellem testene
En penetrationstest er en undersøgelse på et bestemt tidspunkt. Mellem testene kan en løbende scanning af jeres egne adresser fange nye åbne tjenester, udløbne certifikater og kendte sårbarheder, så snart de opstår. Scanningen tænker ikke som en tester og vurderer ikke sammenhænge, men den reagerer hurtigt på ændringer.
Brug resultaterne som input til beslutningen om næste test. Hvis scanningen gentagne gange finder nye forhold, er internetsiden i bevægelse, og en test kan være på sin plads tidligere end planlagt. → Sårbarhedsscanning mellem testene
Fuld test eller afgrænset test
Ikke alle ændringer kræver en test af hele internetsiden. Efter indførelsen af en ny fjernadgangsløsning kan en afgrænset test af netop den være nok, mens en flytning af mange tjenester til cloud kan begrunde en bredere test.
Skeln derfor mellem den tilbagevendende test af hele internetsiden og de afgrænsede test, der følger med store ændringer. Den tilbagevendende test giver et samlet billede og fanger det, ingen har registreret. De afgrænsede test sikrer, at store ændringer ikke venter for længe på at blive afprøvet.
Når I beskriver en afgrænset test, så skriv tydeligt, hvilken ændring den knytter sig til, og hvad der ikke er med. Ellers kan en rapport om den nye fjernadgang senere blive læst som en vurdering af hele internetsiden. Hold desuden en simpel oversigt over, hvornår hver del af internetsiden sidst blev testet. Så kan I se, om en del er blevet overset i flere omgange, fordi opmærksomheden hele tiden gik til det nye.
Læg testen ind i driftens kalender
En test, der ligger midt i en stor migrering eller lige før en ferieperiode, giver mindre værdi. Planlæg den, så der er folk til at følge den, og så der er tid til at rette bagefter. Er en stor ændring på vej, kan det være bedre at vente med testen, til ændringen er gennemført, så testen rammer det, der faktisk skal køre. → Rapporten i næste års driftsplan
Det skal I lade være med
- At lade kalenderen alene bestemme. Store ændringer kan ikke vente et helt interval.
- At tolke et minimumskrav som tilstrækkeligt. Kravet siger intet om jeres ændringstakt.
- At teste midt i en ombygning. Så tester I et øjebliksbillede, der snart er forældet.
- At bruge scanning som erstatning for test. Den fanger ændringer, ikke sammenhænge.
- At glemme ændringer uden for IT. Andre afdelinger åbner også tjenester mod internettet.
Hvad kan og ikke kan konkluderes
En fast rutine for at vurdere ændringer giver et begrundet svar på, hvornår næste test er relevant. Den kan ikke sikre, at alle ændringer bliver registreret, og den kan ikke forudsige nye sårbarheder i udstyr, der ikke er ændret. Et interval, der opfylder et krav, viser, at kravet er overholdt, ikke at internetsiden er undersøgt tilstrækkeligt.
Tjekliste til næste beslutning
- ☐ Kender I de krav fra standarder og kunder, der sætter et minimum?
- ☐ Spørger ændringsstyringen, om en ændring påvirker internetsiden?
- ☐ Er de markerede ændringer gennemgået siden sidste test?
- ☐ Kører der løbende scanning af jeres egne adresser?
- ☐ Er det besluttet, om næste test skal være fuld eller afgrænset?
- ☐ Passer tidspunktet med driftens kalender og tid til rettelser?
Kilder
- Microsoft Learn: PCI DSS krav 11: krav 11.4.3 om ekstern penetrationstest mindst hver tolvte måned og efter væsentlige ændringer.
- NCSC: Penetration testing: ingen fast frekvens, løbende afprøvning mellem test.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Typiske fund i en ekstern test · Ekstern penetrationstest i praksis
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
