ISO 27001-revisionsbevis for NIS2 og DORA

Klokken er 08:17 en tirsdag, og CISO’en i en hurtigt voksende fintech-SaaS-virksomhed har tre beskeder liggende.

Den første er fra en større bankkunde: “Send venligst jeres seneste interne revisionsrapport, referater fra ledelsens gennemgang, status for korrigerende handlinger, procedure for rapportering af hændelser, leverandørregister og revisionsbevis for bestyrelsestilsyn.”

Den anden er fra CFO’en: “Er vi omfattet af NIS2 eller DORA, og hvilket revisionsbevis har vi allerede?”

Den tredje er fra CEO’en: “Kan vi sige, at vi er revisionsklar?”

Det ubehagelige svar i mange organisationer er ikke, at der ikke sker noget. Det er værre. Sikkerhedsarbejdet foregår overalt, men revisionsbeviset findes ingen steder. Der er kontroller, men intet revisionsspor. Der er tickets, men ingen tydelig kobling til risici. Der er ledelsesopdateringer, men ingen formelle resultater fra ledelsens gennemgang. Der er leverandørdrøftelser, men intet revisionsmæssigt forsvarligt leverandørregister, ingen kontraktgennemgang og ingen exitstrategi.

Netop dette hul er dér, hvor ISO/IEC 27001:2022-interne revisioner og ledelsens gennemgang bliver mere end certificeringsaktiviteter. De bliver den operationelle rytme for NIS2, DORA, GDPR, kundedokumentation, cyberforsikring og bestyrelsens ansvarlighed.

SaaS-, cloud-, MSP-, MSSP- og fintech-teams fejler sjældent, fordi de mangler sikkerhedsaktiviteter. De fejler, fordi aktiviteterne er spredt på Slack, Jira, regneark, leverandørportaler, SOC-tickets, indkøbsfiler og bestyrelsesmateriale. En tilsynsmyndighed, ekstern revisor eller enterprise-kunde ønsker ikke en heroisk forklaring. De ønsker objektivt revisionsbevis.

Den praktiske løsning er ikke at køre separate revisionsprogrammer for hvert framework. Det er at bruge ISO 27001-ISMS’et som den centrale motor for revisionsbevis og derefter tagge beviset til NIS2, DORA, GDPR og kontraktlige krav. Udført korrekt kan én intern revision og én cyklus for ledelsens gennemgang besvare mange spørgsmål om efterlevelse.

Fra framework-træthed til en samlet ISMS-model for revisionsbevis

Mange CISO’er står med en variant af Marias problem. Maria leder sikkerheden i en B2B-SaaS-virksomhed med kunder i den finansielle sektor. Hendes team bestod en ISO/IEC 27001:2022-certificeringsaudit for seks måneder siden. ISMS’et modnes, politikkerne følges, og kontrolansvarlige forstår deres ansvar. Så videresender CEO’en to artikler, én om NIS2-direktivet og én om DORA, med et kort spørgsmål: “Er vi dækket?”

Svaret afhænger af omfang, tjenester, kunder og juridiske enheder. Men det operationelle svar er klart: Hvis Maria behandler NIS2 og DORA som separate complianceprojekter, skaber hun dobbeltarbejde, inkonsistent revisionsbevis og stigende revisionstræthed. Hvis hun behandler dem som krav fra interessenter i ISMS’et, kan hun bruge ISO 27001 til at indarbejde, teste og dokumentere beredskab.

ISO/IEC 27001:2022 er designet til dette. Punkt 4 kræver, at organisationen forstår sin kontekst og krav fra interessenter, herunder juridiske, regulatoriske, kontraktlige og afhængighedsdrevne forpligtelser. Punkt 5 kræver lederskab og integration i forretningsprocesser. Punkt 6 kræver risikovurdering og risikobehandling. Punkt 9 kræver evaluering af præstation gennem overvågning, intern revision og ledelsens gennemgang. Punkt 10 kræver forbedring og korrigerende handling.

NIS2 og DORA passer naturligt ind i denne struktur.

