Intern ISO 27001-revision for NIS2 og DORA

Det er det første møde i revisionsudvalget i 2026. Sarah, CISO hos FinSecure, en hurtigt voksende SaaS- og FinTech-udbyder, har femten minutter på dagsordenen. Bestyrelsen har fem spørgsmål.

Er vi klar til vores ISO/IEC 27001:2022-overvågningsaudit? Er vi omfattet af NIS2 som udbyder af administrerede tjenester? Påvirker DORA os, fordi vi understøtter kunder i den finansielle sektor? Kan vi dokumentere, at hændelsesrapportering, leverandør-due diligence og forretningskontinuitet fungerer i praksis? Og hvorfor fandt sidste kvartals adgangsreview stadig konti, der burde have været fjernet?

Sarah har dokumentation, men den ligger spredt. Engineering har eksporter fra sårbarhedsscanninger. Indkøb har leverandørspørgeskemaer. Jura har kontraktklausuler. Den complianceansvarlige har en GDPR-tracker. SOC har hændelsessager. Intet af det er åbenlyst forkert, men intet af det fortæller en sammenhængende assurance-historie.

Det er her, et internt ISO 27001-revisionsprogram enten bliver en strategisk dokumentationsmotor eller forbliver en årlig hastesag.

For organisationer, der er omfattet af NIS2 og DORA, kan intern revision ikke længere være en ceremoniel tjekliste. Den skal være et risikobaseret assurance-system, der bekræfter, om ISMS-omfanget er korrekt, om kontroller fungerer i praksis, om regulatoriske krav er kortlagt, om konstateringer klassificeres konsekvent, og om korrigerende handlinger når frem til ledelsens gennemgang. I 2026 vil de stærkeste programmer ikke kun spørge: “Har vi gennemført en revision?” De vil spørge: “Kan vi måned for måned dokumentere, at sikkerhedsstyring, IKT-robusthed, leverandørsikkerhed og hændelsesberedskab fungerer?”

Det er den tilgang, Clarysec indbygger i Zenith Blueprint: en revisors 30-trins køreplan, Zenith Controls: vejledningen til efterlevelse på tværs af rammeværker og Clarysecs politikpakke. Målet er ikke at etablere separate ISO-, NIS2- og DORA-projekter. Målet er at styrke ISMS’et, så ét revisionsprogram producerer genanvendelig dokumentation på tværs af flere assurance-behov.

Hvorfor interne revisionsprogrammer for 2026 skal ændres

NIS2 og DORA har flyttet revisionsdialogen fra dokumentation til styret robusthed.

NIS2 gælder for mange mellemstore og store organisationer i kritiske og vigtige sektorer, herunder digital infrastruktur, cloud computing-udbydere, datacenterudbydere, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, online markedspladser, onlinesøgemaskiner og sociale netværksplatforme. Medlemsstaterne begyndte at anvende nationale foranstaltninger fra oktober 2024, og i 2026 arbejder mange organisationer i det første fulde år med modne NIS2-forventninger.

DORA gælder fra 17. januar 2025 for en bred gruppe af finansielle enheder, herunder kreditinstitutter, betalingsinstitutter, e-pengeinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, forsikrings- og genforsikringsselskaber, crowdfunding-tjenesteudbydere og relevante IKT-tredjepartsleverandører. DORA er den sektorspecifikke ordning for digital operationel robusthed for omfattede finansielle enheder. IKT-leverandører, der betjener finansielle enheder, kan også blive påvirket af DORA gennem kontrakter, revisionsrettigheder, deltagelse i test, hændelsessupport, kontroller for underleverandører og exitkrav.

Begge reguleringer skærper ansvarligheden. NIS2 Article 20 kræver, at ledelsesorganer godkender og fører tilsyn med risikostyringsforanstaltninger for cybersikkerhed og modtager træning i cybersikkerhed. DORA Article 5 gør ledelsesorganet endeligt ansvarligt for IKT-risiko, herunder godkendelse af og tilsyn med strategien for digital operationel robusthed, IKT-politikker, kontinuitetsordninger og tredjepartsrisiko.

