NIS 2: Hvordan ved I, om I er i mål?

Det er ikke svært at finde en liste over NIS 2-kravene. Udfordringen er at vide, hvor I står, hvad der konkret mangler, og hvordan I dokumenterer, at sikkerhedstiltagene virker i praksis.

Som med alle andre compliancekrav er NIS 2 ikke svært at tale om. Det er svært at udføre.

Til hverdag møder jeg virksomheder, der står meget forskellige steder. Nogle ved godt, at de er omfattet, men ikke, hvor de skal begynde. Ledelsen og de, der har fået ansvaret for implementeringen, har hørt om risikovurderinger, ledelsesansvar, leverandørsikkerhed og 24-timersunderretning, men de mangler et samlet billede af, hvad det betyder for netop deres organisation.

Andre er i den anden ende. De har multifaktorautentificering, antivirus eller EDR, backup, en beredskabsplan og en større samling sikkerhedspolitikker. Måske har de også købt en SIEM-løsning, gennemført en penetrationstest og fået præsenteret en flot modenhedsmåling.

Alligevel kan det være overraskende svært at svare præcist på helt grundlæggende spørgsmål:

• Hvilke tjenester er det vigtigst, at I kan opretholde?
• Hvilke systemer, personer og leverandører er tjenesterne afhængige af?
• Hvilken konkret risiko reducerer den enkelte sikkerhedsforanstaltning?
• Er foranstaltningen implementeret i hele det relevante miljø?
• Hvordan opdager I, hvis den holder op med at virke?
• Hvornår blev den sidst testet?
• Hvem har accepteret den risiko, der er tilbage?
• Kan I reelt vurdere og underrette om en væsentlig hændelse inden for 24 timer?

Det er dér, det rigtige NIS 2-arbejde begynder.

Denne artikel handler derfor ikke kun om, hvad NIS 2 kræver. Den handler om, hvordan I finder ud af, hvor I står, hvordan I omsætter kravene til konkrete handlinger, hvordan I prioriterer indsatsen, hvordan I dokumenterer, at foranstaltningerne er implementeret — og hvordan I ved, om de faktisk virker.

For NIS 2 bliver ikke løst med en mappe fuld af politikker. Og det bliver heller ikke løst ved at købe ét nyt sikkerhedsprodukt.

Indhold

• Afklar først, om og hvordan I er omfattet
• Det er som udgangspunkt hele den juridiske enhed
• Gap-analysen er jeres nulpunkt
• Hvad kræver NIS 2 formelt?
• Det sværeste ord i NIS 2 er “passende”
• Fra nulpunkt til dokumenterbar drift
• Ledelsen skal ikke bare orienteres
• 24 timer er en frist — ikke en plan
• Et tilsyn spørger til virkeligheden
• Der findes ikke et generelt NIS 2-stempel
• Tjekliste: Hvordan ved I, om I er i mål?

Afklar først, om og hvordan I er omfattet

Den danske NIS 2-lov trådte i kraft den 1. juli 2025. Den gælder for offentlige og private enheder inden for de aktiviteter og sektorer, der fremgår af lovens bilag 1 og 2, når de relevante størrelses-, jurisdiktions- eller særlige kriterier er opfyldt.

Loven opererer med to kategorier:

1. Væsentlige enheder (bilag 1). En enhed af en type i bilag 1 anses som hovedregel for at være en væsentlig enhed efter NIS 2-lovens § 4, hvis den beskæftiger 250 personer eller derover, eller hvis den både har en årlig omsætning på over 50 millioner euro og en årlig samlet balance på over 43 millioner euro.

2. Vigtige enheder (bilag 1 og 2). En enhed af en type i bilag 1 eller 2, som ikke allerede er væsentlig, anses som hovedregel for at være en vigtig enhed efter § 5, hvis den beskæftiger 50 personer eller derover, eller hvis den både har en årlig omsætning på over 10 millioner euro og en årlig samlet balance på over 10 millioner euro.

Bemærk to detaljer, der ofte bliver læst forkert.

For det første er der eller mellem personkriteriet og det økonomiske kriterium. Det økonomiske kriterium består til gengæld af to betingelser, der begge skal være opfyldt: både kravet til omsætning og kravet til balance. En virksomhed med en omsætning på 20 millioner euro og en balance på 5 millioner euro opfylder altså ikke det økonomiske kriterium — men den kan udmærket være omfattet på personkriteriet i stedet.

For det andet anvender loven formuleringen “personer”. Men vejledningen fra Styrelsen for Samfundssikkerhed (SAMSIK) henviser til EU’s regler om årsarbejdsenheder (årsværk), når størrelsen skal beregnes. Deltidsansatte og sæsonansatte indgår som brøkdele, og partner- eller tilknyttede virksomheder kan påvirke beregningen af både arbejdsstyrke, omsætning og balance. I kan derfor ikke blot tælle navnene i medarbejderkartoteket.

Nogle enheder betragtes desuden som væsentlige uanset størrelse — blandt andet bestemte tillidstjenesteudbydere, topdomæneadministratorer, DNS-tjenesteudbydere, centrale offentlige forvaltningsenheder og enheder identificeret efter CER-loven. En enhed kan også blive omfattet eller klassificeret på baggrund af sin særlige samfundsmæssige eller systemiske betydning. Energi-, tele- og dele af finanssektoren er desuden omfattet af særskilt eller sektorspecifik regulering. En størrelsestest eller et onlineværktøj kan derfor være et godt første pejlemærke, men det bør ikke stå alene.

Det er den enkelte juridiske enheds eget ansvar at vurdere, om den er omfattet, og i givet fald registrere sig hos den relevante kompetente myndighed. Virksomhederne bliver som udgangspunkt ikke først kontaktet og udpeget af myndighederne.

