Kortlægning af NIS2-bevismateriale med ISO 27001:2022 i 2026

NIS2-problemet i 2026 er ikke bevidsthed, men dokumentation

Det er mandag morgen kl. 08.35. Maria, den nyudnævnte CISO hos en hurtigt voksende B2B-udbyder af cloud og administrerede tjenester, deltager i det kvartalsvise risikomøde med bestyrelsen med en omfattende NIS2-gap-analyse åben på sin laptop. Den første slide ser beroligende ud. Politikker findes. Der findes en risikovurdering. Hændelseshåndtering er dokumenteret. Leverandører er registreret. Sårbarhedsscanninger kører hver måned.

Så stiller bestyrelsesformanden det spørgsmål, der ændrer mødet:

“Kan vi dokumentere, at disse foranstaltninger virkede i sidste kvartal, og kan vi vise, hvilke ISO 27001:2022-kontroller, ejere og registreringer der understøtter hver NIS2-forpligtelse?”

Der bliver stille i lokalet.

Jura ved, at virksomheden er omfattet af NIS2, fordi den leverer administrerede IKT- og cloudtjenester til EU-kunder. Compliance ved, at Article 21 kræver tekniske, operationelle og organisatoriske foranstaltninger til styring af cybersikkerhedsrisici. Driften ved, at teamet patcher systemer, gennemgår leverandører og overvåger logfiler. Men bevismaterialet ligger spredt på tværs af helpdesk-systemet, SIEM-eksporter, politikmapper, regneark, cloudportaler, leverandørportaler og mødereferater.

Ingen kan hurtigt vise en forsvarlig sporbarhedskæde fra NIS2 Article 21 til ISO 27001:2022-omfang, risiko, kontrol, politik, ejer, procedure, driftsregistrering og revisionskonstatering.

Det er den reelle udfordring i 2026.

Mange organisationer spørger ikke længere: “Er vi omfattet af NIS2?” De stiller et sværere spørgsmål: “Kan vi dokumentere, at vores tekniske NIS2-foranstaltninger faktisk virker?” Svaret kan ikke være et engangsregneark med en kortlægning. Det skal være en levende driftsmodel i ledelsessystemet for informationssikkerhed (ISMS), hvor retlige forpligtelser omsættes til risici, politikker, kontroller, ejere, bevismateriale og løbende forbedring.

Clarysecs model bruger ISO/IEC 27001:2022 som rygraden i ledelsessystemet, NIS2 Article 21 som sættet af regulatoriske forpligtelser, politikklausuler som den operationelle regelbog, Zenith Blueprint: en auditors 30-trins køreplan som implementeringsvejen og Zenith Controls: vejledning til tværgående efterlevelse som tværgående efterlevelseskort for ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF og COBIT-lignende assurance.

Start med omfanget, fordi NIS2-bevismateriale begynder før kontrollerne

En almindelig NIS2-fejl er at gå direkte til MFA, logning, hændelseshåndtering og sårbarhedsstyring, før enhedsomfang, tjenesteomfang og jurisdiktionsomfang er bekræftet.

NIS2 gælder for omfattede offentlige og private enheder i regulerede sektorer, der opfylder kriterier for størrelse og aktivitet, mens visse enhedstyper er omfattet uanset størrelse. Relevante digitale og IKT-kategorier omfatter udbydere af cloud computing-tjenester, datacentertjenester, tjenester vedrørende indholdsleveringsnet, tillidstjenester, offentligt tilgængelige elektroniske kommunikationstjenester, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, onlinemarkedspladser, onlinesøgemaskiner og sociale netværksplatforme.

For cloududbydere, SaaS-platforme, MSP’er, MSSP’er og udbydere af digital infrastruktur er denne afgrænsning ikke teoretisk. Article 3 kræver, at medlemsstater skelner mellem væsentlige og vigtige enheder. Article 27 kræver, at ENISA fører et register for flere digitale og IKT-udbydere, herunder DNS-tjenesteudbydere, TLD-navneregistre, enheder der udbyder domænenavnsregistreringstjenester, udbydere af cloud computing-tjenester, datacentertjenester, tjenester vedrørende indholdsleveringsnet, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, onlinemarkedspladser, onlinesøgemaskiner og sociale netværksplatforme.

