Er din organisation “bare” omfattet af NIS2 – eller er I den type enhed, myndighederne forventer reagerer hurtigere, dokumenterer mere og bliver mødt af mere direkte tilsyn?
I NIS2 er der en praktisk og juridisk vigtig skillelinje mellem vigtige og væsentlige enheder. Den skillelinje påvirker ikke kun, hvilke sikkerhedskrav der gælder, men især hvordan tilsyn udføres, hvor proaktivt myndighederne kan gribe ind, og hvad der typisk sker, hvis noget går galt.
I denne artikel får du et klart overblik over forskellen, konkrete eksempler på klassificering, og en handlingsorienteret guide til, hvordan du vurderer jeres status og prioriterer compliance-arbejdet uden at drukne i papir.
Hurtig definition: Hvad betyder “vigtig” og “væsentlig” under NIS2?
NIS2 opdeler omfattede organisationer i to hovedkategorier: væsentlige enheder (Essential Entities) og vigtige enheder (Important Entities). Begge kategorier skal efterleve krav til risikostyring, hændelsesrapportering og ledelsesansvar, men kategorien har stor betydning for tilsynsformen og myndighedernes sanktionsmuligheder i praksis.
Den korte tommelfingerregel er: væsentlige enheder ligger typisk i de mest samfundskritiske sektorer og forventes derfor at være underlagt mere løbende og aktiv kontrol, mens vigtige enheder oftere møder et mere reaktivt tilsyn, der typisk aktiveres ved tegn på problemer eller efter hændelser.
Mini-konklusion: Klassificeringen handler ikke om “om” I har pligter, men om hvordan I bliver kontrolleret, og hvor hårdt myndighederne kan og vil skrue op, når krav ikke efterleves.
Hvorfor skellet betyder noget: Tilsyn, tempo og bevisbyrde
Det mest håndgribelige ved kategoriseringen er, at den påvirker myndighedens tilgang: hvor ofte I kan forvente dialog, hvor hurtigt I skal kunne fremlægge dokumentation, og hvor detaljeret jeres sikkerhedsprogram skal kunne forklares.
Proaktivt vs. reaktivt tilsyn
For væsentlige enheder er tilsynet typisk mere proaktivt: myndigheden kan i højere grad opsøge, kræve dokumentation, gennemføre audits og følge op på forbedringsplaner. For vigtige enheder er tilsynet oftere reaktivt og hændelsesdrevet: det aktiveres fx ved indberettede hændelser, klager eller indikationer på manglende efterlevelse.
Konsekvensen for jeres interne arbejde
I praksis betyder det, at væsentlige enheder bør kunne fremvise styring, kontroller og logik bag risikovalg “på dagen”, mens vigtige enheder ofte kan arbejde mere etapevist – men stadig skal kunne dokumentere, at de har truffet rimelige foranstaltninger.
Mini-konklusion: To organisationer kan have næsten samme tekniske sikkerhedsniveau, men opleve meget forskellige krav til dokumentation og kontrol, afhængigt af om de er vigtige eller væsentlige.
Hvad afgør om man er vigtig eller væsentlig? Sektorer, størrelse og funktion
Klassificeringen afgøres typisk af to ting: (1) hvilken sektor og undersektor I tilhører, og (2) om I opfylder størrelseskriterier (ofte knyttet til virksomhedsstørrelse), samt om I leverer særligt kritiske tjenester.
Sektortilhørsforhold: “kritikalitet” vejer tungt
Væsentlige enheder findes typisk i de mest kritiske områder (fx energi, transport, sundhed, digital infrastruktur og visse offentlige funktioner). Vigtige enheder kan ligge i andre vigtige sektorer, hvor samfundspåvirkningen stadig er stor, men hvor tilsynsmodellen er mindre indgribende.
Størrelse og undtagelser: når en mindre aktør stadig kan være omfattet
Størrelse spiller ind, men det er ikke et frikort at være “lille”. Under NIS2 kan enkelte typer organisationer være omfattet, selvom de ikke matcher klassiske SME-grænser, hvis deres rolle er særlig kritisk (fx som central leverandør, knudepunkt eller udbyder af afgørende digitale tjenester).
Mini-konklusion: I tvivlstilfælde er det sjældent it-teamet alene, der kan afgøre status. Det kræver en fælles vurdering på tværs af forretning, jura, compliance og drift.
Konkrete eksempler: sådan kan to “næsten ens” organisationer ende i hver sin kategori
Her er nogle typiske situationer, jeg har set i praksis, hvor organisationer undervurderer betydningen af sektor og rolle i værdikæden:
- Et større regionalt forsyningsselskab: ofte klassificeret som væsentlig pga. direkte samfundskritisk leverance.
- En IT-serviceprovider, der driver drift for flere kritiske kunder: kan være vigtig eller i nogle tilfælde løfte sig i kritikalitet via sin rolle som “single point of failure”.
- En privat sundhedsklinik med begrænset størrelse: kan være omfattet pga. sektor, datatyper og afhængigheder.
- En producent med OT-miljø og leverancer til kritisk infrastruktur: klassificering afhænger ofte af undersektor og hvor uerstattelig leverancen er.
- En kommune eller offentlig myndighed: vil typisk være omfattet, og forventningen til governance og dokumentation er høj.
- En SaaS-virksomhed med få ansatte men stor udbredelse: kan blive omfattet via funktion og markedsrolle, ikke kun headcount.
Bemærk, at det ikke kun er “hvad I er”, men “hvad der sker, hvis I går ned”. En times nedetid i en bookingsystem-leverandør er irriterende; en times nedetid i en kritisk driftsplatform kan være samfundsmæssigt alvorlig.
Mini-konklusion: Klassificering er en risikofortælling om konsekvens og afhængigheder – ikke en brandingøvelse om brancheetiketter.
Kravene ligner hinanden – men forskellen viser sig i tilsyn og konsekvenser
Både vigtige og væsentlige enheder skal etablere risikobaserede sikkerhedsforanstaltninger, sikre hændelseshåndtering, og kunne rapportere væsentlige hændelser rettidigt. Men forventningsniveauet til modenhed og myndighedsdialog er typisk højere for væsentlige enheder.
Hvis du vil læse mere om, hvordan afgrænsningen typisk forstås i praksis, kan du se denne gennemgang af vigtig eller væsentlig enhed i NIS2 og bruge den som tjekliste i jeres egen vurdering.
Ledelsesansvar: det stopper ikke ved IT
Et centralt punkt i NIS2 er, at ansvar og beslutninger skal kunne forankres i ledelsen. Det betyder i praksis, at topledelsen skal kunne forstå og godkende risikoniveau, budgetprioriteter og større afvigelser. For væsentlige enheder ser jeg oftere, at myndigheder forventer en mere formaliseret governance-struktur med faste rapporteringslinjer og klare beslutningsprotokoller.
Dokumentation: “har I gjort det?” vs. “kan I bevise det?”
Ved tilsyn bliver forskellen ofte tydelig: Vigtige enheder slipper sjældent med mundtlige forklaringer. Væsentlige enheder kan opleve, at der efterspørges flere artefakter: risikovurderinger, kontroltest, leverandøroversigter, øvelsesreferater, afvigelseslog og forbedringsplaner.
Mini-konklusion: De tekniske kontroller er kun halve arbejdet; den anden halvdel er evnen til at dokumentere beslutninger, test og opfølgning på en måde, en myndighed kan revidere.
Sådan vurderer du jeres status og scope (uden at bruge måneder)
Den mest effektive måde at komme i mål på er at arbejde i en fast rækkefølge: først afgrænsning, så risikoprofil, så kontroller og dokumentation. Her er en praktisk proces, der typisk kan gennemføres på få uger for en mellemstor organisation, hvis man har adgang til de rette personer og data:
- Identificér jeres sektor og undersektor ud fra NIS2-rammen og national implementering.
- Afklar størrelseskriterier (medarbejdere, omsætning, koncernforhold) og eventuelle undtagelser.
- Kortlæg kritiske tjenester: hvad leverer I, til hvem, og hvilke afhængigheder har kunderne?
- Lav en “single points of failure”-analyse af systemer, leverandører og nøgleprocesser.
- Placér jeres sandsynlige kategori og dokumentér begrundelsen, inkl. usikkerheder.
- Fastlæg scope: hvilke systemer, sites, teams og leverandører er inde/ude – og hvorfor.
Det vigtigste er at skrive begrundelsen ned. Ved senere tilsyn eller intern revision er det ofte scope-argumentationen, der afgør, om jeres program virker gennemtænkt eller tilfældigt.
Mini-konklusion: Hvis du kan forklare jeres kategori og scope på én side, er du allerede foran mange organisationer, der ellers “bare implementerer kontroller” uden at kunne forklare hvorfor.
Hvad koster det at efterleve? De reelle omkostningsdrivere i NIS2-arbejdet
Spørgsmålet “hvad koster NIS2?” kan ikke besvares med ét tal, fordi modenhed, kompleksitet og leverandørlandskab varierer enormt. Men omkostningerne falder typisk i fire praktiske kurveknæk:
- Styring og tid: interne timer til risikostyring, politikker, ledelsesrapportering og koordinering.
- Tekniske forbedringer: logning, overvågning, segmentering, sårbarhedsstyring, backup/restore-test, MFA, hårdning.
- Leverandørstyring: kontraktbilag, krav til underdatabehandlere, audit rights, og opfølgning på rapporter.
- Øvelser og beredskab: incident response-planer, tabletop-øvelser, kontaktlister, og rapporteringsprocedurer.
For mange “vigtige” enheder er den dyreste del ikke et nyt værktøj, men at få driften til at køre disciplineret: faste patch-vinduer, dokumenterede change-processer og evidens for, at kontroller faktisk virker. For “væsentlige” enheder er der ofte et ekstra lag: hyppigere test, mere formaliseret rapportering og mere omfattende revisionsegnede spor.
Mini-konklusion: Budgettet sprænger sjældent på én stor investering; det sprænger på vedvarende drift, dokumentation og opfølgning, hvis det ikke planlægges som et program.
Typiske fejl og faldgruber (og hvordan du undgår dem)
NIS2-fejl gentager sig, uanset branche. Her er de mest almindelige, jeg ser, og hvad der konkret kan gøres anderledes:
Faldgrube 1: Man gætter sin kategori og bygger resten på antagelser
Hvis jeres status som vigtig/væsentlig er uklar, risikerer I enten at overimplementere (dyrt) eller underimplementere (risikabelt). Løsningen er en kort, skriftlig klassificeringsnote med sektor, størrelse, kritiske tjenester og afhængigheder – og en plan for afklaring, hvis noget er usikkert.
Faldgrube 2: “Vi har en politik” bliver forvekslet med “vi gør det”
Myndigheder og revisorer kigger efter evidens: logs, rapporter, testresultater, ticketspor og beslutningsreferater. Løsningen er at designe kontroller, der automatisk efterlader spor: fx månedlige sårbarhedsscans med opfølgning, og kvartalsvis restore-test med dokumenteret resultat.
Faldgrube 3: Leverandører bliver ikke behandlet som en del af sikkerhedsprogrammet
Nogle af de mest alvorlige hændelser starter i driftsleverandører, SaaS-platforme eller underleverandørkæder. Løsningen er at prioritere de 10–20 mest kritiske leverandører og kræve minimumsstandarder, rapportering og hændelseskommunikation, der matcher jeres eget beredskab.
Mini-konklusion: Den hurtigste vej til problemer er at gøre NIS2 til et dokumentprojekt. Den hurtigste vej til robust compliance er at gøre det til et driftsprojekt med målbare rutiner.
Bedste praksis: sådan gør du jer klar til tilsyn uanset kategori
Selvom tilsyn kan være mere proaktivt for væsentlige enheder, er de samme grunddiscipliner afgørende for begge. Hvis du vil stå stærkt, så brug en “tilsynsklar” tilgang, hvor alt vigtigt kan forklares og fremvises hurtigt.
En pragmatisk “tilsynsklar” tjekliste
- Scope og kritiske services er dokumenteret og godkendt af ledelsen.
- Risikoregister med top-10 risici, ejere, og planlagte afværgeforanstaltninger.
- Incident response: roller, kontaktpunkter, eskalationskriterier og øvelseslog.
- Kontrol-evidens: patching, backup/restore-test, adgangsstyring, logging/monitorering.
- Leverandørstyring: kritikalitetsvurdering, kontraktkrav og årlig opfølgning.
- Ledelsesrapportering: faste KPI’er (fx patch compliance, MFA-dækning, MTTD/MTTR).
Praktisk tip: vælg 6–8 målepunkter, der kan gentages
De bedste programmer måler få ting, men måler dem konsekvent. Eksempler: andel systemer med MFA, gennemsnitlig patch-latens på kritiske sårbarheder, succesrate for restore-test, antal åbne højrisikoafvigelser over 30 dage, og tid til første triage ved alarmer. Det giver jer både styring og noget konkret at vise ved tilsyn.
Mini-konklusion: Tilsyn bliver sjældent “nemt”, men det bliver forudsigeligt, når jeres sikkerhedsarbejde er rytmisk, målbart og ledelsesforankret.
Hvad skal du gøre nu? En kort handlingsplan for de næste 30 dage
Hvis du skal skabe fremdrift hurtigt, så gør det i denne rækkefølge:
- Afklar kategori og scope med en skriftlig begrundelse (og få den accepteret i ledelsen).
- Identificér 5 kritiske scenarier (fx ransomware, leverandørnedbrud, kompromitterede konti, OT-forstyrrelse, datalæk) og tjek om I kan reagere.
- Find dokumentationshullerne: hvor mangler I evidens for det, I siger, I gør?
- Prioritér tre forbedringer der både reducerer risiko og øger tilsynsklarhed (fx MFA overalt, restore-test, central logning).
- Planlæg en øvelse og aftal på forhånd, hvordan læring omsættes til ændringer
