NIS 2-loven og dine software­leverandører: hvad begge parter skal gøre

01Status i begyndelsen af november 2026

NIS 2-direktivet (åbner et eksternt websted), direktiv (EU) 2022/2555, blev offentliggjort i EU-Tidende 27. december 2022 og trådte i kraft 16. januar 2023. Medlemsstaterne skulle vedtage og offentliggøre deres nationale regler senest 17. oktober 2024 og anvende dem fra 18. oktober 2024, samme dag som det første NIS-direktiv blev ophævet.

Fordi NIS 2 er et direktiv, er det den nationale gennemførelseslov der binder en organisation. Gennemførelsen har været ujævn: nogle medlemsstater anvendte deres lov til tiden, andre først i 2025 eller 2026, og Europa-Kommissionen har indledt traktatbrudsprocedurer mod medlemsstater der overskred fristen. Registreringspligter, indberetningsportaler og tilsynsmyndigheder er derfor forskellige fra land til land.

I Danmark er direktivet gennemført med lov nr. 434 af 6. maj 2025 (åbner et eksternt websted) om foranstaltninger til sikring af et højt cybersikkerhedsniveau, NIS 2-loven, der trådte i kraft 1. juli 2025. Styrelsen for Samfundssikkerhed (SAMSIK) under Ministeriet for Samfundssikkerhed og Beredskab er kompetent myndighed, og sektormyndighederne fører tilsyn med hver deres sektor. Fristen for at registrere sig var 1. oktober 2025. SAMSIK samler sin vejledning på samsik.dk (åbner et eksternt websted).

02Væsentlige og vigtige enheder

NIS 2 gælder offentlige og private enheder i sektorerne i bilag I (sektorer af særlig kritisk betydning: energi, transport, bankvirksomhed, finansielle markedsinfrastrukturer, sundhed, drikkevand, spildevand, digital infrastruktur, forvaltning af ikt-tjenester, offentlig forvaltning og rummet) og bilag II (andre kritiske sektorer: post- og kurertjenester, affaldshåndtering, kemikalier, fødevarer, fremstilling, digitale udbydere og forskning). Som udgangspunkt omfatter reglerne mellemstore og store organisationer. Nogle er omfattet uanset størrelse, for eksempel tillidstjenesteudbydere, udbydere af DNS-tjenester og enheder i den centrale offentlige forvaltning.

Direktivets artikel 3 deler organisationerne i to kategorier:

• Væsentlige enheder: primært store organisationer i sektorerne i bilag I samt enheder der er væsentlige uanset størrelse, for eksempel kvalificerede tillidstjenesteudbydere, registre for topdomæner, udbydere af DNS-tjenester og enheder i den centrale offentlige forvaltning. De er under forudgående tilsyn, der kan omfatte audits og inspektioner på stedet.
• Vigtige enheder: de øvrige omfattede organisationer i bilag I og II. Tilsynet sker efterfølgende: myndigheden griber ind, når der er tegn på at enheden ikke overholder reglerne.

Begge kategorier har de samme kernepligter: foranstaltninger til risikostyring (artikel 21), indberetning af hændelser (artikel 23) og ledelsens ansvar (artikel 20). Forskellen ligger i tilsynet og bøderne. For overtrædelser af artikel 21 eller 23 skal national lov give mulighed for maksimale bøder på mindst 10 mio. euro eller 2 % af den samlede globale årlige omsætning for væsentlige enheder og mindst 7 mio. euro eller 1,4 % for vigtige enheder, alt efter hvilket beløb der er højest. Medlemsstaterne afgør om, og i hvilket omfang, bøder kan pålægges enheder i den offentlige forvaltning.

Er din softwareleverandør selv omfattet?

At skrive software er ikke i sig selv en NIS 2-sektor. En leverandør kan alligevel være omfattet direkte. Bilag I omfatter udbydere af administrerede tjenester, og NIS 2 definerer dem bredt: enheder der installerer, administrerer, driver eller vedligeholder ikt-produkter, netværk, infrastruktur eller applikationer for kunder, på stedet eller på afstand. En mellemstor eller større leverandør der driver eller vedligeholder applikationer for sine kunder, kan derfor selv være omfattet, ligesom udbydere af cloudcomputing og datacentertjenester. For disse udbydere fastsætter gennemførelsesforordning (EU) 2024/2690 (åbner et eksternt websted) de tekniske krav i detaljer.

De fleste softwareleverandører møder dog NIS 2 gennem deres kunder, der omsætter deres egen pligt for forsyningskæden til kontraktklausuler, spørgeskemaer og audits. Softwareprodukter er også omfattet af forordningen om cyberrobusthed (åbner et eksternt websted), forordning (EU) 2024/2847: dens pligter til at indberette aktivt udnyttede sårbarheder og alvorlige hændelser gælder fra 11. september 2026, og de øvrige pligter fra 11. december 2027.