ISO 27001:2022 giver den rette struktur. Punkt 4.1 til 4.4 kræver, at organisationen forstår eksterne og interne forhold, interessenter, krav, grænseflader og afhængigheder og derefter definerer ISMS-omfanget. NIS2 skal registreres her, ikke efterlades i et juridisk notat.

En praktisk NIS2-omfangsregistrering bør omfatte:

• Juridisk enhed og analyse af etablering i EU
• NIS2-sektor og tjenestekategori
• Status som væsentlig eller vigtig enhed, hvor dette er bekræftet af national ret eller myndighedsudpegning
• Relevans for ENISA-registeret, hvor relevant
• Kritiske tjenester leveret til kunder
• Net- og informationssystemer, der understøtter disse tjenester
• Afhængigheder af cloud, datacenter, telekommunikation, sikkerhedsovervågning, identitet og softwareleverandører
• Koblinger til DORA, GDPR, kundekontrakter og sektorspecifikke forpligtelser
• Placeringer for bevismateriale, systemejere og gennemgangsfrekvens

Det er også her, DORA skal adskilles korrekt. NIS2 anerkender, at hvor en sektorspecifik EU-retsakt pålægger tilsvarende forpligtelser vedrørende styring af cybersikkerhedsrisici eller hændelsesunderretning, finder den sektorspecifikke ordning anvendelse i stedet for de tilsvarende NIS2-bestemmelser. For omfattede finansielle enheder er DORA generelt den operative ordning for cybersikkerhed og rapportering af IKT-hændelser. DORA finder anvendelse fra 17. januar 2025 og dækker styring af IKT-risiko, hændelsesrapportering, test af digital operationel robusthed, IKT-tredjepartsrisiko og tilsyn med kritiske IKT-tredjepartsudbydere.

En fintech-koncern kan derfor have forskellige efterlevelsesbehandlinger inden for én selskabsstruktur. Betalingsenheden kan primært være underlagt DORA. MSP-datterselskabet kan være direkte underlagt NIS2. En fælles cloudplatform kan understøtte begge. Det modne svar er ikke dobbelte kontroller. Det er én ISMS-baseret evidensmodel, der kan understøtte flere regulatoriske vinkler.

ISO 27001:2022 som operativsystem for NIS2-efterlevelse

NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til at styre risici for net- og informationssystemer og til at forebygge eller minimere hændelsers påvirkning af tjenestemodtagere og andre tjenester.

ISO 27001:2022 er velegnet til at operationalisere dette krav, fordi standarden gennemtvinger tre discipliner.

For det første styring. Punkt 5.1 til 5.3 kræver øverste ledelses engagement, tilpasning til den strategiske retning, ressourcer, kommunikation, tildeling af ansvar og en dokumenteret informationssikkerhedspolitik. Dette flugter direkte med NIS2 Article 20, som kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager træning.

For det andet risikobehandling. Punkt 6.1.1 til 6.1.3 kræver en gentagelig risikovurderingsproces, risikoejere, risikoevaluering, behandlingsmuligheder, kontroludvælgelse, en anvendelighedserklæring (SoA), en risikobehandlingsplan og godkendelse af restrisiko.

For det tredje operationel styring. Punkt 8.1 kræver, at organisationen planlægger, implementerer og styrer ISMS-processer, opretholder dokumenteret information, styrer ændringer og håndterer eksternt leverede processer, produkter og tjenester, der er relevante for ISMS.

Det omdanner NIS2 fra en juridisk tjekliste til en operationel kontrolmodel.

Hver række kræver en ejer, en registreringskilde og en stikprøvemetode. Hvis de mangler, har organisationen en kontrolambition, ikke en kontrol.

Politikken er der, hvor NIS2 bliver til operationel adfærd

Politikker behandles ofte som skabeloner. For NIS2 er det farligt. En regulator eller auditor bliver ikke overbevist af en politikmappe, hvis politikkerne ikke tildeler ejerskab, definerer registreringer, kobler til risici og producerer bevismateriale.

