Et testkrav i en leverandøraftale kan være skrevet, så ingen af parterne bagefter ved, om det er opfyldt. “Leverandøren skal gennemføre årlige penetrationstest” lyder klart, men siger intet om, hvad der skal testes, af hvem, eller hvad I får at se. Et krav, der kan opfyldes, hviler på jeres egen risikovurdering af leverancen og besvarer seks spørgsmål: hvilken del af leverancen, hvilken testtype, hvem tester, hvad der afleveres, med hvilken hyppighed, og hvad I selv må teste.
Processen omkring leverandørstyringen, med register og risikovurdering, behandles ikke her. Det gør selve formuleringen af testkravet. Teksten er ikke juridisk rådgivning.
Grundlaget for at stille kravet
NIS 2-lovens § 6, stk. 1, nr. 4, pålægger jer foranstaltninger for forsyningskædesikkerhed, og nr. 6 handler om politikker og procedurer til vurdering af foranstaltningernes effektivitet. Bemærkningerne til lovforslaget siger om nr. 4, at enhederne navnlig bør tilskyndes til at indarbejde foranstaltninger til styring af cybersikkerhedsrisici i kontrakterne med deres direkte leverandører. Om nr. 6 nævner de vurdering af behovet for tekniske test, fx sårbarhedsscanninger eller penetrationstest.
For de digitale udbydere, gennemførelsesforordning (EU) 2024/2690 gælder for, er det mere præcist. Bilagets punkt 5.1.4, litra a, nævner cybersikkerhedskrav til leverandøren i kontrakten, og punkt 6.1.2, litra f, nævner metoder til at validere, at det leverede opfylder sikkerhedskravene, og dokumentation for resultatet. Andre kunder kan bruge punkterne som model. → Forordningens kontraktpunkter
Afgræns den del af leverancen, der skal testes
Et krav om at teste “leverandørens systemer” kan læses som alt fra et enkelt website til hele virksomheden. Skriv i stedet den del, jeres risikovurdering peger på: fjernadgangen, leverandørens support bruger hos jer, integrationen til jeres systemer, den portal, jeres medarbejdere logger ind på, eller det miljø, hvor jeres data behandles.
SAMSIK’s vejledning om foranstaltninger, afsnit 4, anbefaler en risikobaseret tilgang, hvor kravene står i forhold til den konkrete leverances betydning, og vejledningen om anvendelsesområdet, afsnit 8, siger, at I ikke skal stille præcis de samme krav, som I selv er underlagt. Et smalt krav om det, I er afhængige af, er lettere at opfylde og lettere at kontrollere end et bredt krav om alt. → Forholdsmæssige krav
Testtype og hyppighed efter risiko
Skriv, hvilken slags afprøvning I forventer. SAMSIK’s afsnit 6.b nævner bl.a. sårbarhedsscanning, penetrationstest, konfigurationsgennemgang, kodegennemgang og test af adgangskontroller. Et krav om penetrationstest af en simpel informationsside kan være mere, end risikoen tilsiger, mens en scanning alene kan være for lidt for en fjernadgang med administratorrettigheder.
Hyppigheden står ikke som et tal i loven. Forordningens punkt 6.5.2, litra a, knytter behov, omfang, hyppighed og type til risikovurderingen, og SAMSIK nævner test med planlagte mellemrum og ved større ændringer eller væsentlige hændelser. Skriv derfor både et interval, I kan begrunde, og de begivenheder, der udløser en ny test, fx en ny version af den del, I bruger, et skift af hostingpartner eller en hændelse, der har berørt leverancen. → Testfrekvens efter risiko
Hvem tester, og hvad I får at se
Vil I have en tester, der er uafhængig af leverandørens udviklere og drift, så skriv det, og skriv, hvordan uafhængigheden skal fremgå af dokumentationen. SAMSIK nævner, at test kan udføres af enheden selv eller af en tredjepart, så kravet er jeres valg og bør have en begrundelse. → Krav om uafhængig tredjepart
Beskriv afleveringen lige så præcist. Punkt 6.5.2, litra c, kan bruges som skabelon: testens art, afgrænsning, periode og resultat, og for hvert fund både hvor alvorligt det er, og hvad der gøres ved det. Tag stilling til formen: et resumé med statusliste, en fuld rapport eller en erklæring fra testeren. Overvej, hvad I selv har brug for at opbevare. En fuld rapport om leverandørens svagheder er følsom, også hos jer, og et resumé kan være nok, hvis I kan bede om at se uddrag, når et fund rammer jeres del. Aftal også en frist for, hvornår I får status på alvorlige fund. Punkt 5.1.4, litra f, nævner leverandørens forpligtelse til at håndtere sårbarheder, der udgør en risiko for jer.
Når I selv vil teste
Punkt 5.1.4, litra e, nævner retten til audit eller retten til at modtage auditrapporter. Vil I selv teste leverandørens løsning, skal aftalen sige, hvad I må teste, hvem der giver tilladelsen, hvordan testen varsles, og hvad der sker med fundene. Husk, at leverandøren ikke kan give jer lov til at teste systemer, leverandøren ikke selv ejer, fx en cloudplatform eller en hostingpartners net. → Kunden vil selv teste
Et tænkt eksempel på en formulering, der kan opfyldes: Leverandøren lader supportadgangen til kundens installation og integrationen til kundens lønsystem penetrationsteste af en tester uden for leverandørens udviklings- og driftsteam, med det interval, parterne har aftalt i bilaget, og efter væsentlige ændringer i de to dele. Kunden modtager et resumé med type, omfang, tid, fund og status senest et aftalt antal uger efter testen. Kunden kan efter skriftlig varsling selv teste de samme dele inden for de rammer, ejeren af platformen tillader.
Det skal I lade være med
- At kopiere jeres egen lovtekst ind i aftalen · kravet skal passe til leverancen, ikke til jeres pligter.
- At skrive årlig uden at sige, hvad der testes · så er kravet opfyldt af en test af hvad som helst.
- At kræve testtypen uden en begrundelse · leverandøren kan med rette spørge, hvilken risiko den skal belyse.
- At glemme afleveringen · uden en aftalt form ved ingen, hvad der er nok.
- At give jer selv ret til at teste andres systemer · tilladelsen ligger hos ejeren. → Når kunden vil have testet noget, leverandøren ikke ejer
Hvad kan og ikke kan konkluderes
Et præcist testkrav gør det muligt at afgøre, om leverandøren har leveret det aftalte, og giver jer et grundlag at vurdere dokumentationen imod. Det kan ikke erstatte jeres egen risikovurdering af leverancen, og et opfyldt testkrav betyder ikke, at leverancen er uden svagheder. Hvordan ledelsen kan se på sikkerhedstest i kontrakten med en IT-leverandør uden for NIS2, er beskrevet på sikkerhedstesten.dk.
Tjekliste til kravbilaget
- ☐ Er den del af leverancen, der skal testes, beskrevet med jeres egne betegnelser?
- ☐ Er testtypen valgt ud fra en risiko, I kan forklare?
- ☐ Er der både et interval og de begivenheder, der udløser en ny test?
- ☐ Står det, om testeren skal være uafhængig, og hvordan det dokumenteres?
- ☐ Er form og frist for afleveringen aftalt, også for status på alvorlige fund?
- ☐ Er det aftalt, hvad I selv må teste, og hvem der giver tilladelsen?
Når dokumentationen kommer, er kravbilaget jeres målestok. → Sådan vurderer NIS2-kunden testdokumentationen
Kilder
- NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 4 og 6.
- Lovforslag L 141 (folketingsåret 2024-25), som fremsat: bemærkningerne til § 6, stk. 1, nr. 4 og 6.
- Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.4, litra a, e og f, 6.1.2, litra f, og 6.5.2, litra a og c.
- SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om risikobaserede krav til leverandører og afsnit 6.b om tekniske test.
- SAMSIK, vejledning om anvendelsesområdet (maj 2025): afsnit 8 om krav til leverandører.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om NIS2 og penetrationstest
Læs også: Pligt til at håndtere sårbarheder i leverandøraftalen · Kundens frister for rettelser
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
