NIS2-pentest

Gennemførelsesforordning 2024/2690: hvem den gælder for, og hvorfor leverandører møder den

Gennemførelsesforordning 2024/2690: hvem den gælder for, og hvorfor leverandører møder den

Nogle leverandører møder formuleringer som “dokumenteret testmetode” eller “type, omfang, tid og resultater” i et kravbilag og kan ikke finde dem i den danske NIS 2-lov. De kan stamme fra Kommissionens gennemførelsesforordning (EU) 2024/2690. Svaret på titlens spørgsmål hviler på forordningens artikel 1: den gælder kun en afgrænset gruppe af digitale udbydere, men dens bilag er så konkret, at andre kunder låner ordene, når de skriver krav til leverandører.

For jer betyder det, at I skal skelne mellem to situationer. Enten er I selv en af de udbydere, forordningen gælder for, og så er teksten bindende for jer. Eller også bruger kunden forordningens ord som skabelon, og så er det aftalen, der binder. Teksten er ikke juridisk rådgivning.

Hvem forordningen gælder for

Artikel 1 opregner de “relevante enheder”: DNS-tjenesteudbydere, topdomænenavneadministratorer og udbydere af cloudcomputingtjenester, datacentertjenester, indholdsleveringsnetværk, administrerede tjenester, administrerede sikkerhedstjenester, onlinemarkedspladser, onlinesøgemaskiner, platforme for sociale netværkstjenester og tillidstjenester.

Forordningen er vedtaget med hjemmel i NIS2-direktivets artikel 21, stk. 5, som pålagde Kommissionen at fastsætte tekniske og metodologiske krav netop for disse typer udbydere. Som forordning gælder den umiddelbart i alle medlemsstater uden en dansk gennemførelseslov. SAMSIK’s vejledning om foranstaltninger forklarer det samme i en fodnote og nævner forordningen som den, der er vedtaget for digitale udbydere.

En kommune, en vandforsyning eller en fødevareproducent er altså ikke omfattet af forordningen, selv om de er omfattet af NIS 2-loven. For dem er det lovens § 6 og myndighedernes vejledninger, der gælder. → Direktiv, lov og forordning: hvilken tekst gælder for jeres kunde?

Når I selv er en af de relevante enheder

Driver I hosting, cloud eller administrerede IT-tjenester for andre virksomheder, kan I selv høre til gruppen. Så er bilagets krav jeres egne, også punkt 6.5 om sikkerhedstest, og ikke kun noget, en kunde beder om. Det ændrer samtalen med kunden: I tester ikke for at tilfredsstille et kravbilag, men fordi I selv skal kunne dokumentere det over for jeres egen myndighed.

Om jeres ydelse falder ind under definitionerne, er en vurdering, I skal lave selv eller med rådgivning. → Forordningens krav om sikkerhedstest gælder MSP’en direkte

Hvorfor andre kunder låner ordene

Forordningens bilag er langt mere detaljeret end lovteksten. Hvor NIS 2-lovens § 6, stk. 1, nr. 6, kun nævner politikker og procedurer til vurdering af effektiviteten, siger bilagets punkt 6.5.2 konkret, at behovet for, omfanget af, hyppigheden af og typen af sikkerhedstest fastlægges ud fra risikovurderingen, at test følger en dokumenteret metode, og at type, omfang, tid og resultater dokumenteres.

En kunde, der skal skrive et kravbilag, finder her et færdigt sprog. Det samme gælder punkt 5.1.4 om, hvad kontrakter med leverandører kan indeholde: blandt andet cybersikkerhedskrav, pligt til at underrette om hændelser uden unødig forsinkelse, ret til audit eller til at modtage auditrapporter, pligt til at håndtere sårbarheder og krav til underleverandører. Når I ser de punkter i et udkast, er kilden sandsynligvis forordningen, også selv om kunden ikke er bundet af den.

Det, ordene betyder i praksis for jer