Virksomhedens Politik for juridisk og regulatorisk efterlevelse fastlægger fundamentet i punkt 6.2.1:

Alle juridiske og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).

Denne klausul er broen mellem NIS2 og ISO 27001:2022. NIS2 Article 21 opføres ikke blot som et eksternt krav. Den nedbrydes i politikforpligtelser, kortlægges til kontroller, tildeles ejere og testes gennem bevismateriale.

For mindre organisationer holder SMV-versionen af Politik for juridisk og regulatorisk efterlevelse det samme koncept letvægtsbaseret. Punkt 5.1.1 kræver:

Direktøren skal vedligeholde et enkelt, struktureret efterlevelsesregister, der angiver:

Sætningen er bevidst praktisk. SMV’er behøver ikke en kompleks GRC-implementering for at komme i gang. De har brug for et efterlevelsesregister, der registrerer forpligtelse, anvendelighed, ejer, politik, bevismateriale og gennemgangsfrekvens.

Risikobehandling omsætter derefter forpligtelsen til handling. Virksomhedens Politik for risikostyring, punkt 6.4.2 angiver:

Den risikoansvarlige skal sikre, at behandlinger er realistiske, tidsbundne og kortlagt til ISO/IEC 27001 Annex A-kontroller.

For SMV’er giver Politik for risikostyring - SMV, punkt 5.1.2 den mindste brugbare risikoregistrering:

Hver risikopost skal omfatte: beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan.

Disse klausuler er vigtige, fordi NIS2 udtrykkeligt er risikobaseret og proportional. Article 21 forventer, at foranstaltninger afspejler det aktuelle tekniske niveau, relevante standarder, implementeringsomkostninger, risikoeksponering, størrelse samt hændelsers sandsynlighed og alvorlighed, herunder samfundsmæssig og økonomisk påvirkning. Et risikoregister uden ejere og behandlingsplaner kan ikke dokumentere proportionalitet.

Virksomhedens Informationssikkerhedspolitik fuldender evidensprincippet i punkt 6.6.1:

Alle implementerede kontroller skal kunne revideres og understøttes af dokumenterede procedurer og bevaret bevismateriale for drift.

Det er forskellen mellem at have et NIS2-program og at have et NIS2-evidensprogram.

Clarysec-vejen fra kortlægning til drift

Zenith Blueprint er værdifuld, fordi den afspejler, hvordan auditorer tænker. De spørger ikke kun, om en kontrol findes. De spørger, hvorfor den blev valgt, hvor den er dokumenteret, hvordan den fungerer, hvem der ejer den, hvilket bevismateriale der dokumenterer den, og hvordan organisationen forbedrer den.

I risikostyringsfasen angiver trin 13, at teams skal tilføje sporbarhed mellem risici, kontroller og klausuler:

✓ Kortlæg kontroller til risici: I behandlingsplanen i jeres risikoregister har I angivet bestemte kontroller for hver risiko. I kan tilføje en kolonne “Annex A-kontrolreference” til hver risiko og angive kontrolnumrene.

For NIS2 betyder det, at risikoregisteret og anvendelighedserklæringen bør vise, hvorfor kontroller som 8.8 Styring af tekniske sårbarheder, 5.19 Informationssikkerhed i leverandørrelationer og 5.24 Planlægning og forberedelse af hændelsesstyring er anvendelige.

Trin 14 i Zenith Blueprint gør den regulatoriske kortlægning eksplicit:

For hver regulering kan I, hvis relevant, oprette en enkel kortlægningstabel (eventuelt som bilag i en rapport), der angiver reguleringens centrale sikkerhedskrav og de tilsvarende kontroller/politikker i jeres ISMS.

Det forhindrer fragmentering. GDPR-sikkerhed for personoplysninger, NIS2-hændelsesrapportering, DORA-test af IKT-robusthed og kunders sikkerhedsforpligtelser kan alle bygge på samme bevismateriale: adgangsrettighedsgennemgange, afhjælpning af sårbarheder, logningsregistreringer, backuptest, leverandørgennemgange og hændelsesrapporter.

Trin 19 flytter arbejdet fra design til drift:

Knyt hvert af disse dokumenter til den relevante kontrol i jeres SoA eller ISMS-manual. De vil fungere som bevis for implementering og som intern reference.

