NIS2 kort fortalt: Hvem er omfattet, og hvad ændrer sig i praksis?

Mange organisationer mærker lige nu, at nye EU-krav til cybersikkerhed ikke længere er “noget for IT-afdelingen”, men et ledelsesansvar, der påvirker drift, leverandører og budgetter. I denne artikel får du et praktisk overblik over direktivet, hvem det rammer, hvilke konsekvenser det kan få, og hvad der konkret ændrer sig i hverdagen.

Du får også en handlingsorienteret forståelse af, hvordan du vurderer din egen status, undgår typiske fejl og prioriterer de vigtigste tiltag. Målet er, at du efter læsning kan forklare kravene internt, planlægge næste skridt og stille de rigtige spørgsmål til både IT, jura og indkøb.

Hvad er direktivet, og hvorfor betyder det noget?

Direktivet er et sæt bindende EU-krav, der skal løfte cybersikkerhedsniveauet på tværs af sektorer og lande, især hvor samfundskritiske eller bredt anvendte tjenester kan blive ramt af cyberangreb. Kort sagt: det handler om styring, risikohåndtering og dokumentation af sikkerhed, ikke kun om teknik.

Det betyder noget, fordi angreb i dag ofte rammer gennem leverandørkæder, driftsmiljøer og menneskelige fejl. Kravene skubber derfor organisationer fra ad hoc-tiltag til systematik: klare roller, faste processer, hændelseshåndtering og løbende kontrol.

Mini-konklusion: Direktivet gør cybersikkerhed til et forretningsvilkår, hvor “vi gør noget” ikke er nok; man skal kunne vise, at man gør det rigtige.

Målgrupper: Hvem bliver omfattet, og hvordan vurderer man det?

Målgruppen er bredere end mange tror. Typisk bliver både væsentlige og vigtige enheder omfattet, afhængigt af sektor, størrelse og rolle i forsynings- og værdikæder. Det kan omfatte alt fra energi og transport til digitale tjenesteudbydere, sundhed, vand, finans og visse offentlige aktører.

Sådan laver du en hurtig afklaring

Start med at afklare sektor, størrelse (fx antal ansatte og omsætning) samt om I leverer kritiske tjenester eller er en central leverandør. Hvis I er i tvivl, så behandl det som en risikofaktor: det er lettere at skrue ned for et robust program end at bygge et i panik.

  • Kortlæg jeres primære ydelser og kunder
  • Vurder om I leverer samfundskritiske eller “bærende” funktioner
  • Afklar om I falder i en reguleret sektor eller underleverandørled
  • Match virksomhedens størrelse mod tærskler i nationale regler
  • Identificér om I driver netværk, driftstjenester eller digitale platforme
  • Dokumentér beslutningen og hvem der har godkendt den

Leverandører bliver en del af målgruppen i praksis

Selv hvis I ikke er direkte omfattet, kan I blive indirekte ramt via kontraktkrav, sikkerhedsaudits og krav om rapportering. Derfor bør man tænke “målgruppe” som et økosystem, ikke kun en juridisk kategori.

Mini-konklusion: Afklaring handler ikke kun om jura; den handler om, hvilken risiko I udgør for andre, og hvilken risiko andre udgør for jer.

De vigtigste ændringer: Fra tekniske kontroller til ledelsesstyring

Den største ændring er, at kravene typisk stiller skarpere forventninger til ledelsen, governance og konsekvensstyring. Sikkerhed bliver målbart, reviderbart og forankret i beslutningsprocesser. Det betyder bl.a., at man skal kunne dokumentere risikovurderinger, træffe valg om prioriteringer og følge op med kontroller.

Derudover strammes fokus på hændelser, rapportering og samarbejde med myndigheder. Organisationer skal kunne opdage, reagere og lære af angreb hurtigere, og de skal øve deres processer, ikke bare skrive dem.

  1. Ledelsesansvar for sikkerhedspolitik, ressourcer og opfølgning
  2. Systematisk risikostyring på tværs af IT, OT og forretning
  3. Skærpet krav til hændelseshåndtering og rapporteringsfrister
  4. Kontrol af leverandør- og supply chain-risici
  5. Bedre dokumentation, auditspor og løbende forbedringer

