NIS2-pentest

Forordningens krav om sikkerhedstest gælder MSP’en direkte

Forordningens krav om sikkerhedstest gælder MSP'en direkte

For en leverandør uden for forordningens område er gennemførelsesforordning (EU) 2024/2690 en tekst, kunden kan låne formuleringer fra. For en udbyder af administrerede tjenester eller administrerede sikkerhedstjenester er den noget andet: en forordning, der gælder direkte for virksomheden selv. Artikel 1 nævner begge typer udbydere blandt de relevante enheder, og som forordning gælder den umiddelbart i Danmark uden en national gennemførelseslov.

Det betyder, at bilagets punkt 6.5 om sikkerhedstest og punkt 6.10 om sårbarheder er krav til jeres egne systemer, ikke kun til de leverancer, kunderne spørger om. Forudsætningen er, at I er omfattet, og den vurdering ligger uden for denne tekst. Teksten er ikke juridisk rådgivning.

Punkt 6.5, læst som egen pligt

Bilagets punkt 6.5 har tre dele. Punkt 6.5.1 siger, at I fastlægger, gennemfører og anvender en politik og procedurer for sikkerhedstest. Punkt 6.5.3 siger, at politikken gennemgås og om nødvendigt ajourføres med planlagte mellemrum. Imellem står punkt 6.5.2 med fire krav:

  1. Risikovurderingen bestemmer · behov, omfang, hyppighed og type af test fastlægges ud fra den risikovurdering, der foretages efter punkt 2.1.
  2. Dokumenteret metode · testen følger en dokumenteret testmetode og omfatter de komponenter, der i en risikoanalyse er udpeget som relevante for sikker drift.
  3. Dokumentation pr. fund · testens type, omfang, tid og resultater dokumenteres med en vurdering af kritisk betydning og afbødende foranstaltninger for hver konstatering.
  4. Afbødning · der anvendes afbødende foranstaltninger ved alvorlige konstateringer.

Når en kunde bruger samme ord, kan I forhandle omfanget. Når kravet er jeres eget, er det jeres risikovurdering, der skal kunne forklare valget, også over for jeres myndighed. → Dokumenteret testmetode

Hvilke systemer kravet rammer

Forordningen gælder den relevante enheds net- og informationssystemer. For en driftsleverandør er det ikke kun den platform, kunderne ser. Det er også de værktøjer og konti, I bruger til at administrere kunderne, jeres interne systemer og de dele, der drives af jeres egne underleverandører. Digitaliseringsstyrelsen skriver, at det er hele enheden, der er omfattet, også hvis tjenesten kun er en mindre del af forretningen.

Risikovurderingen bør derfor begynde med spørgsmålet: hvor kan en svaghed hos os ramme flere kunder på én gang? Svaret peger på de komponenter, punkt 6.5.2, litra b, kalder relevante for sikker drift. Skriv begrundelsen ned. Hvis en komponent er valgt fra, skal det kunne forklares, og artikel 2, stk. 2, siger, at en enhed, der finder et krav med forbeholdet hvor det er relevant uanvendeligt, dokumenterer sin begrundelse på en forståelig måde. → Test af MSP’ens fjernadministration

Punkt 6.10: test er ikke hele svaret

Ved siden af test stiller punkt 6.10 krav om løbende håndtering af sårbarheder. Punkt 6.10.2 siger blandt andet, at I overvåger oplysninger om sårbarheder fra CSIRT’er, myndigheder og leverandører, foretager sårbarhedsscanninger med planlagte intervaller, hvor det er relevant, og afhjælper sårbarheder af kritisk betydning for driften uden unødig forsinkelse. Punkt 6.10.3 kræver en plan for afhjælpning, når den potentielle indvirkning berettiger det, og ellers en begrundelse for, at det ikke er nødvendigt.

En årlig penetrationstest dækker altså ikke kravet alene. Den skal spille sammen med scanninger, overvågning af sårbarhedsoplysninger og en proces, der følger fundene til ende. → Mellem to penetrationstest

Effektivitet og uafhængig gennemgang

