Hvem bestemmer, hvor ofte vi tester?

Hvor ofte virksomheden skal teste sin sikkerhed, er ikke et teknisk spørgsmål, som IT eller testeren kan afgøre. Det er en ledelsesbeslutning, der bygger på tre forhold: hvor meget virksomheden ændrer sig, hvilke krav kunder, standarder og aftaler stiller, og hvor stor en risiko ledelsen vil leve med mellem to test. Der findes ingen fast hyppighed, der passer alle, og den, der lover en, svarer på et andet spørgsmål end jeres.

Det betyder ikke, at IT og testeren ikke har noget at bidrage med. De kan fortælle, hvad der er ændret, og hvor svaghederne kan opstå. Men valget mellem at teste oftere og at bruge pengene på noget andet er en prioritering, og den hører til i ledelsen.

Hvorfor hyppigheden ikke er IT’s beslutning

Når hyppigheden overlades til IT, kan den blive bestemt af budgettet eller af vane. Testen kommer, når der er penge tilbage, eller fordi det er tid igen. Ingen af delene har nødvendigvis noget at gøre med, hvornår virksomheden har brug for et nyt billede.

Hyppigheden er også et udtryk for, hvor meget usikkerhed ledelsen accepterer. Jo længere mellem to test, jo længere tid kan en svaghed eksistere, uden at nogen udefra har set efter. Den britiske myndighed NCSC skriver i sin vejledning om penetrationstest, at der kan gå lang tid mellem to test, og at svagheder derfor kan eksistere længe uden at blive opdaget, hvis testen er den eneste kontrol. Det er en vurdering, ledelsen skal tage stilling til, ikke en teknisk detalje. → Risikovillighed

Hvad der bør styre hyppigheden

Tre forhold bør veje tungest, når ledelsen fastlægger, hvor ofte der testes.

Ændringer · nye systemer, nye leverandører, nye digitale kanaler og vækst gør det seneste billede forældet hurtigere. → Når virksomheden vokser hurtigere end sikkerheden
Krav udefra · kunder, aftaler og standarder kan stille krav om test med bestemte mellemrum.
Hvad der står på spil · systemer med kundedata, betalinger eller kritisk drift fortjener tættere opmærksomhed end andre.

NCSC anbefaler i sin vejledning om ledelse af cyberrisici, at bestyrelsen sikrer sig, at risikovurderinger foretages regelmæssigt og tager højde for ændringer i organisationen, teknologien, reguleringen og trusselsbilledet. Vejledningen er britisk og frivillig, men den peger på det centrale: hyppigheden bør følge ændringerne, ikke kalenderen alene.

Når kravet kommer udefra

Nogle virksomheder har ikke frit valg. Kunder kan i kontrakter kræve, at der testes med bestemte mellemrum. Virksomheder, der håndterer betalingskort, skal forholde sig til betalingskortindustriens standard PCI DSS, hvor krav 11 handler om regelmæssig test af sikkerheden, og hvor penetrationstest både skal ske med faste mellemrum og efter væsentlige ændringer. Det præcise indhold afhænger af virksomhedens situation og bør afklares med den, der stiller kravet.

Er I i tvivl om, hvad en kunde egentlig mener med sit krav, så spørg. Et krav om regelmæssig test kan dække over meget forskellige forventninger til omfang og dokumentation.

Et krav udefra sætter et minimum, ikke et mål. Det fortæller, hvor ofte virksomheden mindst skal teste for at opfylde aftalen, men ikke om det er nok til at beskytte det, der er vigtigt for virksomheden selv. → Kundekrav eller egne behov?

Fast rytme og begivenheder

En mulighed er at kombinere to ting: en fast rytme, der sikrer, at testen ikke bliver glemt, og test ved særlige begivenheder som en ny webshop, et leverandørskifte eller en større opdatering. Den faste rytme giver forudsigelighed i budgettet. Begivenhederne sikrer, at testen følger forretningen.