NIS2 kræver, at væsentlige og vigtige enheder implementerer passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til styring af cybersikkerhedsrisici. Direktivet placerer også ansvar hos ledelsesorganer for at godkende disse foranstaltninger, føre tilsyn med implementeringen og kunne drages til ansvar for overtrædelser. Minimumsforanstaltningerne omfatter risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, sårbarhedsstyring, effektivitetsvurdering, træning, kryptografi, HR-sikkerhed, adgangsstyring, politik for aktivstyring og, hvor det er relevant, multifaktorgodkendelse eller løbende autentifikation.

DORA finder anvendelse fra 17. januar 2025 og etablerer et sektorspecifikt regime for digital operationel robusthed for finansielle enheder. Det kræver ledelsesorganets ansvar for styring af IKT-risiko, en dokumenteret ramme for IKT-risikostyring, strategi for digital operationel robusthed, IKT-kontinuitets- og genopretningsplaner, robusthedstest, styring af IKT-hændelser og styring af IKT-tredjepartsrisici. For SaaS- og cloududbydere, der betjener finansielle enheder, kan DORA vise sig gennem kontraktlige forpligtelser, kunderevisioner og forventninger til styring af IKT-tredjepartsrisici, selv når udbyderen ikke selv er en finansiel enhed.

GDPR tilføjer ansvarlighedslaget. Når personoplysninger behandles inden for GDPR’s anvendelsesområde, skal organisationer kunne dokumentere overholdelse af databeskyttelsesprincipperne og passende tekniske og organisatoriske foranstaltninger.

ISO 27001 er ikke et magisk efterlevelsesbevis for disse forpligtelser. Det er det ledelsessystem, der kan organisere, dokumentere og forbedre dem.

Omfangsspørgsmålet: hvad dokumenterer I, og for hvem?

Før der opbygges en revisionsklar evidenspakke, skal ledelsen besvare et grundlæggende spørgsmål: Hvilke forpligtelser er omfattet?

For SaaS- og cloudvirksomheder kan NIS2-omfanget være bredere end forventet. NIS2 gælder for offentlige eller private enheder i oplistede sektorer, der opfylder størrelsestærskler, samt for visse enheder med høj samfundsmæssig betydning uanset størrelse. Relevante sektorer kan omfatte digital infrastruktur, cloud computing-tjenester, datacenterudbydere, content delivery networks, tillidstjenesteudbydere, udbydere af offentlige elektroniske kommunikationstjenester og B2B-udbydere af IKT-service management, såsom managed service providers og managed security service providers. SaaS-udbydere bør være særligt opmærksomme på, hvordan tjenester leveres, hvilke sektorer de understøtter, og om de muliggør administration efter behov og bred fjernadgang til skalerbare delte IT-ressourcer.

For fintech- og finansielle sektorleverandører skal DORA analyseres særskilt. DORA omfatter direkte en bred vifte af finansielle enheder, herunder kreditinstitutter, betalingsinstitutter, kontooplysningstjenesteudbydere, e-pengeinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, markedspladser, fondsforvaltere, forsikrings- og genforsikringsselskaber samt crowdfunding-tjenesteudbydere. IKT-tredjepartsleverandører er også en del af DORA-økosystemet, fordi finansielle enheder skal styre deres IKT-afhængigheder, føre registre over kontraktlige ordninger og inkludere specifikke kontraktbestemmelser for IKT-tjenester, der understøtter kritiske eller vigtige funktioner.

NIS2 og DORA interagerer også. Når en sektorspecifik EU-retsakt pålægger tilsvarende krav til styring af cybersikkerhedsrisici eller underretning om hændelser, finder de tilsvarende NIS2-bestemmelser muligvis ikke anvendelse på disse enheder for disse områder. DORA er det sektorspecifikke regime for operationel robusthed for finansielle enheder. Det gør ikke NIS2 irrelevant for alle omkringliggende udbydere. Det betyder, at evidensmodellen skal skelne mellem, om organisationen er en finansiel enhed direkte omfattet af DORA, en IKT-tredjepartsleverandør, der understøtter finansielle enheder, en SaaS-udbyder omfattet af NIS2 eller en koncern med flere juridiske enheder og tjenestelinjer.