Bilagets punkt 7 handler om politikker og procedurer til at vurdere, om foranstaltningerne gennemføres og opretholdes effektivt. Punkt 7.2 kræver blandt andet, at det fastlægges, hvilke foranstaltninger der overvåges og måles, med hvilke metoder, hvornår og af hvem. Sikkerhedstest er et af de redskaber, der kan give målinger, men punkt 7 er bredere.

Punkt 2.3 kræver desuden en uafhængig gennemgang af tilgangen til sikkerhed, udført af personer med passende auditkompetence. Det er et andet krav end testen, og de to skal ikke forveksles. → Uafhængig gennemgang og teknisk test

Hvad ENISA tilføjer

ENISA’s tekniske vejledning til forordningen er ikke bindende, men Digitaliseringsstyrelsen henviser til den. Til punkt 6.5 anbefaler den blandt andet test ved opsætning, efter væsentlige opgraderinger eller ændringer og efter vedligeholdelse, test af hele enheden med planlagte mellemrum eller ved væsentlige hændelser og ændringer, og dokumentation, som en sagkyndig tredjepart kan forstå. Den nævner pentest, sårbarhedsvurdering, kodegennemgang og red teaming blandt de testtyper, der kan vælges imellem. Til punkt 6.5.3 foreslår den, at politikken gennemgås mindst hvert andet år. → ENISA’s tekniske vejledning

Kundernes krav kommer oveni

Jeres kunder kan selv være omfattet og stille krav til jer efter punkt 5.1.4 om kontrakter med leverandører, fx om sårbarhedshåndtering, besked om hændelser og ret til audit eller auditrapporter. Er kunden selv omfattet af forordningen, kræver punkt 6.7.2, litra d og h, at kunden har kontrol med tjenesteudbyderes fjernadgang og kun tillader forbindelser fra tjenesteudbydere efter anmodning og i en bestemt periode, fx under en vedligeholdelsesopgave. Det kan ramme den måde, I arbejder hos den kunde på, og det kan gøre jeres egen fjernadgang til et oplagt emne for kundens spørgsmål om test. Jeres egen testplan bør derfor kunne vise både, hvad I gør for at opfylde jeres egne krav, og hvordan de dele, kunderne spørger til, er dækket. → MSP’ens kunder kræver hver deres test

Det skal I lade være med

  • At behandle forordningen som kundens tekst · for en omfattet driftsleverandør er den egen pligt.
  • At teste kun det, kunderne ser · administrationsværktøjer og interne systemer hører med.
  • At lade den årlige test stå alene · punkt 6.10 kræver løbende håndtering.
  • At forveksle test med uafhængig gennemgang · punkt 2.3 og 6.5 er to krav.
  • At citere ENISA som krav · vejledningen forklarer, men binder ikke.

Hvad kan og ikke kan konkluderes

Forordningen viser, hvilke krav til sikkerhedstest og sårbarhedshåndtering der gælder for omfattede udbydere af administrerede tjenester. Den fastsætter ikke en bestemt testtype eller et bestemt interval; det følger af risikovurderingen. Artikel 2, stk. 2, siger, at enheden skal tage hensyn til sin eksponering, størrelse og sandsynligheden for hændelser. En gennemført og dokumenteret test kan vise, at punkt 6.5 er fulgt for den konkrete test, men den viser ikke, at resten af bilaget er opfyldt. → Gennemførelsesforordning 2024/2690

Tjekliste for MSP’en

  • ☐ Har I en politik og procedurer for sikkerhedstest?
  • ☐ Bygger behov, omfang, hyppighed og type på jeres risikovurdering?
  • ☐ Følger testen en dokumenteret metode?
  • ☐ Har hvert fund en vurdering af kritisk betydning og afbødende foranstaltninger?
  • ☐ Omfatter planen jeres administrationsværktøjer og interne systemer?
  • ☐ Spiller testen sammen med scanninger og overvågning af sårbarhedsoplysninger?
  • ☐ Er det planlagt, hvornår politikken gennemgås igen?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om NIS2 og penetrationstest

Læs også: Testpolitik · Testfrekvens efter risiko

→ 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.