Dokumentationssættet i trin 19 omfatter slutbrugerudstyrssikkerhed, adgangsstyring, autentifikation, sikre konfigurationsbaselines, logning og overvågning, patchstyring, sårbarhedsstyring, kapacitetsplanlægning og rapportering om IT-drift. Det er netop de operationelle dokumenter, der er nødvendige for at gøre tekniske NIS2-foranstaltninger revisionsbare.

Trin 26 forklarer, hvordan revisionsbevismateriale bør indsamles:

Efterhånden som I indsamler bevismateriale, skal I registrere jeres konstateringer. Notér, hvor forholdene er i overensstemmelse med kravet (positive konstateringer), og hvor de ikke er det (mulige afvigelser eller observationer).

For NIS2 betyder det, at bevismateriale skal stikprøves, før en regulator, kundevurderingspart eller certificeringsauditor efterspørger det.

Zenith Controls’ rolle i tværgående efterlevelse

Zenith Controls er ikke et separat kontrolframework. Det er Clarysecs vejledning til tværgående efterlevelse for kortlægning af ISO/IEC 27001:2022- og ISO/IEC 27002:2022-kontroller til relaterede kontroller, revisionsforventninger og eksterne rammeværker. Den hjælper teams med at forstå, hvordan én ISO 27001:2022-kontrol kan understøtte NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT-lignende assurance.

Tre ISO 27001:2022-kontroller er særligt vigtige for kortlægning af NIS2-bevismateriale.

Kontrol 5.1 Politikker for informationssikkerhed er indgangspunktet, fordi NIS2 Article 21 omfatter risikoanalyse og sikkerhedspolitikker for informationssystemer. Hvis en teknisk NIS2-foranstaltning ikke afspejles i en politik, er den vanskelig at styre og svær at revidere ensartet.

Kontrol 5.36 Overholdelse af politikker, regler og standarder for informationssikkerhed er realitetstjekket. Den kobler politikkrav til faktisk overensstemmelse med interne regler, standarder og eksterne forpligtelser. I NIS2-termer er det her, en organisation spørger, om den gør det, dens Article 21-kortlægning siger, at den gør.

Kontrol 8.8 Styring af tekniske sårbarheder er et af de sværeste testområder i 2026. Sårbarhedsstyring er direkte relevant for sikker anskaffelse, udvikling, vedligeholdelse, sårbarhedshåndtering og offentliggørelse. Den understøtter også DORA-test og afhjælpning, GDPR-ansvarlighed for sikkerhed, NIST CSF Identify- og Protect-resultater samt ISO 27001-revisionsstikprøver.

Understøttende standarder kan skærpe designet uden at kræve yderligere certificeringer. ISO/IEC 27002:2022 giver implementeringsvejledning for Annex A-kontroller. ISO/IEC 27005 understøtter informationssikkerhedsrisikostyring. ISO/IEC 27017 understøtter cloudsikkerhed. ISO/IEC 27018 understøtter beskyttelse af personhenførbare oplysninger (PII) i scenarier med behandling i public cloud. ISO 22301 understøtter forretningskontinuitet. ISO/IEC 27035 understøtter hændelsesstyring. ISO/IEC 27036 understøtter sikkerhed i leverandørrelationer.

Målet er ikke flere standarder for standardernes skyld. Målet er bedre evidensdesign.

Praktisk eksempel: opbyg en NIS2-evidenspakke for sårbarheder

Betragt Marias SaaS-platform. Den betjener produktionskunder i EU og afhænger af cloudtjenester, open source-komponenter, CI/CD-pipelines og administreret overvågning. Hendes gap-rapport siger “sårbarhedsstyring implementeret”, men bevismaterialet er spredt på tværs af scannere, Jira, GitHub, værktøjer til cloudkonfiguration og ændringssager.

En NIS2-klar evidenspakke kan bygges i ét fokuseret sprint.

Trin 1: Definér risikoscenariet

Risiko: En udnyttelig sårbarhed i en interneteksponeret applikation, afhængighed eller cloudkomponent medfører driftsafbrydelser, uautoriseret adgang eller eksponering af kundedata.