Denne omfangsanalyse hører hjemme i ISMS-konteksten og interessentregisteret. Uden den vil revisionsplanen teste de forkerte forhold.

Ét revisionsspor, mange efterlevelsesspørgsmål

En almindelig fejl er at oprette separate evidenspakker til ISO 27001, NIS2, DORA, GDPR, cyberforsikring og kunderevisioner. Den tilgang skaber duplikering og modstridende svar. En bedre tilgang er én evidensmodel med flere perspektiver.

I centrum står ISMS’et. Omkring det ligger fem evidensfamilier.

Denne struktur er i overensstemmelse med Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint. I fasen Audit, Review & Improvement fokuserer Step 25 på programmet for intern revision, Step 26 på revisionsudførelse, Step 28 på ledelsens gennemgang og Step 29 på løbende forbedring.

Vejledningen i Blueprint’s Step 25 er bevidst praktisk:

“Udarbejd en plan, der beskriver, hvornår revisioner finder sted, og hvad de omfatter.”

“Brug skabelonen Internal Audit Plan template, hvis den er tilgængelig; det kan være et simpelt dokument eller regneark, der angiver revisionsdatoer, omfang og tildelte revisorer.”

Fra Zenith Blueprint, Audit, Review & Improvement phase, Step 25: Internal Audit Program Zenith Blueprint

Den enkle revisionsplan bliver stærk, når den er risikobaseret og tagget til NIS2-, DORA- og GDPR-forpligtelser.

ISO 27001-kontroller, der forankrer revisionsberedskab

For revisionsberedskab er tre ISO/IEC 27002:2022-kontroller særligt vigtige, når de fortolkes gennem Zenith Controls: The Cross-Compliance Guide Zenith Controls:

• 5.4 Ledelsens ansvar
• 5.35 Uafhængig gennemgang af informationssikkerhed
• 5.36 Overholdelse af politikker, regler og standarder for informationssikkerhed

Dette er ikke separate “Zenith-kontroller”. Det er ISO/IEC 27002:2022-kontroller, som Zenith Controls hjælper med at kortlægge, revidere og fortolke på tværs af frameworks.

Kontrol 5.4 spørger, om ansvar for informationssikkerhed er tildelt og forstået. Kontrol 5.35 spørger, om informationssikkerhed gennemgås uafhængigt. Kontrol 5.36 spørger, om organisationen overholder sine politikker, regler og standarder.

Zenith Controls klassificerer kontrol 5.35 på en assurance-orienteret måde:

ISO/IEC 27002:2022-kontrol 5.35, “Uafhængig gennemgang af informationssikkerhed,” behandles i Zenith Controls som “Preventive, Corrective” og understøtter fortrolighed, integritet og tilgængelighed gennem cybersikkerhedskoncepterne “Identify” og “Protect” med operationel kapacitet inden for “Information Security Assurance.” Zenith Controls

Det er vigtigt, fordi intern revision både er forebyggende og korrigerende. Den forebygger blinde vinkler ved at teste ISMS’et før ekstern kontrol, og den korrigerer svagheder gennem dokumenterede handlinger.

Den bredere krydskortlægning starter med NIS2- og DORA-krav og identificerer derefter det ISO 27001-revisionsbevis, der kan dokumentere dem.

Kontrolkortlægning er kun nyttig, når revisionsbeviset er stærkt. Hvis registreringen er svag, kan ingen krydskortlægning redde den. Hvis registreringen er komplet, kan det samme bevis besvare spørgsmål i ISO-, NIS2-, DORA-, GDPR-, NIST Cybersecurity Framework 2.0- og COBIT 2019-stil.

Politikbevis, som Clarysec forventer, at organisationer opbevarer

Clarysecs politikker omsætter ISMS-teori til forventninger til revisionsbevis.

For SMV’er kræver Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme ledelsesgodkendelse og revisionsdisciplin:

“Den administrerende direktør (GM) skal godkende en årlig revisionsplan.”

Fra Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.1.1 Audit and Compliance Monitoring Policy-sme

Den fastsætter også en minimumskadence:

“Interne revisioner eller efterlevelsesgennemgange skal udføres mindst årligt.”