ISO 27001 er velegnet til dette miljø, fordi det er et ledelsessystem. Det kræver, at organisationen forstår sin kontekst, definerer interessenter og krav, fastlægger ISMS-omfanget, vurderer og behandler risici, overvåger performance, gennemfører interne revisioner og driver løbende forbedring. Pointen er ikke at tvinge NIS2 og DORA ind i en ISO-form. Pointen er at bruge ISO 27001 som driftsmodel for gentagelig assurance.

Start med omfanget: revidér det system, bestyrelsen baserer sig på

Et svagt internt revisionsprogram starter med et uklart omfang som “informationssikkerhed”. Et stærkt program starter med den forretningsmæssige og regulatoriske afgrænsning.

ISO 27001 kræver, at ISMS-omfanget tager højde for interne og eksterne forhold, interessentkrav samt grænseflader eller afhængigheder til andre organisationer. Det er vigtigt, fordi NIS2- og DORA-forpligtelser ofte ligger i organisationens grænseflader: cloudplatforme, outsourcede SOC-ydelser, Managed Detection and Response (MDR), betalingssystemer, fintech-API’er, behandling af kundedata, backup-tjenester og partnere til eskalering af hændelser.

Clarysecs Politik for revision og overvågning af efterlevelse for SMV’er fastsætter styringsbaselinen:

Direktøren (GM) skal godkende en årlig revisionsplan.

Fra afsnittet ‘Styringskrav’, politikklausul 5.1.1.

For større miljøer hæver Clarysecs Politik for revision og overvågning af efterlevelse forventningen:

En risikobaseret revisionsplan skal udarbejdes og godkendes årligt under hensyntagen til:

Fra afsnittet ‘Styringskrav’, politikklausul 5.2.

Omfanget er derfor ikke blot en revisors præference. Det er en ledelsesgodkendt assurance-forpligtelse.

Et internt ISO 27001-revisionsprogram for 2026, der understøtter NIS2 og DORA, bør omfatte:

• ISMS-klausuler og -processer, herunder kontekst, lederskab, risikostyring, målsætninger, understøttelse, drift, evaluering af performance og forbedring.
• Relevante kontrolområder i ISO/IEC 27001:2022 Annex A, herunder leverandørrelationer, hændelsesstyring, forretningskontinuitet, retlige forpligtelser, databeskyttelse, logning, overvågning, sårbarhedsstyring, adgangsstyring, kryptografi, sikker udvikling, ændringsstyring og cloud governance.
• Regulatoriske overbygninger, herunder NIS2 Articles 20, 21 and 23, DORA Articles 5, 6, 8 to 14, 17 to 19, 24 to 27 and 28 to 30 samt GDPR-krav til sikkerhed og ansvarlighed.
• Nøgletjenester og forretningsprocesser, især kritiske eller vigtige funktioner, væsentlige tjenester, kundevendte platforme og systemer, der understøtter regulerede kunder.
• Tredjepartsafhængigheder, herunder IKT-leverandører, cloududbydere, outsourcet udvikling, SOC, MSSP, databehandlere og kritiske underleverandører.
• Processer, der producerer dokumentation, herunder risikovurderinger, adgangsreviews, afhjælpning af sårbarheder, hændelsesøvelser, gendannelsestest af backup, leverandørgennemgange, kontinuitetstest og ledelsens gennemgang.

Zenith Blueprint understreger dette i fasen Revision, gennemgang og forbedring, Step 25, internt revisionsprogram:

Fastlæg omfanget af jeres interne revisionsprogram. I løbet af et år skal I i sidste ende dække alle relevante ISMS-processer og -kontroller.

Fra fasen Revision, gennemgang og forbedring, Step 25: Internt revisionsprogram.

I behøver ikke revidere alt hver måned. Men over den årlige cyklus bør I dække alle relevante ISMS-processer og -kontroller med hyppigere arbejde på højrisiko- og regulerede områder.

Opbyg revisionsuniverset omkring NIS2- og DORA-kontroltemaer

NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger. Grundlaget omfatter risikoanalyse, sikkerhedspolitikker, håndtering af hændelser, forretningskontinuitet, backupstyring, katastrofeberedskab, krisestyring, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, håndtering af sårbarheder, vurdering af effektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver, MFA eller løbende autentifikation, hvor det er relevant, og sikker kommunikation.

DORA har en tilsvarende operationel livscyklus. Den kræver, at finansielle enheder identificerer og klassificerer IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver, afhængigheder og tredjepartssammenkoblinger. Den kræver også beskyttelse, detektion, klassificering af hændelser, respons, genopretning, backup, gendannelse, test, læring efter hændelser, kommunikation og styring af IKT-tredjepartsrisici.

Et samlet revisionsunivers forhindrer den almindelige fejl, hvor ISO 27001 revideres adskilt fra NIS2 og DORA.

Denne struktur gør hvert revisionsdomæne til et fælles assurance-objekt. Den interne revisor tester ISO 27001-kravet og registrerer derefter, om den samme dokumentation også understøtter forventningerne i NIS2, DORA, GDPR, NIST CSF og COBIT 2019.

Planlæg året efter risiko, ikke papirarbejde

Zenith Blueprint giver teams en praktisk rækkefølge til at omsætte revision til forbedring:

• Step 25, internt revisionsprogram: planlæg omfang, frekvens, uafhængighed og risikobaserede prioriteter.
• Step 26, revisionsudførelse: indsamling af objektiv dokumentation gennem interviews, dokumentgennemgang, observation og stikprøver.
• Step 27, revisionskonstateringer, analyse og rodårsag: klassificér konstateringer og identificér rodårsag.
• Step 28, ledelsens gennemgang: indarbejd revisionsresultater, hændelser, afvigelser, målsætninger, risici og ressourcebehov i ledelsens gennemgang.
• Step 29, løbende forbedring: opbyg korrigerende handlinger, der fjerner årsager, ikke kun symptomer.

Zenith Blueprint er tydelig om uafhængighed:

Ideelt set bør den interne revisor ikke revidere sit eget arbejde.

Fra fasen Revision, gennemgang og forbedring, Step 25: Internt revisionsprogram.

For en mindre SaaS- eller fintech-virksomhed kan det betyde, at en leder fra en anden funktion reviderer sikkerhedsprocesser, at kontrolansvarlige roteres, eller at en ekstern konsulent anvendes. Det centrale er at dokumentere kompetence og uafhængighed, især når NIS2- og DORA-dokumentation senere kan blive gennemgået af kunder, regulatorer, tilsynsmyndigheder eller eksterne revisorer.

Politik for revision og overvågning af efterlevelse for SMV’er definerer også minimumsstrukturen for revision:

Hver revision skal omfatte et defineret scope, mål, ansvarligt personale og krævet dokumentation.

Fra afsnittet ‘Styringskrav’, politikklausul 5.2.3.

En praktisk kvartalsstruktur for en SaaS- eller IKT-udbyder i høj vækst kan være:

Dette erstatter ikke månedlig indsamling af dokumentation. Det giver året en tydelig assurance-rytme.

Stikprøver: hvor meget dokumentation er nok?

Stikprøver er dér, hvor mange interne revisioner enten bliver for overfladiske eller for dyre. I regulerede IKT-miljøer skal stikprøver være risikobaserede, forklarlige og dokumenterede.

Zenith Blueprint, Step 26, angiver det praktiske princip:

Tag stikprøver og udfør stikprøvekontrol: I kan ikke kontrollere alt, så brug stikprøver.

Fra fasen Revision, gennemgang og forbedring, Step 26: Revisionsudførelse.

Clarysecs enterprise-politik gør dette revisionsbart:

Dokumentation af stikprøvestrategien, revisionsomfanget og begrænsningerne

Fra afsnittet ‘Styringskrav’, politikklausul 5.5.3.