Ethvert seriøst NIS 2-forløb bør derfor starte med en dokumenteret vurdering af, om virksomheden er omfattet — et kort og dateret anvendelsesnotat, der som minimum fastslår:

• hvilken juridisk enhed vurderingen vedrører,
• hvilke aktiviteter og tjenester enheden leverer,
• hvilken sektor og delsektor aktiviteterne hører under,
• hvordan størrelseskriterierne er vurderet,
• om der gælder undtagelser eller særregler,
• om enheden er væsentlig eller vigtig,
• hvilken myndighed der er kompetent,
• hvilke registreringskrav der gælder,
• og hvornår vurderingen skal genbesøges.

Det behøver ikke være et langt juridisk responsum. Det vigtige er, at vurderingen kan genfindes, forklares og opdateres, hvis virksomheden ændrer størrelse, struktur, aktiviteter eller geografisk tilstedeværelse.

Registreringsfristerne er ikke ens for alle

NIS 2-loven opererer med to registreringsregimer.

For de enheder, der er opregnet i NIS 2-lovens § 9 — herunder DNS-tjenesteudbydere, topdomænenavneadministratorer, cloud-, datacenter- og CDN-udbydere, MSP’er, MSSP’er, onlinemarkedspladser, onlinesøgemaskiner og platforme for sociale netværkstjenester — er registreringsfristen som udgangspunkt tre måneder.

For de øvrige væsentlige og vigtige enheder, der registreres efter § 10, er fristen som udgangspunkt to uger. De samme frister gælder ved ændringer i de registrerede oplysninger, regnet fra datoen for ændringen.

Registreringen bør derfor have en navngiven ejer og ikke blot blive betragtet som en engangsopgave.

Det er som udgangspunkt hele den juridiske enhed

En af de vigtigste — og efter min erfaring mest oversete — præciseringer er denne: Er en juridisk enhed omfattet, er hele enheden som udgangspunkt omfattet.

Virksomheden skal derfor forholde sig til alle de net- og informationssystemer, den anvender til sine operationer eller til at levere sine tjenester. I kan ikke uden videre beslutte, at NIS 2 kun gælder produktionssystemet, ERP-platformen eller en håndfuld systemer, I selv har valgt at kalde “NIS 2-kritiske”.

Det betyder ikke, at alle systemer skal beskyttes på præcis samme niveau. Et informationsdisplay i receptionen har næppe samme kritikalitet som virksomhedens identitetsplatform, produktionsstyring eller centrale integrationsmiljø. Forskellige sikkerhedsniveauer kan være fuldt rimelige, når forskellene bygger på en dokumenteret risikovurdering.

Den praktiske regel er:

I må gerne differentiere sikkerhedsniveauet. I må ikke ignorere dele af miljøet uden en risikobaseret begrundelse.

Gap-analysen er jeres nulpunkt

Når det er afklaret, at virksomheden er omfattet, og hvilke regler der gælder, bør næste skridt være en NIS 2-gap-analyse.

NIS 2-loven dikterer ikke, at virksomheden skal udarbejde et dokument med overskriften “gap-analyse”. Men en struktureret vurdering af den nuværende situation viser jer, hvor langt I er, hvad der mangler, hvilke mangler der indebærer den største risiko, hvor indsatsen skal begynde, og hvor mange ressourcer arbejdet reelt kræver.

Uden et nulpunkt bliver planen i bedste fald et kvalificeret gæt.

Hvordan vi konkret griber gap-analyse, teknisk efterprøvning og dokumentation an, står på vores NIS 2-emneside.

Hvad er en NIS 2-gap-analyse?

En gap-analyse er en struktureret sammenligning mellem:

1. Det virksomheden er forpligtet til at gøre.
2. Det virksomhedens politikker og procedurer siger, at den gør.
3. Det virksomheden rent faktisk gør.
4. Det virksomheden kan dokumentere, at den gør.

De fire ting er langt fra altid ens.

Virksomheden kan eksempelvis have en politik, der siger, at multifaktorautentificering er obligatorisk, uden at alle privilegerede konti, fjernadgange eller cloudtjenester reelt er omfattet. Den kan have en procedure for adgangsreviews, som aldrig er blevet gennemført. Den kan have backup af alle centrale servere, men aldrig have testet, om en samlet forretningstjeneste kan genetableres inden for det tidsrum, ledelsen forventer.

Endelig kan den have en beredskabsplan, der ikke tager højde for NIS 2-underretning, utilgængelige kommunikationssystemer, kompromitterede administratoridentiteter, eller at de personer, som normalt træffer beslutningerne, ikke kan kontaktes.

Det er netop forskellen mellem det beskrevne, det implementerede og det dokumenterede, som gap-analysen skal gøre synlig.

En gap-analyse er ikke bare et spørgeskema

En brugbar gap-analyse bør som minimum kombinere gennemgang af politikker, procedurer og risikovurderinger, interviews med de personer, der ejer eller udfører processerne, gennemgang af tekniske konfigurationer og rapporter, stikprøver på, om procedurerne faktisk bliver fulgt, vurdering af den eksisterende dokumentation — og en risikobaseret prioritering af de konstaterede mangler. Et selvrapporteret spørgeskema med svarmulighederne ja, nej og delvist rækker ikke alene.

Når en virksomhed svarer, at den “har MFA”, bør analysen ikke stoppe dér. Den bør også undersøge:

• hvilke brugere og systemer der er omfattet,
• om alle privilegerede konti er dækket,
• om ældre protokoller eller tekniske undtagelser kan omgå kravet,
• hvordan nødadgangskonti er sikret,
• hvem der kan oprette undtagelser,
• og om undtagelserne bliver kontrolleret.

