NIS2 er EU’s måde at sige: “Cybersikkerhed er ikke længere et hobbyprojekt i IT-afdelingen.” Hvis din organisation leverer noget, samfundet faktisk bruger (energi, sundhed, transport, digital infrastruktur, offentlige ydelser osv.), eller du er en væsentlig leverandør ind i de kæder, så bliver kravene strammere. Ikke fordi EU elsker compliance. Men fordi angrebene ikke er stoppet af, at nogen har skrevet “IT-sikkerhedspolitik_v3_final.pdf”.
Her får du en kort, praktisk gennemgang af hvem der typisk er omfattet, og hvad det betyder i praksis: hvad du skal have styr på, hvad ledelsen hæfter for, og hvordan du undgår at drukne i papir, mens risikoen stadig står og banker på døren.
Hvad er NIS2 i én sætning?
NIS2 er et EU-direktiv, der stiller krav til udvalgte organisationers risikostyring, cybersikkerhedsforanstaltninger og hændelsesrapportering, plus tydeligere ansvar hos ledelsen.
Det handler mindre om “har I en firewall?” og mere om:
kan I modstå angreb, opdage dem hurtigt, håndtere dem ordentligt og dokumentere at I gør det?
Hvem er omfattet?
NIS2 deler i praksis organisationer op i to hovedkategorier:
- Væsentlige enheder (essential entities)
- Vigtige enheder (important entities)
Begge typer skal leve op til kravene. Forskellen ligger især i tilsyn, kontrol og sanktioner, som typisk er hårdere for “væsentlige”.
1) Sektorer: arbejder I i en NIS2-sektor?
NIS2 omfatter en række sektorer, hvor nedbrud eller kompromittering kan ramme samfundet bredt. Typisk eksempler:
- Energi (el, gas, fjernvarme m.m.)
- Transport (luft, jernbane, sø, vej-infrastruktur)
- Bank og finans
- Sundhed (hospitaler, klinikker, laboratorier m.m.)
- Drikkevand og spildevand
- Digital infrastruktur (cloud, datacentre, netværk, DNS, m.m.)
- Offentlig forvaltning (dele af den offentlige sektor afhængigt af national implementering)
- Producenter/leverandører i visse kritiske områder (fx udvalgte typer it/teknologi og industri)
Du behøver ikke være “kritisk infrastruktur” for at være relevant. NIS2 har generelt udvidet scope sammenlignet med NIS1.
2) Størrelse: “medium og large” er ofte hovedreglen
En stor del af NIS2-scope følger en size-cap logik:
Hvis du er mellemstor eller stor og opererer i en relevant sektor, er der høj sandsynlighed for at du er omfattet.
- Mellemstor: typisk 50+ ansatte og/eller omsætning/balance over en vis grænse
- Stor: typisk endnu større end det
Men: der findes undtagelser, især hvis man er særligt kritisk, eller hvis ens rolle i forsyningskæden gør én central.
3) “Vi er ikke i en sektor” kan være en falsk tryghed
Her er den del, mange overser:
Du kan være indirekte påvirket, selv hvis du ikke er “omfattet” direkte.
Hvis du leverer it-drift, udvikling, support, hosting, SaaS, logistik, betalingsflows, OT/industri-systemer eller datahåndtering til en NIS2-enhed, så får du typisk NIS2-krav ind ad døren via:
- kontraktkrav
- leverandørvurderinger
- audits og sikkerhedsspørgeskemaer
- krav om incident-notifikation og dokumentation
Oversættelse: Du kan stadig blive tvunget til at stramme op, bare uden at EU skriver dit navn på forsiden.
Hurtig “er vi omfattet?”-tjekliste
Brug den her som første screening:
- Er vi i en sektor, der typisk nævnes som kritisk/vigtig?
- Er vi mellemstor eller stor?
- Driver vi kritiske systemer, infrastruktur eller data for andre?
- Har vi mange afhængigheder (leverandører, integrationer, cloud)?
- Ville et nedbrud hos os ramme mange brugere/kunder/borgere?
Hvis du svarer “ja” til flere, bør du regne med at NIS2 er relevant for jer i praksis.
Hvad betyder det i praksis? De konkrete krav (uden fluff)
NIS2 stiller i praksis krav i tre store bunker:
- Risikostyring og sikkerhedsforanstaltninger
- Hændelseshåndtering og rapportering
- Ledelsesansvar, governance og dokumentation
Lad os tage dem i menneskesprog.
1) Risikostyring: “vis mig jeres kontrolmiljø”
I skal kunne vise, at I arbejder systematisk med cybersikkerhed, ikke tilfældigt.
Typisk betyder det, at I skal have styr på:
Politikker og governance
- klare roller og ansvar (hvem ejer sikkerhed?)
- risikostyring (hvordan vurderer og prioriterer I?)
- sikkerhedspolitikker, der faktisk bliver brugt
Asset management
- hvad har I af systemer, data, integrationer og leverandører?
- hvilke er kritiske?
- hvem ejer dem?
Hvis I ikke kan liste jeres vigtigste aktiver, så kan I heller ikke beskytte dem. Trist, men logisk.
Adgangsstyring
- MFA hvor det giver mening (ofte “overalt”)
- mindst mulige rettigheder (least privilege)
- styr på admin-konti
- offboarding der virker (brugere skal ikke leve videre i systemet efter de er stoppet)
Sårbarhedsstyring og patching
- patch-cyklus og prioritering (kritiske først)
- scanning eller anden systematik
- håndtering af “kan ikke patches” (kompenserende kontroller)
Backup og recovery
- backup der er adskilt (så ransomware ikke bare krypterer alt)
- test af restore (ellers er det ønsketænkning, ikke backup)
- definerede RTO/RPO på kritiske systemer
Logging og detektion
- logs der er til at bruge
- monitorering på kritiske systemer
- en plan for hvordan alarmer håndteres
Supply chain (leverandører)
- risikovurdering af leverandører
- krav i kontrakter (incident-notifikation, sikkerhedsniveau, underleverandører)
- styr på “hvem har adgang til hvad”
NIS2 er ret tydelig med, at leverandørkæden ikke er en undskyldning. Den er en del af risikoen.
2) Hændelser og rapportering: “I skal kunne reagere hurtigt”
NIS2 lægger vægt på, at organisationer ikke bare skal forebygge, men også:
- opdage hændelser
- håndtere dem
- rapportere dem efter reglerne
Det betyder typisk:
Incident Response-plan
- hvem gør hvad ved ransomware, datalæk, nedbrud, kompromitterede konti osv.
- kontaktliste (internt og eksternt)
- playbooks for top-scenarier
- øvelser (tabletop er fint, hvis det bliver gjort)
Rapportering
Der er krav om at underrette relevante myndigheder inden for bestemte tidsrammer, afhængigt af hændelsens alvor og national implementering.
Du behøver ikke memorere paragraffer. Du skal have:
- en proces, der kan trykke på knappen hurtigt
- klar definition af “hvad er en væsentlig hændelse?”
- dokumentation for hvad der skete, og hvad I gjorde
3) Ledelsesansvar: det er ikke kun “IT’s problem” længere
NIS2 skubber ansvar opad. Ledelsen skal:
- godkende sikkerhedsforanstaltninger og risikostyring
- sikre at der er ressourcer
- kunne holdes ansvarlig, hvis man ignorerer det
Det betyder i praksis:
- ledelsen skal involveres i risikobillede og prioriteringer
- der skal være governance, der kan forklares i et tilsyn
- sikkerhed skal indgå i den normale ledelsesrapportering
Det er ikke for at være dramatisk. Det er for at stoppe “vi fik ikke budget til det” som standardforklaring.
Hvad skal I gøre nu? En realistisk startplan
Her er en lavpraktisk “første 30-60 dage”-plan, der ikke kræver en hel hær:
Trin 1: Afklar scope og klassificering
- er vi sandsynligt omfattet?
- essential vs important (hvis relevant)
- hvilke systemer er kritiske?
Trin 2: Lav en gap-liste (ikke en roman)
- 30–60 kontroller er nok til start
- vurder modenhed (0–3)
- find top 10-20 huller
Trin 3: Prioritér efter risiko
- hvad kan vælte driften?
- hvad giver størst skade (data, drift, forsyning, borgere, kunder)?
- hvad er lavthængende frugter (MFA, backup-test, admin hygiene)
Trin 4: Byg et 90-dages program
- owner på hver opgave
- deadline
- “definition of done”
- evidens (hvad kan I fremvise?)
Hvis du vil have en mere samlet ramme og indhold, der går direkte på praktisk compliance og implementering, så kan du tage udgangspunkt i NIS2 krav.
(Det er jeres ene backlink. Nyd det. Google gør.)
Typiske misforståelser (som koster tid)
“Vi køber bare et værktøj”
NIS2 handler ikke om at købe én platform. Du kan købe dig til dele af løsningen, men governance og proces skal stadig eksistere.
“Vi laver en politik”
Politikker uden implementering er bare pæne PDF’er. Tilsyn og realiteten kigger på praksis og evidens.
“Vi er ikke omfattet, så vi er ligeglade”
Hvis du er leverandør til en NIS2-omfattet aktør, bliver du presset alligevel. Bare via kontrakter og krav, i stedet for direkte lovtekst.
Konklusion
NIS2 er ikke (kun) compliance-teater. Det er et pres for at få styr på:
- risikostyring og kontroller
- hændelseshåndtering og rapportering
- ledelsesansvar og governance
- leverandørkæde og dokumentation
Og den vigtigste pointe:
Det handler ikke om at være perfekt. Det handler om at være systematisk, kunne dokumentere det, og have en plan der faktisk bliver eksekveret.