For NIS2 og DORA bør stikprøver tage højde for kritikalitet, risiko, leverandørens betydning, tidsperiode, hændelseshistorik, geografi og om den udvalgte proces understøtter kritiske eller vigtige funktioner.

For DORA-berørte miljøer fortjener testdokumentation særlig opmærksomhed. DORA kræver test af digital operationel robusthed for finansielle enheder med mere avanceret test, såsom trusselsstyret penetrationstest for udvalgte enheder mindst hvert tredje år. Jeres revisionsstikprøve bør ikke kun omfatte testrapporter, men også dokumentation for, at konstateringer blev prioriteret, afhjulpet og gentestet.

Praktisk revisionseksempel: IKT-tredjepartsrisiko

Leverandørsikkerhed er ofte den hurtigste måde at afdække huller mellem dokumentation og operationel virkelighed. DORA Articles 28 to 30 kræver styring af IKT-tredjepartsrisici, kontraktindhold og informationsregistre. NIS2 Article 21 kræver sikkerhed i forsyningskæden, som tager højde for sårbarheder og praksis hos direkte leverandører.

Til en Q2-revision udvælger Sarah fem kritiske leverandører, tre nye leverandører onboardet inden for de seneste seks måneder og to leverandører med nyligt fornyede kontrakter. Revisoren interviewer indkøb, jura, serviceejere og ansvarlige for sikkerhedskontroller.

Denne tabel gør mere end at styre indsamlingen af dokumentation. Den dokumenterer, at organisationen har omsat reguleringstekst til ISO-afstemte revisionskriterier og konkret dokumentation.

Konstateringer: skriv dem, så ledelsen kan handle

En revisionskonstatering bør ikke lyde som en vag klage. Den bør være struktureret nok til, at ledelsen kan forstå risikoen, placere ejerskab og godkende korrigerende handling.

Politik for revision og overvågning af efterlevelse for SMV’er angiver:

Alle revisionskonstateringer skal dokumenteres med risikovurderinger og foreslåede handlinger.

Fra afsnittet ‘Styringskrav’, politikklausul 5.4.1.

Enterprise-udgaven af Politik for revision og overvågning af efterlevelse tilføjer disciplinen for korrigerende handling:

Alle konstateringer skal resultere i en dokumenteret CAPA, der omfatter:

Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.2.1.

I Zenith Blueprint anbefaler Step 27 at kategorisere konstateringer som større afvigelser, mindre afvigelser eller observationer og derefter udføre rodårsagsanalyse. En større afvigelse angiver et alvorligt hul eller systematisk svigt. En mindre afvigelse er et isoleret brud i en proces, der ellers er i overensstemmelse. En observation er en forbedringsmulighed.

En stærk konstatering omfatter:

• Krav eller kontrolforventning.
• Observeret tilstand.
• Udvalgt dokumentation.
• Risiko og forretningsmæssig påvirkning.
• Regulatorisk relevans.
• Klassificering og risikovurdering.
• Rodårsag.
• Ejer af korrigerende handling og frist.

Eksempel på konstatering:

Konstatering NC-2026-07, mindre afvigelse, forsinket gennemgang af leverandørsikkerhed

Krav: Gennemgang af leverandørsikkerhed for kritiske IKT-udbydere skal udføres mindst årligt og understøtte ISO 27001-leverandørkontroller, NIS2-forventninger til forsyningskæden og DORA-forpligtelser vedrørende IKT-tredjepartsrisiko.

Tilstand: To ud af tolv kritiske IKT-leverandører havde ikke gennemført sikkerhedsgennemgange for 2026 inden den krævede dato.

Dokumentation: Eksport fra leverandørregister dateret 15. juni 2026, leverandørgennemgangstracker, interview med indkøbsansvarlig og to manglende gennemgangsregistreringer.

Risiko: Forsinket leverandørgennemgang kan forhindre rettidig identifikation af sårbarheder, ændringer i underleverandører, mangler i hændelsessupport eller kontraktmæssig manglende overholdelse, der påvirker kritiske tjenester.