Kombinationen kræver, at nogen holder øje med, hvornår en begivenhed er stor nok til at udløse en test. Det er en opgave for den, der ejer sikkerhedstesten i ledelsen. → Hvem i ledelsen skal eje sikkerhedstesten?

Hvordan en fast test holdes relevant år efter år, og hvordan hyppigheden afstemmes med de enkelte systemer, er beskrevet på penetrationtest.dk. Ledelsens del er at beslutte princippet og sørge for, at det bliver fulgt.

Hvad en hyppighed koster, og hvad den sparer

Hver test koster penge og tid fra IT og leverandører, og hver rettelse koster mere. Derfor er det fristende at strække intervallet. Men omkostningen ved at teste sjældnere er bare mindre synlig. Den viser sig som en længere periode, hvor ingen udefra har set efter, og som en større bunke fund, når testen endelig kommer, fordi ændringerne har hobet sig op.

Ledelsen kan ikke regne sig frem til den rigtige hyppighed, men den kan stille de rigtige spørgsmål. Hvor stor en del af virksomhedens systemer er ændret siden sidste test? Hvor lang tid gik der fra sidste rapport, til de alvorlige fund var rettet? Hvis rettelserne tog lang tid, giver det ikke mening at teste oftere, før der er kapacitet til at følge op. Hyppigheden skal passe til virksomhedens evne til at bruge resultatet. Hvordan omfanget påvirker prisen, kan I læse om under pris og tilbud.

Skriv beslutningen ned

En hyppighed, der kun findes i hovedet på IT-chefen, forsvinder, når IT-chefen skifter job, eller når budgettet strammes. Skriv derfor beslutningen ned: hvor ofte der testes som udgangspunkt, hvilke begivenheder der udløser en ekstra test, og hvem der har ansvaret for at holde øje. Tag beslutningen op igen, når strategien gennemgås, eller når virksomheden ændrer sig væsentligt.

Når hyppigheden er besluttet, bliver det også lettere at budgettere. Testen kan stå som en fast post i stedet for at skulle kæmpe om pengene hver gang. → Sikkerhedstest som fast budgetpost · → Flerårig testplan

Det skal I lade være med

At overlade hyppigheden til IT alene · det er en prioritering af risiko og penge.
At bruge et kundekrav som eneste målestok · det sætter et minimum, ikke et mål.
At teste efter kalenderen og overse ændringerne · et nyt system kan gøre det seneste billede forældet.
At tro på en universel hyppighed · det, der passer en anden virksomhed, passer ikke nødvendigvis jeres.
At lade beslutningen være uskreven · den forsvinder med den, der husker den.

Hvad kan og ikke kan konkluderes

En fastlagt hyppighed sikrer, at virksomheden jævnligt får et nyt billede af de undersøgte dele. Den kan ikke sikre, at der ikke opstår svagheder mellem to test, og den erstatter ikke den daglige drift og overvågning af sikkerheden. Hyppigheden er en del af ledelsens risikostyring, ikke en garanti. → Fra engangstest til fast praksis

Tjekliste til beslutningen om hyppighed

☐ Er det ledelsen, der har besluttet, hvor ofte der testes?
☐ Kender vi de krav, kunder, aftaler og standarder stiller?
☐ Er det aftalt, hvilke ændringer der udløser en ekstra test?
☐ Er der en ansvarlig, der holder øje med ændringerne?
☐ Er beslutningen skrevet ned og knyttet til budgettet?
☐ Er det aftalt, hvornår beslutningen tages op igen?

Kilder

NCSC (UK), Penetration testing: at der kan gå lang tid mellem to test, og at svagheder kan eksistere længe uden at blive opdaget.
NCSC og UK Government, Cyber Governance Code of Practice: princip A om regelmæssige risikovurderinger, der afspejler ændringer.
PCI DSS krav 11 (Microsoft Learn): krav om regelmæssig test af sikkerheden for virksomheder omfattet af PCI DSS.

Senest gennemgået: oktober 2026.