Når kunden bruger forordningens formuleringer, kan I læse dem som en tjekliste over, hvad kunden forventer at kunne se:

  • Dokumenteret testmetode · en beskrivelse af, hvordan testen er tilrettelagt, så den kan gentages og forstås af andre.
  • Komponenter udpeget i en risikoanalyse · testens omfang skal kunne forklares ud fra, hvad der er vigtigt for driften.
  • Type, omfang, tid og resultater · fire oplysninger, som kunden vil kunne finde i jeres dokumentation.
  • Vurdering af kritisk betydning og afbødende foranstaltninger · hvert fund skal have en vurdering og en plan.
  • Alvorlige konstateringer · kunden vil vide, at de er håndteret.

→ Type, omfang, tidspunkt og resultat: fire oplysninger, kunden kan forvente dokumenteret

Proportionalitet står også i forordningen

Artikel 2, stk. 2, siger, at enhederne skal tage hensyn til deres eksponering for risici, deres størrelse og sandsynligheden for hændelser og deres alvor. Betragtningerne nævner, at mindre enheder kan bruge kompenserende foranstaltninger. Hvor bilaget skriver “hvor det er relevant”, skal en enhed, der fravælger et krav, dokumentere begrundelsen på en forståelig måde.

Den sidste regel er nyttig at kende. Hvis en kunde kopierer et krav, der i forordningen kun gælder “hvor det er relevant”, kan I bede om at få det samme forbehold med i aftalen og så selv begrunde fravalg på skrift. → Forholdsmæssige krav

Tre spørgsmål til kunden

Når kravbilaget tydeligvis bygger på forordningen, er det rimeligt at spørge, hvorfor. Svarene afgør, hvor meget fleksibilitet der er i kravet.

  1. Er kunden selv en relevant enhed efter artikel 1? · i så fald har kunden en direkte pligt, og formuleringerne er som udgangspunkt ikke til forhandling, selv om omfanget stadig kan drøftes.
  2. Er teksten valgt som skabelon? · så kan omfang og form tilpasses jeres leverance.
  3. Hvilken del af leverancen skal testen belyse? · svaret gør det muligt at afgrænse testen fornuftigt.

Skriv svarene ind i aftalen eller i en kort note, så næste gennemgang ikke starter forfra.

Det skal I lade være med

  • At tro, at forordningen gælder alle NIS2-kunder · den gælder de udbydere, artikel 1 nævner.
  • At afvise kravet, fordi kunden ikke er omfattet · kunden kan stadig aftale det med jer.
  • At gå ud fra, at I selv står uden for · hosting, cloud og administrerede tjenester kan være omfattet.
  • At læse ENISA’s vejledning som en del af forordningen · vejledningen er ikke bindende.
  • At skrive forordningens ord ind uden forbehold · “hvor det er relevant” bør følge med, hvis det står sådan i kilden.

Hvad kan og ikke kan konkluderes

Når et kravbilag bruger forordningens sprog, kan I slutte, hvor ordene stammer fra, og hvad kunden sandsynligvis vil se. I kan ikke slutte, at forordningen gælder kunden eller jer. Det afgøres af, om I eller kunden driver en af de tjenester, artikel 1 nævner. En test kan opfylde punkt 6.5’s krav til dokumentation, men den siger ikke, at de øvrige punkter i bilaget er opfyldt. ENISA’s tekniske vejledning forklarer bilaget punkt for punkt, men den er ikke bindende. → ENISA’s tekniske vejledning: hvad den siger om sikkerhedstest

Tjekliste, når kravet ligner forordningen

  • ☐ Har I afklaret, om I selv driver en tjeneste, som artikel 1 nævner?
  • ☐ Ved I, om kunden er en relevant enhed efter forordningen?
  • ☐ Er de lånte formuleringer markeret i kravbilaget?
  • ☐ Står forbeholdet “hvor det er relevant” med, hvor kilden har det?
  • ☐ Kan jeres testdokumentation vise type, omfang, tid og resultater?
  • ☐ Er alvorlige fund fulgt op med en plan?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om NIS2 og penetrationstest

Læs også: MSP og NIS2 · Dokumenteret testmetode

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Har en kunde stillet NIS2‑krav?

Fortæl kort, hvad kunden har bedt om, og hvornår kunden skal have svar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.