Når virksomheden svarer, at den “har backup”, bør analysen tilsvarende undersøge:

• om alle relevante data og systemer er med,
• om backupmiljøet er tilstrækkeligt adskilt fra produktionen,
• hvem der har adgang til at ændre eller slette backup,
• hvordan fejl opdages og håndteres,
• hvornår den seneste gendannelse blev gennemført,
• om afhængigheder og rækkefølge er dokumenteret,
• og om den faktiske gendannelsestid matcher forretningens behov.

“Vi har backup” er ikke en konklusion. Det er begyndelsen på en række opfølgende spørgsmål.

Hvad skal gap-analysen resultere i?

En ordentlig gap-analyse skal give et klart svar på fem spørgsmål:

1. Hvad har vi allerede på plads?
2. Hvad findes kun på papiret eller i dele af organisationen?
3. Hvad mangler helt?
4. Hvilke mangler indebærer den største risiko?
5. Hvad skal vi gøre først, hvem ejer opgaven, og hvornår skal den være løst?

Svarene bør ikke kun samles i en farvekodet oversigt med røde, gule og grønne felter. Laves gap-analysen rigtigt, er resultatet et reelt beslutningsgrundlag med det konstaterede gap, den relevante dokumentation eller mangel på samme, den tilknyttede risiko, den anbefalede korrigerende handling, prioritet, ansvarlig ejer, afhængigheder, forventet indsats og en realistisk tidsplan.

Ledelsen skal på den baggrund kunne se forskel på hurtige forbedringer, grundlæggende tekniske mangler, organisatoriske problemer, manglende dokumentation og større ændringer, der kræver investeringer eller ændringer i arkitekturen.

Gap-analysen er kortet — ikke destinationen

En gap-analyse fortæller, hvor virksomheden står, men den lukker ikke i sig selv et eneste gap.

Jeg ser jævnligt vurderinger, hvor et område er markeret som grønt, alene fordi der findes en politik. Det er efter min opfattelse for tidligt. En mere brugbar modenhedsskala ser sådan ud:

Niveau	Hvad det reelt betyder
1. Beskrevet	Virksomheden har formuleret, hvad den ønsker at gøre.
2. Besluttet	Omfang, ansvar, risikoniveau og fremgangsmåde er godkendt.
3. Implementeret	Foranstaltningen er teknisk eller organisatorisk etableret i det aftalte scope.
4. I drift	Foranstaltningen bliver løbende udført, overvåget og vedligeholdt.
5. Testet og dokumenteret	Virksomheden har kontrolleret, at foranstaltningen virker, og kan dokumentere resultatet.
6. Forbedret	Test, hændelser og afvigelser fører til konkrete ændringer.

Gap-analysen skal derfor ikke kun vise, om virksomheden har forholdt sig til et krav. Den skal vise, hvor langt virksomheden er fra at kunne dokumentere, at kravet er omsat til noget, der fungerer i praksis.

Der findes ikke en NIS 2-knap

Flere virksomheder har fortalt mig, at de er blevet ringet op af en leverandør og tilbudt et sikkerhedsprodukt — med den besked, at produktet vil gøre virksomheden “NIS 2-compliant”.

Det gør det ikke.

Det kan være et fremragende produkt. Det kan være både relevant og nødvendigt, og det kan hjælpe virksomheden med at lukke et eller flere konkrete gaps. Men et sikkerhedsprodukt kan ikke afgøre, om den juridiske enhed er omfattet, gennemføre virksomhedens risikovurdering, fastlægge et passende sikkerhedsniveau, udpege risikoejere, acceptere restrisici, godkende foranstaltninger på ledelsens vegne, stille de rigtige krav til leverandørerne, gennemføre en kriseøvelse, teste en samlet genetablering eller sikre, at virksomheden kan gennemføre en korrekt NIS 2-underretning.

Det samme gælder, uanset om produktet hedder antivirus, EDR, XDR, SIEM, backup, awareness, sårbarhedsscanning eller identity protection.

Software kan understøtte efterlevelsen. Software kan levere tekniske kontroller, automatisere processer og skabe værdifuld dokumentation. Men software kan ikke alene gøre virksomheden NIS 2-compliant.

Når en leverandør påstår noget andet, bør I bede om et præcist svar på:

1. Hvilke konkrete NIS 2-forpligtelser understøtter produktet?
2. Hvilke dele af kravene dækker det ikke?
3. Hvilket scope beskytter løsningen faktisk?
4. Hvilke afhængigheder og forudsætninger har løsningen?
5. Hvilken dokumentation efterlader den?

Ét produkt kan lukke et gap. Det kan ikke lukke NIS 2. Der findes ikke ét stykke software, der med et trylleslag kan gøre jer NIS 2-compliant. Beklager.

Hvad kræver NIS 2 formelt?

NIS 2-lovens § 6, stk. 1, nr. 1-10, fastlægger de ti områder, som enhedens cybersikkerhedsforanstaltninger som minimum skal omfatte. Bestemmelsen kræver, at væsentlige og vigtige enheder træffer passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger. Formålet er både at styre risiciene for sikkerheden i de anvendte net- og informationssystemer og at forhindre hændelser eller begrænse deres konsekvenser for modtagere af tjenesterne og for andre tjenester.

Foranstaltningerne skal som minimum omfatte ti områder:

Formelt kravområde	Hvad det bør betyde i praksis
1. Politikker for risikoanalyse og informationssystemsikkerhed	En fast metode til risikovurdering, dokumenterede risikovurderinger, risikoejere, en risikohåndteringsplan og et sammenhængende sæt sikkerhedspolitikker.
2. Håndtering af hændelser	Evnen til at opdage, analysere, eskalere, inddæmme, dokumentere og håndtere hændelser samt genetablere sikker drift.
3. Driftskontinuitet	Backupstyring, dokumenterede gendannelsesprocedurer, disaster recovery, krisestyring, nødkommunikation og relevante øvelser.
4. Forsyningskædesikkerhed	Overblik over direkte leverandører, vurdering af leverandørrisici, sikkerhedskrav i aftaler, hændelsesvarsling og løbende opfølgning.
5. Sikker anskaffelse, udvikling og vedligeholdelse	Sikkerhedskrav ved indkøb og udvikling, change management, patch management samt processer for håndtering og offentliggørelse af sårbarheder.
6. Vurdering af foranstaltningernes effektivitet	Kontrol, måling, tekniske test, øvelser og opfølgning, som viser, om foranstaltningerne faktisk virker.
7. Cyberhygiejne og uddannelse	Grundlæggende sikkerhedspraksis, rollebaseret uddannelse, awareness og opfølgning på, om indsatsen har effekt.
8. Kryptografi og kryptering	Politikker og tekniske beslutninger om kryptering, certifikater, nøgler, protokoller og beskyttelse af data.
9. Personalesikkerhed, adgangskontrol og aktivstyring	Livscyklus for brugere, privilegerede konti, adgangsreviews, funktionsadskillelse, asset management samt sikker onboarding og fratrædelse.
10. Autentificering og sikker kommunikation	Multifaktorautentificering eller kontinuerlig autentificering samt sikret tale-, video-, tekst- og nødkommunikation, hvor det er relevant.

Der er tale om ti kravområder — ikke nødvendigvis ti separate dokumenter. I behøver ikke opfinde én politik pr. punkt, hvis jeres eksisterende politikker, procedurer og tekniske kontroller samlet dækker indholdet.

Dokumentation er heller ikke kun Word-filer og PDF-dokumenter. Styrelsen for Samfundssikkerhed (SAMSIK) nævner blandt andet logs, udskrifter af adgangstilladelser og referater som mulige dokumentationsformer. Det afgørende er, at dokumentationen kan gøres tilgængelig og viser, hvad der er besluttet og gennemført.

Det sværeste ord i NIS 2 er “passende”

Loven kræver ikke, at alle virksomheder køber de samme produkter, gennemfører de samme test eller indfører præcis de samme sikkerhedskontroller. Det ville heller ikke give mening.

Et raffinaderi, en kommune, en cloududbyder og en produktionsvirksomhed kan alle være omfattet af NIS 2, men de har ikke samme risikobillede, afhængigheder eller konsekvenser ved en hændelse.

Derfor er NIS 2 risikobaseret. Det betyder ikke, at virksomheden frit kan vælge et sikkerhedsniveau, der passer til budgettet eller den eksisterende organisation. Det betyder, at virksomheden skal kunne forklare og dokumentere, hvorfor netop det valgte sikkerhedsniveau er passende. Vurderingen skal blandt andet inddrage de tjenester, virksomheden leverer, systemernes kritiske betydning, de relevante trusler og sårbarheder, sandsynligheden for hændelser, konsekvenserne for virksomheden, konsekvenserne for kunder, borgere og samarbejdspartnere — og den potentielle samfundsmæssige påvirkning.

SAMSIK fremhæver, at vurderingen ikke kun skal tage udgangspunkt i virksomhedens egen økonomi, omdømme eller risikoappetit. Der skal også ses på den skade, en hændelse kan medføre for andre og for samfundet.

Den centrale opgave er derfor ikke at sætte flueben ved flest mulige kontroller. Den består i at skabe en sammenhængende og dokumenterbar kæde:

Tjeneste → konsekvens → systemer og leverandører → risiko → foranstaltning → ejer → dokumentation → test → ledelsesbeslutning → forbedring

Jeg kalder det NIS 2-beviskæden.

Hvis I ikke kan følge kæden begge veje, har I sandsynligvis enten sikkerhedsforanstaltninger uden en tydelig risikomæssig begrundelse — eller væsentlige risici, som ingen reelt har taget ansvar for.

Fra nulpunkt til dokumenterbar drift

Der findes ikke én metode, der passer perfekt til alle organisationer. Men nedenstående rækkefølge fungerer i de fleste NIS 2-forløb, fordi den starter med forretningen og slutter med dokumentation, test og ledelsesstyring.

1. Afklar anvendelsesområdet og registreringen

Begynd med det juridiske og organisatoriske fundament: hvilke juridiske enheder der er omfattet, hvilke aktiviteter der udløser omfattelsen, om enheden er væsentlig eller vigtig, hvilke sektorregler der gælder, hvilken myndighed der er kompetent, om registreringen er korrekt, hvem der ejer NIS 2-programmet, og hvem der kan træffe beslutninger om risici og undtagelser.

Resultatet bør være et anvendelsesnotat, dokumentation for registreringen og en enkel governance-model. Uden det risikerer I at gennemføre et stort sikkerhedsprojekt i det forkerte scope eller med uklare beslutningskompetencer.

2. Gennemfør gap-analysen

Gap-analysen etablerer nulpunktet. Den skal vise, hvilke krav der allerede er dækket, hvor dækningen kun er delvis, hvad der findes på papiret men ikke i driften, hvor dokumentationen mangler, og hvilke risici der skal håndteres først.

Der bør være tydelig sporbarhed fra hvert konstateret gap til det relevante NIS 2-krav, den berørte tjeneste eller del af organisationen, den tilknyttede risiko, den anbefalede handling og den ansvarlige ejer.

3. Kortlæg de tjenester, virksomheden skal kunne levere

Start ikke med kontrolkataloget. Start med at spørge:

Hvad er det konkret, vi skal kunne fortsætte med at levere — også når noget går galt?

