Kunden vil se jeres testpolitik: hvad en politik for sikkerhedstest indeholder

Når kunden beder om “jeres politik for sikkerhedstest”, vil kunden se, at testene ikke sker tilfældigt, men efter en fastlagt ramme. Svaret hviler især på punkt 6.5 i bilaget til gennemførelsesforordning 2024/2690, som kræver en politik og procedurer for sikkerhedstest hos bestemte digitale udbydere, og på SAMSIK’s vejledning om foranstaltninger, som beskriver det samme for alle enheder omfattet af NIS 2-loven.

Kort sagt er en testpolitik et kort dokument, der siger, hvorfor, hvad, hvor ofte og hvordan I tester, hvem der må teste, og hvad der sker med fundene. Er I ikke selv omfattet, er politikken ikke en lovpligt for jer. Den er det dokument, der gør jeres testrapporter forståelige for kunden.

Hvorfor kunden spørger efter en politik og ikke kun en rapport

En rapport viser én test. Kunden skal vurdere, om jeres leverance også er under kontrol året efter, og om næste test kommer af sig selv. Det er det, en politik kan vise. SAMSIK’s vejledning lægger op til, at enheden ud fra en risikovurdering definerer behov og frekvens for forskellige typer test, og at det sker løbende. En kunde, der selv skal leve op til det, leder efter det samme hos sine vigtige leverandører.

Politikken skal ikke være lang. Kunden læser den for at finde svar på nogle få spørgsmål, og et dokument på få sider, der svarer klart, er mere nyttigt end en håndbog.

Hvad forordningen kræver, og hvem den gælder for

Forordning 2024/2690 gælder direkte for blandt andet cloud, datacentre, MSP og MSSP. For dem siger bilagets punkt 6.5.1, at enheden skal fastlægge, gennemføre og anvende en politik og procedurer for sikkerhedstest. Punkt 6.5.2 lister fire ting, enheden skal gøre:

Litra a · fastlægge behov, omfang, hyppighed og type af test ud fra risikovurderingen.
Litra b · teste efter en dokumenteret metode, der dækker de komponenter, risikoanalysen har udpeget.
Litra c · dokumentere testens type, omfang, tidspunkt og resultater, herunder vurdering af alvor og afhjælpning for hvert fund.
Litra d · afhjælpe kritiske fund.

Punkt 6.5.3 tilføjer, at politikken skal gennemgås med planlagte mellemrum. Er I selv en af de udbydere, forordningen gælder for, er punkterne bindende for jer. Ellers er de en god skabelon, fordi kunder kan skrive deres krav ud fra samme ordlyd. → Forordning 2024/2690

Punkterne i en testpolitik, kunden kan genkende

En politik, der svarer på kundens spørgsmål, kan rumme disse afsnit:

Formål og omfang · hvilke systemer og leverancer politikken gælder for, og hvilke der er udeladt.
Grundlag for hyppighed · hvordan risikovurderingen bestemmer, hvor ofte hver del testes. → Testfrekvens efter risiko
Testtyper · hvilke typer I bruger, fx sårbarhedsscanning, penetrationstest og konfigurationsgennemgang, og hvornår hver bruges.
Udløsende hændelser · hvilke ændringer eller hændelser der fører til en ekstra test.
Hvem der tester · egne folk, en ekstern testleverandør eller begge, og hvordan de godkendes.
Metode · at der testes efter en beskrevet metode, og hvor den er beskrevet. → Dokumenteret testmetode
Dokumentation · hvad hver test skal efterlade af oplysninger. → Fire oplysninger om testen
Fund og afhjælpning · hvordan fund vurderes, hvem der ejer rettelsen, og hvem der kan acceptere en restrisiko.
Fortrolighed · hvem der må se resultaterne, også hos kunderne.
Gennemgang · hvornår politikken selv tages op igen.

