NIS2 compliance-checklist: 75 punkter til danske SMV'er

Hvad skal en NIS2-checkliste indeholde?#

En NIS-2-checkliste skal dække de ti foranstaltninger i direktivets artikel 21, ledelsens ansvar og uddannelse i artikel 20 og reglerne for underretning om hændelser i artikel 23. Denne checkliste samler det i 75 konkrete punkter fordelt på otte sektioner, som I kan svare ja, delvist eller nej til.

Hvis I er omfattet af NIS-2 og bare skal have overblikket, er problemet sjældent mangel på information. Problemet er, at direktivteksten er lang og skrevet i juridisk EU-sprog, og de danske vejledninger fra Styrelsen for Samfundssikkerhed er spredt over mange dokumenter. Når IT-chefen skal rapportere status til bestyrelsen mandag morgen, hjælper det ikke at have læst det hele. Det hjælper at kunne sætte flueben.

Det er formålet med denne checkliste. Den forsøger ikke at forklare hele NIS-2 (start i stedet med Er I omfattet?, hvis I er i tvivl). Den giver 75 konkrete punkter, I kan gennemgå med jeres IT-ansvarlige og bestyrelsesformand. "Ja" betyder ja, og "nej" betyder, at der er et hul, I skal lukke.

Checklisten er bygget op om foranstaltningerne i NIS-2 artikel 21 samt kravene til ledelsens ansvar (art. 20) og underretning (art. 23). Den erstatter ikke juridisk rådgivning, og den udgør ikke i sig selv compliance, men den viser jer, hvor I står.

Sådan bruger I NIS2-checklisten#

I bruger checklisten ved at gå den igennem sektion for sektion med jeres IT-ansvarlige og ledelse og give hvert punkt et af tre svar. Print PDF'en (link nederst), sæt et bestyrelsesmøde af på 60 minutter, og gå igennem sektion for sektion. Hvert punkt har tre mulige svar:

• ✓Ja: vi har det på plads, og vi kan dokumentere det.
• ✓Delvist: det findes, men er ikke fuldstændigt implementeret eller dokumenteret.
• ✓Nej: vi mangler.

Målet er ikke at nå 100% første gang. Målet er at få et ærligt billede og en prioritetsliste. Det er ikke katastrofalt at have mange nej'er første gang. Det er værre ikke at vide, hvor I står, når den sektoransvarlige myndighed ringer.

Vores vurdering er, at de tekniske punkter (MFA, backup, logging) ofte er nemmere at få på plads end de organisatoriske (dokumenteret ledelses-uddannelse, leverandør-due-diligence, kvartalsvise bestyrelsespunkter). De organisatoriske punkter kræver disciplin i kalenderen frem for IT-projekter, og det er netop dem, der skal kunne dokumenteres.

Oversigt over de 8 sektioner i checklisten#

Tabellen viser, hvad de otte sektioner dækker, hvilken artikel i NIS-2 de knytter sig til, og hvor mange punkter der er i hver.

Punkterne bygger på direktivteksten, Styrelsen for Samfundssikkerheds vejledninger og ENISA's tekniske implementeringsvejledning, men konkrete tal som "mindst dagligt" eller "inden for 24 timer" er vores anbefalinger, ikke lovkrav. De er formuleret som konkrete udsagn, så I kan svare ja eller nej uden fortolkning.

Hvilke NIS2-artikler bygger checklisten på?#

Checklisten hviler på tre artikler i direktivet:

• ✓Art. 20 placerer ansvaret hos ledelsesorganet. Ledelsen skal godkende foranstaltningerne, føre tilsyn med dem og selv deltage i uddannelse.
• ✓Art. 21 oplister ti foranstaltninger, som omfattede virksomheder skal have på plads. Sektion 2-7 dækker de fleste af dem. Sikkerhed ved anskaffelse og udvikling (litra e), måling af foranstaltningernes effektivitet (litra f) og kryptering (litra h) er kun berørt og bør gennemgås separat.
• ✓Art. 23 fastsætter fristerne for underretning om væsentlige hændelser: tidlig varsling inden for 24 timer, hændelsesunderretning inden for 72 timer og endelig rapport senest en måned efter. Den første frist er kortere end GDPR's, og reglerne gælder også hændelser uden persondata.