Det kan eksempelvis være produktion, ordrebehandling, lønudbetaling, kundeservice, logistik, behandling af patienter eller borgere, levering af energi eller vand, adgang til en digital platform, eller overvågning og styring af tekniske anlæg.

For hver væsentlig tjeneste bør I forstå, hvor længe den kan være utilgængelig, hvor meget datatab der kan accepteres, hvilke brud på fortrolighed eller integritet der vil være kritiske, hvem der bliver påvirket, hvilke manuelle nødprocedurer der findes, og hvilke økonomiske eller samfundsmæssige konsekvenser en hændelse kan få.

Det behøver ikke begynde som en 200-siders business impact analysis. Start med de vigtigste tjenester. Få de reelle beslutningstagere med. Udbyg derefter analysen.

4. Kortlæg de faktiske afhængigheder

Når I har kortlagt tjenesterne, skal I forbinde dem med det, der får dem til at fungere: Active Directory eller Entra ID, netværk og internetforbindelser, ERP-, økonomi- og produktionssystemer, cloudplatforme og SaaS-løsninger, endpoints og mobile enheder, OT-, ICS- og IoT-systemer, databaser og integrationsplatforme, certifikater, nøgler og hemmeligheder, fysiske lokationer og forsyninger, nøglepersoner samt eksterne leverandører.

Det er ofte her, de systemiske risici bliver synlige. Tre forretningskritiske tjenester kan se uafhængige ud, men alle tre kan være afhængige af den samme identitetsplatform, den samme internetforbindelse, den samme virtualiseringsplatform, den samme eksterne driftsleverandør eller den samme person med en særlig viden.

Det er ikke altid det mest synlige system, der udgør den største risiko.

5. Beskriv risiciene som konkrete scenarier

Et risikoregister med overskrifter som “ransomware”, “nedbrud” og “menneskelige fejl” er sjældent tilstrækkeligt. Risikoen bør beskrives som et scenarie:

En angriber kompromitterer en privilegeret konto i virksomhedens identitetsplatform og bruger adgangen til at deaktivere sikkerhedskontroller, kryptere centrale servere og slette onlinebackup. Det medfører, at ordrebehandling og produktion ikke kan gennemføres i flere dage.

Nu kan I begynde at træffe meningsfulde beslutninger: Hvilke eksisterende foranstaltninger reducerer risikoen? Hvilke svagheder gør scenariet realistisk? Hvor stor er sandsynligheden? Hvad er den mulige konsekvens? Hvilke yderligere foranstaltninger er nødvendige? Hvem ejer risikoen? Hvem kan acceptere den tilbageværende risiko?

NIS 2 bygger desuden på en tilgang, der omfatter alle relevante farer. Det er ikke kun ondsindede cyberangreb. Det kan også være menneskelige fejl, systemfejl, strømudfald, brand, oversvømmelse og andre fysiske eller miljømæssige hændelser.

6. Vælg foranstaltninger ud fra risikoen

Når risiciene er forstået, kan de relevante tekniske, operationelle og organisatoriske foranstaltninger vælges. Her kan rammeværk og standarder som ISO 27001, NIST Cybersecurity Framework, CIS Controls og IEC 62443 være en god støtte.

Men de er værktøjer. Ikke juridiske genveje. SAMSIK understreger udtrykkeligt, at det at følge en standard kan hjælpe med efterlevelsen, men ikke i sig selv er en sikkerhed for, at NIS 2-kravene er opfyldt.

En ISO 27001-certificering kan derfor være et stærkt fundament. Den fritager ikke virksomheden for at vurdere, om det certificerede scope svarer til NIS 2-scope, om alle relevante tjenester og systemer er omfattet, om NIS 2’s underretningskrav er operationaliseret, om de relevante sektorregler er dækket, og om de valgte foranstaltninger er passende i det faktiske risikobillede.

Foranstaltningerne bør som minimum kunne spores til den konkrete risiko, den tjeneste og de systemer, der beskyttes, det relevante NIS 2-kravområde, en navngiven ejer, den dokumentation, som kontrollen efterlader, og den metode, der bruges til at teste effekten.

Er virksomheden eksempelvis DNS-, cloud-, datacenter-, CDN-, MSP- eller MSSP-udbyder, kan Kommissionens gennemførelsesforordning (EU) 2024/2690 være direkte relevant. Forordningen indeholder mere detaljerede tekniske og metodologiske krav samt mere specifikke kriterier for, hvornår en hændelse er væsentlig. Den gælder for bestemte digitale udbydere og tillidstjenesteudbydere — ikke som en universel facitliste for alle NIS 2-enheder.

7. Definér dokumentationen, før kontrollen sættes i drift

For hver væsentlig sikkerhedsforanstaltning bør følgende være klart:

Felt	Spørgsmålet, der skal besvares
Formål	Hvilken risiko skal foranstaltningen reducere?
Tjeneste	Hvilken forretningstjeneste beskyttes?
Scope	Hvilke systemer, brugere, lokationer og leverandører er omfattet?
Ejer	Hvem er ansvarlig for, at kontrollen fungerer?
Udførelse	Hvad skal konkret ske, og hvornår?
Dokumentation	Hvilket bevis efterlader kontrollen?
Overvågning	Hvordan opdages det, hvis kontrollen fejler?
Test	Hvordan og hvornår vurderes effekten?
Afvigelser	Hvordan håndteres undtagelser og mangler?
Restrisiko	Hvilken risiko er tilbage, og hvem har accepteret den?

Hvis I først tænker på dokumentationen, når tilsynet spørger, bliver arbejdet unødigt tungt. Dokumentationen bør så vidt muligt være en naturlig del af driften: konfigurationsudtræk, automatiske rapporter, tickets, change records, adgangsreviews, logdata, backup- og gendannelsesrapporter, sikkerhedstest, leverandørvurderinger, beslutningsreferater og dokumenteret accept af restrisici.

