NIS2 og din webapp: hvad betyder det for leverandører?

Leverer du en webapp til en virksomhed eller kommune der er omfattet af NIS2, rammer loven dig som regel indirekte: kunden skal styre sikkerheden hos sine leverandører, og kravene ender i din kontrakt. De handler typisk om sikker udvikling, faste sikkerhedsopdateringer, hurtig besked ved hændelser, multifaktorlogin og dokumentation du kan vise frem. Selv er du som udgangspunkt kun omfattet hvis din virksomhed er i en af de udpegede sektorer og har mindst 50 årsværk eller over 10 mio. EUR i både omsætning og balance.

Jeg er udvikler, ikke jurist. Guiden bygger på den danske NIS 2-lov og vejledningerne fra Styrelsen for Samfundssikkerhed, og den er skrevet fra leverandørens side af bordet: hvad kunden kommer til at spørge om, og hvad du skal have på plads i koden, driften og kontrakten.

Den korte version: rammer NIS2 dig som leverandør?

Find den række der passer på dig. De fleste softwareleverandører hører til i den øverste.

Min tommelfingerregel: Jo tættere din webapp er på kundens kerneydelse, og jo mere adgang du har til deres systemer og data, jo flere krav kommer der. En bookingapp til kantinen og et system der styrer driften på et vandværk bliver ikke vurderet ens.

NIS2 er kun én del af ansvaret for en webapp i drift. Opdateringer, backup, overvågning og hvem der gør hvad, gennemgår jeg i guiden til drift og vedligehold af webapps.

Hvad er NIS2, og hvorfor rammer det leverandører?

NIS2 er et EU-direktiv om cybersikkerhed. I Danmark er det gennemført i lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau, kaldet NIS 2-loven. Loven trådte i kraft 1. juli 2025, og omfattede virksomheder skulle registrere sig via virk.dk senest 1. oktober 2025. Styrelsen for Samfundssikkerhed udgiver de fælles vejledninger, tilsynet ligger hos de sektoransvarlige myndigheder, og energi, tele og finans har deres egne NIS 2-love.

Loven gælder som udgangspunkt offentlige og private enheder i de sektorer der står i lovens to bilag hvis de har mindst 50 årsværk eller en årlig omsætning og en samlet balance på over 10 mio. EUR hver (Styrelsen for Samfundssikkerheds vejledning om anvendelsesområdet). Bilagene dækker blandt andet energi, transport, sundhed, drikkevand, spildevand, digital infrastruktur, offentlig forvaltning, affaldshåndtering, fødevarer og dele af fremstillingsindustrien. Kommuner er omfattet på samme måde som andre enheder, og enkelte typer enheder er omfattet uanset størrelse.

Leverandørerne kommer ind i billedet gennem lovens § 6. Den oplister ti områder hvor omfattede enheder skal have sikkerhedsforanstaltninger, og nr. 4 er forsyningskædesikkerhed: de sikkerhedsmæssige forhold mellem enheden og dens direkte leverandører. Styrelsen skriver det ret direkte i sin FAQ om NIS2: virksomheder der ikke selv er omfattet, kan alligevel blive påvirket hvis de leverer varer eller tjenester til en virksomhed der er.

En direkte leverandør er i vejledningens forstand en der har en direkte aftale med den omfattede enhed og leverer produkter eller tjenester der påvirker dens it-systemer. Udvikler, hoster eller vedligeholder du en webapp for kunden, er det dig.

De krav du typisk møder som leverandør

Styrelsens vejledning om cybersikkerhedsforanstaltninger giver eksempler på hvad en omfattet enhed kan skrive ind i kontrakten med sine leverandører. Oversat til en webapp ser det sådan ud:

Sikker udvikling og opdateringer

§ 6, nr. 5 handler om sikkerhed ved erhvervelse, udvikling og vedligeholdelse af it-systemer, herunder håndtering af sårbarheder. Vejledningen foreslår blandt andet at sikre sikkerhedsopdateringer i hele systemets levetid, at styre ændringer efter en fast procedure og at stille krav om sikker udvikling i alle faser.

For dig betyder det at kunden vil spørge om din proces, ikke kun om resultatet. Hvordan kommer en ændring fra din computer ud i drift? Bliver den testet og gennemgået? Kan du se hvem der har ændret hvad? Et Git-repository (kodearkiv) med pull requests, automatiske tests og et separat testmiljø besvarer de fleste af spørgsmålene. Kritiske sårbarheder bør håndteres uden unødige forsinkelser, så forvent en klausul om netop det, og nogle kunder vil også bede om en penetrationstest af webappen.