Risikoregisteret bør indeholde beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan. Behandlingsplanen bør referere til ISO 27001:2022-kontrol 8.8 Styring af tekniske sårbarheder samt relaterede kontroller for aktivfortegnelse, sikker udvikling, logning, adgangsstyring, leverandørstyring og hændelseshåndtering.

Trin 2: Kortlæg risikoen til NIS2 Article 21

Risikoen understøtter Article 21-krav til sikker anskaffelse, udvikling og vedligeholdelse, sårbarhedshåndtering og offentliggørelse, risikoanalyse, hændelseshåndtering, sikkerhed i forsyningskæden og vurdering af kontroleffektivitet.

Trin 3: Forankr driftsreglerne i politik

Brug en sårbarhedsstyringsprocedure, standard for sikker udvikling, krav til patchstyring, politik for sikkerhedstestning og regler for revisionsbevismateriale.

Virksomhedens Politik for sikkerhedstestning og Red Teaming, punkt 6.1 angiver:

Testtyper: Sikkerhedstestprogrammet skal som minimum omfatte: (a) sårbarhedsscanning, bestående af automatiserede ugentlige eller månedlige scanninger af netværk og applikationer for at identificere kendte sårbarheder; (b) penetrationstest, bestående af manuel dybdegående test af specifikke systemer eller applikationer udført af kvalificerede testere for at identificere komplekse svagheder; og (c) red team-øvelser, bestående af scenariebaserede simuleringer af reelle angreb, herunder social engineering og andre taktikker, for at teste organisationens samlede detektions- og responskapacitet.

Denne klausul skaber en forsvarlig testbaseline. Den flugter også med DORA’s forventning om tilbagevendende, risikobaseret test af digital operationel robusthed for omfattede finansielle enheder.

Trin 4: Definér metadata for bevismateriale

Politik for revision og overvågning af efterlevelse - SMV, punkt 6.2.3 angiver:

Metadata (f.eks. hvem der indsamlede det, hvornår og fra hvilket system) skal dokumenteres.

For sårbarhedsbevismateriale bør pakken registrere:

• Scannernavn og konfiguration
• Scanningsdato og -tidspunkt
• Aktivomfang og undtagelser
• Kritiske og høje konstateringer
• Sagsnummer og ejer
• Patch- eller afbødningsbeslutning
• Risikoacceptbeslutning, hvor relevant
• Afhjælpningsdato
• Valideringsscanning
• Link til ændringsregistrering
• Undtagelsesejer og udløbsdato

Trin 5: Tilføj logningsbevismateriale

Lognings- og overvågningspolitik - SMV, punkt 5.4.4 omfatter systemlogfiler såsom:

Systemlogfiler: Konfigurationsændringer, administrative handlinger, softwareinstallationer, patchningsaktivitet

En patchsag alene dokumenterer ikke nødvendigvis, at ændringen blev gennemført. Konfigurationslogfiler, administrative handlinger og registreringer af softwareinstallation styrker evidenskæden.

Trin 6: Gennemfør en stikprøverevision

Vælg fem kritiske eller høje sårbarheder fra det foregående kvartal. For hvert punkt skal det verificeres, at aktivet var i aktivfortegnelsen, at scanneren detekterede konstateringen, at en sag blev åbnet inden for SLA, at en ejer blev tildelt, at afhjælpningen svarede til alvorlighed og udnyttelighed, at logfiler viser ændringen, at validering bekræfter lukning, og at enhver undtagelse har godkendelse fra risikoejeren med en udløbsdato.

Dette sprint producerer en NIS2-klar sårbarhedsevidenspakke og en intern revisionsstikprøve for ISO 27001:2022.

Leverandørsikkerhed er økosystemstyring

NIS2 Article 21 kræver sikkerhed i forsyningskæden, herunder sikkerhedsaspekter vedrørende relationer med direkte leverandører og tjenesteudbydere. Den forventer også, at organisationer tager højde for leverandørsårbarheder, produktkvalitet, leverandørers cybersikkerhedspraksis og praksis for sikker udvikling.