Det handler ikke om at gemme alt. Det handler om at gemme det, der viser, at de væsentlige kontroller findes, anvendes og virker.

8. Test det, der betyder noget

NIS 2 stiller udtrykkeligt krav om politikker og procedurer til vurdering af sikkerhedsforanstaltningernes effektivitet. Det betyder, at virksomheden skal kunne undersøge, om foranstaltningerne faktisk reducerer de relevante risici.

Det kan blandt andet være gendannelse af kritiske systemer fra backup, sårbarhedsscanninger, penetrationstest, konfigurationsgennemgange, test af netværkssegmentering, gennemgang af privilegerede konti, stikprøver på onboarding og fratrædelser, test af logdækning og alarmer, phishingøvelser, krise- og beredskabsøvelser, leverandørøvelser og simulation af NIS 2-underretningen.

Ikke alt skal testes lige ofte eller på samme måde. Men hvis virksomheden aldrig har testet sin gendannelse, nødkommunikation, hændelseseskalering eller privilegerede adgang, ved den reelt ikke, om de mest centrale dele af beredskabet virker.

9. Gør arbejdet til en løbende styringsproces

NIS 2 bliver aldrig et statisk projekt. Virksomheden ændrer sig. Nye systemer indføres. Leverandører udskiftes. Trusselsbilledet udvikler sig. Sårbarheder opdages. Nye aktiviteter kan ændre både risiciene og det regulatoriske scope. Har I ikke selv kapaciteten til at holde processen kørende, er en fast, uvildig sikkerhedspartner én måde at gøre det på — se CISO Service.

Derfor skal arbejdet indarbejdes i den almindelige styring: Risikovurderinger skal opdateres. Kontroller skal overvåges. Afvigelser skal behandles. Test skal planlægges og følges op. Leverandører skal revurderes. Registreringsoplysninger skal holdes ajour. Ledelsen skal modtage relevant rapportering. Beslutninger og accepterede restrisici skal dokumenteres.

NIS 2 bør ikke være en årlig øvelse, hvor man finder sidste års regneark frem og ændrer datoen. Det skal være en del af den måde, virksomheden styrer sin drift og sine risici på.

Ledelsen skal ikke bare orienteres

NIS 2 gør ikke cybersikkerhed til et rent IT-ansvar. Efter NIS 2-lovens § 7 skal ledelsesorganet:

1. Godkende de valgte cybersikkerhedsforanstaltninger.
2. Føre tilsyn med, at foranstaltningerne bliver gennemført.
3. Deltage i relevante kurser om styring af cybersikkerhedsrisici.

Arbejdsopgaver kan godt uddelegeres til eksempelvis en CISO, IT-chefen, et sikkerhedsudvalg eller et revisionsudvalg. Det samlede ledelsesorgan beholder imidlertid det kollektive ansvar for, at forpligtelserne bliver håndteret.

Det betyder ikke, at bestyrelsen skal godkende hver enkelt firewallregel. Ledelsen skal derimod have et beslutningsgrundlag, der gør den i stand til at forstå og tage stilling til virksomhedens væsentligste cyberrisici, den planlagte behandling af risiciene, væsentlige afvigelser og undtagelser, accepterede restrisici, status på prioriterede forbedringer, resultater fra test og øvelser, væsentlige leverandørrisici, og alvorlige hændelser eller nærvedhændelser.

Hvis ledelsesrapporteringen kun viser antallet af blokerede phishingmails, installerede patches eller alarmer fra sikkerhedssystemerne, mangler den sandsynligvis forbindelsen til forretningens risici.

Ledelsen skal ikke bare modtage tal. Den skal kunne træffe beslutninger.

SAMSIK har ikke fastsat én bestemt kursusform eller certificering for ledelsen. Uddannelsen skal gøre ledelsen i stand til at vurdere risici, træffe beslutninger om foranstaltningerne og følge op på dem. Uddannelsesaktiviteterne skal kunne dokumenteres.

24 timer er en frist — ikke en plan

Der er opstået en udbredt forestilling om, at alle sikkerhedshændelser skal indberettes inden for 24 timer. Det er ikke korrekt.

Underretningspligten gælder væsentlige hændelser. En hændelse er efter loven væsentlig, hvis den enten har forårsaget eller kan forårsage alvorlige driftsforstyrrelser eller økonomiske tab for enheden, eller har påvirket eller kan påvirke andre fysiske eller juridiske personer ved at forårsage betydelig fysisk eller ikkefysisk skade.

Når hændelsen er væsentlig, gælder som hovedregel:

Frist	Hvad skal ske?
Senest 24 timer	En tidlig varsling, der blandt andet angiver, om hændelsen mistænkes for at være forårsaget af ulovlige eller ondsindede handlinger eller kan have grænseoverskridende virkning.
Senest 72 timer	En hændelsesunderretning med en indledende vurdering af hændelsens alvor og indvirkning samt kompromitteringsindikatorer, hvor de foreligger.
Efter anmodning	En foreløbig rapport med relevante statusopdateringer.
Senest én måned efter 72-timersunderretningen	En endelig rapport med detaljeret beskrivelse, sandsynlig årsag, afbødende foranstaltninger og eventuelle grænseoverskridende virkninger.

Underretningerne skal ikke blot sendes inden maksimumfristen, men uden unødigt ophold.

Hvis en væsentlig hændelse sandsynligvis vil påvirke leveringen af virksomhedens tjenester negativt, skal modtagerne af tjenesterne også underrettes uden unødigt ophold. Potentielt berørte modtagere skal desuden informeres om relevante modforholdsregler ved en væsentlig cybertrussel.

