NIS2 bliver først rigtig dyrt, når det behandles som “noget IT lige fikser” i stedet for et ledelsesansvar med klare beslutninger, prioriteringer og ansvar.
I denne artikel får du et praktisk overblik over, hvorfor NIS2 handler om governance og forretningens risici – og hvordan du som leder, compliance-ansvarlig eller sikkerhedschef kan organisere arbejdet, så det bliver styrbart. Du får konkrete eksempler, typiske faldgruber, og en handlingsliste til at komme fra hensigt til dokumenterbar efterlevelse.
Du får især værdi, hvis du står med spørgsmål som: Hvem ejer NIS2? Hvad koster det i tid og penge? Hvordan prioriterer vi mellem drift, projekter og sikkerhed? Og hvordan undgår vi at ende med et “compliance-teater”, der falder sammen ved første tilsyn eller hændelse?
Hvad er NIS2 – og hvorfor betyder det noget for ledelsen?
NIS2 er EU’s opdaterede direktiv om cybersikkerhed, som skærper kravene til risikostyring, hændelseshåndtering og ledelsesansvar for en bredere kreds af virksomheder og organisationer end tidligere. Direktivet omsættes til national lovgivning, og fællesnævneren er tydelig: cybersikkerhed bliver en styringsdisciplin på linje med økonomi, kvalitet og arbejdsmiljø.
Det betyder noget, fordi kravene ikke kun handler om tekniske kontroller, men om, at ledelsen skal kunne dokumentere beslutninger, prioriteringer og opfølgning. Når en hændelse rammer, er spørgsmålet sjældent “hvilken firewall havde I?”, men “hvilke risici accepterede I, og hvorfor?”
Mini-konklusion: NIS2 er ikke en tjekliste til IT-afdelingen; det er et krav om, at organisationen styrer cyberrisiko med ledelsesmæssig disciplin.
Hvorfor NIS2 ikke kan reduceres til et IT-projekt
Et klassisk IT-projekt har en afgrænset scope, en start og en slutdato. NIS2-arbejdet har derimod en løbende karakter: risici ændrer sig, leverandører skifter, forretningen vokser, og trusselsbilledet udvikler sig uge for uge. Derfor er NIS2 i praksis et governance- og driftssetup, der skal fungere over tid.
Det bliver også hurtigt tydeligt, at mange centrale krav ligger uden for IT’s kontrol: kontrakter, leverandørstyring, HR-processer, træning, beredskab, kommunikation og beslutningsveje. IT kan implementere tekniske tiltag, men kan ikke alene sikre, at organisationen faktisk prioriterer dem rigtigt.
Cybersikkerhed er forretningsrisiko – ikke systemrisiko
Hvis et ERP-system er nede i 24 timer, er det ikke bare “nedetid”; det kan være tabt omsætning, brudte leveringsaftaler, bod, omdømmeskade og ekstraomkostninger i logistik. Mange ledelser undervurderer, at cyberhændelser ofte rammer på tværs: drift, kundeservice, økonomi, leverance og juridisk.
Som tommelfingerregel kan en mellemstor produktionsvirksomhed miste et betydeligt beløb pr. time i forstyrret drift, når man medregner stop i produktion, spild, hastetransport og overarbejde. Derfor skal risikovurderinger forankres i forretningens konsekvenser – ikke kun i tekniske sårbarheder.
IT kan ikke beslutte acceptabel risiko
Det er ledelsen, der ejer beslutningen om, hvilke risici man accepterer, og hvilke man mitigere. IT kan og skal rådgive, men det er ikke IT, der kan legitimere at leve med f.eks. manglende segmentering, utilstrækkelig backup eller et forældet system, hvis konsekvensen er kritisk for forretningen.
Mini-konklusion: Når NIS2 behandles som et IT-projekt, mangler der typisk et klart risikoejerskab – og så ender man enten med overkontrol eller farlige huller.
Governance: Hvem ejer hvad – og hvordan ser “god styring” ud?
Governance er i praksis svaret på tre spørgsmål: Hvem beslutter? Hvem udfører? Hvem kontrollerer, at det virker? NIS2 presser organisationer til at gøre dette eksplicit, fordi ansvar uden mandat er det samme som ingen ansvar.
En enkel governance-model, der virker i praksis
I mange organisationer fungerer en “tre-linjer”-tænkning godt, uden at det bliver tungt:
- Ledelsen fastlægger risikoniveau, prioriterer budget og godkender politikker og beredskab.
- 1. linje (forretning og IT-drift) implementerer kontroller og leverer sikker drift.
- 2. linje (compliance/risk) sætter rammer, hjælper med risikovurdering og følger op.
- 3. linje (intern/ekstern audit) tester uafhængigt, om kontroller virker som tiltænkt.
Det afgørende er ikke, hvad linjerne hedder, men at der er adskillelse mellem dem, der “gør”, og dem, der “tjekker”. Ellers ender man med selv-evaluering forklædt som kontrol.
RACI: Den hurtigste vej til klarhed
Hvis NIS2-arbejdet går i stå, skyldes det ofte uklare roller. En RACI-matrix (Responsible, Accountable, Consulted, Informed) kan på få timer skabe klarhed for centrale områder som risikovurdering, patching, backup, leverandørstyring, awareness og incident response.
Mini-konklusion: God NIS2-governance er ikke flere møder – det er tydelige beslutningsveje, ejerskab og dokumentation for, at styringen fungerer.
Prioritering: Fra “alt er vigtigt” til en realistisk plan
Det største praktiske problem i NIS2-arbejdet er sjældent vilje; det er prioritering. Mange teams drukner i opgavelister, fordi de starter med tekniske kontrolkataloger i stedet for at starte med de vigtigste forretningsprocesser og de mest sandsynlige angrebsscenarier.
Start med de kroniske risici: Identitet, backup, leverandører
På tværs af brancher går de samme temaer igen, når man gennemgår hændelser og modenhed:
- Identitet og adgang: MFA, admin-rettigheder, joiner/mover/leaver-processer.
- Backup og gendannelse: testede restore-planer, isolation, RPO/RTO.
- Patch- og sårbarhedsstyring: ansvar, vinduer, undtagelser og rapportering.
- Leverandør- og tredjepartsrisiko: kontraktkrav, due diligence, opfølgning.
- Hændelseshåndtering: roller, eskalation, kommunikation, logning.
- Netværkssegmentering: begræns bevægelse ved kompromittering.
Du behøver ikke løse alt på én gang. Men du skal kunne forklare, hvorfor du løser netop disse ting først, og hvornår resten kommer. Det er det, tilsyn og bestyrelser lytter efter.
Brug “minimum viable compliance” – men gør det ærligt
Det er legitimt at arbejde iterativt, så længe det er gennemsigtigt. En god tilgang er at definere en minimumspakke, der reducerer de største risici hurtigt (typisk 8–12 uger), og derefter en modenhedsplan over 6–18 måneder.
Mini-konklusion: Den bedste prioritering er den, du kan forsvare med risikologik og dokumentere med milepæle – ikke den, der ser pæn ud i et regneark.
Ledelsens ansvar i praksis: Beslutninger, dokumentation og kultur
NIS2 gør det nødvendigt, at ledelsen kan vise aktiv involvering: at man har taget stilling, allokeret ressourcer og følger op. Det handler ikke om at “blive teknisk”, men om at lede en risikodagsorden, hvor IT er en central leverandør.
De 5 ledelsesbeslutninger, der typisk mangler
- Hvilke forretningsprocesser er kritiske, og hvad er acceptabel nedetid?
- Hvilket risikoniveau accepterer vi for legacy-systemer – og hvad er exit-planen?
- Hvem har mandat til at stoppe drift/ændringer ved kritiske sårbarheder?
- Hvilke leverandører er “kritiske”, og hvilke minimumskrav stiller vi til dem?
- Hvad er vores beredskabsmål: tid til at opdage, reagere og genetablere?
Hvis disse beslutninger ikke er taget, ender IT ofte med at træffe dem implicit – og det er netop dét, NIS2 forsøger at undgå.
Kultur og adfærd: Awareness uden plakater
Træning virker bedst, når den kobles til rolle og situation: økonomi får fokus på betalingssvindel og godkendelsesflows, drift får fokus på fjernadgang og ændringsstyring, ledere får fokus på eskalation og beslutninger under pres. En årlig e-learning alene flytter sjældent adfærd; korte øvelser og konkrete scenarier gør.
Mini-konklusion: Ledelsesansvar i NIS2 er at sætte retning, træffe de svære valg og sikre, at organisationen kan bevise, at den gør det, den siger.
Sådan kommer I fra krav til kontroller: Et operationelt NIS2-program
Et NIS2-program bør designes, så det kan køre i en travl organisation med begrænsede ressourcer. Det betyder faste rytmer, få men skarpe målepunkter og tydelig rapportering. Midt i dette arbejde giver det ofte mening at samle krav, gap-analyse og dokumentationsbehov ét sted, så både ledelse og teams kan navigere i det – for eksempel via en struktureret tilgang til NIS2 compliance som tydeliggør, hvad der skal være på plads.
Et pragmatisk 90-dages forløb (eksempel)
Et typisk forløb jeg har set virke i praksis, ser sådan ud:
- Uge 1–2: Afgrænsning, kritiske services, risikokriterier og governance (RACI, mødestruktur).
- Uge 3–5: Gap-analyse på identitet, backup, logging, patching, leverandører.
- Uge 6–8: Implementér “hurtige gevinster” og opdater politikker/procedurer, så de matcher virkeligheden.
- Uge 9–10: Incident response-øvelse og forbedringsplan (inkl. kommunikationsflow).
- Uge 11–13: Ledelsesrapport, risikoregister, roadmap og budgetforslag.
Det vigtige er, at hvert skridt ender i noget, der kan bruges: beslutninger, kontroller, beviser og en plan – ikke bare slides.
Hvad koster NIS2-arbejdet – og hvad koster det at lade være?
“Hvad koster NIS2?” er et fair spørgsmål, men svaret afhænger af modenhed, kompleksitet og leverandørlandskab. De største omkostningsdrivere er typisk: oprydning i identiteter og rettigheder, opgradering af logging/overvågning, backup-robusthed, segmentering og ressourcer til governance og leverandørstyring.
Som et konkret pejlemærke ser man ofte, at organisationer med lav modenhed bruger mest på at få basale kontroller på plads (og på at rydde op i historisk gæld), mens mere modne organisationer bruger relativt mere på dokumentation, test, øvelser og løbende forbedringer. Det er sjældent “én engangsudgift”; det er en kombination af etablering og drift.
Omkostningen ved at lade være er til gengæld typisk undervurderet. Når en hændelse rammer, er de dyreste poster ofte ikke teknik, men forretningsforstyrrelse, krisehåndtering, genopretning, tab af tillid og ekstraarbejde. Det er her governance betaler sig: hurtigere beslutninger og færre fejl under pres.
Mini-konklusion: NIS2 koster penge og tid, men fraværet af styring koster næsten altid mere – især når tempoet er højt, og konsekvenserne er forretningskritiske.
Typiske fejl og faldgruber – og sådan undgår I dem
De samme mønstre går igen, når NIS2-initiativer mislykkes eller bliver til “papir”. Her er de mest almindelige – og hvad du kan gøre ved dem.
- Faldgrube: Politikker skrives, men processer ændres ikke. Undgå: Kræv evidens: logs, tests, øvelser og stikprøver.
- Faldgrube: Uklar ejerskab mellem IT, risk og forretning. Undgå: Lav RACI og få den godkendt i ledelsen.
- Faldgrube: Man starter med værktøjer i stedet for risici. Undgå: Start med kritiske services og realistiske scenarier.
- Faldgrube: Leverandører antages “at have styr på det”. Undgå: Kontraktkrav, opfølgning og klassificering af kritiske leverandører.
- Faldgrube: Backup findes, men restore er aldrig testet. Undgå: Planlagte restore-tests med klare RTO/RPO.
- Faldgrube: Incident response er en PDF uden telefonnumre og mandat. Undgå: Korte øvelser og konkrete eskalationsregler.
Mini-konklusion: NIS2 fejler sjældent på ambition; det fejler på udførelse og manglende ledelsesopfølgning.
Bedste praksis: Sådan gør I NIS2 til en ledelsesdisciplin
Når NIS2 fungerer godt, føles det ikke som et projekt, men som en måde at drive forretning sikkert på. Det kræver en ledelsesrytme og en rapportering, der gør cyberrisiko forståelig uden at forsimple den.
En enkel rapportering, som bestyrelse og direktion faktisk kan bruge
Hold det på få, skarpe indikatorer, der kan følges månedligt eller kvartalsvist:
- Antal kritiske sårbarheder over SLA (og hvorfor de ikke er lukket)
- Status på backup/restore-tests (seneste test og resultater)
- Phishing- og identitetsindikatorer (f.eks. MFA-dækning, admin-konti)
- Kritiske leverandører: risikostatus og seneste review
- Hændelser og “near misses”: læring og forbedringstiltag
Gør plads til undtagelser – men styr dem
Ingen organisation er 100% “compliant” hele tiden. Legacy, opkøb, tidskritiske leverancer og teknisk gæld findes. Derfor bør I have en formaliseret undtagelsesproces: hvem godkender, hvor længe, hvilke kompensationskontroller, og hvornår revurderes det. Det er et af de mest undervurderede governance-værktøjer.
Mini-konklusion: NIS2 bliver ledelsesdisciplin, når risici, undtagelser og fremdrift kan
About the Author
