NIS2 kan føles som et kæmpe, abstrakt compliance-projekt—lige indtil du bryder det ned i drift, roller og helt konkrete opgaver.
I denne artikel får du en operationel måde at arbejde med NIS2 på: en trin-for-trin tilgang, som kan bruges af både IT, sikkerhed, ledelse og forretningen. Du får også typiske faldgruber, realistiske estimater for tid og omkostninger samt eksempler på, hvordan du omsætter krav til praksis.
Målet er, at du kan gå fra “vi skal være NIS2-compliant” til en plan med tydelige leverancer, ejerskab og målepunkter—uden at drukne i paragraffer.
Hvad er NIS2, og hvorfor betyder det noget?
NIS2 er EU’s direktiv for cybersikkerhed, der skærper kravene til risikostyring, hændelseshåndtering, leverandørstyring og ledelsesansvar for udvalgte sektorer og virksomheder. Kort sagt: NIS2 kræver, at cybersikkerhed bliver en styret, dokumenteret og kontrolleret del af driften—ikke et ad hoc-initiativ.
Hvorfor det betyder noget: For mange virksomheder ændrer NIS2 “best effort” til “dokumenteret ansvar”. Det handler både om at reducere risikoen for driftsstop og databrud samt om at kunne påvise, at man arbejder systematisk med sikkerhed.
Mini-konklusion: Hvis du behandler NIS2 som et rent IT-projekt, bliver det dyrere og sværere. Hvis du behandler det som driftsledelse med IT som motor, bliver det gennemførligt.
Start rigtigt: Afgrænsning, scope og “hvad der er i spil”
Det første praktiske skridt er at afklare, hvad NIS2 gælder for hos jer: hvilke enheder, systemer, lokationer og leverancer. Mange går galt her ved at vælge et for bredt scope og forsøge at “fikse alt på én gang”.
Kortlæg dine kritiske services før du kortlægger alt andet
Jeg anbefaler at starte med 3–10 kritiske services, fx “ordreflow”, “produktion”, “kundesupport”, “betalingsflow” eller “logistikplanlægning”. For hver service beskriver du:
- Hvem bruger servicen, og hvad er “god drift” (SLA/SLO i praksis)?
- Hvilke systemer, integrationer og data afhænger den af?
- Hvilke leverandører/outsourcingleverancer indgår?
- Hvilke hændelser giver reelt stop eller alvorlig påvirkning?
Et konkret eksempel på scope, der virker
En mellemstor produktionsvirksomhed valgte at starte med to services: “produktionsplanlægning” og “lager/EDI”. I stedet for at kortlægge hele IT-landskabet kortlagde de kun de systemer og leverandører, der understøttede disse services. Det gav et scope på ca. 25 systemkomponenter frem for 140—og gjorde risikovurdering og kontroller realistiske.
Mini-konklusion: Scope bliver operationelt, når det tager udgangspunkt i services og konsekvenser—ikke i en fuld asset-liste fra dag ét.
Trin 1: Gap-analyse, der kan omsættes til opgaver
En klassisk NIS2-gap-analyse ender ofte som en lang rapport uden ejerskab. For at gøre den brugbar skal du oversætte “krav” til “kontroller” og derefter til “aktiviteter”.
Brug et simpelt format pr. kontrolområde:
- Hvad kræver vi i praksis (policy/standard)?
- Hvad gør vi i dag (evidens)?
- Hvad mangler der (gap)?
- Hvem ejer det (rolle/navn)?
- Hvordan måler vi det (KPI/KRI)?
- Hvornår er det “godt nok” (acceptkriterie)?
Det gør det muligt at oprette konkrete tickets/epics i jeres backlog i stedet for at parkere arbejdet i et Word-dokument.
Mini-konklusion: En god gap-analyse slutter ikke med “mangler” men med en prioriteret backlog, ejere og målbare acceptkriterier.
Trin 2: Byg et minimums-ISMS i drift (uden at opfinde et bureaukrati)
NIS2 læner sig op ad velkendte principper fra ISO 27001/27002: styring, dokumentation og løbende forbedring. Du behøver ikke et tungt ISMS for at komme i gang, men du skal have et “minimum viable ISMS”, der virker i hverdagen.
De 6 styringsartefakter, der typisk giver mest effekt
- Sikkerhedspolitik i 1–2 sider: formål, principper, ansvar, sanktioner.
- Risikostyringsmetode: skalaer for sandsynlighed/konsekvens og beslutningsproces.
- Asset- og servicekatalog (start small): hvad er kritisk, og hvem ejer det?
- Kontrolkatalog: hvilke kontroller har I valgt, og hvor gælder de?
- Afvigelses- og forbedringslog: hvad blev fundet, hvornår lukkes det?
- Ledelsesrapportering: månedlig/kvartalsvis status med 5–10 nøgletal.
Sådan undgår du “compliance-teater”
Den mest almindelige fejl er at skrive flotte politikker uden at ændre drift. Løsningen er at kræve evidens fra dag 1: skærmbilleder, logudtræk, uddannelseslister, change records, testresultater. Hvis en kontrol ikke kan bevises, eksisterer den reelt ikke, når det gælder.
Mini-konklusion: Det mest effektive ISMS er det, der kan forklares på 10 minutter—og dokumenteres på 10 sekunder.
Trin 3: Risiko og proportionalitet—prioritér som en forretning, ikke som en tjekliste
NIS2 handler ikke om at implementere “alt” men om at implementere det rigtige i forhold til risiko. Her er proportionalitet nøglen: de mest kritiske services og mest sandsynlige trusler først.
En praktisk tilgang er at køre risiko-workshops pr. kritisk service (60–90 min) med IT, drift og en forretningsrepræsentant. Identificér 5–10 top-scenarier pr. service, fx ransomware, fejlkonfiguration, leverandørnedbrud, insiderfejl, DDoS eller utilsigtet datatab.
Derefter kan du koble scenarierne til konkrete kontroller: backup/restore, segmentering, MFA, hardening, patching, logning, træning, beredskab osv.
Bedste praksis: Prioritér kontroller, der både reducerer sandsynlighed og konsekvens. Eksempel: testet restore reducerer konsekvens drastisk, selv hvis et angreb lykkes.
Mini-konklusion: Når risiko bliver koblet til services, bliver investeringer i sikkerhed lettere at forklare—og lettere at prioritere.
Trin 4: Incident response og rapportering—gør det “øvelsesklart”
Mange virksomheder har en incident-proces på papir, men den falder fra hinanden i en rigtig hændelse. NIS2 skubber på for, at I kan reagere hurtigt, koordinere og dokumentere. Det kræver ikke en SOC fra dag ét, men det kræver et beredskab, der kan aktiveres.
Minimums-setup til hændelseshåndtering
For at gøre det operationelt bør du som minimum have:
- En klar definition af “incident” vs. “problem” vs. “change” (ellers drukner I i støj).
- En vagt/tilkaldeplan (også hvis den bare er en telefonkæde).
- En skabelon til incident-log: tidslinje, beslutninger, beviser, kommunikation.
- Et teknisk “first response kit”: logkilder, adgang, isolation, snapshots.
- En øvelseskalender: 2 tabletop-øvelser årligt og 1 teknisk øvelse.
Kommunikation: den oversete kontrol
Under hændelser er intern kommunikation ofte flaskehalsen. Aftal på forhånd, hvem der udtaler sig til kunder, hvem der informerer ledelse, og hvem der koordinerer med leverandører. En enkel RACI (Responsible, Accountable, Consulted, Informed) kan spare timer, når det brænder på.
Mini-konklusion: Hvis I ikke har øvet jeres incident-proces, har I reelt ikke en proces—kun et dokument.
Trin 5: Leverandør- og supply chain-sikkerhed i praksis
NIS2 lægger vægt på risici i leverandørkæden, og i mange virksomheder er det her, de største huller findes: outsourced drift, cloud, ERP-partnere, MSP’er, integrationshuse og nicheleverandører.
Et typisk “quick win” er at kategorisere leverandører efter kritikalitet og adgang. Du behøver ikke samme krav til kantineleverandøren som til den, der driver jeres AD, cloud eller produktionsnet.
- Kritisk leverandør: direkte drift af kritiske services eller adgang til følsomme systemer/data.
- Vigtig leverandør: påvirker drift væsentligt, men uden dyb adgang.
- Standard leverandør: lav påvirkning og minimal adgang.
For kritiske leverandører kan du kræve konkrete ting som patch-SLA, MFA, logging, adskillelse af kundemiljøer, hændelsesnotifikation og dokumentation (fx ISO 27001- eller SOC 2-rapporter, hvor det giver mening).
Midt i dette arbejde vil mange have gavn af en mere struktureret guide til implementering af NIS2 som støtte til at omsætte kravene til kontroller, evidens og en realistisk plan.
Mini-konklusion: Leverandørstyring virker, når du differentierer krav efter risiko—og når du kan følge op med stikprøver og konsekvenser.
Trin 6: Tekniske kontroller, der typisk giver mest NIS2-effekt pr. krone
Spørgsmålet “hvad skal vi implementere teknisk?” kommer altid. Svaret afhænger af jeres risiko, men der er et mønster i, hvilke kontroller der næsten altid flytter noget i audits og i den reelle sikkerhed.
Her er en prioriteret liste, som ofte giver høj effekt i SMV’er og mellemstore organisationer:
- MFA på alle administrative adgangsveje og eksterne logins (VPN, cloud, mail).
- Patch management med faste vinduer og undtagelsesproces (ikke “når vi når det”).
- Backup og restore-test (fx månedlig test af en kritisk service, kvartalsvis fuld test).
- Central logning for kritiske systemer (og alarmer på de vigtigste hændelser).
- Segmentering af netværk (især mellem kontor-IT og produktion/OT, hvis relevant).
- Privileged access: begræns admin-konti, brug “just-in-time” hvor muligt.
En nyttig tommelfingerregel: Hvis I kan gendanne en kritisk service på timer i stedet for dage, falder den forretningsmæssige risiko dramatisk—ofte mere end ved at købe endnu et sikkerhedsværktøj.
Mini-konklusion: Vælg tekniske kontroller, der reducerer både sandsynlighed og nedetid—og dokumentér dem med målinger og testresultater.
Hvad koster NIS2-arbejdet, og hvordan planlægger man realistisk?
“Hvad koster det?” afhænger især af modenhed, kompleksitet og hvor meget der er outsourcet. Men du kan bruge nogle realistiske pejlemærker for at planlægge indsatsen.
I praksis ser jeg ofte disse intervaller for en mellemstor virksomhed, der starter fra “rimelig IT-drift, men begrænset dokumentation”:
- Foranalyse + scope + første gap-analyse: 2–6 uger.
- Grundlæggende ISMS og governance: 4–10 uger.
- Tekniske forbedringer (MFA, backup-tests, logging, patch-proces): 1–4 måneder, ofte parallelt.
- Leverandørsporet (kritiske kontrakter, krav, opfølgning): 1–3 måneder.
- Øvelser og driftssætning (kontinuerligt): 2–4 uger for første cyklus.
Omkostningsmæssigt kan det spænde fra “primært interne timer” til større investeringer i logging, EDR, segmentering eller konsulenthjælp. Den dyreste løsning er næsten altid den reaktive: at vente til et angreb eller en myndighedsforespørgsel tvinger jer til hasteindsatser.
Mini-konklusion: Planlæg NIS2 som et program med faser og milepæle—ikke som en engangsleverance. Det gør både budget og bemanding mere stabile.
Typiske fejl og faldgruber—og hvordan du undgår dem
NIS2-arbejdet bliver oftest tungt, når organisationen falder i nogle velkendte mønstre. Her er de hyppigste fejl og de konkrete modtræk:
- For bredt scope fra start: Start med kritiske services og udvid iterativt.
- Dokumenter uden drift: Kræv evidens og kobling til ITSM/changes fra dag 1.
- Ingen klar rollefordeling: Udpeg ejere pr. service og pr. kontrol (ikke “IT” som ejer).
- Overfokus på værktøjer: Processer og ansvar før nye platforme—værktøjer kan understøtte, ikke erstatte.
- Manglende ledelsesinvolvering: Fast kvartalsvis rapportering med nøgletal og beslutningspunkter.
- Leverandørblindhed: Kortlæg adgang og afhængigheder, og stil differentierede krav.
Et praktisk tip: lav en “NIS2-uge” hvert kvartal, hvor I lukker afvigelser, opdaterer risici og gennemfører en mini-øvelse. Det skaber rytme og gør compliance til drift.
Mini-konklusion: De fleste problemer skyldes ikke manglende vilje, men manglende struktur. Når struktur og ejerskab er på plads, følger kontrollerne efter.