Hændelser og frister

Omfattede enheder skal indberette væsentlige hændelser i tre trin: en tidlig varsling inden for 24 timer, en hændelsesunderretning inden for 72 timer og en endelig rapport senest en måned efter (vejledning om hændelsesunderretning). Fristerne gælder kunden, ikke dig. Men kunden kan kun overholde dem hvis du siger til hurtigt, så forvent at kontrakten pålægger dig at give besked så snart du bliver opmærksom på en hændelse, og at hjælpe med oplysninger til indberetningen. Det forudsætter fejlrapportering og overvågning, ellers finder du først ud af det når kunden ringer.

Adgang, MFA og personale

§ 6, nr. 9 og 10 handler om adgangskontrol, personalesikkerhed og multifaktorlogin hvor det er relevant. Vejledningen nævner også at kontrakten kan stille krav til uddannelse og baggrundskontrol af leverandørens folk hvis de arbejder med kundens mest kritiske systemer. Det mest konkrete krav er MFA: forvent at skulle bruge det på alt der giver adgang til kundens system, dvs. hostingkonto, kodearkiv, database og administrationspanel.

Sådan gør du din webapp klar: 7 trin

Ingen af trinnene kræver en certificering. De fleste handler om at få styr på noget du formentlig allerede gør, og om at kunne vise det.

1. Find ud af hvilke kunder der er omfattet. Spørg dem direkte. Omfattede enheder har registreret sig og ved det som regel. Spørg også hvad de vil se fra dig, og hvornår de skal bruge det.
2. Lav et overblik over systemet. Hvor hostes appen, hvilke eksterne tjenester bruger den (mail, betaling, fejlrapportering, AI-tjenester), og hvem har adgang til hvad? Listen over underleverandører kommer kunden til at spørge efter.
3. Opdatér, og sæt opdateringerne i fast rytme. Kør composer audit og npm audit (kommandoer der tjekker dine pakker mod lister over kendte sårbarheder), ret fundene, og aftal en fast rytme. Jeg har skrevet om hvad det koster at lade framework og pakker sejle.
4. Stram adgangen. Slå MFA til overalt, brug personlige konti i stedet for delte logins, begræns adgangen til produktionsdata, og hav en fast rutine for at lukke adgange når nogen stopper.
5. Skriv en hændelsesprocedure på én side. Hvem opdager problemet, hvem kontakter kunden inden for hvor mange timer, og hvad står der i beskeden: hvad skete, hvornår, hvilke brugere og data er berørt, og hvad er gjort. Gennemgå den mindst én gang om året.
6. Test at backup kan gendannes. En backup der aldrig er gendannet, er en antagelse og ikke en plan. Se min guide til backup af webapps og 3-2-1-reglen.
7. Saml det i en sikkerhedsbeskrivelse. To til fire sider om hosting, underleverandører, opdateringsrytme, adgang og MFA, backup, hændelsesprocedure og kontaktperson. Sender du den med tilbuddet, besvarer den de fleste spørgeskemaer på forhånd.

Hvad NIS2 ikke forpligter kunden til at kræve

Det sker at en lille leverandør får et sikkerhedsbilag der ligner noget skrevet til en stor it-koncern. Her er det værd at kende Styrelsens egen formulering i vejledningen om anvendelsesområdet: NIS2 betyder ikke at omfattede enheder skal stille præcis de samme krav til leverandørerne som dem de selv er underlagt, og heller ikke at de skal kræve fx en særlig certificering eller revisionserklæring. Kravene skal være forholdsmæssige og bygge på en vurdering af den risiko din leverance udgør.

Det betyder ikke at kunden ikke må kræve det. En kunde kan godt skrive ISO 27001 (den internationale standard for informationssikkerhed) ind som betingelse, men så er det et forretningskrav og ikke et lovkrav, og det kan du forhandle om. Mit råd er at svare på risikoen: vis hvad du gør, og foreslå et niveau der passer til hvad appen faktisk gør for kunden.

Hvornår en lille leverandør ikke er det rigtige valg

Der er også situationer hvor en freelancer som mig ikke er svaret, og det er bedre at sige det højt:

• Kunden kræver ISO 27001-certificering eller en revisorerklæring som ISAE 3402 fra leverandøren som ufravigeligt krav.
• Systemet skal overvåges døgnet rundt med garanterede responstider om natten og i weekenden.
• Kunden kræver navngivne stedfortrædere og baggrundstjek af alle med adgang.

I de tilfælde passer en større leverandør med certificering og vagtordning bedre. Nogle gange er løsningen en kombination: udviklingen hos én og driften hos en certificeret hostingpartner.

Kontrakten: det skal du kigge efter

Når kundens sikkerhedsbilag lander, så læs det med tre spørgsmål i baghovedet: Kan jeg overholde det? Hvad koster det? Og hvem bærer risikoen hvis det går galt?

• Frist for besked. "Uden unødig forsinkelse" er realistisk for de fleste. "Inden for en time, døgnet rundt" kræver en vagtordning. Aftal også hvad der tæller som en hændelse.
• Revision. Hvem betaler, hvor ofte, og med hvilket varsel? En årlig skriftlig gennemgang er noget helt andet end besøg med kort varsel.
• Ansvar. Tjek at ansvarsbegrænsningen også gælder for sikkerhedsbilaget, så en overset klausul ikke åbner for ubegrænset erstatning.
• Underleverandører. Skal kunden godkende nye? Du bruger sandsynligvis hosting, mailtjenester og andre tjenester, og skift skal kunne ske uden en ny forhandling hver gang.
• Ophør. Aftal i hvilket format data udleveres, og hvornår de slettes.
• Pris. Sikkerhedsarbejdet tager tid. Opdateringer, dokumentation og hjælp ved hændelser hører hjemme i en løbende aftale, ikke i gratis ekstraarbejde.

Mange af punkterne hører naturligt til i en serviceaftale med svartider og faste opdateringer. Er kontrakten stor eller kunden kritisk, så få en advokat til at læse bilaget med.

Næste skridt: din NIS2-tjekliste som leverandør

Brug tjeklisten før næste møde med en kunde der er omfattet. Kan du krydse alle punkter af, står du stærkt når spørgeskemaet kommer.

Vil du have hjælp til den tekniske del, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende webapps. Den juridiske vurdering af om du eller din kunde er omfattet, bør du stadig få fra en rådgiver.

Ofte stillede spørgsmål

Skal jeg registrere min virksomhed under NIS2?+

Kun hvis din virksomhed selv er omfattet af loven. Registreringen sker via virk.dk med MitID Erhverv, og enheder der bliver omfattet efter den første frist, skal som udgangspunkt registrere sig inden for to uger. Er du en lille softwareleverandør under størrelsesgrænserne, skal du ikke registrere dig blot fordi dine kunder er omfattet. Er du i tvivl, kan værktøjet NIS 2-tjek på nis2tjek.dk, som Styrelsen for Samfundssikkerhed henviser til, hjælpe med en første vurdering.

Gælder Cyber Resilience Act også for min webapp?+

Som udgangspunkt ikke hvis din webapp kun leveres som en tjeneste i browseren. Cyber Resilience Act (EU-forordning 2024/2847) handler om produkter med digitale elementer, fx software og udstyr der sælges og installeres, og den indfases gradvist frem til december 2027. Sælger du software som kunden installerer, eller en app der hører til et fysisk produkt, bør du undersøge reglerne nærmere med en rådgiver.

Hvad er forskellen på NIS2-krav og GDPR-krav fra en kunde?+

GDPR beskytter persondata, mens NIS2 handler om sikkerheden og driften af hele systemet, også når der ingen persondata er. I praksis overlapper de meget, og kunder lægger ofte kravene i samme bilag som databehandleraftalen. Fristerne er forskellige: brud på persondatasikkerheden anmeldes til Datatilsynet, NIS2-hændelser indberettes efter egne regler. De tekniske GDPR-krav har jeg samlet i en tjekliste over GDPR for SaaS.

Hvem betaler for det ekstra sikkerhedsarbejde?+

Det er en forhandling, men det løbende arbejde hører som regel med i prisen for drift og vedligehold. Opdateringer, MFA og en hændelsesprocedure bør være standard for enhver seriøs leverandør. Krav der kun skyldes én kundes behov, fx særlige rapporter, revisionsbesøg eller kortere svartider om natten, er rimeligt at prissætte for sig. Aftal det før kontrakten underskrives, ikke når første revision står for døren.