ENISA’s tekniske vejledning, som ikke er bindende, nævner som eksempler på indhold blandt andet godkendte testparter, interne eller eksterne, fortrolighedsniveauer og målene med testene. Den foreslår også at gennemgå politikken mindst hvert andet år. Det er en anbefaling fra ENISA og ikke et krav i forordningen.

Et tænkt eksempel

En leverandør af adgangskontrol til en række produktionsvirksomheder får spørgsmålet i et spørgeskema: “Beskriv jeres politik for sikkerhedstest.” Leverandøren har en penetrationstest af styringsportalen fra sidste år, men ingen skreven politik. Svaret bliver en kort politik på to sider: portalen og fjernadgangen testes efter risiko, mindst ved større ændringer, af en ekstern tester, efter en beskrevet metode, og kritiske fund rettes før næste release. Rapporten fra sidste år vedlægges som det første eksempel på politikken i brug.

Bemærk rækkefølgen i eksemplet. Politikken er skrevet ud fra det, leverandøren allerede gør, og rapporten viser, at det er sandt. Hvis kunden senere beder om noget, politikken ikke dækker, fx test af en ny integration, er det let at se, om det kræver en ændring af politikken eller blot en ekstra test inden for den. Det gør også næste års svar kortere, fordi kunden kan nøjes med at spørge til ændringer siden sidst.

Politikken skal passe til det, I faktisk gør

Det er fristende at skrive en ambitiøs politik for at tilfredsstille kunden. Men kunden kan bede om at se, at politikken følges, og en politik, der lover kvartalsvise test, som aldrig bliver gennemført, er værre end en beskeden politik, der overholdes. Skriv hyppigheden, så den følger jeres risikovurdering og jeres budget, og forklar, hvad der udløser en ekstra test.

Politikken kan også vise, hvordan test over flere år hænger sammen, så kunden ser forløbet frem for enkeltstående rapporter. → Testprogram over flere år

Politikker og styring som helhed, fx informationssikkerhedspolitik og ledelsens godkendelse, ligger uden for dette site. Her handler det kun om den del, der angår test.

Det skal I lade være med

At skrive en politik, I ikke kan følge · kunden kan spørge efter beviset for, at den bruges.
At kopiere kundens kravtekst ind som jeres politik · politikken skal beskrive jeres egen praksis.
At udelade, hvem der må teste · kunden kan spørge, om en ekstern part er med.
At glemme fundene · en politik uden afsnit om afhjælpning svarer kun på halvdelen. → Kritiske fund skal afhjælpes
At lægge tekniske detaljer om jeres systemer i politikken · den bliver delt med kunder og skal kunne læses af flere.

Hvad kan og ikke kan konkluderes

En testpolitik viser, at I har en ramme for, hvornår og hvordan I tester, og at fund bliver fulgt op. Sammen med testrapporterne kan den give kunden et billede af en praksis over tid. Politikken alene viser ikke, at testene er gennemført, eller at systemerne er sikre. Om den opfylder kundens krav, afhænger af kundens aftale og risikovurdering. Teksten er ikke juridisk rådgivning.

Tjekliste til jeres testpolitik

☐ Står det, hvilke systemer og leverancer politikken dækker?
☐ Er hyppigheden begrundet i en risikovurdering?
☐ Er det beskrevet, hvad der udløser en ekstra test?
☐ Er det klart, hvem der må teste, og hvordan de godkendes?
☐ Er dokumentation og afhjælpning af fund beskrevet?
☐ Er der en dato for næste gennemgang af politikken?
☐ Kan politikken deles med kunden uden fortrolige detaljer?

Kilder

Gennemførelsesforordning (EU) 2024/2690: bilaget, punkt 6.5.1 til 6.5.3 om politik og procedurer for sikkerhedstest.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 6.a og 6.b om vurdering af effektivitet og tekniske tests.
ENISA, NIS2 Technical Implementation Guidance (juni 2025): ikke bindende eksempler på indhold i en testpolitik og forslag til gennemgang.

Senest gennemgået: oktober 2026.