En procedure i et dokument er ikke nok til at løse dette. Virksomheden bør på forhånd have kriterier for vurdering af væsentlighed, tydelige roller og beslutningskompetencer, adgang til juridiske, tekniske og kommunikative kompetencer, kontaktoplysninger på interne og eksterne nøglepersoner, en eskalationsvej til ledelsen, skabeloner til de forskellige underretninger, en proces for information til kunder og andre berørte — samt en øvelse, hvor forløbet faktisk gennemføres.

Det er vanskeligt at etablere processen midt i en alvorlig hændelse, hvor systemerne måske er utilgængelige, informationerne er usikre, og ledelsen samtidig kræver svar.

24 timer er en frist. Det er ikke en beredskabsplan.

Et tilsyn spørger til virkeligheden

De kompetente myndigheder kan blandt andet gennemføre kontrol og tilsyn, foretage eller kræve sikkerhedsaudits, gennemføre sikkerhedsscanninger, kræve oplysninger, data og dokumenter, og kræve dokumentation for gennemførelsen af cybersikkerhedspolitikker.

For væsentlige enheder er tilsynsrammen proaktiv. For vigtige enheder er tilsynet som udgangspunkt reaktivt og kan iværksættes på baggrund af indikationer på manglende overholdelse.

Den 19. maj 2026 indledte SAMSIK et surveybaseret tilsyn med alle 98 kommuner. Kommunerne fik et spørgeskema bygget på lovens forpligtelseskrav, og udvalgte kommuner udtages efterfølgende til dybdegående tilsyn. Spørgerammen er udarbejdet til kommunerne og skal derfor ikke læses som en universel facitliste for alle sektorer. Den giver alligevel et meget tydeligt billede af, hvordan overordnede lovkrav bliver gjort konkrete i et tilsyn.

Der bliver blandt andet spurgt til implementerede sikkerhedspolitikker, dokumenterede risikovurderinger, risikohåndteringsplaner, udpegede risikoejere, ledelsesrapportering, procedurer for hændelser og genetablering, beskyttelse og opbevaring af logs, leverandørstyring, sårbarhedshåndtering og løbende vurdering og teknisk test af foranstaltningernes effektivitet.

Hvad tilsynet møder i praksis, har vi målt i Exchange på lånt tid: forældede mailservere, der stadig står åbne mod internettet — også hos kommuner.

SAMSIKs FAQ til tilsynet gør samtidig en vigtig pointe klar: Der er ikke krav om bestemte dokumentnavne eller om ét dokument pr. krav. Det afgørende er, at politikker og procedurer dækker det nødvendige indhold, virker efter hensigten og kan dokumenteres.

Det er efter min opfattelse hele essensen. Det er ikke nok at kunne vise en procedure. I skal kunne forklare, om den er implementeret, hvilket omfang den dækker, hvordan den bliver anvendt, hvordan I følger op, og hvordan I ved, at den virker.

Der findes ikke et generelt NIS 2-stempel

Der findes personcertificeringer inden for NIS 2. Der findes også standarder, revisioner, modenhedsvurderinger og tekniske certificeringsordninger, som kan understøtte arbejdet. Men den danske NIS 2-lov etablerer ikke en generel ordning, hvor en virksomhed én gang for alle kan få et officielt certifikat med teksten “Denne virksomhed er NIS 2-compliant”.

NIS 2-lovens § 8 giver mulighed for, at der kan fastsættes krav om anvendelse af bestemte ikt-produkter, -tjenester eller -processer, som er certificeret efter en europæisk cybersikkerhedscertificeringsordning — for at påvise overensstemmelse med bestemte krav i § 6. Bestemmelsen etablerer altså ikke i sig selv et generelt certificeringskrav, og slet ikke en ordning, hvor hele virksomheden kan erklæres “NIS 2-compliant”.

Det gør ikke certificeringer værdiløse. Det gør det nødvendigt at forstå, hvad de certificerer.

Jeg har selv certificeringen PECB Certified NIS 2 Directive Senior Lead Implementer. Det er en personcertificering. Den dokumenterer kompetencer og erfaring med at planlægge, implementere, styre, overvåge og forbedre et cybersikkerhedsprogram med udgangspunkt i NIS 2. Den betyder ikke, at Sekuritet eller en kunde automatisk bliver NIS 2-certificeret.

Jeg ser certificeringen som dokumentation for, at metoden og det formelle fundament er på plads. Ikke som en erstatning for praktisk erfaring.

Og netop fordi der ikke findes ét virksomhedscertifikat, man kan gemme sig bag, bliver det vigtigt at have rådgivere, som forstår hele kæden:

EU-direktivet → dansk lovgivning → sektorspecifik regulering → myndighedsvejledninger → tilsynspraksis → virksomhedens konkrete drift

NIS 2-regelgrundlaget er forholdsvis nyt. De underliggende sikkerhedsdiscipliner er det ikke. Risikovurdering, adgangsstyring, hændelseshåndtering, backup, leverandørstyring og beredskab har eksisteret i mange år. Det nye er blandt andet den regulatoriske ramme, det udvidede anvendelsesområde, ledelsens formelle rolle, underretningspligten, og den måde kravene nu bliver gjort til genstand for tilsyn.

Det kræver, at den, der rådgiver virksomheden, har sat sig ind i kravene fra EU-direktivet og frem, forstår den danske implementering, identificerer relevante sektorregler, følger nye vejledninger og tilsynserfaringer — og samtidig kan omsætte det hele til faktiske konfigurationer, processer, test og ledelsesbeslutninger.

Det er også sådan, vi arbejder i Sekuritet. Vi har været med til at klargøre flere virksomheder til NIS 2, herunder virksomheder, som driver eller understøtter kritisk infrastruktur og samfundskritiske tjenester.

