Styring af politikkernes livscyklus i ISO 27001, NIS2 og DORA

E-mailen landede i CISO Maria Petrovas indbakke med et diskret dunk, der føltes som en sirene. Den kom fra den eksterne revisor og indeholdt en foreløbig anmodningsliste til en kombineret ISO/IEC 27001:2022-overvågningsaudit og DORA-parathedsvurdering. Det første punkt så enkelt ud:
“Fremsend venligst den aktuelle informationssikkerhedspolitik, dens fuldstændige versionshistorik, revisionsbevis for ledelsens godkendelse af hver version samt registreringer, der dokumenterer, at den er kommunikeret til relevant personale i de seneste 24 måneder.”
Marias virksomhed, en mellemstor fintech-platform, havde politikker. Dusinvis af dem. De havde en informationssikkerhedspolitik, en hændelseshåndteringsplan, et spørgeskema om leverandørsikkerhed, et risikoregister, en procedure for adgangsstyring, en plan for forretningskontinuitet og en mappe fuld af revisionsbevis. Men filerne lå spredt på SharePoint-sites, ældre Confluence-rum, e-mailtråde, vedhæftede filer i tickets og fællesdrev, som tilhørte personer, der allerede havde forladt virksomheden.
Det reelle problem blev tydeligt, da revisors opfølgende spørgsmål kom.
Hvem godkendte den aktuelle hændelsesprocedure? Hvorfor angiver leverandørsikkerhedspolitikken i SharePoint version 2.1, mens indkøbsfunktionen bruger version 1.8? Hvilken politik er mappet til NIS2 Article 21 om risikostyringstiltag? Hvor er registreringen, der viser, at medarbejderne blev informeret om den seneste politikopdatering? Hvorfor blev der givet en undtagelse for privilegeret adgang, hvem accepterede restrisikoen, og hvornår udløber undtagelsen? Er forældede dokumenter fjernet fra operationel brug? Hvor længe opbevares revisionsrapporter? Kan virksomheden dokumentere, at politikbiblioteket blev gennemgået efter den seneste større systemændring?
Maria havde kontroller, men ikke kontrol over kontrollerne.
Det er udfordringen ved styring af politikkernes livscyklus i 2026. Organisationer fejler ikke længere kun revisioner, fordi en firewallregel er forkert, eller en backuptest mangler. De fejler, fordi dokumenteret information er fragmenteret, ikke kan auditeres, er dubleret, forældet, ukontrolleret eller frakoblet retlige forpligtelser. Efter ISO/IEC 27001:2022 klausul 7.5 er dokumenteret information ikke administrativ oprydning. Det er ISMS’ets operationelle hukommelse. Under NIS2 understøtter den ledelsesorganets godkendelse og tilsyn. Under DORA bliver den en del af styringsrammen for IKT-risiko og revisionssporet for robusthed. Under GDPR dokumenterer den ansvarlighed.
Clarysecs synspunkt er enkelt: Et politikbibliotek er ikke et dokumentdepot. Det er et styret evidenssystem.
Hvorfor styring af politikkernes livscyklus nu er et bestyrelsesanliggende
Styring af politikkernes livscyklus er disciplinen for at udarbejde, godkende, offentliggøre, kommunikere, gennemgå, ændre, udfase, opbevare og dokumentere politikker og tilhørende registreringer. Den besvarer de spørgsmål, som revisorer, tilsynsmyndigheder, kunder og bestyrelser nu rutinemæssigt stiller:
- Hvem ejer hver politik?
- Hvem godkender den?
- Hvilke retlige, kontraktlige og risikomæssige krav opfylder den?
- Hvilke kontroller og procedurer implementerer den?
- Hvilken version er aktuel?
- Hvem blev informeret, trænet eller pålagt at bekræfte den?
- Hvilke undtagelser er knyttet til den?
- Hvilke registreringer dokumenterer, at den fungerer i praksis?
- Hvad sker der, når den bliver forældet?
ISO/IEC 27001:2022 understøtter denne disciplin gennem klausul 7.5 om dokumenteret information, klausul 5 om lederskab, klausul 6 om planlægning og risikobehandling, klausul 8 om operationel styring samt Annex A-kontroller, der dækker politikker, registreringer, retlige krav, leverandører, hændelser, kontinuitet, privatliv, logning, overvågning og ændringsstyring.
Det regulatoriske pres er lige så direkte.
NIS2 Article 20 kræver, at ledelsesorganer godkender cybersikkerhedsrisikostyringstiltag, fører tilsyn med implementeringen og modtager relevant træning. Article 21 kræver risikobaserede tekniske, operationelle og organisatoriske foranstaltninger, herunder sikkerhedspolitikker, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker udvikling, vurdering af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for aktivstyring og autentifikation. Et politikkorpus uden ejerskab, godkendelse og revisionsbevis for gennemgang svækker fortællingen om ledelsens ansvarlighed.
DORA finder anvendelse fra 17. januar 2025 og etablerer en ensartet EU-ramme for styring af IKT-risiko, hændelsesrapportering, test af digital operationel robusthed, IKT-tredjepartsrisiko og kontraktlige krav. For finansielle enheder, der også er væsentlige eller vigtige enheder under NIS2, behandles DORA som den sektorspecifikke EU-retsakt for de tilsvarende cybersikkerhedsforpligtelser. Article 5 kræver ledelsesorganets ansvar for styringsrammen for IKT-risiko, politikker, ansvarsområder, kontinuitetsplaner, revisioner, IKT-tredjepartspolitikker, rapporteringskanaler og træning. Article 6 kræver en veldokumenteret styringsramme for IKT-risiko, der som minimum gennemgås årligt for ikke-mikrofinansielle enheder og forbedres på grundlag af læring.
GDPR tilføjer kravet om ansvarlighed. Article 5 kræver, at personoplysninger behandles lovligt, rimeligt og gennemsigtigt, til specificerede formål, med dataminimering, nøjagtighed, opbevaringsbegrænsning og sikkerhed. Article 5(2) gør den dataansvarlige ansvarlig for at kunne dokumentere efterlevelse. Den dokumentation afhænger af kontrollerede registreringer: beslutninger om behandlingsgrundlag, opbevaringsplaner, konsekvensanalyser vedrørende databeskyttelse (DPIA’er), hvor det er relevant, databehandler-due diligence, registreringer af brud, gennemgang af adgangsrettigheder, træningslogfiler og politikgodkendelser.
Fællesnævneren er revisionsbevis. En revisor vil ikke kun spørge, om der findes en politik. Revisor vil bede om dens fødselsattest, versionshistorik, godkendelsesspor, kommunikationsregistrering, relaterede procedurer og de operationelle registreringer, der dokumenterer, at den virker.
Rygraden for ISO/IEC 27001:2022-dokumenteret information
Rygraden i forsvarlig dokumentation er ISO/IEC 27001:2022 klausul 7.5, Dokumenteret information. Den kræver, at organisationer opretter, opdaterer og styrer den dokumenterede information, som ISMS’et har behov for, og som standarden kræver.
En praktisk måde at forstå dette på er at opdele dokumenteret information i tre lag:
| Lag | Eksempler | Styringsformål |
|---|---|---|
| Styrende dokumenter | ISMS-omfang, informationssikkerhedspolitik, risikometodik, anvendelseserklæring, risikobehandlingsplan, mål | Fastlægge retning, beføjelser, krav og ansvarlighed |
| Driftsdokumenter | Procedurer, standarder, playbooks, runbooks, tjeklister, skabeloner | Omsætte politik til gentagelige handlinger |
| Registreringer | Risikovurderinger, træningslogfiler, hændelsesrapporter, revisionsrapporter, godkendelser, referater fra ledelsens gennemgang, gennemgang af adgangsrettigheder, leverandørregistreringer, beslutninger om undtagelser | Dokumentere, at beslutninger blev truffet, og kontroller fungerede |
Clarysecs Zenith Blueprint: En revisors 30-trins køreplan behandler dette eksplicit i fasen for ISMS-fundament og lederskab, trin 6: Dokumenteret information og opbygning af ISMS-biblioteket. Den forklarer, at klausul 7.5 dækker dokumentation generelt, oprettelse og opdatering samt styring af dokumenteret information.
Zenith Blueprint omsætter dette til praktisk implementeringsvejledning:
“Dokumenter bør have korrekt identifikation (en titel, eventuelt et dokumentnummer eller en unik identifikator, en forfatter), et passende format … og gennemgang og godkendelse af egnethed før brug.”
Den angiver også den operationelle regel, som mange organisationer overser:
“Sørg for, at kun den aktuelle version er let at finde (arkivér forældede versioner, eller markér dem tydeligt som erstattet).”
Det er her, mange ISMS-implementeringer stille bryder sammen. En politik kan være blevet godkendt én gang, men hvis gamle versioner fortsat er tilgængelige, medarbejdere bruger forældede procedurer, eller revisorer ikke kan spore ændringer, er dokumentet ikke længere styret på en meningsfuld måde.
Zenith Blueprint anbefaler at etablere et “ISMS-dokumentationsbibliotek” med mapper til politikker og procedurer, risikovurdering og SoA, træningsregistreringer, revision og gennemgang, hændelsesregistreringer, aktiver og fortegnelser samt et Annex A-kontrolbibliotek. Den angiver også, at repositoriet skal være “tilgængeligt, men sikkert”, hvor politikker kan læses af medarbejdere, mens fortrolige mapper såsom risikovurderinger og hændelsesregistreringer er adgangsbegrænsede.
Dette er ikke kun en arkiveringsmodel. Det er en styringsarkitektur.
Clarysecs model for politikkernes livscyklus
Clarysec strukturerer styringen af ISO 27001-politikkernes livscyklus omkring et lukket kredsløb: krav, ejer, dokument, godkendelse, publicering, kommunikation, revisionsbevis, gennemgang, ændring, opbevaring og udfasning. Dette kredsløb forhindrer den klassiske revisionsfejl, hvor en virksomhed har dokumenter, men ikke kan dokumentere beføjelser, aktualitet eller kontrol.
| Livscyklusfase | Styringsspørgsmål | Revisionsbevis, som revisorer forventer | Clarysec-implementeringsanker |
|---|---|---|---|
| Kravmodtagelse | Hvilken forpligtelse eller risiko kræver denne politik? | Retligt register, kundekrav, post i risikoregister, kontrolmapping | Retlig og regulatorisk mapping samt ISMS-omfang |
| Ejerskab | Hvem vedligeholder politikken? | Felt for politikkejer, RACI, rolletildeling | Politik for styringsroller og ansvarsområder |
| Godkendelse | Hvem godkendte den før brug? | Godkendelsesregistrering, mødereferater, elektronisk godkendelse | Ledelsens gennemgang eller delegeret bemyndigelse |
| Versionsstyring | Hvilken version er aktuel? | Versionshistorik, ændringslog, dokumentmetadata | Kontrolleret ISMS-repository |
| Kommunikation | Hvem blev informeret? | Meddelelse, bekræftelse, træningslog | Awareness- og kommunikationsregistreringer |
| Drift | Hvilke procedurer implementerer den? | SOP’er, tjeklister, tickets, kontrolregistreringer | Dokumenterede driftsprocedurer |
| Undtagelser | Hvilke afvigelser er tilladt? | Undtagelsesregister, risikoaccept, udløbsdato | Risikobehandling og governance-eskalering |
| Gennemgang | Hvornår blev den gennemgået og hvorfor? | Registrering af årlig gennemgang, triggerbaseret gennemgang | Gennemgangskalender og attestering fra politikkejer |
| Opbevaring | Hvor længe opbevares registreringer? | Opbevaringsplan, arkivregistreringer | Revision og overvågning af efterlevelse |
| Udfasning | Hvordan styres forældede dokumenter? | Erstattet arkiv, fjernelse fra aktivt bibliotek | Dokumentstyringsworkflow |
Denne livscyklus er stærkere end en engangsgodkendelse, fordi den forbinder dokumenter med kontroller, ejere og revisionsbevis. Den understøtter også tværgående efterlevelse. Én hændelseshåndteringspolitik kan mappes til ISO/IEC 27001:2022 Annex A-hændelseskontroller, NIS2 Article 23-parathed til underretning, DORA-hændelsesklassificering og rapporteringsprocesser, GDPR-håndtering af brud på persondatasikkerheden, NIST CSF 2.0 Respond-resultater og COBIT 2019-governanceforventninger.
Hvad Clarysec-politikker kræver for gennemgang, versionsstyring og revisionsbevis
Clarysecs politikbibliotek er udformet, så krav til politikkernes livscyklus ikke overlades til fortolkning.
For SMV’er fastsætter Informationssikkerhedspolitik-sme - SME en klar gennemgangsudløser:
“Denne politik skal gennemgås af direktøren (GM) mindst én gang årligt for at sikre fortsat efterlevelse af ISO/IEC 27001-certificeringskrav, regulatoriske ændringer (såsom GDPR, NIS2 og DORA) og udviklende forretningsbehov.”
Den kræver også dokumenterede ændringsregistreringer:
“Alle politikgennemgange og ændringer skal dokumenteres formelt med tydelig angivelse af dato, ændringernes karakter og GM’s godkendelse.”
Og den bevarer historisk sporbarhed:
“En historisk registrering af politikversioner skal opbevares sikkert for at dokumentere politikkens udvikling og efterlevelse under revisioner.”
Disse tre klausuler løser et almindeligt SMV-problem. Organisationen har måske ikke en stor governance-funktion, men den har stadig brug for dokumentation for gennemgang, godkendelse og versionshistorik.
SMV-udgaven af Politik for styringsroller og ansvarsområder-sme - SME tilføjer sporbarhedskravet for governance-beslutninger:
“Alle væsentlige sikkerhedsbeslutninger, undtagelser og eskaleringer skal registreres og kunne spores.”
Den klausul er kritisk for politikundtagelser. En midlertidig afvigelse fra MFA, en forsinket leverandørgennemgang eller en nødændring af logopbevaring bør ikke kun eksistere i e-mailtråde. Den skal være knyttet til den relevante politik, kontrol, risikoejer, beslutning om restrisiko og udløbsdato.
For centralisering af revisionsbevis angiver SMV-udgaven af Politik for revision og overvågning af efterlevelse-sme - SME:
“Alt revisionsbevis skal opbevares i en central revisionsmappe.”
I enterprise-miljøer kræver Clarysecs Informationssikkerhedspolitik, at politikker:
“Versionsstyres og dokumenteres”
og:
“Kommunikeres til alle berørte parter via officielle kommunikationskanaler”
Enterprise-udgaven af Politik for styringsroller og ansvarsområder indlejrer begrebet:
“Politikkejer og godkender”
Enterprise-udgaven af Politik for revision og overvågning af efterlevelse tilføjer forventninger til opbevaring:
“Rapporter skal opbevares i mindst seks år (eller længere, hvor det kræves efter lovgivningen), opbevares sikkert og være omfattet af versionsstyring i henhold til Politik for dokument- og registreringsstyring (P6).”
Endelig forbinder enterprise-udgaven af Politik for juridisk og regulatorisk efterlevelse retlige forpligtelser med ISMS’et:
“Alle retlige og regulatoriske forpligtelser skal mappes til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).”
Dette krav er broen mellem styring af politikkernes livscyklus og revisionsbevis for NIS2, DORA og GDPR. Uden mapping af forpligtelser kan en virksomhed have dokumenter, men den kan ikke vise, at dokumenterne opfylder specifikke retlige, kontraktlige eller risikobaserede krav.
Kontroltrekanten: politikker, registreringer og driftsprocedurer
Clarysecs Zenith Controls: Vejledningen til tværgående efterlevelse giver det tværgående efterlevelseskompas for dette emne. For ISO/IEC 27002:2022-kontrol 5.1, Politikker for informationssikkerhed, identificerer Zenith Controls den som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset governance- og identifikationsbegreber inden for cybersikkerhed og er knyttet til operationelle kapaciteter for governance og politikstyring.
Det er vigtigt, fordi politikstyring ikke kun er et efterlevelsesartefakt. Den er forebyggende. En tydeligt ejet og kommunikeret politik for adgangskontrol reducerer risikoen for uautoriseret adgang, før hændelser opstår. En korrekt godkendt leverandørpolitik forebygger uadministreret outsourcingrisiko. En kontrolleret hændelsesprocedure forbedrer responsens ensartethed, før den første regulatoriske underretningsfrist begynder at løbe.
Zenith Controls fremhæver også ISO/IEC 27002:2022-kontrol 5.33, Beskyttelse af registreringer, som forebyggende og tilpasset retlig efterlevelse, aktivstyring og informationsbeskyttelse. Dette er centralt for revisionsbevis. Zenith Blueprint udbygger samme begreb i fasen Controls in Action, trin 23:
“Registreringer er ikke blot levn fra tidligere beslutninger. De er revisionsbevis for efterlevelse, handling og ansvarlighed.”
Den fortsætter:
“Registreringer beskyttes passende mod tab, uautoriseret adgang, manipulation og for tidlig destruktion”
ISO/IEC 27002:2022-kontrol 5.37, Dokumenterede driftsprocedurer, er også relevant. Zenith Controls klassificerer den som forebyggende og korrigerende, med understøttelse af beskyttelse og genopretning. For DORA og NIS2 er dokumenterede driftsprocedurer den måde, hvorpå politik bliver til gentagelig handling: hændelsestriage, gendannelse af sikkerhedskopier, onboarding af leverandører, sårbarhedshåndtering, sikker udvikling, ændringsstyring, indsamling af bevismateriale og krisekommunikation.
Tilsammen skaber 5.1, 5.33 og 5.37 kontroltrekanten for politikkernes livscyklus:
| ISO/IEC 27002:2022-kontrol | Rolle i livscyklus | Hvad den dokumenterer |
|---|---|---|
| 5.1 Politikker for informationssikkerhed | Retning, godkendelse, ejerskab og kommunikation | Ledelsen har fastsat forventninger og placeret ansvarlighed |
| 5.33 Beskyttelse af registreringer | Revisionsbevisets integritet, opbevaring og sikker adgang | Efterlevelsesregistreringer kan tillægges tillid |
| 5.37 Dokumenterede driftsprocedurer | Gentagelig udførelse af politikkrav | Medarbejdere ved, hvordan kontrollerede aktiviteter skal udføres |
Et modent ISMS har behov for alle tre. Politikker uden registreringer er erklæringer. Registreringer uden procedurer er inkonsistente. Procedurer uden politisk retning bliver lokale vaner i stedet for styrede kontroller.
Tværgående efterlevelsesmapping for ISO 27001, NIS2, DORA, GDPR, NIST og COBIT
Hvis politikker styres separat for ISO 27001, NIS2, DORA og GDPR, skaber det dublering, modstrid og evidenstræthed. En bedre model er at vedligeholde ét kontrolleret ISMS-bibliotek med mappingmetadata. Det gør det muligt for ét evidenskorpus at opfylde flere interessenters dokumentationsbehov.
| Kravfamilie | Hvad tilsynsmyndigheder eller revisorer forventer | Revisionsbevis for politikkernes livscyklus |
|---|---|---|
| ISO/IEC 27001:2022 klausul 7.5 | Dokumenter identificeres, gennemgås, godkendes, er tilgængelige, beskyttes og styres | Dokumentregister, godkendelsesregistreringer, versionshistorik, adgangstilladelser, arkiv for forældede dokumenter |
| ISO/IEC 27002:2022 5.1 | Informationssikkerhedspolitikker er defineret, godkendt, offentliggjort, kommunikeret og gennemgået | Politiksuite, godkendelsesworkflow, kommunikationsregistreringer, gennemgangslog |
| ISO/IEC 27002:2022 5.33 | Registreringer beskyttes mod tab, destruktion, forfalskning, uautoriseret adgang og videregivelse | Opbevaringsplan, sikkert repository, adgangsstyring, integritetsbevis |
| ISO/IEC 27002:2022 5.37 | Driftsprocedurer er dokumenteret og tilgængelige for det personale, der har behov for dem | SOP’er, runbooks, playbooks, revisionsbevis for proceduregennemgang |
| NIS2 Articles 20 and 21 | Ledelsesgodkendelse og tilsyn med cybersikkerhedsrisikostyringstiltag | Bestyrelsesgodkendelser, politikmappinger, træningsregistreringer, referater fra gennemgang, revisionsbevis for kontroleffektivitet |
| NIS2 Article 23 | Parathed til underretning om væsentlige hændelser og revisionsbevis for rapportering | Hændelsespolitik, klassificeringsprocedure, eskaleringslog, revisionsbevis for 24-timers- og 72-timers-workflow, skabelon til slutrapport |
| DORA Articles 5 and 6 | Veldokumenteret IKT-risikostyringsramme godkendt og overvåget af ledelsen | IKT-politiksuite, strategi, risikoramme, revisionsbevis for årlig gennemgang, revisionsresultater, erfaringer |
| DORA Articles 17 to 19 | Hændelsesproces til at detektere, klassificere, eskalere, kommunikere og rapportere | Hændelsesregister, alvorlighedskriterier, eskaleringsregistreringer, skabeloner til kundeunderretning, rodårsagsregistreringer |
| DORA Articles 28 to 30 | Politik for IKT-tredjepartsrisiko, register, kontrakter, due diligence og exitplanlægning | Leverandørpolitik, kontraktregister, risikovurderinger, revisionsrettigheder, revisionsbevis for exitstrategi |
| GDPR Article 5(2) | Evne til at dokumentere efterlevelse af privatlivsprincipper | Databeskyttelsespolitik, fortegnelser over behandlingsaktiviteter, opbevaringsplan, registreringer af brud, adgangslogfiler, DPIA-registreringer, hvor relevant |
| GDPR Article 32 | Passende tekniske og organisatoriske sikkerhedsforanstaltninger | Sikkerhedspolitikker, procedurer for adgangsstyring, krypteringsstandarder, backupregistreringer, testbevis |
| NIST CSF 2.0 GOVERN | Politikker, roller, risikovillighed, retlige forpligtelser og tilsyn etableres og opdateres | Governance-profil, registreringer af politikgennemgang, risikoregister, roller og ansvar |
| COBIT 2019 assurance lens | Governance-mål, ejerskab, performanceovervågning og kontrolbevis | RACI, ledelsesgodkendelser, revisionsbevis for kontroludførelse, sporing af afhjælpning af forhold |
NIST CSF 2.0 er særligt nyttig som kommunikationslag. GOVERN-funktionen forventer, at retlige, regulatoriske og kontraktlige forpligtelser er forstået, at risikostyringsmål og ansvarsområder er defineret, at politikker er etableret og opdateret, og at resultater evalueres. Metoden Organizational Profile giver også en praktisk proces: afgræns profilen, indhent input såsom politikker, risikoprioriteter og krav, opret nuværende og målprofiler, analysér huller og implementér en prioriteret handlingsplan.
Det flugter tæt med Clarysecs tilgang: Byg én evidensunderstøttet driftsmodel, og map den derefter ud mod NIS2, DORA, GDPR, NIST og COBIT i stedet for at vedligeholde separate efterlevelsessiloer.
Et sprint på én uge til at opbygge en kontrolpakke for revisionsbevis vedrørende politikker
En fuld transformation af politikstyringen tager tid, men et fokuseret sprint på én uge kan synliggøre manglerne og skabe et forsvarligt fundament.
Dag 1: Opret dokumentregisteret
Start med et regneark, et GRC-system eller en struktureret SharePoint-liste. Dokumentregisteret er indekset, der gør det muligt for revisorer at navigere i evidenskorpusset.
| Felt | Eksempel |
|---|---|
| Dokument-ID | P01 |
| Dokumentnavn | Informationssikkerhedspolitik |
| Type | Politik |
| Ejer | CISO |
| Godkender | CEO |
| Aktuel version | 3.0 |
| Ikrafttrædelsesdato | 2026-02-01 |
| Næste gennemgangsdato | 2027-02-01 |
| Triggerbaseret gennemgang | Større hændelse, regulatorisk ændring, fusion, ny kritisk leverandør |
| Fortrolighedsklassificering | Intern |
| Primære kontroller | ISO/IEC 27002:2022 5.1, 5.33, 5.37 |
| Retlig mapping | NIS2 Article 21, DORA Article 6, GDPR Article 5 |
| Placering af revisionsbevis | ISMS Documentation/Policies/P01 |
| Placering af forældede dokumenter | ISMS Documentation/Archive/P01 |
| Tilknyttede undtagelser | EX-2026-004 |
| Kommunikationsregistrering | Awareness-kampagne AC-2026-02 |
Gør det ikke unødigt komplekst. Hvis registeret pålideligt viser ejer, godkender, version, gennemgangsdato, mapping og placering af revisionsbevis, løser det allerede mange problemer med fremsøgning ved revision.
Dag 2: Etabler repositoriet
Følg strukturen i Zenith Blueprint trin 6: Politikker og procedurer, Risikovurdering og SoA, Trænings- og awareness-registreringer, Revision og gennemgang, Hændelsesregistreringer, Aktiver og fortegnelser samt Kontrolbibliotek.
Anvend adgangsregler. Politikker kan læses af alle medarbejdere. Risikovurderingsregistreringer bør begrænses til ISMS-teamet og ledelsen. Hændelsesregistreringer bør være need-to-know. Leverandørkontrakter bør begrænses til indkøb, jura, økonomi og sikkerhed. Forældede dokumenter bør være utilgængelige til daglig brug, men opbevares af hensyn til revisionssporbarhed.
Dag 3: Standardisér headers og ændringslogfiler
Hver politik bør indeholde dokumentnavn, ejer, godkender, version, ikrafttrædelsesdato, næste gennemgangsdato, klassificering, relaterede kontroller, relaterede retlige forpligtelser og ændringshistorik.
| Version | Dato | Ændringsresumé | Gennemgangsansvarlig | Godkender |
|---|---|---|---|---|
| 2.0 | 2025-09-15 | Tilføjede DORA-referencer om tredjepartsrisiko | Sikkerhedschef | COO |
| 2.1 | 2025-11-20 | Opdaterede eskaleringsroller for hændelser | CISO | CEO |
| 3.0 | 2026-02-01 | Årlig gennemgang og opdatering af NIS2-mapping | CISO | CEO |
Dette understøtter styring af ISO/IEC 27001:2022-dokumenteret information, NIS2-ledelsestilsyn, DORA-forventninger til gennemgang og GDPR-ansvarlighed.
Dag 4: Knyt undtagelser til politikker
Opret et undtagelsesregister med undtagelses-ID, berørt politik, berørt kontrol, forretningsmæssig begrundelse, kompenserende kontroller, risikoejer, godkendelse, udløbsdato og gennemgangsstatus.
Et eksempel: Et ældre system kan ikke understøtte MFA i 60 dage. Undtagelsen knyttes til politik for adgangskontrol, aktivfortegnelsen, risikoregisteret og afhjælpningsplanen. Risikoejeren godkender restrisikoen, og undtagelsen udløber automatisk, medmindre den fornyes. Dette implementerer Clarysecs SMV-governancekrav om, at væsentlige beslutninger, undtagelser og eskaleringer skal registreres og kunne spores.
Dag 5: Opbyg pakken med revisionsbevis
For hver overordnet politik oprettes en undermappe til revisionsbevis, der indeholder den godkendte aktuelle version, tidligere version og ændringslog, godkendelsesbevis, kommunikationsbevis, trænings- eller bekræftelsesregistrering, relateret procedure, relateret operationel registrering, undtagelser, seneste gennemgangsregistrering, næste gennemgangsdato og mapping til retlige forpligtelser og kontroller.
For hændelseshåndtering skal der medtages registreringer fra tabletop-øvelser, kriterier for hændelsesklassificering, kontaktlister, skabeloner til efterhændelsesgennemgang og registreringer af beslutninger om underretning. Dette understøtter NIS2 Article 23-parathed til trinvis rapportering, DORA-hændelsesklassificering og GDPR-ansvarlighed ved brud.
Dag 6: Test fremsøgning
Bed en intern revisor eller compliance-ansvarlig om at fremsøge revisionsbevis til tre spørgsmål:
- Dokumentér, at informationssikkerhedspolitikken blev godkendt, kommunikeret og gennemgået.
- Dokumentér, at leverandørsikkerhedsforpligtelser mappes til DORA- og NIS2-krav.
- Dokumentér, at GDPR-ansvarlighedsbevis opbevares og beskyttes.
Hvis fremsøgning tager mere end 30 minutter pr. spørgsmål, skal repositoriet forbedres.
Dag 7: Præsentér for ledelsen
Opsummér status for politikkernes livscyklus i ledelsens gennemgang:
- Politikker, der er aktuelle, forsinkede eller forfalder inden for 90 dage
- Åbne og udløbne undtagelser
- Huller i revisionsbevis
- Opdateringer af regulatorisk mapping
- Revisionskonstateringer
- Korrigerende handlinger
- Ressourcebehov
Dette lukker kredsløbet med ISO/IEC 27001:2022-ledelsesforventninger, NIS2-bestyrelsesansvarlighed og DORA-ledelsesorganets tilsyn.
Hvordan revisorer vil undersøge politikkernes livscyklus
Forskellige revisorer ser på det samme revisionsbevis gennem forskellige linser.
En ISO/IEC 27001:2022-revisor starter med styring af dokumenteret information. Revisor vil kontrollere, om krævede dokumenter findes, om de er godkendt før brug, om versioner er styret, om dokumenter er tilgængelige, hvor der er behov for dem, om fortrolige registreringer er beskyttet, og om utilsigtet brug af forældede dokumenter forhindres. Revisor vil forbinde politikkens livscyklus med lederskab, risikobehandling, operationel styring, intern audit og ledelsens gennemgang.
En DORA-fokuseret reviewer vil have fokus på robusthed. Vedkommende vil undersøge, om styringsrammen for IKT-risiko er veldokumenteret, godkendt af ledelsen, gennemgået mindst årligt, hvor det er relevant, revideret regelmæssigt, forbedret på baggrund af læring og forbundet med hændelsesrapportering, test, tredjepartsrisiko, kontinuitet og genopretning.
En NIS2-tilsynsmyndighed vil ønske at se en ubrudt kæde af revisionsbevis fra risikoidentifikation til cybersikkerhedsrisikostyringstiltag, videre til ledelsesorganets godkendelse, implementering og overvågning. Ethvert brud i den kæde kan fremstå som manglende fornøden omhu.
En GDPR-revisor eller databeskyttelsesreviewer vil spørge, om registreringer for governance af personoplysninger dokumenterer ansvarlighed: behandlingsformål, behandlingsgrundlag, opbevaring, tekniske og organisatoriske foranstaltninger, databehandlerkontroller, registreringer af brud og revisionsbevis for håndhævelse af politikken.
En COBIT 2019- eller ISACA-orienteret revisor vil fokusere på styringssystemets komponenter: processer, organisatoriske strukturer, informationsflows, politikker, roller, kultur, kompetencer og tjenester. Vedkommende vil spørge, om ejerskab er defineret, om ledelsen overvåger performance, om undtagelser eskaleres, og om revisionsbevis understøtter kontroludførelse og ledelsestilsyn.
Det samme kontrollerede evidensrepository kan opfylde dem alle, men kun hvis dokumenterne er mappet, aktuelle, beskyttede og sporbare.
Almindelige fejl i politikkernes livscyklus, der bør rettes før revisor ankommer
De fleste fejl i politikkernes livscyklus er grundlæggende styringssvagheder, der gentages på tværs af miljøer:
- Politikker findes, men har ingen navngiven ejer.
- Godkendere er uklare, forældede eller for junior i forhold til risikoen.
- Politikker er godkendt, men ikke kommunikeret.
- Gennemgangsdatoer overskrides uden eskalering.
- Forældede versioner er fortsat tilgængelige i fællesmapper.
- Procedurer er i konflikt med politikker.
- Undtagelser godkendes uformelt via e-mail.
- Retlige forpligtelser er mappet til rammeværk, men ikke til faktiske kontroller eller ejere.
- Revisionsbevis er spredt på personlige drev, helpdesk-sagsstyringssystemer og chatbeskeder.
- Opbevaringsperioder er udefinerede eller anvendes inkonsistent.
- Registreringer opbevares, men beskyttes ikke mod uautoriseret ændring.
- Leverandørpolitikker er ikke knyttet til kontraktregistre, due diligence eller exitplaner.
- Hændelsesprocedurer er ikke tilpasset beslutningspunkter for underretning efter NIS2, DORA eller GDPR.
Disse forhold skaber revisionsfriktion, fordi de underminerer tillid. Hvis en revisor ikke kan have tillid til politikkorpusset, vil revisor undersøge kontroludførelsen dybere.
Marias afhjælpningsplan var ikke at skrive endnu en politik. Den var at skabe én fælles sandhedskilde. Hun udpegede ét officielt ISMS-dokumentationsbibliotek, migrerede aktuelle politikker til det, arkiverede ukontrollerede placeringer, standardiserede ejer- og godkenderfelter, etablerede godkendelsesworkflows, mappede politikker til NIS2- og DORA-forpligtelser og gav revisorer skrivebeskyttet adgang til struktureret revisionsbevis. Det, der havde været en kilde til bekymring, blev en dokumentation af kontrol.
Clarysecs vej frem
Styring af politikkernes livscyklus er ikke bureaukratisk overhead. Det er den operationelle disciplin, der gør ISO 27001-dokumenteret information, NIS2-ledelsesansvarlighed, DORA-governance for IKT-risiko og GDPR-ansvarlighed juridisk forsvarlig.
Brug Zenith Blueprint: En revisors 30-trins køreplan til at opbygge ISMS-biblioteket i den korrekte fase og rækkefølge, især trin 6 for dokumenteret information og trin 22 for politikstyring. Brug Clarysecs SMV- og enterprise-politikker til at definere krav til gennemgang, godkendelse, versionsstyring, kommunikation, sporbarhed, centralisering af revisionsbevis og opbevaring. Brug Zenith Controls: Vejledningen til tværgående efterlevelse til at mappe ISO/IEC 27002:2022-kontroller såsom 5.1, 5.33 og 5.37 til tværgående efterlevelsesforventninger, kontrolattributter og revisionsperspektiver.
Før I køber endnu et værktøj eller skriver endnu en politik, skal I besvare ét spørgsmål:
Kan I dokumentere, at hver vigtig politik er ejet, godkendt, aktuel, kommunikeret, mappet, underbygget med revisionsbevis, gennemgået, beskyttet og korrekt udfaset?
Hvis svaret endnu ikke er ja, kan Clarysec hjælpe jer med at opbygge det revisionsklare ISMS-bibliotek, workflowet for politikkernes livscyklus og den tværgående efterlevelsesmapping, som revisorer, bestyrelser og kunder forventer i 2026. Download Zenith Blueprint, udforsk Clarysecs SMV- og enterprise-politikpakker, eller book en parathedsvurdering for at gøre jeres politikbibliotek til et forsvarligt efterlevelsesaktiv.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