Rodårsag: Indkøb blev ikke automatisk underrettet, når datoer for leverandørgennemgang nærmede sig, og ejerskab for DORA-relateret leverandørdokumentation var ikke tildelt.

Korrigerende handling: Konfigurér automatiske påmindelser om gennemgang, tildel navngivne kontrolansvarlige for alle kritiske IKT-leverandører, gennemfør forfaldne gennemgange senest 31. juli 2026, og udfør kvartalsvise stikprøvekontroller.

Til rodårsagsanalyse er teknikken “5 Whys” nyttig. Hvis en vurdering før kontrakt blev overset, er den reelle årsag ikke nødvendigvis en individuel fejl. Det kan være, at indkøbsflowet tillod IKT-kontrakter med lav værdi at omgå sikkerhedsgennemgang, selv om DORA- og NIS2-forventninger gælder baseret på risiko og afhængighed, ikke kun forbrug.

Dokumentationskalenderen for 2026

En dokumentationskalender for 2026 omsætter intern revision til en driftsrytme. Den fordeler produktion af dokumentation over året og undgår hastværk ved årets afslutning.

Clarysecs Informationssikkerhedspolitik forventer styringsmæssig gennemgang af:

Gennemgang af sikkerheds-KPI’er, hændelser, revisionskonstateringer og risikostatus

Fra afsnittet ‘Styringskrav’, politikklausul 5.3.2.

Dokumentation indsamles ikke kun til revisorer. Den understøtter beslutninger om risiko, budget, ressourcer, leverandører, værktøjer, træning og korrigerende handling.

Denne kalender giver revisionsudvalget en fremadskuende assurance-plan og giver kontrolansvarlige tid til at skabe dokumentation gennem normal drift.

ISO 27002:2022-rygraden: 5.31, 5.35 og 5.36

Zenith Controls er Clarysecs vejledning til efterlevelse på tværs af rammeværker. Den kortlægger kontrolområder i ISO/IEC 27001:2022 og ISO/IEC 27002:2022 til andre standarder, reguleringer, revisionsforventninger og dokumentationsmønstre. Den er særligt nyttig til at forbinde intern gennemgang, retlige forpligtelser og overholdelse af politikker.

Tre kontrolområder i ISO/IEC 27002:2022 udgør rygraden i et samlet internt revisionsprogram:

Kontrol 5.35 er hjørnestenen i assurance, fordi den validerer, om ISMS’et gennemgås uafhængigt. Kontrol 5.36 bekræfter, at politikker ikke blot er godkendt, men faktisk følges. Kontrol 5.31 forbinder ISMS’et med retlige, regulatoriske og kontraktlige forpligtelser, herunder NIS2, DORA, GDPR og kunders sikkerhedskrav.

Kortlægning på tværs af efterlevelseskrav: én revision, mange assurance-perspektiver

Et modent internt revisionsarbejdspapir bør eksplicit vise, hvordan ét dokumentationselement understøtter flere assurance-forventninger.

Det er dette, der gør det muligt for CISO’en at sige til bestyrelsen: “Vores hændelsesrevision i juli producerede dokumentation til ISO 27001, NIS2, DORA-kundeassurance, GDPR-beredskab ved brud, responsresultater i NIST CSF og COBIT-hændelsesstyring.”

Ledelsens gennemgang: hvor revision bliver til ansvarlighed

Intern revision har begrænset værdi, hvis konstateringer ikke når ledelsen. ISO 27001-ledelsens gennemgang giver mekanismen, og NIS2 og DORA gør styringsforventningen eksplicit.

Politik for revision og overvågning af efterlevelse for SMV’er kræver:

Revisionskonstateringer og statusopdateringer skal indgå i processen for ISMS-ledelsens gennemgang.

Fra afsnittet ‘Styringskrav’, politikklausul 5.4.3.

Den angiver også:

GM skal godkende en plan for korrigerende handling og følge implementeringen.

Fra afsnittet ‘Styringskrav’, politikklausul 5.4.2.

Ledelsens gennemgang bør besvare:

