Hvem er omfattet, og hvem fører tilsyn
Danmark har gennemført NIS2 i tre love. Energisektoren fik sin egen, lov nr. 258 om styrket beredskab i energisektoren, i kraft 7. marts 2025. Telesektoren fik lov nr. 435, og de fleste andre sektorer lov nr. 434, begge i kraft 1. juli 2025. Banker og den finansielle infrastruktur er dækket af EU’s DORA-forordning, som går forud for NIS2.
Energiloven er bred. Den omfatter el, gas, olie, fjernvarme, fjernkøling og brint, og ladepunkter og tankstationer over en vis størrelse. Som udgangspunkt gælder den virksomheder med mindst 50 ansatte eller over 10 mio. euro i omsætning og balance. Alle netselskaber er omfattet uanset størrelse. Tilsynet ligger hos Klima-, Energi- og Forsyningsministeriet, i praksis Energistyrelsen.
Efter den generelle NIS2-lov udpeger ingen myndighed jer. I skal selv vurdere, om I er omfattet, og registrere jer på virk.dk; fristen var 1. oktober 2025. Energiselskaber indberetter i stedet til Energistyrelsen, som indplacerer dem i niveauer. Første frist var 1. april 2025.
Ledelsen står i første række. Energiloven giver ministeren hjemmel til at kræve, at ledelsen godkender risikovurderingen, beredskabsplanerne og leverandørkontrakterne, og at den selv tilegner sig viden om risikostyring. Retter en væsentlig virksomhed ikke op inden for fristen efter et påbud, kan ministeren midlertidigt forbyde direktøren at udøve ledelse i virksomheden. Og direktivet giver jer 24 timer til en tidlig varsling, efter I har fået kendskab til en væsentlig hændelse, 72 timer til en underretning og en måned efter underretningen til den endelige rapport.
Seksten dage i maj 2023
Den 25. april 2023 meldte Zyxel om et kritisk hul i en række af deres firewalls, og opdateringen lå klar. Mange danske energiselskaber bruger dem foran deres styringssystemer. SektorCERT, de kritiske sektorers fælles cybersikkerhedscenter, advarede medlemmerne igen den 1. maj.
Den 11. maj, 16 dage efter, angreb en gruppe 16 udvalgte energiselskaber med én enkelt netværkspakke hver. 11 blev kompromitteret. I løbet af maj blev 22 selskaber ramt, og flere måtte køre i ø-drift.
Ifølge SektorCERT lykkedes de fleste angreb, fordi opdateringen ikke var lagt på. Grundene var almindelige. Nogle troede, at en ny firewall havde den nyeste software. Nogle troede, at leverandøren sørgede for det. Nogle havde fravalgt opdateringen, fordi leverandøren tog betaling for at installere den. Nogle vidste ikke, at de havde enheden, fordi en leverandør havde sat den op. Og nogle troede, at den var opdateret, når den ikke var.
Det er ikke særligt for Danmark. ENISA spurgte i 2025 1.080 organisationer i EU’s NIS-sektorer, hvor lang tid det tager at lægge en kritisk opdatering på et kritisk system. 8 % gør det inden for en uge. 28 % bruger mere end tre måneder. Hver anden nævner opdateringer som et af de sværeste NIS2-krav.
Kun 8 % lukker et kritisk hul inden for en uge
Hvor lang tid det tager at lægge en kritisk opdatering på et kritisk system, it eller OT. Angrebet i maj 2023 kom 16 dage efter opdateringen.
- Inden for en uge
- 8 %
- Inden for en måned
- 31 %
- Inden for tre måneder
- 32 %
- Mere end tre måneder
- 28 %
- Varierer eller måles ikke
- 1 %
Hvorfor regnearket ikke holder
Flere af de ramte selskaber troede, at deres firewall var opdateret. Det stod sikkert også i et dokument et sted.
Den typiske NIS2-indsats er et regneark. Hver linje er et krav, hver kolonne en kontrol, en ansvarlig og en status. Det udfyldes en gang om året af nogen, der ikke selv ændrer systemerne.
Systemerne ændrer sig hver dag. En ny bruger, en åbnet port, en ny leverandør med adgang til driften. Regnearket beskriver landskabet, som det så ud, da det blev udfyldt.
Når tilsynet kommer, vil det se beviser. Hvem havde adgang til styringssystemet den 3. marts? Hvad blev ændret i firewallen den uge? Findes loggen fra natten til den 4.? Regnearket kan ikke svare. Systemerne kan, hvis de er bygget til det.
Tre kontroller, der hører hjemme i koden
Energiloven lister de cybersikkerhedsforanstaltninger, ministeren kan stille krav om. Tre af dem er lettere at bevise i kode end i et dokument.
Adgang. Hvem der har adgang til hvad, og med hvilken rolle, står i koden og ændres via en pull request, som en anden godkender. Multifaktor er slået til i konfigurationen, ikke i en vejledning. Listen over adgange er repositoriet, og historikken er dets log.
Logning. Hvert system, der udrulles, får sin logning med fra start: hvad der logges, hvor det sendes hen, og hvor længe det gemmes. Alarmerne er også kode. Et nyt system kan ikke komme i drift uden at være synligt.
Ændringer. Ingen ændrer driften i hånden. Hver ændring går gennem en pipeline, der viser, hvad der vil ske, før det sker, og som gemmer, hvem der godkendte den. Hvad der kører, og i hvilken version, står i koden, så ingen enhed er ukendt. Afviger driften fra koden, opdager en daglig kontrol det, også den firewall, alle troede var opdateret.
Beviset for tilsynet bliver et biprodukt. Spørgsmålet om den 3. marts besvares med et opslag, ikke med et møde.
To eksempler fra driften
For Sinal og Norlys byggede vi en observabilitetsplatform på open source, der sporer en fiberordre på tværs af systemerne. Den kom i produktion i et OT-miljø under NIS2-krav på seks måneder.
For netselskabet N1 byggede vi, gennem VaaS.Digital, en platform, der flytter millioner af målerdata om dagen mellem selskabets systemer, under NIS2- og OT-krav og med Terraform som udgivelsesmiljø. Der gik ca. 1 år fra første interessentmøde til en platform i drift.
I begge tilfælde var sikkerheden en del af det, der blev udrullet. Den blev ikke tilføjet bagefter.
Hvor I begynder
Vælg ét system, der understøtter jeres vigtigste tjeneste.
Beskriv adgangen til det som kode, og lad ændringer gå gennem en godkendelse.
Sæt logningen op som en del af udrulningen, med alarmer.
Luk for ændringer i hånden, og sæt en daglig kontrol op, der finder afvigelser.
Læg regnearket ved siden af, og se hvilke linjer koden nu besvarer.