NIS2-software er bedst, når den hjælper organisationen med at gennemføre og dokumentere sit eget sikkerhedsarbejde. Et navn på en kravliste eller en grøn status er ikke bevis for, at en sikkerhedsforanstaltning virker. Denne købsguide giver danske organisationer en konkret fremgangsmåde til at afprøve risikostyring, hændelser, leverandører og ledelsesopfølgning, før de vælger et værktøj.
Resultatet bør være et afprøvningsreferat: hvilke opgaver blev løst, hvilket materiale blev produceret, og hvilke mangler skal håndteres inden ibrugtagning? Der findes ikke én dokumenteret vinder for alle sektorer. Vi angiver derfor hverken en leverandørrangering eller udokumenterede markedspriser. Anbefalingerne nedenfor er indkøbskriterier, mens lovkravene er markeret med henvisninger til de relevante retskilder. Regler og myndighedskilder er kontrolleret den 27. september 2026.
NIS2 i Danmark: hvad gælder?
Den danske NIS 2-lov, lov nr. 434 af 6. maj 2025, trådte i kraft den 1. juli 2025. Den er en del af gennemførelsen, ikke hele den danske regulering. Tele-, energi- og finansområdet har særskilt lovgivning. Afklar derfor først den juridiske enhed, dens aktiviteter, størrelse og relevante særregler. En branchebetegnelse i et salgsoplæg er ikke en tilstrækkelig anvendelsesvurdering.
SAMSIK’s vejledning om anvendelsesområdet beskriver vurderingen og registreringsansvaret. Sektortilsynet er fordelt mellem kompetente myndigheder; alle virksomheder skal ikke registreres hos eller rapportere direkte til SAMSIK. Den oprindelige registreringsfrist den 1. oktober 2025 er heller ikke en fremtidig projektfrist. Ved nye aktiviteter eller ændret størrelse skal organisationen undersøge de løbende registrerings- og opdateringskrav.
Gem vurderingen som et selvstændigt dokument med dato, ejer og begrundelse. Den mere generelle guide om NIS2 i Danmark hjælper med den juridiske afgrænsning. I indkøbet skal vurderingen omsættes til rettigheder, rapporteringsmodtagere og kravpakker for netop de omfattede enheder. En koncern kan have forskellige forpligtelser i forskellige selskaber.
Væsentlige kontra vigtige entiteter: hvad betyder det for værktøjsvalget?
Kategorien påvirker navnlig tilsynsformen og håndhævelsen. Den giver ikke vigtige enheder en generel tilladelse til at have dårligere sikkerhed. Passende og forholdsmæssige foranstaltninger skal vurderes ud fra blandt andet risici og eksponering. Et værktøj bør derfor registrere både kategorien og den konkrete begrundelse for sikkerhedsniveauet frem for at tildele en automatisk, lavere kontrolpakke.
Direktivets artikel 34 stiller krav til medlemsstaternes maksimale administrative bødeniveauer: mindst 10 millioner euro eller 2 procent af global årsomsætning for de relevante væsentlige enheder og mindst 7 millioner euro eller 1,4 procent for relevante vigtige enheder, med det højeste beløb som reference. Det er ikke en automatisk dansk bødetakst. Den danske hovedlovs § 32 indeholder straffebestemmelser. Hold direktivets rammer, national hjemmel og en konkret afgørelse adskilt.
Ledelsesansvar skal tilsvarende beskrives præcist. Krav om godkendelse, tilsyn med gennemførelse og uddannelse betyder ikke, at enhver hændelse automatisk medfører personligt erstatnings- eller strafansvar. Brug software til at synliggøre beslutninger og opfølgning, ikke til at love juridisk immunitet.
Beskriv arbejdet, før I bestiller en demonstration
Skriv først tre problemer, som værktøjet skal løse. Det kan eksempelvis være manglende ejere af risici, uklar eskalation ved driftsstop og leverandørvurderinger, der ikke bliver opdateret. For hvert problem beskrives den ønskede ændring, den ansvarlige medarbejder og det dokument, som skal kunne eksporteres. Denne bestilling gør det lettere at afvise funktioner, der ser avancerede ud, men ikke hjælper med jeres opgaver.
Afgræns samtidig systemets rolle. Et dokumentationsværktøj udfører ikke nødvendigvis sikkerhedsovervågning, sårbarhedsscanning eller genetablering af driften. Det kan registrere resultater fra disse aktiviteter. Bed leverandøren vise, hvor oplysninger kommer fra, hvilke forbindelser der skal konfigureres, og hvad der stadig skal indtastes eller godkendes manuelt. En importeret kontrolstatus må ikke fremstå som en uafhængig teknisk verifikation.
Brug jeres kortlægning af it-systemer og afhængigheder til at vælge et sammenhængende eksempel. En kundetjeneste, dens identitetsløsning, driftsleverandør og backup giver et mere realistisk billede end en demonstration med løsrevne risici.
Afprøv risikostyring fra hændelse til beslutning
Et hypotetisk eksempel er en produktionsvirksomhed, hvor fjernadgang til et vedligeholdelsessystem kan stoppe leverancerne. Leverandøren skal oprette risikoen, beskrive de berørte aktiviteter, knytte eksisterende foranstaltninger til den og sende en resterende risiko til den rette beslutningstager. Bed derefter om at ændre en forudsætning, eksempelvis at en ekstern administrator får større adgang.
Afprøvningen skal vise, om den oprindelige vurdering bevares, om ændringen udløser ny behandling, og om den ansvarlige kan begrunde sin beslutning. Et farveskift alene er utilstrækkeligt. En høj risikoscore kan kræve hurtig handling, mens en lav score kan være baseret på udokumenterede antagelser. Værktøjet skal gøre denne forskel synlig for den, der godkender.
Metoden i en cyberrisikoanalyse med konkrete scenarier kan bruges som fagligt grundlag. Kræv ikke, at alle leverandører anvender netop jeres første regnemodel, men kræv at sandsynlighed, konsekvens, usikkerhed og risikobehandling kan forklares og eksporteres sammen med resultatet.
De ti minimumsforanstaltninger efter artikel 21
Artikel 21 behandler blandt andet risikoanalyse, hændelser, kontinuitet, leverandørkæde, sikker udvikling, effektivitetsvurdering, cyberhygiejne, kryptografi, personalesikkerhed og sikker adgang og kommunikation. Et bibliotek kan hjælpe med overblikket, men en række udfyldte felter viser ikke, om foranstaltningerne er tilstrækkelige. Den konkrete udformning skal afspejle organisationens forhold og eventuelle sektorspecifikke regler.
Bed om at se forbindelsen mellem en informationssikkerhedspolitik, dens praktiske instrukser og et dateret bevis. For adgangskontrol kan det være en godkendt politik, en faktisk gennemgang af administratorrettigheder og en rettelse efter fundet af en tidligere medarbejders konto. De tre dokumenter har forskellige funktioner og bør ikke erstatte hinanden.
Det er et godt indkøbskriterium, at udløbne eller manglende beviser kan ses særskilt. En kontrol kan være besluttet uden at være indført, og indført uden at være undersøgt. Lad ikke en samlet procentvis gennemførelsesgrad skjule disse forskelle. Grundlæggende it-sikkerhedsforanstaltninger kan give operationelle eksempler, som jeres sikkerhedsansvarlige kan omsætte til dokumentationskrav.
Incidentrapportering: de tre trin
Efter hovedlovens hændelsesregler skal relevante væsentlige hændelser håndteres i flere trin. Som udgangspunkt skal tidlig varsling ske uden unødigt ophold og inden 24 timer efter kendskab, efterfulgt af hændelsesunderretning inden 72 timer. Den endelige rapport skal som udgangspunkt sendes senest en måned efter hændelsesunderretningen. Pågår hændelsen stadig, skal der i stedet sendes en statusrapport og derefter en endelig rapport senest en måned efter håndteringen. Underretningen efter 72 timer er altså ikke nødvendigvis en fuldt opklaret rapport. Tillidstjenesteudbydere har en særlig 24-timersfrist for hændelsesunderretningen.
Afprøv derfor flere tidsstempler: første tekniske signal, tidspunktet for den relevante viden, klassifikation, godkendelse og faktisk indsendelse. Systemet skal kunne forklare, hvilken oplysning der starter en frist. Et almindeligt fejlscenarie er, at uret først begynder, når en sagsbehandler åbner en opgave, selv om organisationen allerede har haft kendskab til hændelsen.
SAMSIK’s tilsynsside henviser til den praktiske indberetningskanal og beskriver den nationale CSIRT. Kræv en dokumenteret vej fra internt udkast til korrekt modtager. En eksportknap er ikke bevis for indsendelse. Hvis leverandøren lover integration, skal den demonstreres med kvittering, fejlhåndtering og en reserveprocedure uden at sende en fiktiv myndighedsanmeldelse.
Hold persondatabrud og driftsforstyrrelser adskilt
Det samme angreb kan udløse flere vurderinger. En væsentlig driftsforstyrrelse er ikke automatisk et anmeldelsespligtigt persondatabrud, og et brud på fortroligheden kan være vigtigt efter GDPR uden at ramme NIS2’s hændelseskriterier. Registrér fælles fakta én gang, men bevar særskilte beslutninger, frister og modtagere for hvert relevant regelsæt.
En procedure for brud og brudlog hjælper med den interne arbejdsgang, mens anmeldelse efter artikel 33 og 34 handler om databeskyttelsens vurderinger. I demonstrationen bør samme sag kunne afsluttes uden GDPR-anmeldelse med begrundelse, samtidig med at en anden underretning fortsætter. Det er bedre evidens for fleksibilitet end en påstand om samlet compliance.
Leverandørstyring skal følge den leverede tjeneste
En leverandørs navn og et generelt certifikat fortæller ikke, hvad virksomheden er afhængig af. Knyt tjenesten til konkrete systemer, ansvarlige personer og konsekvenser ved svigt. Registrér dokumentationens omfang og dato, så en rapport om en anden tjeneste ikke utilsigtet bruges som bevis for jeres egen løsning.
Afprøv en ændring af underleverandør eller driftssted. Systemet bør vise, hvilke vurderinger der skal genbesøges, og hvem der ejer kontakten til leverandøren. Forlang ikke nødvendigvis, at al dokumentation ligger i samme system; en kontrolleret henvisning kan fungere, hvis adgang og version er stabile.
NIS2’s leverandørhensyn og GDPR’s databehandleraftaler overlapper kun delvist. En kritisk teknisk leverandør kan være relevant for driften uden at være databehandler. Omvendt kan en databehandler med begrænset driftsmæssig betydning håndtere følsomme oplysninger. Værktøjet skal kunne registrere begge vurderinger uden automatisk at sidestille rollerne.
Kontinuitet skal kunne fungere uden platformen
Planlæg en demonstration, hvor compliance-platformen selv er utilgængelig. Kan organisationen stadig finde kontaktveje, beslutningskompetence og de vigtigste trin i en beredskabsplan for forretningskontinuitet? Hvis alle instrukser kræver adgang til den identitetsløsning, der er nede, er systemets dokumentationskvalitet ikke nok.
Bed om en kontrolleret eksport til beredskabsbrug, en navngiven ejer og en måde at se, om kopien er forældet. Vurdér også oplysningerne i eksporten: en detaljeret sårbarhedsliste skal ikke ligge åbent i en almindelig fællesmappe. Adgang under en krise og fortrolighed skal tænkes sammen.
Efter øvelsen skal fund kunne føres tilbage til de relevante risici og foranstaltninger. En afsluttet øvelse med åbne kritiske problemer er ikke det samme som et robust beredskab. Brug opfølgningen til at se, om systemet understøtter reel forbedring over tid.
Ledelsens ansvar
Ledelsen har brug for et beslutningsgrundlag, der viser konsekvenser og valgmuligheder. En rapport med hundreder af kontrolnumre kan være korrekt uden at være anvendelig. Bed om et eksempel med en udestående risiko, mulige foranstaltninger, ressourcebehov og en anbefalet beslutning. Vis derefter, hvordan beslutningen bliver omsat til ansvar og opfølgning.
Godkendelser bør knyttes til den version, der faktisk blev forelagt. Hvis en risikovurdering ændres efter godkendelsen, må systemet ikke give indtryk af, at ledelsen også har accepteret det nye indhold. Det samme gælder registreret uddannelse: deltagelse, indhold og den efterfølgende anvendelse er forskellige forhold.
Softwarealternativer og samlet pris
Et specialiseret risikoværktøj, en bredere styringsplatform eller en eksisterende dokumentationsløsning kan alle være relevante. Vurder den faktiske opsætning og arbejdsdeling. Der er ikke belæg for generelt at kalde en udvidelse af eksisterende GDPR-software billigst eller sikrest. Kriterier til sammenligning af GDPR-værktøjer kan bruges til fælles administrative behov; finansielle aktiviteter kræver særskilt vurdering af DORA-værktøjer.
Indhent tilbud på samme antal juridiske enheder, brugere, leverandører og integrationer. Medregn datarensning, opsætning, undervisning, support, årlige ændringer og eksport ved ophør. Brug arbejdet med et softwarebudget som struktur frem for at overføre et udokumenteret standardbeløb til NIS2.
Skriv et afprøvningsreferat, som indkøb kan bruge
Referatet skal beskrive det konkrete prøveforløb og resultatet for hvert nødvendigt krav. Notér hvilken produktversion, konfiguration og brugerrolle der blev anvendt. Hvis leverandøren måtte rette opsætningen under demonstrationen, skal det fremgå, om rettelsen er en del af standardleverancen eller kræver særskilt arbejde. Ellers kan et vellykket salgsmøde skjule en væsentlig opgave efter underskrift.
Skeln mellem dokumenteret funktion, dokumenteret begrænsning og ubesvaret spørgsmål. Et eksempel er en rapport, som kan eksporteres, men mister henvisningen til det bevis, der underbygger kontrollen. Funktionen findes, men resultatet opfylder måske ikke jeres behov. Beskriv konsekvensen og afklar, om en manuel henvisning er tilstrækkelig, eller om manglen bør blokere valget.
Lad brugerne vurdere opgaverne fra deres egen rolle. En risikoejer skal kunne forstå, hvad der skal besluttes; en driftsmedarbejder skal kunne indsende et bevis uden adgang til alle følsomme vurderinger. En central administrator må gerne have flere muligheder, men demonstrationen bør ikke udføres udelukkende med administratoradgang. Det kan give et misvisende billede af den daglige brug.
Planlæg overdragelsen fra projekt til drift
Inden købet godkendes, skal organisationen vide, hvem der administrerer brugere, ændrer kravbiblioteket og følger op på manglende dokumentation. Hvis leverandøren foreslår løbende rådgivning, skal omfanget beskrives særskilt. Værktøjslicens og faglig bistand er forskellige leverancer, og ingen af dem overfører ledelsens ansvar til leverandøren.
Fastlæg en enkel opfølgningsperiode efter ibrugtagning. Undersøg eksempelvis, om en faktisk leverandørændring blev registreret korrekt, om en risiko kom frem til den rette beslutningstager, og om en afsluttet opgave har brugbart bevis. Det er jeres interne kvalitetskontrol, ikke en lovbestemt universel tidsplan. Brug resultaterne til at justere instrukser og rettigheder, mens erfaringerne stadig er konkrete.
Planlæg også, hvordan organisationen kan forlade løsningen. Bed om en prøveeksport af risici, kontroller, dokumenthenvisninger og godkendelser. Materialet skal kunne forstås af en kollega uden at åbne den gamle platform. Aftal, hvilke filer der kan udleveres, hvor længe overgangsadgang varer, og hvordan resterende kopier bliver håndteret. En omfattende eksport er kun nyttig, hvis relationerne og dokumenternes betydning stadig fremgår.
Endelig bør beslutningsnotatet forklare, hvorfor netop denne løsning er egnet til de vigtigste opgaver. Henvis til prøveforløbet og de accepterede begrænsninger. Hvis et afgørende spørgsmål stadig mangler svar, skal ledelsen kende usikkerheden og konsekvensen. En samlet pointsum kan understøtte vurderingen, men må ikke skjule et uopfyldt krav, som organisationen faktisk er afhængig af.
Ofte stillede spørgsmål
Er vores GDPR-software nok til NIS2?
Kun hvis de konkrete nødvendige arbejdsgange faktisk kan gennemføres og dokumenteres. En fortegnelse efter GDPR erstatter ikke hændelsesklassifikation, kontinuitetsarbejde eller ledelsesopfølgning. Afprøv de manglende funktioner og vurder en kontrolleret forbindelse mellem systemer, før I køber en større platform.
Kræver reglerne EU-hosting og dansk brugerflade?
Det er ikke generelle krav, der kan udledes alene af NIS2. Dataplacering, adgang, leverandørforhold og relevant databeskyttelsesret skal vurderes konkret. Dansk dokumentation kan være et praktisk indkøbskrav, men organisationen skal forklare behovet og afprøve forståeligheden hos de faktiske brugere.
Hvordan ved vi, at købet er klar til godkendelse?
Når afprøvningsreferatet viser fungerende arbejdsgange, kendte begrænsninger og en realistisk plan for de resterende opgaver. Lad sikkerhed, drift, indkøb og ledelse bekræfte deres respektive dele. Et køb kan accepteres med afgrænsede mangler, hvis risici og afhjælpning er tydelige; ubekræftede løfter bør ikke tælles som leveret funktionalitet.