Fra Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.2.1

Og den kobler konstateringer til korrektion og ledelsens gennemgang:

“GM skal godkende en plan for korrigerende handlinger og følge dens implementering.”

Fra Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.4.2

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

Fra Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.4.3

Opbevaring af revisionsbevis er også eksplicit:

“Revisionsbevis skal opbevares i mindst to år eller længere, hvor det kræves af certificeringer eller kundeaftaler.”

Fra Audit and Compliance Monitoring Policy-sme, Policy Implementation Requirements, clause 6.2.4

For større organisationer udvider Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, som i nogle Clarysec-materialer også omtales som P33 Audit and Compliance Monitoring Policy, strukturen:

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

Fra Audit and Compliance Monitoring Policy, Governance Requirements, clause 5.2 Audit and Compliance Monitoring Policy

“Organisationen skal vedligeholde et revisionsregister, der indeholder:”

Fra Audit and Compliance Monitoring Policy, Governance Requirements, clause 5.4

“Interne revisioner skal følge en dokumenteret procedure, der omfatter:”

Fra Audit and Compliance Monitoring Policy, Policy Implementation Requirements, clause 6.1.1

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

Fra Audit and Compliance Monitoring Policy, Policy Implementation Requirements, clause 6.2.1

Ledelsens gennemgang er forankret i Information Security Policy Information Security Policy, som i nogle Clarysec-materialer også omtales som P01 Information Security Policy:

“Aktiviteter for ledelsens gennemgang (jf. ISO/IEC 27001 punkt 9.3) skal udføres mindst årligt og skal omfatte:”

Fra Information Security Policy, Governance Requirements, clause 5.3 Information Security Policy

Disse krav skaber den beviskæde, revisorer forventer: godkendt plan, defineret procedure, revisionsregister, konstateringer, CAPA, opbevaring og ledelsesgennemgang.

Opbygning af den revisionsklare evidenspakke

En revisionsklar evidenspakke er ikke en stor mappe, der oprettes to dage før revisionen. Det er en levende struktur, der vedligeholdes hele året.

Evidenspakken bør kortlægges til ISO/IEC 27001:2022-punkter og Anneks A-kontroller, men tagges for regulatorisk relevans. En leverandørrevisionsregistrering kan f.eks. understøtte Anneks A-leverandørkontroller, NIS2-sikkerhed i forsyningskæden og DORA-styring af IKT-tredjepartsrisici. En registrering fra en tabletop-øvelse for hændelser kan understøtte ISO 27001-hændelsesstyring, NIS2-beredskab til trinvis underretning og DORA-styring af større IKT-relaterede hændelser.

Sådan udføres den integrerede interne revision

Step 26 i Zenith Blueprint fremhæver objektivt revisionsbevis:

“Udfør revisionen ved at indsamle objektivt revisionsbevis for hvert punkt på din tjekliste.”

“Interview relevant personale.”

“Gennemgå dokumentation.”

“Observer praksis.”

“Udtag stikprøver og foretag stikprøvekontrol.”

Fra Zenith Blueprint, Audit, Review & Improvement phase, Step 26: Audit Execution Zenith Blueprint

Det er præcis, hvad NIS2- og DORA-beredskab kræver. Tilsynsmyndigheder og kunder accepterer ikke “vi mener, det virker”. De spørger, hvordan I ved det.

En velfungerende revision tester fire evidensdimensioner.

Overvej en simuleret ransomware-hændelse på en stagingserver. Revisoren tester, om processen for hændelseshåndtering kan opfylde ISO 27001-krav, NIS2-forventninger til trinvis rapportering og DORA-kundeforpligtelser.

NIS2 har en trinvis rapporteringsstruktur for væsentlige hændelser, herunder tidlig advarsel inden for 24 timer efter kendskab, hændelsesunderretning inden for 72 timer og en slutrapport inden for én måned efter hændelsesunderretningen. DORA har sit eget klassificerings- og rapporteringsrammeværk for IKT-relaterede hændelser for finansielle enheder. Den interne revision bør verificere, at playbooks registrerer kendskabstidspunkt, alvorlighedskriterier, berørte tjenester, kompromitteringsindikatorer (IOC’er), afbødende handlinger, rodårsag, kunders underretningsforpligtelser og data til slutrapportering.