Det arbejde bliver ikke udført med en generisk checkliste alene. Det kræver, at man kan tale med ledelsen om risiko og ansvar. Og at man kan gå ned i den tekniske virkelighed og vurdere, om eksempelvis identitetsbeskyttelse, logning, backup, segmentering, sårbarhedshåndtering og beredskab faktisk fungerer.

Tjekliste: Hvordan ved I, om I er i mål?

Der findes ikke ét procenttal, som kan give et sikkert og permanent svar. Men nedenstående spørgsmål giver en god indikation af, om virksomheden har en sammenhængende og dokumenterbar NIS 2-position:

• Har vi en skriftlig og aktuel vurdering af, hvorfor den juridiske enhed er omfattet, og hvilke regler der gælder?
• Er registreringen gennemført, og er der en ejer af de registrerede oplysninger?
• Har vi forholdt os til hele enheden og alle relevante net- og informationssystemer?
• Har vi gennemført en reel gap-analyse, der omfatter både dokumentation, processer og teknisk implementering?
• Ved vi, hvilke tjenester det er vigtigst at opretholde?
• Kan vi forbinde tjenesterne med de systemer, data, personer og leverandører, de afhænger af?
• Har vi dokumenterede risikovurderinger, risikoejere og en prioriteret risikohåndteringsplan?
• Er alle ti formelle kravområder dækket af relevante tekniske, operationelle og organisatoriske foranstaltninger?
• Kan vi dokumentere, at foranstaltningerne er implementeret i det tiltænkte scope?
• Ved vi, hvilke undtagelser og afvigelser der findes?
• Har vi testet, om de væsentligste foranstaltninger faktisk virker?
• Kan vi vurdere en hændelses væsentlighed og gennemføre underretningen inden for fristerne?
• Har ledelsesorganet godkendt sikkerhedsniveauet og ført reelt tilsyn med gennemførelsen?
• Er restrisici synlige og accepteret af de rette personer?
• Har vi en proces, der sikrer, at vurderingen bliver opdateret, når virksomheden, teknologien eller trusselsbilledet ændrer sig?

Et “ja” skal kunne følges af dokumentation. Ellers er det stadig kun en antagelse.

Hvad bør virksomheden stå tilbage med?

Et seriøst NIS 2-forløb bør ikke kun efterlade virksomheden med en rapport om alt det, den mangler. Det bør som minimum resultere i et dokumenteret anvendelsesområde, korrekt registrering, en grundig gap-analyse, et overblik over væsentlige tjenester og konsekvenser, en kortlægning af systemer og leverandørafhængigheder, dokumenterede risikovurderinger og risikoejere, en prioriteret risikohåndteringsplan, en kontrol- og dokumentationsmatrix, et opdateret hændelses- og kriseberedskab, en operationel proces for NIS 2-underretninger, en plan for test af foranstaltningernes effektivitet, ledelsesrapportering og dokumenterede godkendelser samt en realistisk plan for de resterende forbedringer.

Og vigtigst af alt: IT-chefen, ledelsen og de ansvarlige medarbejdere skal forstå, hvordan delene hænger sammen.

I bliver ikke færdige. Men I kan komme i kontrol

NIS 2 handler ikke om at dokumentere, at virksomheden aldrig vil blive ramt af en hændelse. Det kan ingen love.

Det handler om at kunne vise, at virksomheden forstår sine væsentligste risici, har truffet bevidste beslutninger om sikkerhedsniveauet, har implementeret passende og forholdsmæssige foranstaltninger, ved om foranstaltningerne virker, kan håndtere og underrette om alvorlige hændelser — og løbende forbedrer sig, når noget ændrer sig eller ikke fungerer som forventet.

Målet er ikke en perfekt mappe. Målet er heller ikke et badge på hjemmesiden. Målet er, at ledelsen på et oplyst grundlag kan sige:

Vi ved, hvilke tjenester og risici der betyder mest. Vi ved, hvad vi har gjort ved dem. Vi kan dokumentere, at det er implementeret. Og vi tester, om det virker.

Det er efter min opfattelse den mest ærlige og operationelle definition på at være i mål med NIS 2. Eller måske mere præcist: I bliver aldrig helt færdige. Men I kan komme i kontrol.

---

Har I styr på jeres NIS 2-beviskæde? En NIS 2-vurdering bør ikke kun identificere manglende politikker. Den bør afdække, om virksomhedens tjenester, risici, tekniske kontroller, leverandører, dokumentation, test og ledelsesstyring hænger sammen — og om dokumentationen kan stå distancen ved et tilsyn eller en alvorlig hændelse.

Vi hjælper med at afklare anvendelsesområdet, gennemføre den indledende gap-analyse, prioritere de væsentligste risici, vurdere den tekniske implementering, etablere den nødvendige dokumentation og omsætte resultatet til en realistisk handlingsplan. Omfanget aftales individuelt — se, hvordan et NIS 2-forløb ser ud hos os, eller tag fat i os for en uforpligtende snak om, hvor I står.

Officielle kilder og videre læsning

• NIS 2-loven — lov nr. 434 af 6. maj 2025 (Retsinformation)
• SAMSIK: Vejledning om anvendelsesområdet (PDF)
• SAMSIK: Vejledning til implementering af cybersikkerhedsforanstaltninger (PDF)
• SAMSIK: Vejledning om ledelsens rolle og opgaver (PDF)
• SAMSIK: Vejledning om hændelsesunderretning (PDF)
• SAMSIK: NIS 2-tilsyn — tilsynsplaner og status
• SAMSIKs samlede oversigt over NIS 2-vejledninger — opdateres løbende
• Kommissionens gennemførelsesforordning (EU) 2024/2690 (EUR-Lex)