Det var her, den første version af Marias gap-rapport var svagest. Den registrerede leverandører, men dokumenterede ikke due diligence, sikkerhedsklausuler i kontrakter, overvågning eller exitparathed.

Politik for tredjeparts- og leverandørsikkerhed giver politikforankringen. Relateret implementering kan understøttes af Politik for sikker udvikling, Politik for bevidsthed om informationssikkerhed og uddannelse, Politik for sårbarheds- og patchstyring, Politik for kryptografiske kontroller, Politik for adgangskontrol og Politik for fjernadgang.

Et enkelt leverandørevidensregister kan understøtte NIS2, DORA og ISO 27001:2022.

Denne tabel forhindrer dobbelte spørgeskemaer, dobbelte registre og modstridende kontrolejerskab.

Én hændelsesarbejdsgang for NIS2, DORA og GDPR

NIS2 Article 23 kræver, at væsentlige hændelser underrettes uden unødig forsinkelse. Artiklen fastlægger en trinvis tidslinje: tidlig varsling inden for 24 timer efter kendskab, hændelsesunderretning inden for 72 timer med indledende vurdering af alvorlighed eller påvirkning og tilgængelige kompromitteringsindikatorer, mellemliggende opdateringer hvis anmodet om det og en endelig rapport senest én måned efter hændelsesunderretningen.

DORA har en tilsvarende livscyklus for finansielle enheder: detektion, klassificering, logning, alvorlighedsvurdering, eskalering, kundekommunikation, myndighedsrapportering, rodårsagsanalyse og afhjælpning. GDPR tilføjer analyse af brud på persondatasikkerheden, herunder dataansvarlig- og databehandlerroller, påvirkning af registrerede og 72-timers underretningsfristen, hvor relevant.

Det korrekte design er ikke tre hændelsesprocesser. Det er én samlet arbejdsgang for hændelser med regulatoriske beslutningsgrene.

Politik for hændelseshåndtering - SMV, punkt 5.4.1 angiver:

Alle hændelsesundersøgelser, konstateringer og korrigerende handlinger skal registreres i et hændelsesregister, der vedligeholdes af direktøren.

Et stærkt hændelsesregister bør omfatte:

GDPR-koblingen bør ikke undervurderes. NIS2-kompetente myndigheder kan informere GDPR-tilsynsmyndigheder, hvor mangler i styring af cybersikkerhedsrisici eller rapportering kan indebære et brud på persondatasikkerheden. ISMS bør derfor gøre databeskyttelsesvurdering til en del af hændelsestriage, ikke en eftertanke.

Hvordan auditorer og regulatorer vil teste jeres NIS2-bevismateriale

En organisation, der er klar til 2026, bør forvente, at den samme kontrol testes fra forskellige vinkler.

En ISO 27001:2022-auditor vil starte med ISMS. Auditoren vil spørge, om NIS2-forpligtelser er identificeret som krav fra interessenter, om ISMS-omfanget dækker relevante tjenester og afhængigheder, om risici er vurderet og behandlet, om anvendelighedserklæringen begrunder de anvendelige kontroller, og om registreringer dokumenterer drift.

En NIS2-kompetent myndighed vil fokusere på juridiske resultater. Den kan spørge, om alle Article 21-foranstaltninger er adresseret, om kontroller er passende og proportionale, om ledelsen har godkendt og fører tilsyn med foranstaltningerne, og om hændelsesrapportering kan overholde de krævede tidsfrister.

En DORA-tilsynsmyndighed vil for omfattede finansielle enheder teste IKT-risikostyring, hændelsesklassificering, robusthedstest, tredjepartsrisiko, kontraktlige ordninger, koncentrationsrisiko og exitstrategier.

En GDPR-gennemgang vil teste, om tekniske og organisatoriske foranstaltninger beskytter personoplysninger, om vurdering af brud er indlejret i hændelseshåndtering, om dataansvarlig- og databehandlerroller er klare, og om ansvarlighedsregistreringer findes.

En vurderingspart med NIST CSF 2.0- eller COBIT 2019-tilgang vil fokusere på styring, risikoejerskab, performancemetrikker, nuværende og ønskede resultater, proceskapabilitet og tilpasning til organisationens risikovillighed.