Fra én revisionskonstatering til NIS2- og DORA-bevis

En realistisk leverandørkonstatering viser, hvordan revisionsbevis bør flyde.

Under den interne revision udtager revisoren stikprøver på fem kritiske leverandører. Én udbyder af cloudbaseret logning understøtter svigovervågning og sikkerhedsalarmering for fintech-platformen. Leverandøren er opført i fortegnelsen, men der findes ingen dokumenteret exitplan, intet bevis for årlig sikkerhedsgennemgang og ingen bekræftelse af, at kontrakten omfatter bistand ved hændelser eller revisionsrettigheder.

Revisoren registrerer en afvigelse vedrørende leverandørsikkerhed og krav til cloud-exit. En svag respons ville være: “leverandørgennemgang mangler.” En stærk respons skaber en beviskæde for tværgående efterlevelse:

1. Registrér konstateringen i revisionsrapporten, herunder stikprøvestørrelse, leverandørnavn, kontraktreference og manglende revisionsbevis.
2. Tilføj en CAPA-post med rodårsag, f.eks. “tjekliste for onboarding af leverandører omfattede ikke kritikalitetsklassificering eller udløser for exitplan.”
3. Tildel leverandøransvarlig og risikoejer.
4. Opdater leverandørregisteret for at markere tjenesten som understøttende en kritisk eller vigtig funktion.
5. Udfør en risikovurdering, der dækker driftsafbrydelse, dataadgang, koncentrationsrisiko, afhængighed af hændelsesrapportering og kontraktlige mangler.
6. Opdater risikobehandlingsplanen og anvendelseserklæringen, hvor det er relevant.
7. Indhent et opdateret kontrakttillæg eller en dokumenteret risikoaccept.
8. Opret eller test en exitplan.
9. Genrevidér leverandørens bevis efter afhjælpning.
10. Rapportér konstateringen, risikoen og ressourcebehovene i ledelsens gennemgang.

Denne ene kæde understøtter flere forpligtelser. NIS2 forventer sikkerhed i forsyningskæden og hensyntagen til leverandørers sårbarheder, cybersikkerhedspraksis og procedurer for sikker udvikling. DORA kræver, at finansielle enheder styrer IKT-tredjepartsrisici, vedligeholder registre over kontraktlige ordninger, vurderer udbydere før kontraktindgåelse, inkluderer revisions- og inspektionsrettigheder, hvor det er relevant, opretholder opsigelsesrettigheder og dokumenterer exitstrategier for IKT-tjenester, der understøtter kritiske eller vigtige funktioner. GDPR kan også være relevant, hvis leverandøren behandler personoplysninger.

Revisionsregistreringen er ikke længere blot bevis for efterlevelse. Den er bevis for robusthed.

Ledelsens gennemgang: hvor bevis bliver til ansvarlighed

Intern revision finder sandheden. Ledelsens gennemgang beslutter, hvad der skal gøres ved den.

Step 28 i Zenith Blueprint beskriver inputpakken til ledelsens gennemgang:

“ISO 27001 specificerer flere krævede input til ledelsens gennemgang. Udarbejd en kort rapport eller præsentation, der dækker disse punkter.”

Blueprint’et oplister status på tidligere handlinger, ændringer i eksterne og interne forhold, ISMS-performance og -effektivitet, hændelser eller afvigelser, muligheder for forbedring og ressourcebehov.

Fra Zenith Blueprint, Audit, Review & Improvement phase, Step 28: Management Review Zenith Blueprint

For NIS2 og DORA er ledelsens gennemgang dér, hvor ansvarlighed på bestyrelsesniveau bliver synlig. Gennemgangen bør ikke blot sige “sikkerhed blev drøftet”. Den bør vise, at ledelsen gennemgik:

• Ændringer i NIS2-, DORA-, GDPR-, kunde- og kontraktkrav.
• Omfangsændringer, herunder nye lande, produkter, regulerede kunder eller IKT-afhængigheder.
• Resultater fra intern revision, herunder større og mindre afvigelser.
• Status for CAPA’er og forsinkede handlinger.
• Sikkerhedsmål og målinger.
• Hændelsestendenser, nærved-hændelser og lessons learned.
• Leverandør- og cloudkoncentrationsrisici.
• Resultater fra forretningskontinuitets- og backuptest.
• Performance for sårbarheder og patching.
• Ressourcebehov, herunder medarbejdere, værktøjer, træning og budget.
• Restrisici, der kræver formel accept.
• Forbedringsbeslutninger og ansvarlige ejere.

Det er her, Maria kan omsætte en teknisk rapport til strategisk assurance. I stedet for at sige “vi fandt én mangel i hændelsesprocessen,” kan hun sige: “Revisionen identificerede én mindre afvigelse i vores beslutningskriterier for NIS2-hændelsesrapportering. CAPA’en opdaterer proceduren, tilføjer en beslutningsmatrix og kræver en tabletop-øvelse inden for 30 dage. Vi har behov for ledelsesgodkendelse til juridisk gennemgang og træningstid.”

Det er den type registrering, der understøtter styring, tilsyn og forsvarlig beslutningstagning.

Korrigerende handling: forskellen mellem en konstatering og modenhed

En intern revision uden korrigerende handling er kun en diagnose.

Step 29 i Zenith Blueprint anbefaler organisationer at bruge en CAPA-log:

“Udfyld den med hvert problem: problembeskrivelse, rodårsag, korrigerende handling, ansvarlig ejer, måldato for gennemførelse, status.”

Fra Zenith Blueprint, Audit, Review & Improvement phase, Step 29: Continual Improvement Zenith Blueprint

Den fremhæver også en vigtig sondring:

“I revisionsterminologi: korrektion afhjælper symptomet, korrigerende handling afhjælper årsagen. Begge er vigtige.”

Fra Zenith Blueprint, Audit, Review & Improvement phase, Step 29: Continual Improvement

Hvis bevis for gendannelse fra backup mangler, kan korrektionen være at udføre og dokumentere en gendannelsestest i denne uge. Den korrigerende handling er at ændre backupproceduren, så gendannelsestest planlægges kvartalsvist, automatisk oprettes som tickets, gennemgås af serviceejeren og indgår i målinger til ledelsens gennemgang.

Revisorer leder efter denne modenhed. En ISO 27001-revisor tester overensstemmelse med ISMS’et og valgte kontroller. En NIS2-gennemgang spørger, om foranstaltninger til risikostyring er effektive og under tilsyn. En DORA-gennemgang ser efter integration af IKT-risikostyringsrammen, robusthedstest, styring af tredjepartsafhængigheder og afhjælpning. En NIST Cybersecurity Framework 2.0-vurdering kan spørge, om resultater for governance, identify, protect, detect, respond og recover fungerer. En COBIT 2019-revisor kan fokusere på styringsmål, ejerskab, resultatindikatorer og assurance.

Den samme CAPA-registrering kan opfylde disse perspektiver, hvis den indeholder rodårsag, ejer, risikokonsekvens, korrigerende handling, forfaldsdato, bevis for implementering, effektivitetsgennemgang og synlighed for ledelsen.

Revisors mange perspektiver

Forskellige revisorer læser det samme revisionsbevis forskelligt. Zenith Controls hjælper med at forudse disse spørgsmål ved at fungere som en vejledning for tværgående efterlevelse for ISO/IEC 27002:2022-kontroller og relaterede frameworks.

Kontrol 5.36 er et godt eksempel. ISO 27001-revisoren kan fokusere på, om efterlevelsesgennemgange finder sted og fører til korrigerende handling. NIS2-gennemgangen kan spørge, om disse gennemgange tester juridiske cybersikkerhedsforanstaltninger og ikke kun interne regler. DORA-gennemgangen kan fokusere på, om efterlevelsesgennemgange omfatter kritiske IKT-udbydere og kontraktlig håndhævelse.

Derfor skal revisionsbeviset designes til flere læsere fra begyndelsen.

Et praktisk 30-dages sprint for revisionsberedskab