Mini-konklusion: Hvis I tidligere “var sikre nok”, er det nu nødvendigt at kunne bevise det med processer, beviser og kontinuerlig drift.

Konsekvenser: Hvad betyder det for drift, budget og risici?

Konsekvenserne er både praktiske og strategiske. Praktisk vil flere teams blive involveret: IT, informationssikkerhed, jura, compliance, HR, indkøb og forretningsansvarlige. Strategisk vil prioriteringen flytte sig fra enkeltprojekter til et program, hvor man arbejder i bølger og dokumenterer modenhed over tid.

Budgetmæssigt kan det betyde investeringer i overvågning, logning, backup, sårbarhedsstyring, identitets- og adgangsstyring samt træning. Men mange overser, at en stor del af omkostningen kan ligge i tid: møder, leverandørdialog, kontroller og rapportering. Det kan derfor betale sig at standardisere, genbruge skabeloner og automatisere evidensopsamling.

Hvad koster det typisk?

Der findes ikke ét tal, fordi udgangspunktet varierer voldsomt. En moden organisation kan nøjes med at lukke huller og stramme governance, mens andre skal bygge fundamentet fra bunden. Et realistisk svar er, at omkostningen består af tre poster: løft af teknisk sikkerhed, opbygning af processer samt drift af compliance. Hvis du vil estimere, så start med en gap-analyse og prissæt de største huller først.

Hvad sker der, hvis man ikke lever op til kravene?

Konsekvenser kan omfatte påbud, tilsyn, sanktioner og i værste fald bøder, men også tab af kontrakter, forsikringsdækning og omdømme. I praksis er den største risiko ofte, at man ikke opdager et brud i tide eller ikke kan dokumentere sin indsats efterfølgende.

Mini-konklusion: Det er sjældent billigst at vente; det er billigst at prioritere rigtigt og skabe en gentagelig model.

Hændelsesrapportering og beredskab: Hvad skal på plads?

Et centralt element er krav til håndtering og rapportering af sikkerhedshændelser. Det betyder, at man skal kunne vurdere alvor, påvirkning og udbredelse hurtigt, og at man skal have klare roller for beslutninger og kommunikation. Mange organisationer har en incident response-plan, men få har øvet den under realistisk pres.

Her er en enkel måde at tænke beredskab på: det er en kæde, hvor det svageste led bestemmer tempoet. Hvis overvågning er stærk, men beslutningsveje er uklare, bliver reaktionen stadig langsom.

  • Definér hvad en hændelse er, og hvornår den eskaleres
  • Udpeg ansvarlige roller og stedfortrædere
  • Sikre kontaktliste til myndigheder, leverandører og nøglepersoner
  • Træn beslutninger: isolering, nedlukning, kommunikation, genopretning
  • Forbered bevisindsamling og logadgang til efteranalyse

Midt i arbejdet kan det være nyttigt at holde kravene op mod kendte rammer og fortolkninger, og mange bruger betegnelsen NIS2 som den praktiske reference til det samlede forventningsniveau på tværs af EU og nationale implementeringer.

Mini-konklusion: Beredskab er ikke et dokument; det er en muskel, der skal trænes med faste øvelser og klare grænser for ansvar.

Supply chain og leverandørstyring: Den oversete gamechanger

Angribere går ofte efter den letteste vej ind, og det er tit via leverandører, driftspartnere eller softwarekomponenter. Derfor bliver leverandørstyring et kerneområde. Det handler ikke kun om at få en underskrevet sikkerhedserklæring, men om at kunne vurdere risiko, stille konkrete krav og følge op.

Best practice for kontrakter og kontrol

Gør kravene konkrete: logning, patching, adgangsstyring, underdatabehandlere, ændringsstyring og rapportering ved hændelser. Indbyg også ret til audit eller alternative beviser, fx tredjepartsrapporter, så I ikke står uden indsigt, når det gælder.