• Er NIS2-, DORA-, GDPR- og kontraktlige forpligtelser stadig korrekt afspejlet i ISMS-omfanget?
• Revideres højrisikokontroller hyppigt nok?
• Hvilke konstateringer peger på systemiske svagheder frem for isolerede fejl?
• Er korrigerende handlinger forfaldne?
• Accepterer risikoejere restrisici bevidst?
• Er leverandører, hændelsesrapportering, kontinuitet og test tilstrækkeligt ressourceunderstøttet?
• Peger revisionstendenser på behov for ændringer i politikker, værktøjer, budget eller træning?

Hvis disse svar ikke dokumenteres, kan organisationen have dokumentation for aktivitet, men ikke dokumentation for styring.

Almindelige faldgruber at undgå i 2026

Den mest almindelige fejl er at behandle intern ISO 27001-revision som adskilt fra regulatorisk assurance. Det skaber dobbeltarbejde og blinde vinkler.

Andre faldgruber omfatter:

• Omfanget udelader kritiske leverandører, cloudplatforme eller outsourcede SOC-ydelser.
• NIS2- eller DORA-anvendelighed er ikke dokumenteret i det retlige register.
• Revisionsplanen er ikke godkendt af ledelsen.
• Stikprøver udføres, men dokumenteres ikke.
• Interne revisorer gennemgår deres eget arbejde uden afbødning.
• Konstateringer beskriver symptomer, men ikke rodårsager.
• Korrigerende handlinger opdaterer dokumenter, men retter ikke processer.
• Ledelsens gennemgang modtager revisionsresultater, men træffer ingen beslutninger.
• Hændelsesøvelser tester teknisk respons, men ikke regulatorisk underretning.
• Leverandørrevisioner gennemgår spørgeskemaer, men ikke kontrakter, exitplaner eller koncentrationsrisiko.
• Backupdokumentation viser vellykkede jobs, men ikke gendannelsesintegritet.
• Adgangsreviews udføres, men undtagelser spores ikke til lukning.

Hver faldgrube kan blive en mindre eller større afvigelse afhængigt af alvorlighed og systemisk påvirkning. Vigtigere er det, at hver enkelt svækker organisationens evne til at dokumentere robusthed under NIS2, DORA og kunders kontrol.

Gør jeres revisionsplan for 2026 til en dokumentationsmotor

Hvis jeres interne revisionsprogram stadig er én årlig begivenhed, er tiden inde til at redesigne det.

Start med en ledelsesgodkendt revisionsplan. Definér ISMS-omfanget omkring reelle tjenester, regulerede forpligtelser og tredjepartsafhængigheder. Opbyg et risikobaseret revisionsunivers. Dokumentér stikprøver. Klassificér konstateringer konsekvent. Brug rodårsagsanalyse. Spor CAPA. Indarbejd resultater i ledelsens gennemgang. Vedligehold en månedlig dokumentationskalender.

Clarysec kan hjælpe jer hurtigere frem med:

• Zenith Blueprint: en revisors 30-trins køreplan til revisionsplanlægning, udførelse, konstateringer, ledelsens gennemgang og løbende forbedring.
• Zenith Controls: vejledningen til efterlevelse på tværs af rammeværker til kortlægning af ISO 27001-assurance til forventninger i NIS2, DORA, GDPR, NIST CSF og COBIT.
• Politik for revision og overvågning af efterlevelse og Politik for revision og overvågning af efterlevelse for SMV’er til styringsklar revisionsplanlægning og håndtering af konstateringer.
• Informationssikkerhedspolitik til gennemgang af KPI’er, hændelser, revisionskonstateringer og risikostatus på ledelsesniveau.

Vælg ét højrisikodomæne, for eksempel hændelsesrapportering eller IKT-leverandørstyring, og gennemfør en fokuseret intern revision med Clarysecs struktur for omfang, stikprøver og konstateringer. Inden for én cyklus ved I, om jeres dokumentation er revisionsklar, om jeres kontroller fungerer, og om jeres ledelsesorgan har de oplysninger, det behøver for at styre cyberrisiko.