Hvis CEO’en spørger, om organisationen kan blive revisionsklar på 30 dage, er det ærlige svar: I kan opbygge en troværdig evidensbaseline, hvis ledelsen støtter sprintet, og omfanget er realistisk.

Dette sprint erstatter ikke langsigtet modenhed. Det skaber en forsvarlig operationel baseline. Den reelle værdi opstår, når organisationen gentager cyklussen kvartalsvist eller halvårligt og ikke kun én gang om året.

Almindelige evidensmangler, som Clarysec finder

De samme svagheder går igen i revisioner af SaaS-, cloud- og fintech-virksomheder:

• Revisionsplanen findes, men den er ikke risikobaseret.
• Revisionstjeklisten tester ISO-punkter, men ignorerer NIS2-, DORA-, GDPR- og kundeforpligtelser.
• Referater fra ledelsens gennemgang findes, men de viser ikke beslutninger, ressourceallokering eller risikoaccept.
• CAPA-registreringer oplister handlinger, men ingen rodårsag.
• Konstateringer lukkes uden verifikation af effektivitet.
• Leverandørgennemgange udføres, men kritiske leverandører adskilles ikke fra lavrisikoleverandører.
• Hændelsesplaybooks findes, men ingen kan dokumentere, at rapporteringsarbejdsgangen på 24 eller 72 timer ville fungere.
• Backupjob er grønne, men gendannelsestest er ikke dokumenteret.
• Gennemgang af adgangsrettigheder eksporteres, men undtagelser følges ikke til lukning.
• Logfiler indsamles, men ingen kan vise overvågning, eskalering eller respons.
• Revisionsbevis opbevares i personlige mapper i stedet for i et kontrolleret repository.
• Opbevaringskrav er uklare eller inkonsistente med kundekontrakter.

Disse fejl kan afhjælpes. De kræver en struktureret ISMS-arkitektur for revisionsbevis, ikke dokumentjagt i sidste øjeblik.

Sådan ser godt ud for bestyrelsen

Når CISO’en vender tilbage til CEO’en og CFO’en, er det stærkeste svar ikke “vi bestod en revisionstjekliste”. Det er:

“Vi har en godkendt revisionsplan. Vi har udført en risikobaseret intern revision. Vi har identificeret konstateringer med objektivt revisionsbevis. Vi har godkendt CAPA’er med ejere og forfaldsdatoer. Vi har eskaleret væsentlige risici, hændelser, leverandørafhængigheder og ressourcebehov til ledelsens gennemgang. Vi har kortlagt revisionsbevis til ISO/IEC 27001:2022, NIS2, DORA og GDPR. Vi kan fremvise revisionssporet.”

Det svar ændrer samtalen. Det giver CEO’en tillid over for kunderne. Det giver CFO’en klarhed over regulatorisk eksponering. Det giver bestyrelsen en forsvarlig tilsynsregistrering. Det giver CISO’en en prioriteret køreplan i stedet for en bunke usammenhængende anmodninger.

Vigtigst af alt flytter det organisationen fra compliance-teater til operationel robusthed.

Næste skridt med Clarysec

Jeres næste revision bør ikke være brandslukning. Den bør være synligt bevis på, at jeres ISMS fungerer, at ledelsen er engageret, og at organisationen er klar til ISO 27001, NIS2, DORA, GDPR og kundedokumentation.

Clarysec kan hjælpe jer med at:

• Opbygge en risikobaseret intern revisionsplan ved hjælp af Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint.
• Kortlægge revisionsbevis gennem Zenith Controls: The Cross-Compliance Guide Zenith Controls.
• Implementere revisionsstyring for SMV’er eller enterprise-organisationer ved hjælp af Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme eller Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy.
• Forberede pakker til ledelsens gennemgang, der er tilpasset Information Security Policy Information Security Policy og forventningerne i ISO/IEC 27001:2022 punkt 9.3.
• Omsætte konstateringer til CAPA-registreringer, ledelsesbeslutninger og målbar forbedring.

Download Clarysecs værktøjspakker, book en beredskabsvurdering, eller anmod om en demo for at omsætte jeres næste interne revision til bestyrelsesklar dokumentation for ISO 27001, NIS2, DORA og videre.