Sara Krogh
Kernen først:
1) NIS2 rammer langt flere virksomheder, end mange tror, fordi også vigtige leverandører kan være omfattet. 2) Ledelsen kan ikke bare henvise til IT, hvis noget går galt. 3) Du behøver ikke et kæmpeprogram fra dag ét, men du har brug for et klart scope, en simpel styringsstruktur og nogle få, konkrete leverancer med dokumentation.
Resten af artiklen handler om præcis det: Hvordan du hurtigt finder ud af, om I kan være omfattet, hvad ledelsesansvar betyder i praksis, og hvordan en realistisk top-10 leveranceliste kan se ud i de første 30-60 dage.
Hvem er typisk omfattet af NIS2 (og hvem bliver ramt ad bagvejen)?
Hvis du allerede har siddet med din kaffekop og googlet “NIS2 omfattet”, har du sikkert opdaget, at informationen er tung, fragmenteret og ofte skrevet til jurister. Så lad os starte mere lavpraktisk.
NIS2-direktivet handler om sikkerhed i net- og informationssystemer i samfundskritiske og “vigtige” sektorer. EU og de nationale myndigheder arbejder stadig med den konkrete afgrænsning, men pejlemærkerne er rimeligt tydelige.
Direkte omfattet: de oplagte typer
Typisk vil du være i risikozonen, hvis virksomheden hører hjemme i én af disse kategorier:
Energi, vandforsyning, transport, sundhed, finans, digital infrastruktur, offentlige myndigheder eller større udbydere af cloud, hosting, datacentre og lignende. Hvis I arbejder i den liga, bør I formentlig allerede nu tage et kig på DI’s NIS2-guide og de officielle myndighedssider for at få de konkrete kriterier på størrelse og omsætning.
Jeg ser ofte, at ledelser i disse sektorer godt ved, at NIS2 eksisterer, men undervurderer hvor operationelt det bliver. Det er ikke kun et juridisk kryds i et skema. Det påvirker processer, roller, indkøb, leverandørstyring og rapportering fremadrettet.
Indirekte ramt: leverandører og samarbejdspartnere
Den mere interessante (og lidt mere irriterende) del er, at virksomheder uden for de klassiske, kritiske sektorer alligevel påvirkes. Det sker, når kunder, der er direkte omfattet, begynder at presse krav ned i leverandørkæden.
To typiske scenarier:
En SaaS-leverandør til hospitaler bliver mødt med krav om dokumenteret sikkerhedsorganisation, hændelseshåndtering og risikostyring, fordi hospitalet selv er omfattet af NIS2. Eller en IT-driftspartner til en energivirksomhed får krav om kontroller, test og rapportering på linje med NIS2, selvom partneren måske formelt set ikke er direkte omfattet endnu.
Her giver det mening at tænke i “NIS2-parathed” frem for juridisk minimum. For mange B2B-virksomheder bliver det en konkurrencefaktor at kunne svare roligt og konkret, når kunden spørger: “Hvordan arbejder I med NIS2-kravene og passende foranstaltninger?”
Et simpelt beslutningsspor: 7 spørgsmål der giver dig et første svar
Jeg lovede ikke et stort flowdiagram, men et praktisk beslutningsspor. Så her er en enkel måde at strukturere jeres første NIS2-snack af et møde på: Print spørgsmålene, sæt jer tre-fire personer (IT, leder, evt. jurist/compliance) og svar ærligt.
Spørgsmål 1-3: Sektor, størrelse og kritikalitet
Først de helt basale:
Arbejder vi i en sektor, der typisk nævnes som kritisk eller vigtig i NIS2-sammenhæng (energi, vand, sundhed, finans, digital infrastruktur, offentlig sektor, større hosting/cloud m.m.)? Har vi en størrelse (omsætning/antal ansatte), hvor vi realistisk set kan blive klassificeret som vigtig enhed, når de danske regler er fuldt implementeret? Og hvis vi stopper driften i 48 timer, vil samfunds-, forsynings- eller kritisk B2B-funktionalitet reelt være truet?
Hvis du allerede her sidder og tænker “ja, øv”, så er I i den kategori, der skal regne med, at NIS2 bliver meget relevant. På det tidspunkt er det ikke et spørgsmål om “omfattet eller ej”, men om at få et overblik over kravene og bygge en styringsramme op i tide.
Spørgsmål 4-5: Kunder og leverandørkæde
Dernæst skal du tænke nedstrøms og opstrøms:
Har vi kunder, som tydeligt er i NIS2-risikoen (fx hospitaler, energiselskaber, offentlige myndigheder, større finansaktører)? Har vi allerede nu i kontrakter, udbud eller sikkerhedsspørgeskemaer fået spørgsmål om NIS2, passende foranstaltninger, hændelsesrapportering eller lignende?
Hvis svaret er ja til bare én af dem, så kan du roligt antage, at NIS2-krav eller NIS2-inspirerede krav vil lande hos jer. Det kan godt være, I ikke formelt er kategoriseret endnu, men kommercielt vil forventningen være der.
Spørgsmål 6-7: Egen modenhed og risikovillighed
De to sidste spørgsmål handler mere om jer selv end om lovgivningen:
Har vi i dag et nogenlunde struktureret setup for informationssikkerhed (politik, risikovurdering, hændelsesproces, leverandørstyring), eller er det primært baseret på “vi har dygtige folk i IT”? Og hvis vi får et større nedbrud, datalæk eller ransomware-angreb i morgen, føler ledelsen så, at de har styr på, hvad de både skal gøre og kunne dokumentere efterfølgende?
Hvis du bliver lidt utilpas ved spørgsmålene, er det ikke nødvendigvis et NIS2-problem. Det er et styringsproblem. Men NIS2 kommer til at gøre det meget tydeligere, hvad der forventes på det punkt.
Hvad “ledelsesansvar” konkret betyder i NIS2-kontekst
Der bliver talt meget om, at NIS2 indfører øget ledelsesansvar. Det kan hurtigt føles abstrakt, indtil man oversætter det til helt konkrete beslutninger, der ikke kan delegeres væk.
Beslutninger, ledelsen ikke bare kan parkere hos IT
Der er især fire områder, hvor jeg oplever, at ledelsen skal på banen og ikke kan nøjes med at sige “IT har styr på det”:
For det første risikovillighed. Hvor meget driftsstop, datatab eller nedbrud vil vi reelt acceptere, og hvor meget vil vi betale for at reducere risikoen? Det er ikke en teknisk beslutning, men en forretningsbeslutning.
For det andet prioritering af investeringer. Skal vi bruge penge på bedre overvågning, flere kompetencer, eksterne tests eller backup-strategi først? Her er det ledelsen, der afvejer økonomi, strategi og risiko.
For det tredje governance og roller. Hvem har ansvaret for risikoregisteret, hændelsesrapportering, kontakt til myndigheder og rapportering til bestyrelsen? Og har de tid og mandat til at gøre det ordentligt?
For det fjerde godkendelse af politikker og rammer. Informationssikkerhedspolitikken og de centrale retningslinjer skal være formelt forankret hos ledelsen, ikke bare gemt væk i en SharePoint-mappe hos IT.
Personligt ansvar og kompetencekrav
NIS2 lægger også vægt på, at ledelsen skal have tilstrækkelig forståelse for cybersikkerhedsrisici til at træffe informerede beslutninger. Det betyder ikke, at alle skal kunne forklare krypteringsalgoritmer over frokost, men de skal kunne gennemskue grundlæggende sammenhænge mellem trusler, sårbarheder, konsekvenser og kontroller.
Her giver det ofte mening at planlægge et kort, målrettet kompetenceløft til direktion og bestyrelse. Ikke som et langt seminar, men fx som et fokuseret 2-timers forløb med egne cases, egne systemer og egne risici som omdrejningspunkt. Praktisk, ikke teoretisk.
De første 10 leverancer: sådan ser et realistisk NIS2-startkit ud
Lad os tage fat i det, de fleste faktisk efterspørger: “Hvad skal vi have produceret for at kunne sige, at vi er ordentligt i gang?”
Her er en prioriteret top-10 liste over leverancer, der både hjælper ift. NIS2 og generelt giver jer bedre styring. Ikke alt skal være perfekt fra start, men det skal eksistere og være nogenlunde tænkt igennem.
1. Kort, godkendt informationssikkerhedspolitik
En 2-3 siders politik, som ledelsen formelt har godkendt. Den skal beskrive mål, ansvar og principper. Ikke 40 sider med tekniske detaljer, men en ramme, der viser retningen og dokumenterer, at ledelsen har taget stilling.
Evidens: Godkendt dokument med versionskontrol, mødereferat eller beslutningslog, hvor det fremgår, at politikken er gennemgået og godkendt.
2. Afgrænset scope for NIS2 og kritiske systemer
En oversigt over, hvilke systemer, processer og services der vurderes kritiske i NIS2-kontekst. Start med det vigtigste: de systemer, der ville give jer eller kunderne størst skade, hvis de var nede eller kompromitteret i længere tid.
Evidens: Et simpelt dokument eller diagram, der viser systemlandskab og kritikalitet, gerne med en kort begrundelse for, hvorfor noget er kategoriseret som højt, middel eller lavt vigtigt.
3. Et første risikoregister
Nej, det behøver ikke at være perfekt. Men ja, det skal eksistere. Et enkelt regneark kan sagtens fungere i starten: trussel, sårbarhed, konsekvens, sandsynlighed, nuværende kontroller og planlagte tiltag.
Evidens: Et opdateret ark med dato, ansvarlig og noter om, hvad der er besluttet, og hvad status er på de vigtigste risici.
4. Hændelsesproces: hvem gør hvad, når det brænder
En kort, praktisk beskrivelse af, hvad der sker ved en sikkerhedshændelse: hvem opdager, hvem vurderer, hvem beslutter, hvem kommunikerer, og hvornår skal der rapporteres til myndigheder eller kunder.
Jeg har flere gange set virksomheder, hvor IT faktisk var utrolig dygtige til at slukke ildebrande, men hvor ingen bagefter kunne dokumentere, hvad der var sket. Under NIS2 er den slags efter-dokumentation ikke valgfrit.
Evidens: Dokumenteret proces + eksempler på anvendelse, fx fra øvelser eller håndterede hændelser.
5. Minimumskrav til leverandører
Udpeg de 5-10 vigtigste IT- og driftsleverandører og skriv ned, hvilke sikkerhedskrav I forventer, at de lever op til. Det kan være inspireret af NIS2, ISO 27001 eller bare sunde kontrolprincipper. Pointen er, at det skal være eksplicit.
Evidens: Skabelon til krav, tilføjelser til kontrakter eller bilag, samt dokumentation for at det er sendt/forhandlet med de vigtigste leverandører.
6. Trænings- og awarenessplan
Ingen styring uden mennesker. Lav en kort plan for, hvem der skal have hvilken form for træning: ledelse, nøglepersoner, almindelige brugere. Det kan sagtens være små moduler, e-læring eller korte sessions på afdelingsmøder.
Evidens: Plan med målgruppe, indhold, frekvens og registrering af, hvem der har gennemført hvad.
7. Overblik over “passende foranstaltninger”
NIS2 taler meget om “passende tekniske og organisatoriske foranstaltninger”. I praksis kan du oversætte det til: Hvilke kontroller har vi sat i værk, og hvorfor vurderer vi, at de er tilstrækkelige ift. vores risici?
Lav en simpel liste over centrale kontroller: adgangsstyring, backup, patching, overvågning, kryptering, segmentering osv. Notér kort, hvad I gør, hvordan det overvåges, og hvornår det sidst er blevet testet.
Evidens: Kontroloversigt + logeksempler, rapporter eller testresultater, der viser, at kontrollerne faktisk virker i praksis.
8. Klar rollefordeling og ansvarskort
Det behøver ikke at være et stort organisationsdiagram. Men der skal være tydeligt defineret, hvem der er ansvarlig for hvad: informationssikkerhed, risikoregister, hændelsesrapportering, leverandørstyring, rapportering til ledelse/bestyrelse.
Evidens: RACI (hvem er ansvarlig, udførende, skal konsulteres, informeres), stillingsbeskrivelser eller lignende, hvor rollerne fremgår.
9. Møderytme for sikkerhed og risiko
Én ting er dokumenter. Noget andet er, hvordan de faktisk bliver brugt og vedligeholdt. En fast møderytme er ofte undervurderet som styringsværktøj.
Fx et månedligt operationelt møde (IT, risk, evt. forretning) og et kvartalsvist møde i ledelsen, hvor risici, hændelser og status på kontroller gennemgås. Simpelt, men effektivt.
Evidens: Mødekalender, dagsordener og korte referater eller beslutningslog.
10. En kort ledelsesrapport-skabelon
Lav et 1-sides format for, hvordan status på informationssikkerhed og NIS2-relaterede tiltag rapporteres til ledelse og bestyrelse. Det gør det lettere at holde fokus og sikrer, at I får de samme nøgletal og historier igen og igen.
Evidens: Skabelon + et første udfyldt eksempel, hvor I laver en baseline-status.
Minimum viable styring: roller og møder uden at bygge tungt bureaukrati
Hvis du på nuværende tidspunkt tænker “det lyder som et helt nyt system”, så ja, til dels. Men det behøver ikke at være tungt. Min erfaring er, at et “minimum viable” setup kan gøre en stor forskel, hvis det holdes stramt.
De vigtigste roller i et slankt setup
Du behøver ikke nødvendigvis en fuldtids-CISO fra dag ét. Men du har brug for en person, der reelt har ansvaret for koordineringen. Det kan være en IT-chef med et udvidet mandat eller en dedikeret informationssikkerhedsansvarlig i deltid.
Udover den person er der typisk fire funktioner, der skal være tydeligt i spil: IT/drift (dem der implementerer og driver kontrollerne), risk/compliance (dem der holder styr på risikoregister og politikker), legal/kontrakter (dem der får NIS2-krav ind i aftaler) og indkøb/procurement (dem der faktisk forhandler med leverandører).
Pointen er ikke, at der skal ansættes fire personer. Pointen er, at du kan pege på navngivne mennesker og sige: “Den her del ligger hos dig”.
En enkel møderytme, der virker i praksis
Mit forslag til minimumsstruktur ser ofte sådan ud:
Et månedligt sikkerheds- og risikomøde på 60-90 minutter, hvor risikoregister, nye hændelser, status på leverancer og eventuelle kundekrav gennemgås. Deltagere: IT, risikoejer, evt. en repræsentant fra forretningen.
Et kvartalsvist ledelses- eller bestyrelsespunkt, hvor den kortfattede rapport (fra leverance 10) præsenteres, drøftes og enten godkendes eller bliver udgangspunkt for nye beslutninger om investeringer eller prioritering.
Hvis du vil se eksempler på, hvordan andre kobler digitale indsatser med styring og rapportering, kan artikler om fx data-drevne beslutninger give inspiration til, hvordan man holder styr på nøgletal uden at drukne i dem.
KPI’er og rapportering: hvad giver mening at måle på?
Noget af det, mange kæmper med, er at finde balancen mellem for tekniske KPI’er og for overfladiske KPI’er. Ideelt set skal de både sige noget om niveauet af sikkerhed og om modenheden i jeres styring.
Eksempler på meningsfulde KPI’er
Her er eksempler på KPI’er, jeg ofte ser give mening i en NIS2-kontekst:
Andel af kritiske systemer med dokumenteret risikovurdering inden for de seneste 12 måneder. Andel af identificerede højrisici med en godkendt behandlingsplan. Tid fra opdagelse af alvorlige hændelser til eskalering til rette niveau. Andel af medarbejdere i udvalgte målgrupper, der har gennemført sikkerhedstræning inden for det seneste år. Andel af kritiske leverandører, hvor sikkerhedskrav er kontraktligt beskrevet og senest gennemgået.
Det er ikke tal for tallenes skyld. De peger på, om I faktisk får gjort de ting, NIS2 lægger op til: forstå risici, behandle dem, reagere hurtigt og sikre, at både mennesker og leverandører er en del af billedet.
Hvordan rapporteringen kan se ud på 1 side
En god rapport til ledelse og bestyrelse behøver ikke at være lang. Jeg plejer at tænke i fire afsnit: status på risici (top 5 risici med udvikling siden sidst), status på hændelser (antal, alvorlighed, læring) og kontroller (hvad er styrket, hvad er på vej), status på leverancer/tiltag (hvad er gennemført, hvad er forsinket og hvorfor) samt eventuelle eksterne krav (nye kundekrav, lovkrav, tilsyn mv.).
Hvis du kan have alle fire afsnit på én side, er du et godt sted. Hvis du ikke kan, er det ofte et tegn på, at du enten må skære ned i detaljer eller få bedre opsamling fra de enkelte områder.
Typiske faldgruber: hvor går det galt i praksis?
Jeg ser nogle mønstre gå igen, når virksomheder prøver at være proaktive omkring NIS2. De fleste kan opsummeres i fire klassiske fejl.
Over-compliance og tykke mapper
Første faldgrube er at gå direkte i dokumentmode. Lange politikker, detaljerede procedurer, mange referencer til standarder. Det ser flot ud på overfladen, men hvis ingen læser, bruger eller opdaterer materialet, har I reelt ikke forbedret sikkerheden.
NIS2 vil hellere se fornuftigt dækkende kontroller, der virker i praksis, end perfekte dokumenter, der ligger stille.
Uklart scope og evigt “vi afventer afklaring”
Anden faldgrube er at vente på den perfekte juridiske afklaring. Selvfølgelig skal I følge myndighedernes og fx brancheorganisationers udmeldinger tæt. Men hvis alt parkers på “vi ser lige, hvad det bliver til”, mister I værdifuld tid.
De fleste af de tiltag, jeg har listet, er sunde uanset den endelige paragraftekst. I værste fald har I “for meget” styring, når kravene lander. Det er til at leve med.
IT-projekt uden forretning
Tredje faldgrube er, at man laver NIS2 som et IT-projekt, hvor sikkerhed ses som en teknisk disciplin. Resultatet bliver ofte teknisk stærke løsninger uden forankring i forretningens processer, prioriteringer og hverdag.
NIS2 er i sin natur tværgående. Risiko handler om forretningseffekt, ikke kun om firewalls. Derfor skal forretningen med om bord, fx i risikoworkshops og i beslutninger om niveau for “passende foranstaltninger”.
Manglende evidens og sporbarhed
Fjerde faldgrube er, at man faktisk gør mange gode ting, men uden at kunne dokumentere dem. Der er ingen referater, ingen logik i versionsstyring, ingen simpel oversigt over, hvad der er besluttet hvornår.
Det er ærgerligt, for det betyder, at I ikke får “kredit” for alt det, I faktisk gør. Den gode nyhed er, at det relativt nemt kan fikses med nogle få, faste vaner og simple skabeloner.
Hvad du kan gøre i morgen: en 2-ugers quickstart-plan
Hvis du er nået hertil, har du sandsynligvis både en snert af overblik og en snert af “puha, det er meget”. Lad os lande med noget helt konkret, som kan gennemføres på cirka to uger, uden at det tager al din arbejdstid.
Dag 1-3: Få overblik og træf et par principbeslutninger
Start med et kort møde (maks 90 minutter) med ledelse/IT/compliance, hvor I går de 7 spørgsmål igennem. Beslut to ting: vurderer vi, at vi
Skriv et kort notat (1 side) med konklusioner og de næste skridt. Det er jeres første lille stykke evidens.
Dag 4-7: Definér scope og kritiske systemer
Lav en workshop med IT og 1-2 nøglepersoner fra forretningen. Målet er at kortlægge de vigtigste systemer og services og give dem en kritikalitetsvurdering. Du behøver ikke fancy værktøjer, et whiteboard og et regneark rækker.
Resultatet bliver jeres første scope-dokument og en grov prioritering af, hvor I skal starte med risikovurderinger og kontroller.
Dag 8-10: Første udkast til politik og risikoregister
Skriv et kort udkast til informationssikkerhedspolitik og et simpelt risikoregister. Involver kun de mennesker, der faktisk skal leve med dem. Test dem på 1-2 konkrete eksempler: virker de i virkeligheden?
Send politikudkastet til ledelsen med en klar anbefaling og få det på dagsordenen til næste møde.
Dag 11-14: Hændelsesproces og møderytme
Afslut jeres 2-ugers sprint med at beskrive hændelsesprocessen og aftale en fast møderytme. Book de første tre møder i kalenderen, så det ikke bliver ved snakken.
Når de fire elementer er på plads (scope, politik, risikoregister, hændelsesproces + møder), har I et skelet. Resten af NIS2-arbejdet bliver at fylde skeletet ud med bedre kontroller, mere moden risikostyring og en skarpere kobling til jeres forretningsstrategi.
Hvis du vil fortsætte med at bygge bro mellem regulering, data og forretning, kan du finde mere inspiration i vores indsigter om digitalisering og styring på Eagle insights. Men start roligt med skeletarbejdet. Det løfter jer et overraskende langt stykke.