Virksomhedens Politik for revision og overvågning af efterlevelse, punkt 3.4 indfanger formålet med bevismaterialet:

At generere forsvarligt bevismateriale og et revisionsspor til understøttelse af regulatoriske forespørgsler, retssager eller anmodninger fra kunder om dokumentation.

Det er den operationelle standard, NIS2-teams bør arbejde hen imod.

Ledelsens ansvarlighed: bestyrelsen kan ikke delegere NIS2 væk

NIS2 Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager træning. Medlemmer af ledelsesorganer kan holdes ansvarlige for overtrædelser, underlagt nationale ansvarsregler.

Dette flugter med ledelseskravene i ISO 27001:2022. Øverste ledelse skal sikre, at informationssikkerhedspolitikken og målene er tilpasset den strategiske retning, integrere ISMS-krav i forretningsprocesser, stille ressourcer til rådighed, kommunikere vigtigheden, tildele ansvar og fremme løbende forbedring.

En bestyrelse har ikke brug for rå scannereksporter eller fulde SIEM-logfiler. Den har brug for beslutningsegnet assurance.

En kvartalsvis NIS2-evidenspakke til bestyrelsen bør omfatte:

1. Ændringer i omfang og regulatorisk status
2. De største NIS2-risici og behandlingsstatus
3. Dashboard for kontroleffektivitet for Article 21
4. Væsentlige hændelser, nærved-hændelser og rapporteringsbeslutninger
5. Undtagelser vedrørende leverandør- og cloudrisiko
6. Interne revisionskonstateringer, korrigerende handlinger og forfaldent bevismateriale

Denne pakke giver ledelsen de oplysninger, der er nødvendige for at godkende foranstaltninger, udfordre undtagelser og acceptere restrisiko.

Clarysecs operationelle model for 2026

Operationalisering af tekniske NIS2-foranstaltninger med ISO 27001:2022 kræver en enkel, men disciplineret model:

• Afgræns NIS2, DORA, GDPR og kontraktlige forpligtelser i ISMS
• Kortlæg forpligtelser til risici, politikker, kontroller, ejere og bevismateriale
• Brug anvendelighedserklæringen som autoritativ kilde for kontroller
• Opbyg evidenspakker for højrisikoområder i Article 21
• Integrér hændelsesrapportering i én regulatorisk arbejdsgang
• Behandl leverandørsikkerhed som en livscyklus, ikke som et spørgeskema
• Gennemfør interne revisioner med reelle stikprøver
• Rapportér kontroleffektivitet til ledelsesorganer
• Forbedr på baggrund af hændelser, revisionskonstateringer, test og regulatoriske ændringer

For Maria var vendepunktet erkendelsen af, at hun ikke havde brug for et separat NIS2-projekt. Hun havde brug for en stærkere ISMS-evidensmotor.

Clarysecs politikker, Zenith Blueprint og Zenith Controls er designet til at fungere sammen. Politikker definerer forventet adfærd og registreringer. Zenith Blueprint giver den 30-trins implementerings- og revisionsvej. Zenith Controls giver den tværgående efterlevelseskortlægning, så NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF og COBIT-lignende assurance kan styres som ét sammenhængende program.

Næste skridt: opbyg jeres evidenskort fra NIS2 til ISO 27001:2022

Hvis jeres NIS2-arbejde stadig ligger i et gap-regneark, er 2026 året, hvor det skal operationaliseres.

Start med én teknisk højrisikoforanstaltning, f.eks. sårbarhedsstyring, hændelseshåndtering eller leverandørsikkerhed. Kortlæg den til ISO 27001:2022-risici, politikker, Annex A-kontroller, ejere, procedurer og bevismateriale. Stikprøv derefter sidste kvartals registreringer og stil det svære spørgsmål: Ville dette tilfredsstille en regulator, en kundevurderingspart og en ISO 27001:2022-auditor?

Clarysec kan hjælpe jer med at opbygge dette svar ved hjælp af politikbiblioteket, Zenith Blueprint og Zenith Controls.

Målet er ikke mere dokumentation. Målet er forsvarligt, gentageligt bevismateriale for, at jeres tekniske NIS2-foranstaltninger faktisk virker.