I Danmark er direktivet gennemført ved NIS 2-loven (lov nr. 434 af 6. maj 2025), som trådte i kraft 1. juli 2025. Registreringsfristen på virk.dk var 1. oktober 2025. Er I omfattet og har overset den, så registrér jer nu.

Styrelsen for Samfundssikkerhed koordinerer, og Center for Cybersikkerhed har været en del af styrelsen siden 29. januar 2025. Tilsynet er fordelt på sektoransvarlige myndigheder, fx Trafikstyrelsen, Miljøstyrelsen og Digitaliseringsstyrelsen. Hændelser underrettes via virk.dk, hvorfra underretningen sendes videre til sektormyndigheden og den nationale CSIRT. Er persondata berørt, anmelder I desuden til Datatilsynet (jf. GDPR's 72-timersregel).

1. Governance og ledelsesansvar (art. 20)#

NIS-2 artikel 20 pålægger ledelsesorganet at godkende cybersikkerhedsforanstaltningerne og føre tilsyn med dem, og ledelsen kan holdes ansvarlig for overtrædelser. Læs mere om ledelsens ansvar.

• Vi har identificeret, om vores virksomhed er omfattet af NIS-2 (essential eller important entity)
• Vi er registreret som NIS-2-enhed via virk.dk
• Cybersikkerhed er et fast punkt på bestyrelsesmøder mindst hvert kvartal
• Bestyrelsen har godkendt en skriftlig cybersikkerhedspolitik
• Hvert medlem af bestyrelsen har gennemført dokumenteret cybersikkerhedstræning inden for de seneste 12 måneder
• Vi har udpeget en person med det operationelle ansvar for cybersikkerhed (CISO, IT-chef eller ekstern)
• Rollen og ansvaret for cybersikkerhed er skriftligt beskrevet og delegeret, uden at fralægge bestyrelsens tilsynsansvar
• Vi har afsat budget til cybersikkerhed som en selvstændig linje i årsplanen
• Vi har tegnet en cyberforsikring og gennemgår dækningen årligt

2. Risikostyring (art. 21, litra a)#

Artikel 21, stk. 2, litra a kræver politikker for risikoanalyse og informationssystemers sikkerhed. Målet er ikke at fjerne alle risici, men at kende dem og træffe informerede beslutninger.

• Vi har gennemført en formel risikovurdering inden for de seneste 12 måneder
• Risikovurderingen dækker både interne trusler (fx utilsigtede fejl) og eksterne trusler (fx ransomware, phishing)
• Vi har et risikoregister med prioriterede risici, ejerskab og planlagte mitigationer
• Vores kritiske forretningssystemer og data er identificeret og klassificeret
• Vi har defineret vores risikoaccept: hvad accepterer bestyrelsen, og hvad skal håndteres?
• Vi genbesøger risikovurderingen ved væsentlige ændringer (ny leverandør, nyt system, hændelse)
• Vi har en informationssikkerhedspolitik, der er godkendt af bestyrelsen og kommunikeret til alle medarbejdere
• Politikken er tilgængelig for alle medarbejdere, ikke gemt i et lukket delet drev
• Politikken opdateres mindst hvert andet år

3. Backup og recovery (art. 21, litra c)#

Artikel 21, stk. 2, litra c kræver driftskontinuitet, herunder backupstyring, reetablering efter katastrofer og krisestyring. I skal altså kunne vise, at I kan komme igennem en hændelse, ikke kun at I har taget kopier. Se også vores gennemgang af ransomware.

• Vi tager automatiske backups af alle kritiske systemer mindst dagligt
• Vi følger 3-2-1-reglen: 3 kopier, 2 forskellige medier, 1 offsite
• Mindst én backup-kopi er immutable eller air-gapped (kan ikke slettes af ransomware)
• Vi har testet at gendanne fra backup inden for de seneste 6 måneder (ikke bare tjekket at filerne findes)
• Recovery Time Objective (RTO) og Recovery Point Objective (RPO) er defineret pr. kritisk system
• Backup-adgang kræver separate credentials fra almindelige admin-konti (privilege separation)
• Backups er krypteret både i transit og at rest
• Vi har en Disaster Recovery-plan, der beskriver reetableringsrækkefølgen ved totalnedbrud

4. Adgangskontrol og identitet (art. 21, litra i og j)#

Artikel 21, stk. 2, litra i handler om personalesikkerhed, adgangskontrol og styring af aktiver, og litra j nævner multifaktorautentificering eller kontinuerlig autentificering. MFA kan også omgås, fx med MFA-fatigue. Se vores artikel om MFA-fatigue-angreb.

• MFA er aktiveret på alle admin-konti (uden undtagelser)
• MFA er aktiveret på alle almindelige medarbejder-konti i M365/Google Workspace/kritiske SaaS
• Vi bruger phishing-resistent MFA (FIDO2/passkeys) hvor muligt, og ellers authenticator-app frem for SMS
• Alle brugere har unikke konti (ingen delte "kontor@"-logins til kritiske systemer)
• Vi håndhæver princippet om mindste privilegium (least privilege)
• Admin-rettigheder gives kun ved behov og fjernes ved rolleændring eller opsigelse
• Vi gennemgår adgangsrettigheder mindst hvert kvartal (adgangsreview)
• Vi har en offboarding-proces, der deaktiverer alle konti inden for 24 timer efter opsigelse
• Password-politik følger NIST-anbefalinger: længde over kompleksitet, ingen tvungen rotation uden mistanke
• Vi har en dedikeret proces for privileged access management (PAM), også for eksterne konsulenter

5. Awareness-træning (art. 21, litra g)#

Artikel 21, stk. 2, litra g kræver grundlæggende cyberhygiejne og uddannelse i cybersikkerhed, og efter artikel 20, stk. 2, skal virksomhederne tilskyndes til regelmæssigt at tilbyde medarbejderne uddannelse svarende til ledelsens. En cc-liste er ikke dokumentation. Vil I teste medarbejderne, kan I starte med vores gratis phishing-test.

• Alle medarbejdere gennemfører awareness-træning ved onboarding (inden for første måned)
• Alle medarbejdere gennemfører opfølgende træning mindst årligt
• Træningen dækker som minimum: phishing, password-hygiejne, MFA, sikker hjemmearbejdsplads, incident-rapportering
• Vi kan trække en rapport med hvem der har taget hvilke moduler hvornår
• Rollespecifik træning tilbydes til udsatte grupper (økonomi/CFO-team, HR, IT-admin)
• Vi kører løbende phishing-simuleringer (mindst 2 gange årligt)
• Resultaterne af phishing-simuleringer bruges til at målrette efterfølgende træning
• Nye medarbejdere kan ikke få adgang til kritiske systemer før awareness-modulet er gennemført
• Ledelsens egen træning er dokumenteret separat (jf. art. 20, stk. 2 om bestyrelsens uddannelse)
• Vi har en klar rapporteringskanal for mistænkelige mails/beskeder (fx "Rapportér phishing"-knap)

6. Incident response (art. 21, litra b)#

Artikel 21, stk. 2, litra b kræver håndtering af hændelser. Sammen med fristerne i artikel 23 (se sektion 8) betyder det, at I skal kunne handle hurtigt og struktureret. En beredskabsplan er et godt udgangspunkt.

• Vi har en skriftlig incident response-plan
• Planen definerer roller: Incident Commander, teknisk lead, kommunikationsansvarlig, DPO-liaison
• Alle relevante medarbejdere kender deres rolle og ved, hvem der ringer til hvem
• Vi har en 24/7 kontaktliste for kritiske ressourcer (IT-partner, cyberforsikring, ekstern DFIR)
• Vi har gennemført en table-top-øvelse inden for de seneste 12 måneder
• Vores IT-systemer producerer logs, der kan bruges til efterforskning (min. 90 dage)
• Logs opbevares, så en angriber ikke kan slette dem (WORM/immutable storage eller centralt log-system)
• Vi har defineret klassifikationskriterier for hændelser (lav/middel/høj/kritisk)
• Vi ved, hvornår en hændelse skal eskaleres til bestyrelsen (typisk kritisk eller regulatorisk relevant)
• Vi har testet vores plan mod et ransomware-scenarie

7. Supply chain-sikkerhed (art. 21, litra d)#

Artikel 21, stk. 2, litra d kræver sikkerhed i forsyningskæden, herunder i forholdet til direkte leverandører. Det er også det krav, jeres NIS-2-omfattede kunder typisk sender videre til jer som sikkerhedsspørgeskemaer.

• Vi har en oversigt over alle IT-leverandører med adgang til vores data eller systemer
• Vi har klassificeret leverandørerne efter kritikalitet (fx A/B/C)
• Vi har sikkerhedsklausuler i kontrakter med alle kritiske leverandører
• Kritiske leverandører kan fremvise ISO 27001, SOC 2 eller tilsvarende dokumentation
• Vi udsender et sikkerhedsspørgeskema til nye kritiske leverandører før onboarding
• Vi har defineret krav om hændelses-notifikation fra leverandører (fx inden for 24 timer)
• Vi genbesøger leverandør-due-diligence mindst årligt for de kritiske
• Vi har en exit-plan for kritiske leverandører (hvad hvis vores MSP forsvinder?)
• Vi har vurderet risikoen ved fjerde-parts-leverandører (leverandørens leverandører)

8. Underretning om hændelser (art. 23)#

Artikel 23 kræver, at væsentlige hændelser underrettes med en tidlig varsling inden for 24 timer, en hændelsesunderretning inden for 72 timer og en endelig rapport senest en måned efter. Den første frist er kortere end GDPR's 72-timersregel, og reglerne gælder også hændelser uden persondata.

• Vi ved, hvilken sektoransvarlig myndighed vi hører under
• Vi ved, hvordan vi underretter (via virk.dk, hvorfra underretningen går videre til sektormyndigheden og CSIRT)
• Vi har en skabelon til den tidlige varsling (24 timer)
• Vi har en skabelon til hændelsesunderretningen (72 timer)
• Vi har en skabelon til den endelige rapport (en måned)
• Vi ved, hvornår vi også skal anmelde til Datatilsynet (når persondata er berørt)
• Vi har et internt hændelsesregister, der løbende opdateres (også med hændelser, der ikke krævede ekstern rapportering)
• Vi har defineret intern rapportering (hvornår hører bestyrelsen om det?)
• Vi har testet 24-timers deadline i en table-top-øvelse
• Vi har en kontaktperson hos vores IT-partner/DFIR, som kan hjælpe med rapporteringen

Hvilke misforståelser om NIS2 er de mest almindelige?#

De mest almindelige misforståelser er, at små virksomheder altid er undtaget, at ISO 27001 automatisk dækker kravene, og at ansvaret kan outsources. Det er værd at have dem afklaret, før I går i gang med checklisten.

Myte: Små virksomheder er altid undtaget fra NIS2

Størrelseskravet (mindst 50 ansatte, eller både omsætning og balance over 10 mio. EUR) gælder som hovedregel, men der er undtagelser: DNS-udbydere, TLD-navneregistre, tillidstjenester (eIDAS), udbydere af offentlige elektroniske kommunikationsnet og centraladministrationen er omfattet uanset størrelse. Og hvis I er kritisk leverandør til én af de 18 sektorer, vil kravene i praksis smitte ned til jer via kontrakter. Se er I omfattet? for detaljer.

Myte: ISO 27001 dækker alle NIS2-krav

En certificering hjælper, men den er ikke automatisk NIS-2-compliance. NIS-2 har specifikke krav om ledelsens uddannelse (art. 20, stk. 2), underretning inden for 24 timer (art. 23) og ledelsens godkendelse af foranstaltningerne, som ikke automatisk følger af ISO 27001. I skal kunne pege på præcis, hvordan I opfylder hvert enkelt NIS-2-krav, ikke bare på et certifikat.

Myte: Outsourcet IT er leverandørens ansvar

Nej. I kan outsource driften, men ikke ansvaret. Efter art. 21, stk. 3, skal I tage højde for de sårbarheder, der er specifikke for hver direkte leverandør, og for kvaliteten af leverandørernes cybersikkerhedspraksis. Fører et hul hos MSP'en til en hændelse hos jer, er det jer, der skal underrette og svare myndigheden. Bemærk også, at en MSP af en vis størrelse selv kan være omfattet.

Myte: Kun cyberangreb er NIS2-hændelser

NIS-2 art. 6, nr. 6, definerer en "hændelse" bredt: en begivenhed, der kompromitterer tilgængeligheden, autenticiteten, integriteten eller fortroligheden af data eller tjenester. Det omfatter også utilsigtede nedbrud, konfigurationsfejl og hardwaresvigt. Pligten til at underrette gælder kun væsentlige hændelser (art. 23, stk. 3), men en fejlslettet database kan godt være væsentlig, hvis den forårsager alvorlige driftsforstyrrelser.

Myte: Bestyrelsens uddannelse klares med ét kursus

Direktivet fastsætter ikke en frekvens for ledelsens uddannelse, men Styrelsen for Samfundssikkerheds vejledning om ledelsens rolle lægger vægt på løbende tilsyn og dokumentation. Truslerne ændrer sig, så et enkelt webinar for flere år siden er svært at forsvare. Vores bud er et par timer om året for bestyrelsen og mere for direktion og driftsledere.

Hvordan prioriterer I resultatet af checklisten?#

I prioriterer efter regulatorisk risiko, sandsynlig skade og kontraktuel risiko, i den rækkefølge. Når I er gennem alle 75 punkter, har I et tal, for eksempel 45 ja, 20 delvist, 10 nej. Det tal er interessant, men det er ikke jeres arbejde. Jeres arbejde er de 10 nej-punkter og de 20 delvise. Prioritér efter:

1. 1Regulatorisk risiko: manglende registrering, udokumenteret ledelsesuddannelse, ingen proces for underretning. Det er let for en myndighed at konstatere.
2. 2Sandsynlig skade: ingen MFA på admin-konti, ingen test af backup, ingen incident response-plan. Her kan et enkelt angreb sende virksomheden i knæ.
3. 3Kontraktuel risiko: manglende gennemgang af leverandører. Det er typisk det, jeres NIS-2-omfattede kunder beder om dokumentation for.

Sæt en realistisk tidshorisont. Vores vurdering er, at 6-9 måneder ikke er urimeligt for en SMV, der starter fra bunden. Dokumentér undervejs. Genkør checklisten hvert kvartal.

Og husk: det er bestyrelsens ansvar, ikke IT-chefens alene. Vi anbefaler at gennemgå den samlet på et bestyrelsesmøde og skrive den valgte handlingsplan ind i referatet. Det er et af de bedste beviser, I kan lægge frem, hvis tilsynet dukker op.

NIS2-plan for de første 90 dage

Starter I helt fra bunden, giver denne rækkefølge efter vores vurdering mest for pengene:

1. 1Uge 1-2: Registrer jer på virk.dk (hvis endnu ikke gjort). Læg cybersikkerhed på næste bestyrelsesmødes dagsorden. Find et kursus til bestyrelsen, og dokumentér deltagelsen.
2. 2Uge 3-4: Aktivér MFA på alle admin-konti. Test genoprettelse af en backup fra et kritisk system. Skriv de to første udkast til en incident response-plan (kontaktliste + eskalationsflow).
3. 3Uge 5-8: Rul awareness-træning ud til alle medarbejdere. Kortlæg jeres 5 mest kritiske IT-leverandører og send dem et kort sikkerhedsspørgeskema.
4. 4Uge 9-12: Gennemfør en 90-minutters table-top-øvelse på et ransomware-scenarie. Dokumentér erfaringerne. Genkør checklisten og opdatér prioriteringen.

Efter 90 dage har I ikke løst NIS-2, men I er gået fra "aner det ikke" til "har styr på det vigtigste og en plan for resten". Det er et langt bedre udgangspunkt, hvis myndigheden henvender sig.

Hvad gør I, når en kontrol svigter?

Når en kontrol svigter, så dokumentér årsagen, udpeg en ejer og sæt en dato for, hvornår hullet er lukket. Alle virksomheder oplever før eller siden, at en kontrol svigter. En admin glemmer at aktivere MFA på en ny konto, en leverandør sender ikke deres SOC 2-rapport til tiden, en backup-test viser at RTO er dobbelt så lang som forventet. Det er ikke i sig selv en compliance-katastrofe.

Problemet opstår, når svigtet ikke bliver opdaget, dokumenteret og lukket. NIS-2 kræver ikke, at I er perfekte, men at I har en risikostyring, der opdager og retter fejl.

ShieldUp har et NIS-2-spor med otte moduler i beta, som dækker awareness-delen af listen (sektion 5). De andre sektioner kræver teknisk og organisatorisk arbejde, som et træningsmodul ikke løser. Læs mere på NIS-2-siden.

Hvilke dokumenter skal I have klar til et NIS2-tilsyn?#

Ved et tilsyn kan myndigheden bede om dokumentation for jeres foranstaltninger. Det følgende er vores bud på den dokumentation, checklisten hjælper jer med at samle:

• ✓Bevis på selvregistrering (skærmklip fra virk.dk eller bekræftelses-mail).
• ✓Skriftlig cybersikkerhedspolitik med bestyrelses-godkendelses-dato.
• ✓Deltager-log for ledelsens cybersikkerhedstræning.
• ✓Risikovurdering med dato og ejer.
• ✓Beskrivelse af backup-strategi + seneste restore-test.
• ✓Adgangs-review-protokoller (typisk fra IAM-systemet eller manuelle logs).
• ✓Awareness-træningslog med dato pr. medarbejder pr. modul.
• ✓Incident response-plan + evidens for seneste øvelse.
• ✓Liste over kritiske leverandører med due-diligence-status.
• ✓Rapporterings-skabeloner og bevis for eventuelle indberetninger.

Kan I finde disse dokumenter frem inden for en uge, står I stærkt, også selvom ikke alt er på plads endnu.

Download NIS2-checklisten som PDF#

I kan downloade hele checklisten som en printvenlig A4-PDF med afkrydsningsfelt ved alle 75 punkter. Skriv jeres e-mail nedenfor, så downloades PDF'en med det samme. Nyhedsbrevet er frivilligt: Sætter I flueben i feltet, får I en mail, hvor I bekræfter tilmeldingen.

Spørgsmål og svar om NIS2-checklisten#

Er checklisten officiel dokumentation for NIS2-compliance?

Nej. Checklisten er ShieldUps egen strukturerede oversigt baseret på NIS-2 artikel 20, 21 og 23 samt den danske implementeringslov. Den er ikke godkendt af Styrelsen for Samfundssikkerhed eller nogen anden myndighed. Den er tænkt som et arbejdsredskab til selvvurdering, ikke som juridisk dokumentation i sig selv. Det, der tæller over for tilsynet, er den underliggende dokumentation (politikker, logs, deltagerlister, kontrakter), som checklisten hjælper jer med at få styr på.

Hvorfor 75 punkter og ikke 100 eller 30?

75 punkter dækker de vigtigste dele af art. 20, 21 og 23 uden at drukne i underkontroller, som er mere relevante for større virksomheder med egen CISO. For en SMV er det efter vores vurdering et passende detaljeniveau: nok til at fange de reelle huller, ikke så mange at listen bliver ubrugelig som samtaleværktøj i en bestyrelse.

Er checklisten relevant for leverandører, der ikke selv er omfattet?

Ja. Jeres kunder skal håndtere sikkerheden i deres leverandørkæde (sektion 7), og de vil typisk videreføre kravene i form af sikkerhedsspørgeskemaer og kontraktklausuler. Hvis I kan svare "ja" til de fleste punkter i denne liste, er I langt bedre stillet i den kommende leverandør-dialog. Se også vores gennemgang af supply chain-effekten.

Hvor ofte skal vi gennemgå NIS2-checklisten?

Vi anbefaler hvert kvartal de første 12 måneder, mens I lukker huller, og derefter mindst hvert halve år. Sammen med en årlig risikovurdering og et løbende hændelsesregister giver det et dokumenteret forløb.

Findes checklisten som Word-fil?

Ikke lige nu. PDF'en er valgt fordi den bevarer layout og er nem at printe/dele. Har I brug for en redigerbar udgave til intern brug, må I gerne kopiere indholdet manuelt. Vi har ingen ophavsretlige indvendinger, når det bruges internt i jeres virksomhed.

Kilder og forskning#

Regulatoriske primærkilder bag denne artikel.

NIS-2 (regulatorisk primærkilde)

• ✓Europa-Parlamentet og Rådet (2022). Direktiv (EU) 2022/2555 (NIS-2). Art. 20: ledelsesorganers ansvar og uddannelse; art. 21: foranstaltninger til styring af cybersikkerhedsrisici; art. 23: underretning (24 timer, 72 timer, en måned). Link
• ✓Folketinget (2025). Lov nr. 434 af 6. maj 2025 (NIS 2-loven). Link

Nationale vejledninger og implementering

• ✓Styrelsen for Samfundssikkerhed (løbende). NIS 2: registrering og vejledninger. Link
• ✓Styrelsen for Samfundssikkerhed (2025). Vejledning til NIS 2-loven: Implementering af cybersikkerhedsforanstaltninger. Link
• ✓Styrelsen for Samfundssikkerhed (2025). Vejledning til NIS 2-loven: Hændelsesunderretning. Link
• ✓ENISA (2025). NIS2 Technical Implementation Guidance (juni 2025), til gennemførelsesforordning (EU) 2024/2690. Link

Tjek det på 30 sekunder med vores interaktive selvtjek.