Mange virksomheder spørger: “Er vi omfattet af NIS2, fordi vi har IT?” Svaret er næsten altid: Det er den forkerte vinkel. NIS2 handler om, hvilken sektor I opererer i, hvilken rolle I har i værdikæden, og hvor kritisk jeres leverancer er for samfund og økonomi, ikke om I har en helpdesk, en ERP-løsning eller en cloudkonto.
I denne guide får du en praktisk scope-model, der hjælper jer med at afklare, om og hvordan NIS2 rammer jer, og hvad I realistisk skal kunne dokumentere. Du får også typiske fejl at undgå, samt en konkret tjekliste til den første uge, så CISO, IT, ledelse og jura kan lande et fælles scope hurtigt.
Hvad betyder “NIS2 omfattet” i praksis?
NIS2 er EU’s opdaterede direktiv om cybersikkerhed, der stiller krav til risikostyring, hændelseshåndtering og ledelsesansvar hos udvalgte organisationer. En kort definition er: NIS2 kræver, at visse virksomheder og offentlige aktører styrer og dokumenterer cybersikkerhed proportionalt med deres risiko og samfundsmæssige betydning.
Derfor betyder “omfattet” ikke bare “vi bruger IT”, men “vores forretningsydelser falder inden for en reguleret sektor, og vores rolle/kritikalitet gør os til en relevant aktør”. Mini-konklusion: Hvis I starter med at kortlægge services og kritikalitet, undgår I måneder med gætterier.
En trinvis scope-model, der kan bruges med det samme
Det vigtigste er at gøre scope til en kontrolleret proces, ikke en mavefornemmelse. Modellen her kan gennemføres i workshops og korte interviews, og den giver et spor, I kan forklare til både ledelse, revisor og myndighed.
- Identificér forretningsydelser: Hvad leverer I reelt til kunder, borgere eller partnere?
- Match ydelser til NIS2-sektor-kategorier: Hvor hører leverancen hjemme?
- Kortlæg afhængigheder: Hvad skal fungere, før leverancen fungerer?
- Fastlæg minimum-sikkerhedsdomæner: Hvilke kontroller kan I dokumentere, og hvor er hullerne?
- Valider scope: Få enighed på tværs af IT, forretning og jura.
- Planlæg evidens: Hvilke politikker, logs, kontrakter og processer bliver jeres beviser?
Mini-konklusion: Et godt NIS2-scope er ikke “alt i virksomheden”, men heller ikke “kun fire servere”; det er den del af forretningen, der driver kritiske ydelser og deres nødvendige understøttelse.
Trin 1: Identificér forretningsydelserne, ikke teknologien
Start med at beskrive jeres ydelser i et sprog, forretningen forstår. “Vi driver en Kubernetes-platform” er sjældent en ydelse; “vi leverer online booking og betalingsflow til sundhedsklinikker” er en ydelse. Formulér dem som løfter til omverdenen med tydelige output.
Sådan finder du ydelserne hurtigt
- Tag udgangspunkt i fakturaer, kontrakter og servicekataloger.
- Spørg salg/forretning: Hvad ville kunden savne i morgen, hvis I forsvandt?
- Skeln mellem kerneydelser og støttefunktioner.
- Gruppér variationer: Fem små produkter kan være én samlet digital service.
- Notér tilgængelighedskrav: 24/7, kontortid, batch, deadlines.
Vurder kritikalitet med enkle kriterier
Kritikalitet kan vurderes pragmatisk: påvirkning på sikkerhed, økonomi, drift, mennesker og lovkrav. Hvis et nedbrud stopper en forsyningskæde, påvirker patientforløb eller lammer transaktioner, er det et tydeligt signal. Mini-konklusion: Jo bedre I beskriver ydelser og konsekvenser, jo mere præcis bliver jeres NIS2-afgrænsning.
Trin 2: Match ydelser til NIS2-sektor-kategorier
Næste skridt er at koble jeres ydelser til de sektor-kategorier, der typisk nævnes i NIS2-kontekst: energi, transport, sundhed, finans, drikkevand, digital infrastruktur, offentlige tjenester, data- og online-tjenester m.fl. Det er her, mange går galt, fordi de ser “IT” som sektor, selvom deres rolle i praksis kan være leverandør til en kritisk sektor.
Hvis I vil have en hurtig og praktisk oversigt over, hvordan begrebet bruges i en dansk kontekst, kan I sammenholde jeres egne ydelser med en sektionsliste som den, der fremgår af NIS2 omfattet, og derefter validere jeres match med jura eller compliance. Pointen er ikke at “vinde en debat”, men at få en sporbar begrundelse.
Husk rolle i værdikæden
To virksomheder kan levere “software”, men blive vurderet forskelligt. Er I en direkte operatør af en kritisk service, en managed service provider, en cloud-/hostingpartner, eller en underleverandør med adgang til kundens systemer? Rollen bestemmer, hvilke krav der bliver relevante, og hvor meget myndigheder forventer af jer.
Mini-konklusion: Match på både sektor og rolle, ellers ender I med et scope, der enten undervurderer ansvar eller overdriver krav.
Trin 3: Kortlæg afhængigheder: leverandører, cloud og drift
NIS2-scope stopper ikke ved jeres egne systemer. Hvis en kritisk ydelse afhænger af en cloudplatform, en underleverandør, en driftspartner eller en betalingsgateway, skal afhængigheden med i billedet. Det handler ikke om at kontrollere alt, men om at kunne styre risikoen og stille krav.
Leverandørkæden: hvem kan vælte jeres service?
Lav en liste over de leverandører, der kan påvirke fortrolighed, integritet og tilgængelighed. Tænk i adgang (hvem kan logge ind), dataflow (hvem behandler data), og single points of failure. Inkludér også supportaftaler: hvis I kun kan få hjælp “best effort” på en kritisk platform, er det en reel forretningsrisiko.
Cloud og drift: evidens er lige så vigtig som arkitektur
Mange tror, at cloud “automatisk” leverer compliance. Men NIS2 forventer, at I kan dokumentere jeres egne beslutninger: hardening, rettighedsstyring, logning, backup, ændringsstyring og beredskab. Mini-konklusion: En moderne stack kan være sikker, men kun hvis I kan vise, hvordan den drives.
Trin 4: Inkludér OT/IoT, hvis det påvirker leverancen
Hvis jeres ydelser hænger sammen med produktion, bygninger, sensorer, adgangskontrol eller industrielle systemer, bør OT/IoT ind i scopet. Nogle organisationer overser dette, fordi OT ofte ejes af drift eller teknik, ikke IT. Men cyberhændelser stopper ikke ved organisationsdiagrammet.
Spørg konkret: Hvilke fysiske processer kan påvirkes af et digitalt angreb? Er der fjernadgang for leverandører? Er netværk segmenteret, eller deler OT og kontor-IT samme infrastruktur? Mini-konklusion: Hvis OT er nødvendig for den service, I leverer, er det også nødvendig for jeres NIS2-risikovurdering.
Trin 5: Fastlæg minimum-sikkerhedsdomæner, I skal kunne dokumentere
Når scope er afgrænset, skal I definere et “minimum” af sikkerhedsdomæner, hvor I kan levere dokumentation. Det behøver ikke være et perfekt ISMS fra dag ét, men det skal være konsistent, risikobaseret og forståeligt.
- Risikostyring: metode, risikoregister, beslutninger og opfølgning.
- Adgangsstyring: MFA, least privilege, joiner/mover/leaver.
- Hændelseshåndtering: playbooks, triage, kommunikation, læring.
- Backup og gendannelse: testede restores, RPO/RTO, immutable hvor relevant.
- Sårbarhedsstyring: patching, scanning, undtagelser og deadlines.
- Leverandørstyring: kontraktkrav, due diligence, opfølgning.
- Logning og overvågning: hvilke logs, retention, alarmer og respons.
Hvad koster det? Omkostningen afhænger primært af scopets størrelse, modenhed og hvor mange leverandører I skal styre. Et snævert, veldefineret scope kan ofte løftes med målrettede proces- og konfigurationsforbedringer, mens et uklart scope typisk udløser lange konsulentforløb, værktøjsindkøb og intern friktion. Mini-konklusion: Budgettet følger afgrænsningen; få scope rigtigt, før I køber løsninger.
Typiske fejl: scope for bredt vs. for snævert
Fejl i scope er dyre, enten i kroner eller i risiko. Her er de mest almindelige faldgruber, og hvordan I undgår dem.
For bredt scope: alt bliver kritisk
Når alt erklæres kritisk, bliver intet prioriteret. Resultatet er “compliance-teater”: mange politikker, få forbedringer, og et team der brænder ud. Modtræk: afgræns til ydelser med klare konsekvenser, og bind kontroller til konkrete risici. Brug minimum viable compliance som startpunkt, men vær ærlige om huller.
For snævert scope: I tror, I er færdige, men er det ikke
Den anden grøft er at definere scope som et enkelt system eller et datacenter, mens de kritiske afhængigheder ligger udenfor: identitet, netværk, leverandøradgange eller cloud management plane. Modtræk: kortlæg afhængigheder konsekvent og inkluder de “fælles” komponenter, som alle kritiske ydelser bruger.
Mini-konklusion: Det rigtige scope er sjældent intuitivt; det kræver en struktureret gennemgang af ydelser, roller og afhængigheder.
Første uge: en praktisk tjekliste til at afklare scope internt
Målet i uge 1 er ikke at løse alt, men at skabe fælles sprog, ejerskab og en dokumenterbar beslutning. Brug tjeklisten som arbejdsplan mellem CISO/IT, forretning, ledelse og jura.
- Udpeg en scope-ejer og en beslutningsgruppe (IT, forretning, jura, ledelse).
- Indsaml 10–20 centrale dokumenter: kontrakter, servicekatalog, driftsaftaler, leverandørlister.
- Afhold en 2-timers workshop om forretningsydelser og konsekvenser ved nedbrud.
- Lav første udkast til servicekort: ydelser, kunder, tilgængelighedskrav, data typer.
- Match hver ydelse til mulig sektor og rolle, og markér usikkerheder til juridisk afklaring.
- Kortlæg top-10 afhængigheder per kritisk ydelse: identitet, netværk, cloud, driftspartner, nøgleleverandører.
- Definér minimum-sikkerhedsdomæner og hvilke evidenser I allerede har (og mangler).
- Godkend et foreløbigt scope og en 30-dages plan for validering, gap-analyse og prioriterede tiltag.
Bedste praksis er at skrive scope ned i et kort notat: hvad er med, hvad er ude, og hvorfor. Det gør det lettere at styre forventninger, estimere indsats og justere uden panik, når nye informationer dukker op. Mini-konklusion: Når scope er forankret i ledelsen og forstået af IT og jura, bliver NIS2-arbejdet et styringsprojekt frem for en brandøvelse.