Typiske fejl i leverandørarbejdet

En klassisk faldgrube er at stille for mange krav uden prioritering, så leverandøren svarer med generelle politikker. En anden er at fokusere på indkøb, men glemme driftsfasen, hvor ændringer, nye features og personaleudskiftning skaber nye risici. Løsningen er en risikobaseret model med faste opfølgningspunkter.

Mini-konklusion: Leverandører er ikke et bilag; de er en del af jeres angrebsflade, og det skal styres løbende.

Faldgruber og hvordan du undgår dem

De fleste fejl skyldes ikke manglende vilje, men manglende struktur. Når man forsøger at “compliance-fikse” på kort tid, ender man ofte med flotte dokumenter uden driftsevne. Det giver en falsk tryghed, som kan være farligere end at erkende hullerne.

  • Faldgrube: Kun IT involveres. Løsning: Etabler tværgående governance med klare ejere.
  • Faldgrube: Ingen baseline. Løsning: Lav gap-analyse og modenhedsvurdering først.
  • Faldgrube: For mange kontroller på én gang. Løsning: Prioritér top-risici og skab en roadmap.
  • Faldgrube: Leverandørkrav uden opfølgning. Løsning: Sæt rytme for review og evidens.
  • Faldgrube: Incident plan uden øvelser. Løsning: Kør table-top og tekniske øvelser hvert kvartal.

Mini-konklusion: Den hurtigste vej til robusthed er fokus på få, stærke processer, der faktisk bliver brugt.

Sådan kommer du i gang: En realistisk plan de næste 90 dage

Hvis du skal omsætte krav til handling, så tænk i faser. Først skal I skabe overblik og ejerskab, derefter lukke de største risici, og til sidst etablere en drift, der kan dokumentere og forbedre. En 90-dages plan kan give momentum uden at skabe kaos.

Uge 1–4: Overblik og beslutninger

Udpeg en ansvarlig sponsor i ledelsen, og lav en kort scope-afklaring: hvilke systemer, forretningsprocesser og leverandører er i spil. Herefter gennemfører I en gap-analyse og prioriterer de 5–10 vigtigste huller. Sørg for, at beslutninger bliver skrevet ned med begrundelser.

Uge 5–8: Luk de største huller

Typisk giver det mest effekt at styrke adgangsstyring, patching, backup og overvågning, fordi de både reducerer risiko og forbedrer jeres reaktionstid. Samtidig kan I standardisere leverandørkrav og indføre en enkel proces for risikovurderinger ved ændringer.

Uge 9–12: Gør det driftsklart

Indfør faste møder for risici og hændelser, opbyg et evidensbibliotek, og planlæg en øvelse af jeres incident response. Mål på få indikatorer: fx patch-tid, backup-test, antal kritiske sårbarheder og tid til eskalering. Det er her, compliance bliver til hverdag.

Mini-konklusion: En god plan er ikke lang; den er tydelig om scope, ejere, prioritering og hvordan succes måles.

FAQ i praksis: De spørgsmål du bør kunne svare på internt

Hvad skal vi gøre lige nu? Start med scope, gap-analyse og en prioriteret roadmap. Hvorfor haster det? Fordi kravene typisk kombinerer rapportering, tilsyn og forventning om modenhed, og fordi angreb ikke venter på implementeringsdatoer. Hvordan ved vi, om vi gør nok? Når I kan vise, at risici vurderes, kontroller følges, og hændelser håndteres efter en øvet plan.

Hvilke fejl ser man ofte? Overdokumentation, uklare roller, og at man glemmer leverandører og driftsændringer. Hvad er bedste praksis? Risikobaseret prioritering, få men stærke processer, og automatisering af logning og evidens, hvor det giver mening. Hvad koster det? Det afhænger af udgangspunktet, men den største besparelse ligger ofte i at undgå dobbeltarbejde og at vælge standarder, der kan genbruges på tværs af teams.

Mini-konklusion: Når I kan forklare hvad, hvorfor og hvordan på en side papir, er I tættere på at kunne efterleve kravene i drift.