03De ti minimums­foranstaltninger i artikel 21

Artikel 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger baseret på en tilgang der omfatter alle farer. De skal afspejle det aktuelle tekniske niveau og relevante europæiske og internationale standarder og stå i forhold til enhedens risikoeksponering, størrelse og den sandsynlige alvor af hændelser. Som minimum omfatter de:

1. 01politikker for risikoanalyse og informationssystemers sikkerhed;
2. 02håndtering af hændelser;
3. 03driftskontinuitet, som backupstyring og reetablering efter katastrofer, og krisestyring;
4. 04sikkerhed i forsyningskæden, herunder sikkerhedsaspekter i forholdet til de direkte leverandører og tjenesteudbydere;
5. 05sikkerhed ved erhvervelse, udvikling og vedligeholdelse af net- og informationssystemer, herunder håndtering og offentliggørelse af sårbarheder;
6. 06politikker og procedurer til vurdering af om foranstaltningerne er effektive;
7. 07grundlæggende cyberhygiejne og uddannelse i cybersikkerhed;
8. 08politikker og procedurer for kryptografi og, hvor det er relevant, kryptering;
9. 09personalesikkerhed, politikker for adgangskontrol og forvaltning af aktiver;
10. 10multifaktorautentificering eller kontinuerlig autentificering og sikret tale-, video- og tekstkommunikation og nødkommunikation, hvor det er relevant.

Punkt 4 og 5 er der hvor leverandørerne kommer ind. Artikel 21, stk. 3, beder enhederne tage højde for de sårbarheder der er særlige for hver direkte leverandør, den samlede kvalitet af leverandørens produkter og cybersikkerhedspraksis og dens procedurer for sikker udvikling. Dine kunder forventes at se på hvordan du bygger software, ikke kun på hvad du leverer.

04Ledelsen godkender, fører tilsyn og står til ansvar

Efter artikel 20 skal ledelsesorganerne i væsentlige og vigtige enheder godkende foranstaltningerne til styring af cybersikkerhedsrisici, føre tilsyn med gennemførelsen og kan holdes ansvarlige for overtrædelser. Medlemmerne skal deltage i uddannelse, og enhederne opfordres til også at uddanne deres medarbejdere regelmæssigt. For offentlige myndigheder gælder de nationale regler om offentlige institutioners og ansattes ansvar fortsat.

Det ændrer samtalen med leverandørerne. En bestyrelse eller direktion der skal godkende foranstaltningerne, vil have dokumentation den kan følge: hvilke leverandører der understøtter hvilke tjenester, hvilke risici der står tilbage, og hvad der faktisk er testet.

05Indberetning af hændelser: 24 timer, 72 timer, en måned

Artikel 23 kræver at enhederne indberetter væsentlige hændelser til deres CSIRT eller kompetente myndighed. En hændelse er væsentlig, hvis den har forårsaget eller kan forårsage alvorlige driftsforstyrrelser eller økonomiske tab for enheden eller betydelig materiel eller immateriel skade for andre. I Danmark indberettes væsentlige hændelser via Virk.dk, der sender indberetningen videre til den relevante sektormyndighed og til den nationale CSIRT. Indberetningen sker i etaper:

Hvor det er relevant, skal enhederne også uden unødigt ophold informere modtagerne af deres tjenester om væsentlige hændelser der sandsynligvis vil påvirke tjenesterne. De nationale love tilføjer deres egne formularer og portaler, i Danmark Virk.dk.

Uret starter, når enheden bliver opmærksom på hændelsen. Begynder hændelsen i en leverandørs system, kan kunden kun overholde fristen på 24 timer, hvis leverandøren opdager den, genkender den og giver besked inden for få timer. Detektion, logning og en aftalt kanal til underretning er derfor kontraktvilkår, ikke kun tekniske detaljer.

06Hvad en NIS 2-kunde vil bede sin softwareleverandør om

I praksis bliver artikel 21 til tekniske foranstaltninger og dokumentation som en leverandør skal kunne vise uden at starte et projekt. Dem vi oftest møder:

• En sikker udviklingsproces. Trusselsmodellering ved væsentlige ændringer, kodegennemgang, automatiske sikkerhedstest og scanning af afhængigheder i pipelinen, signerede builds og en softwarestykliste (SBOM) for hver release.
• Håndtering og offentliggørelse af sårbarheder. En offentlig måde at melde sårbarheder på, aftalte svartider efter alvor og besked til kunden, når en sårbarhed påvirker kundens miljø.
• Adgangskontrol for leverandørens medarbejdere. Personlige konti, multifaktorautentificering, mindst mulige rettigheder, tidsbegrænset forhøjet adgang og en log over hver administrativ handling i kundens miljø.
• Logning og dokumentation ved hændelser. Sikkerhedsrelevante hændelser logges med pålidelige tidsstempler, gemmes i en aftalt periode og kan eksporteres, så kunden kan besvare spørgsmålene i den tidlige varsling og den endelige rapport.
• Samarbejde ved hændelser. En navngiven kontaktperson og kanal, en underretningstid langt inden for kundens 24 timer og hjælp til analyse af grundårsagen.
• Kontinuitet og reetablering. Backups der er bevist ved at blive genskabt, mål for reetablering der passer til kundens, og en indøvet procedure.
• Dokumentation af forsyningskæden. En opdateret liste over underleverandører og hostingsteder og over de vigtigste komponenter og tjenester fra tredjepart som løsningen afhænger af.
• En exitplan. Eksport af data i brugbare formater, dokumentation og hjælp til overdragelse, så kunden kan skifte leverandør uden at miste kontrollen over tjenesten.

Intet af dette er nyt for modne udviklingsteams. Det NIS 2 ændrer, er at kunden skal kunne dokumentere det. Vores side om tillid og compliance beskriver hvordan vi arbejder som leverandør, herunder vores ledelsessystem for informationssikkerhed, certificeret efter ISO/IEC 27001.

07En tjekliste til kontrakter og udbud

1. 01Kobl leverandører til tjenester. Registrér hvilke leverandører der understøtter hvilke omfattede tjenester, og hvilke der har adgang til dine systemer eller data.
2. 02Klassificér efter kritikalitet. Stil de tungeste krav til leverandører der driver eller kan ændre kritiske systemer.
3. 03Skriv foranstaltningerne ind i kontrakten. Sikkerhedskrav, tid og kanal for underretning om hændelser, håndtering af sårbarheder, logning og opbevaring, ret til audit eller dokumentation, regler for underleverandører og placeringer. I et offentligt udbud hører kravene hjemme i udbudsmaterialet.
4. 04Bed om dokumentation, ikke erklæringer. Certifikater med deres omfang, testresultater, en SBOM, datoen for den seneste genskabelsestest.
5. 05Aftal exit på forhånd. Tilbagelevering af data, hjælp til overgangen og den periode hvor leverandøren holder tjenesten kørende.
6. 06Øv sammen. Gennemfør en hændelsesøvelse med dine kritiske leverandører, inklusive den tidlige varsling inden for 24 timer.
7. 07Gennemgå regelmæssigt. Leverandører, tjenester og trusler ændrer sig; et leverandørregister der opdateres én gang om året, er forældet det meste af året.

08National lov afgør detaljerne

Registrering, indberetningsportaler, formularer, den kompetente myndighed og eventuelle supplerende krav følger alle af national lov. I Danmark er det NIS 2-loven med SAMSIK og sektormyndighederne og Virk.dk som indgang for indberetninger. Nogle medlemsstater kobler foranstaltningerne i artikel 21 til en national ramme eller certificering. Som udgangspunkt hører en enhed under den medlemsstat hvor den er etableret. Artikel 26 gør undtagelser: udbydere af offentlige elektroniske kommunikationsnet og -tjenester hører under hvert land hvor de leverer tjenester, udbydere af cloud, datacentre og administrerede tjenester og flere andre digitale udbydere under landet for deres hovedetablering, og enheder i den offentlige forvaltning under den stat der har oprettet dem. En leverandør med hovedetablering i et andet EU-land kan altså høre under det lands tilsyn, også når kunden er dansk.

09Hvad du skal holde øje med de kommende måneder

• Vejledning og tilsynspraksis fra SAMSIK og din sektormyndighed, herunder bekendtgørelser under NIS 2-loven.
• Kommissionens forslag om en digital omnibus (åbner et eksternt websted) af 19. november 2025, COM(2025) 837, der vil sende indberetninger af hændelser efter NIS 2, GDPR, DORA og andre regler gennem ét fælles indgangspunkt drevet af ENISA. I oktober 2026 lå forslaget stadig hos Europa-Parlamentet (åbner et eksternt websted)); indtil det er vedtaget og finder anvendelse, gælder de nuværende kanaler og frister.
• EU’s koordinerede risikovurderinger af kritiske ikt-forsyningskæder efter artikel 22, som enhederne skal tage højde for, når de vælger foranstaltninger over for leverandører.
• Tidsplanen for forordningen om cyberrobusthed for softwareprodukter med fuld anvendelse fra 11. december 2027.

For finansielle enheder erstatter forordningen om digital operationel modstandsdygtighed (DORA) NIS 2-reglerne om ikt-risikostyring, indberetning af hændelser og tilsyn; se vores artikel om DORA og tredjepartsudbydere af IKT-tjenester. Kommissionen har en oversigt over NIS 2 og de tilhørende gennemførelsesretsakter på sin side om NIS 2-direktivet (åbner et eksternt websted).