NIS2 i praksis: 6.000 danske virksomheder er omfattet, kun 16% er klar

NIS2-loven trådte i kraft i Danmark den 1. juli 2025, med registreringsfrist den 1. oktober 2025 via Vi. Loven seksdobler antallet af omfattede danske organisationer i forhold til det tidligere NIS1-direktiv, fra omkring 1.000 til omkring 6.000. Alligevel føler kun 16% af virksomhederne sig fuldt forberedt, og 11% er stadig usikre på, hvad NIS2 egentlig kræver af dem.

Det er ikke, fordi kravene er uklare. Det er, fordi de forudsætter noget, de fleste virksomheder ikke har: et opdateret overblik over egne systemer, processer og leverandører, koblet sammen på en måde der kan dokumenteres og vedligeholdes.

Denne artikel er første del af en serie om det fælles fundament bag NIS2, DORA/PCI DSS og AI Act. NIS2 rammer bredest, omkring 15 sektorer, og er derfor det naturlige sted at starte. Fundamentet, vi bygger her, genbruges direkte i de to næste artikler i serien.

Hvad NIS2 kræver, kort fortalt

Loven stiller krav om ti konkrete risikostyringsforanstaltninger under artikel 21, blandt andet risikoanalyse, håndtering af sikkerhedshændelser, driftskontinuitet, sikkerhed i leverandørkæden og adgangsstyring. Opdager man en væsentlig sikkerhedshændelse, skal man sende en tidlig varsling inden for 24 timer, en fyldestgørende underretning inden for 72 timer og en endelig rapport inden for en måned. Bestyrelse og direktion skal formelt godkende foranstaltningerne og gennemføre cybersikkerhedsuddannelse, og overtrædelser kan koste op til 10 millioner euro eller 2% af den globale årsomsætning for væsentlige enheder.

Hvorfor det er svært i praksis

Kravet til leverandørkæde-sikkerhed er det, der typisk sætter virksomheder fast. Det kræver ikke bare en liste over leverandører, men et overblik over hvilke leverandører der understøtter hvilke kritiske processer, hvilke data de har adgang til, og hvor sårbarhederne i den kæde ligger. I de fleste virksomheder findes de svar spredt over et CMDB, nogle regneark, en indkøbsafdeling og en it-afdeling, der sjældent taler sammen om det samme billede. Leverandøraftaler indgås ét sted, driftsansvaret ligger et andet sted, og ingen har til opgave at holde de to sammen, når en leverandør skifter, en kontrakt fornyes, eller en medarbejder stopper.

Uden en kortlagt sammenhæng mellem forretningsprocesser, systemer og leverandører er det umuligt at dokumentere, om risikostyringsforanstaltningerne rent faktisk dækker det, der er kritisk. Det er den samme øvelse, som ligger bag DORAs register over ICT-leverandører, PCI DSS' krav til tredjepartsstyring og AI Acts krav til AI-systemer koblet til data og leverandører. Forskellige navne, samme grundlæggende mangel.

Sådan hjælper Clariox

Vi kortlægger ikke leverandørerne isoleret fra resten af IT-landskabet. Vi bygger et levende billede i Ardoq, hvor forretningskapabiliteter, applikationer, ejerskab og leverandører hænger sammen ét sted og opdateres, i takt med at organisationen ændrer sig, i stedet for at blive genopfrisket manuelt hver gang tilsynet eller en revision spørger. Det foregår i tre trin:

Fase 1: Applikations- og kapabilitetskortlægning

Vi anbefaler at starte med applikationerne, de forretningskapabiliteter de understøtter, og hvem der ejer hver del, altså de grundlæggende streger mellem IT og forretning, før man kigger på leverandørerne. Resultatet er et opslagsværk, man kan bruge igen, næste gang tilsynet, en revision eller en ny kollega spørger, hvad der egentlig er kritisk, og hvem der har ansvaret. I dag findes de svar typisk spredt over et CMDB, nogle regneark og en række møder, der skal genopfriskes hver gang. Er billedet tegnet og holdt ved lige én gang, er det arbejde gjort for alle regulativer på samme tid, i stedet for at blive genstartet fra bunden hver gang.

Fase 2: Leverandør- og systemkortlægning via API-integrationer og Ardoq Surveys

Med kapabiliteter, applikationer og ejerskab på plads kortlægges direkte leverandører og serviceudbydere og kobles til de processer og systemer, de understøtter. Det meste af arbejdet behøver ikke være manuelt. API-integrationer henter kontraktdata og sikkerhedsmæssige forhold direkte fra de indkøbssystemer og leverandørregistre, der allerede findes, i stedet for at nogen skal samle det i et regneark. Hvor data mangler, sender en Ardoq Survey automatisk et par målrettede spørgsmål til den, der ejer leverandørforholdet, og svaret går direkte ind i modellen uden en mellemmand, der taster det ind bagefter. Det er kernen i artikel 21s krav til leverandørkæde-sikkerhed.

Fase 3: Dokumentation og hændelsesberedskab

Data struktureres, så man kan dokumentere risikostyringsforanstaltningerne over for tilsynsmyndigheden, og så hændelsesrapportering inden for 24 timer, 72 timer og en måned kan ske hurtigt, fordi overblikket allerede findes. Fordi kortlægningen holdes ved lige af de samme API-integrationer og surveys, opdateres billedet i takt med at en leverandør skifter eller et system ændres, i stedet for at skulle genskabes manuelt, hver gang tilsynet banker på.

Har virksomheden også berøring med finanssektoren eller udvikler og bruger AI, er fundamentet ovenfor genbrugeligt til både DORA/PCI DSS og AI Act. De to næste artikler i serien går i dybden med, hvordan.

Er man en del af de 6.000, men ikke en del af de 16%?

📅 Book en uforpligtende samtale på clariox.dk/contact

Clariox Advisory er en uafhængig IT-rådgivningsvirksomhed og Ardoq-partner, den eneste Ardoq-fokuserede partner i Danmark. Denne artikel er til informationsformål og udgør ikke juridisk eller regulatorisk rådgivning.

Tal og datoer i denne artikel stammer fra Styrelsen for Samfundssikkerhed (SAMSIK) og en analyse fra Shattered.io om NIS2-parathed i Danmark.