ISO 27001-auditbewijs voor NIS2 en DORA

Het is dinsdag 08:17 en de CISO van een snelgroeiende fintech-SaaS-onderneming heeft drie berichten klaarstaan.

Het eerste komt van een grote bancaire klant: “Stuur alstublieft uw meest recente interne-auditrapport, de notulen van de directiebeoordeling, de status van corrigerende maatregelen, de procedure voor incidentmelding, het leveranciersregister en bewijs van toezicht door het bestuursorgaan.”

Het tweede komt van de CFO: “Vallen wij binnen de reikwijdte van NIS2 of DORA, en welk bewijs hebben we al?”

Het derde komt van de CEO: “Kunnen we zeggen dat we auditgereed zijn?”

Het ongemakkelijke antwoord in veel organisaties is niet dat er niets gebeurt. Het is erger. Beveiligingswerk vindt overal plaats, maar bewijs is nergens snel vindbaar. Er zijn beheersmaatregelen, maar geen audittrail. Er zijn tickets, maar geen duidelijke koppeling met risico’s. Er zijn managementupdates, maar geen formele uitkomsten van de directiebeoordeling. Er zijn gesprekken met leveranciers, maar geen verdedigbaar leveranciersregister, contractbeoordeling of exitstrategie.

Precies in die leemte worden de interne audit en directiebeoordeling binnen ISO/IEC 27001:2022 meer dan certificeringsactiviteiten. Ze worden het operationele ritme voor NIS2, DORA, GDPR, klantassurance, cyberverzekering en verantwoordingsplicht van het bestuursorgaan.

SaaS-, cloud-, MSP-, MSSP- en fintechteams falen zelden omdat er geen beveiligingsactiviteiten plaatsvinden. Ze falen omdat activiteiten verspreid zijn over Slack, Jira, spreadsheets, leveranciersportalen, SOC-tickets, inkoopdossiers en bestuurspresentaties. Een toezichthouder, externe auditor of enterprise-klant wil geen heroïsche uitleg. Die wil objectief bewijs.

De praktische oplossing is niet om voor elk raamwerk afzonderlijke auditprogramma’s te draaien. De oplossing is het ISO 27001-ISMS te gebruiken als centrale bewijsbasis en dat bewijs vervolgens te taggen voor NIS2, DORA, GDPR en contractuele eisen. Goed ingericht kunnen één interne audit en één cyclus voor directiebeoordeling veel nalevingsvragen beantwoorden.

Van raamwerkmoeheid naar een uniform ISMS-bewijsmodel

Veel CISO’s herkennen een variant van Maria’s probleem. Maria leidt de beveiliging bij een B2B-SaaS-bedrijf met klanten in de financiële sector. Haar team heeft zes maanden geleden een ISO/IEC 27001:2022-certificeringsaudit doorstaan. Het ISMS wordt volwassener, beleid wordt gevolgd en eigenaren van beheersmaatregelen begrijpen hun verantwoordelijkheden. Dan stuurt de CEO twee artikelen door, één over de NIS2-richtlijn en één over DORA, met een korte vraag: “Zijn we afgedekt?”

Het antwoord hangt af van toepassingsgebied, diensten, klanten en juridische entiteiten. Maar het operationele antwoord is duidelijk: als Maria NIS2 en DORA als afzonderlijke nalevingsprojecten behandelt, creëert zij dubbel werk, inconsistent bewijs en oplopende auditmoeheid. Als zij ze behandelt als eisen van belanghebbenden binnen het ISMS, kan zij ISO 27001 gebruiken om de eisen op te nemen, te toetsen en gereedheid aan te tonen.

ISO/IEC 27001:2022 is hiervoor ontworpen. Clausule 4 vereist dat de organisatie haar context en de eisen van belanghebbenden begrijpt, inclusief wettelijke, regelgevende, contractuele en door afhankelijkheden gedreven verplichtingen. Clausule 5 vereist leiderschap en integratie in bedrijfsprocessen. Clausule 6 vereist risicobeoordeling en risicobehandeling. Clausule 9 vereist prestatie-evaluatie via monitoring, interne audit en directiebeoordeling. Clausule 10 vereist verbetering en corrigerende maatregelen.

NIS2 en DORA passen op natuurlijke wijze in die structuur.

NIS2 vereist dat essentiële en belangrijke entiteiten passende en evenredige technische, operationele en organisatorische maatregelen voor cyberbeveiligingsrisicobeheer implementeren. De richtlijn legt ook verantwoordelijkheid bij bestuursorganen om die maatregelen goed te keuren, toezicht te houden op de implementatie en aansprakelijk te kunnen worden gehouden voor inbreuken. De minimummatregelen omvatten risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, afhandeling van kwetsbaarheden, beoordeling van doeltreffendheid, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en, waar passend, multifactorauthenticatie of continue authenticatie.

DORA is van toepassing vanaf 17 januari 2025 en creëert een sectorspecifiek regime voor digitale operationele weerbaarheid voor financiële entiteiten. DORA vereist verantwoordelijkheid van het bestuursorgaan voor ICT-risicobeheer, een gedocumenteerd ICT-risicobeheerkader, een strategie voor digitale operationele weerbaarheid, ICT-continuïteits- en herstelplannen, weerbaarheidstests, governance voor ICT-incidenten en risicobeheer voor derde aanbieders van ICT-diensten. Voor SaaS- en cloudproviders die financiële entiteiten bedienen, kan DORA zichtbaar worden via contractuele verplichtingen, klantaudits en verwachtingen voor risicobeheer van derde aanbieders van ICT-diensten, ook wanneer de provider zelf geen financiële entiteit is.

GDPR voegt de laag van verantwoordingsplicht toe. Wanneer persoonsgegevens binnen de reikwijdte van GDPR worden verwerkt, moeten organisaties kunnen aantonen dat zij de beginselen voor gegevensbescherming en passende technische en organisatorische maatregelen naleven.

ISO 27001 is geen magisch nalevingscertificaat voor deze verplichtingen. Het is het managementsysteem dat ze kan ordenen, onderbouwen en verbeteren.

De scopevraag: wat toont u aan, en voor wie?

Voordat een auditgereed bewijspakket wordt opgebouwd, moet de leiding een basisvraag beantwoorden: welke verplichtingen vallen binnen de reikwijdte?

Voor SaaS- en cloudbedrijven kan het toepassingsgebied van NIS2 breder zijn dan verwacht. NIS2 is van toepassing op publieke of private entiteiten in genoemde sectoren die aan omvangsdrempels voldoen, en op bepaalde entiteiten met hoge impact ongeacht omvang. Relevante sectoren kunnen digitale infrastructuur, cloudcomputingproviders, datacenterproviders, aanbieders van content delivery network-diensten, verleners van vertrouwensdiensten, aanbieders van openbare elektronische communicatiediensten en B2B-aanbieders van ICT-dienstenbeheer omvatten, zoals managed service providers en managed security service providers. SaaS-providers moeten goed letten op hoe diensten worden geleverd, welke sectoren zij ondersteunen en of zij beheer op aanvraag en brede toegang op afstand tot schaalbare gedeelde computermiddelen mogelijk maken.

Voor fintech- en financiële dienstverleners moet DORA afzonderlijk worden geanalyseerd. DORA dekt rechtstreeks een brede reeks financiële entiteiten, waaronder kredietinstellingen, betalingsinstellingen, aanbieders van rekeninginformatiediensten, instellingen voor elektronisch geld, beleggingsondernemingen, aanbieders van cryptoactivadiensten, handelsplatformen, fondsbeheerders, verzekerings- en herverzekeringsondernemingen en aanbieders van crowdfundingdiensten. Derde aanbieders van ICT-diensten maken ook deel uit van het DORA-ecosysteem, omdat financiële entiteiten hun ICT-afhankelijkheden moeten beheren, registers van contractuele afspraken moeten bijhouden en specifieke contractuele bepalingen moeten opnemen voor ICT-diensten die kritieke of belangrijke functies ondersteunen.

NIS2 en DORA grijpen ook op elkaar in. Wanneer een sectorspecifieke EU-rechtshandeling gelijkwaardige eisen voor cyberbeveiligingsrisicobeheer of incidentmelding oplegt, zijn de overeenkomstige NIS2-bepalingen voor die gebieden mogelijk niet van toepassing op die entiteiten. DORA is het sectorspecifieke regime voor operationele weerbaarheid van financiële entiteiten. Dat maakt NIS2 niet irrelevant voor alle omliggende providers. Het betekent dat het bewijsmodel onderscheid moet maken tussen een organisatie die een financiële entiteit is en rechtstreeks onder DORA valt, een derde aanbieder van ICT-diensten die financiële entiteiten ondersteunt, een SaaS-provider binnen de reikwijdte van NIS2, of een groep met meerdere juridische entiteiten en servicelijnen.

Deze scopeanalyse hoort thuis in de ISMS-context en het register van belanghebbenden. Zonder die analyse toetst het auditplan de verkeerde zaken.

Eén audittrail, veel nalevingsvragen

Een veelgemaakte fout is het maken van afzonderlijke bewijspakketten voor ISO 27001, NIS2, DORA, GDPR, cyberverzekering en klantaudits. Die aanpak leidt tot duplicatie en tegenstrijdige antwoorden. Een betere aanpak is één bewijsmodel met meerdere invalshoeken.

In het midden staat het ISMS. Daaromheen bevinden zich vijf bewijsfamilies.

Deze structuur sluit aan op Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint. In de fase Audit, beoordeling en verbetering richt stap 25 zich op het interne-auditprogramma, stap 26 op de uitvoering van audits, stap 28 op de directiebeoordeling en stap 29 op voortdurende verbetering.

De richtlijn bij stap 25 van de Blueprint is bewust praktisch:

“Ontwikkel een schema dat aangeeft wanneer audits plaatsvinden en wat zij omvatten.”

“Gebruik de sjabloon voor het interne auditplan indien beschikbaar; dit kan een eenvoudig document of spreadsheet zijn met auditdatums, toepassingsgebied en toegewezen auditors.”

Uit Zenith Blueprint, fase Audit, beoordeling en verbetering, stap 25: Intern auditprogramma Zenith Blueprint

Dat eenvoudige auditplan wordt krachtig wanneer het risicogebaseerd is en is getagd aan NIS2-, DORA- en GDPR-verplichtingen.

ISO 27001-beheersmaatregelen die auditgereedheid verankeren

Voor auditgereedheid zijn drie ISO/IEC 27002:2022-beheersmaatregelen bijzonder belangrijk wanneer zij worden geïnterpreteerd via Zenith Controls: The Cross-Compliance Guide Zenith Controls:

• 5.4 Managementverantwoordelijkheden
• 5.35 Onafhankelijke beoordeling van informatiebeveiliging
• 5.36 Naleving van beleid, regels en normen voor informatiebeveiliging

Dit zijn geen afzonderlijke “Zenith controls”. Het zijn ISO/IEC 27002:2022-beheersmaatregelen die Zenith Controls helpt mappen, auditen en raamwerkoverschrijdend interpreteren.

Beheersmaatregel 5.4 vraagt of verantwoordelijkheden voor informatiebeveiliging zijn toegewezen en worden begrepen. Beheersmaatregel 5.35 vraagt of informatiebeveiliging onafhankelijk wordt beoordeeld. Beheersmaatregel 5.36 vraagt of de organisatie haar beleid, regels en normen naleeft.

Zenith Controls classificeert beheersmaatregel 5.35 op assurancegerichte wijze:

ISO/IEC 27002:2022-beheersmaatregel 5.35, “Onafhankelijke beoordeling van informatiebeveiliging”, wordt in Zenith Controls behandeld als “Preventief, corrigerend”, ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid via de cyberbeveiligingsconcepten “Identificeren” en “Beschermen”, met operationele capaciteit in “Assurance over informatiebeveiliging”. Zenith Controls

Dit is van belang omdat interne audit zowel preventief als corrigerend is. Interne audit voorkomt blinde vlekken door het ISMS te toetsen vóór externe beoordeling, en corrigeert beveiligingszwaktes via gedocumenteerde acties.

De bredere kruisverwijzing begint bij de eisen van NIS2 en DORA en identificeert vervolgens het ISO 27001-bewijs waarmee die eisen kunnen worden aangetoond.

Mapping van beheersmaatregelen is alleen nuttig wanneer het bewijs sterk is. Als de registratie zwak is, redt geen enkele kruisverwijzing die. Als de registratie volledig is, kan hetzelfde bewijs vragen beantwoorden in de stijl van ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 en COBIT 2019.

Beleidsbewijs dat Clarysec organisaties laat bewaren

Het beleid van Clarysec vertaalt ISMS-theorie naar verwachtingen voor bewijs.

Voor mkb-organisaties vereist Audit and Compliance Monitoring Policy-sme Beleid voor audit en toezicht op naleving voor mkb goedkeuring door de leiding en auditdiscipline:

“De algemeen directeur moet een jaarlijks auditplan goedkeuren.”

Uit Beleid voor audit en toezicht op naleving voor mkb, governancevereisten, clausule 5.1.1 Beleid voor audit en toezicht op naleving voor mkb

Het beleid stelt ook een minimumfrequentie vast:

“Interne audits of nalevingsbeoordelingen moeten ten minste jaarlijks worden uitgevoerd.”

Uit Beleid voor audit en toezicht op naleving voor mkb, governancevereisten, clausule 5.2.1

En het koppelt bevindingen aan correctie en directiebeoordeling:

“De algemeen directeur moet een plan voor corrigerende maatregelen goedkeuren en de implementatie ervan volgen.”

Uit Beleid voor audit en toezicht op naleving voor mkb, governancevereisten, clausule 5.4.2

“Auditbevindingen en statusupdates moeten worden opgenomen in het ISMS-proces voor directiebeoordeling.”

Uit Beleid voor audit en toezicht op naleving voor mkb, governancevereisten, clausule 5.4.3

Ook de bewaring van bewijs is expliciet:

“Bewijs moet ten minste twee jaar worden bewaard, of langer wanneer dit vereist is op grond van certificering of klantovereenkomsten.”

Uit Beleid voor audit en toezicht op naleving voor mkb, vereisten voor beleidsimplementatie, clausule 6.2.4

Voor grotere organisaties breidt Audit and Compliance Monitoring Policy Beleid voor audit en toezicht op naleving, in sommige Clarysec-materialen ook aangeduid als P33 Audit and Compliance Monitoring Policy, de structuur uit:

“Een risicogebaseerd auditplan moet jaarlijks worden opgesteld en goedgekeurd, rekening houdend met:”

Uit Beleid voor audit en toezicht op naleving, governancevereisten, clausule 5.2 Beleid voor audit en toezicht op naleving

“De organisatie moet een auditregister bijhouden met:”

Uit Beleid voor audit en toezicht op naleving, governancevereisten, clausule 5.4

“Interne audits moeten een gedocumenteerde procedure volgen, waaronder:”

Uit Beleid voor audit en toezicht op naleving, vereisten voor beleidsimplementatie, clausule 6.1.1

“Alle bevindingen moeten resulteren in een gedocumenteerde CAPA die omvat:”

Uit Beleid voor audit en toezicht op naleving, vereisten voor beleidsimplementatie, clausule 6.2.1

De directiebeoordeling is verankerd in Information Security Policy Informatiebeveiligingsbeleid, in sommige Clarysec-materialen ook aangeduid als P01 Informatiebeveiligingsbeleid:

“Directiebeoordelingen (conform ISO/IEC 27001 clausule 9.3) moeten ten minste jaarlijks worden uitgevoerd en moeten omvatten:”

Uit Informatiebeveiligingsbeleid, governancevereisten, clausule 5.3 Informatiebeveiligingsbeleid

Deze eisen creëren de bewijsketen die auditors verwachten: goedgekeurd plan, gedefinieerde procedure, auditregister, bevindingen, CAPA, bewaring en beoordeling door de leiding.

Het auditgereed bewijspakket opbouwen

Een auditgereed bewijspakket is geen enorme map die twee dagen vóór de audit wordt gemaakt. Het is een levende structuur die gedurende het jaar wordt onderhouden.

Het bewijspakket moet worden gemapt aan ISO/IEC 27001:2022-clausules en Annex A-beheersmaatregelen, maar worden getagd voor regelgevende relevantie. Een leveranciersauditregistratie kan bijvoorbeeld Annex A-leveranciersbeheersmaatregelen, NIS2-beveiliging van de toeleveringsketen en DORA-risicobeheer voor derde aanbieders van ICT-diensten ondersteunen. Een registratie van een tabletopoefening voor incidenten kan ISO 27001-incidentbeheer, gereedheid voor gefaseerde NIS2-melding en DORA-governance voor majeure ICT-gerelateerde incidenten ondersteunen.

De geïntegreerde interne audit uitvoeren

Stap 26 van Zenith Blueprint benadrukt objectief bewijs:

“Voer de audit uit door voor elk item op uw checklist objectief bewijs te verzamelen.”

“Interview relevant personeel.”

“Beoordeel documentatie.”

“Observeer werkwijzen.”

“Neem steekproeven en voer steekproefsgewijze controles uit.”

Uit Zenith Blueprint, fase Audit, beoordeling en verbetering, stap 26: Audituitvoering Zenith Blueprint

Dat is precies wat gereedheid voor NIS2 en DORA vereist. Toezichthouders en klanten accepteren niet “wij geloven dat dit werkt”. Zij vragen hoe u dat weet.

Een goed uitgevoerde audit toetst vier bewijsdimensies.

Neem een gesimuleerd ransomware-incident op een staging-server. De auditor toetst of het incidentresponsproces kan voldoen aan ISO 27001-eisen, verwachtingen voor gefaseerde NIS2-rapportage en DORA-klantverplichtingen.

NIS2 kent een gefaseerde rapportagestructuur voor significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur na bewustwording, een incidentmelding binnen 72 uur en een eindrapport binnen één maand na de incidentmelding. DORA heeft een eigen classificatie- en rapportagekader voor ICT-gerelateerde incidenten voor financiële entiteiten. De interne audit moet verifiëren dat draaiboeken het moment van bewustwording, ernstcriteria, getroffen diensten, indicatoren van compromittering, mitigerende maatregelen, oorzaak, klantmeldingsplichten en gegevens voor eindrapportage vastleggen.

Eén auditbevinding omzetten in NIS2- en DORA-bewijs

Een realistische leveranciersbevinding laat zien hoe bewijs moet doorstromen.

Tijdens de interne audit neemt de auditor een steekproef van vijf kritieke leveranciers. Eén cloudprovider voor logging ondersteunt fraudemonitoring en beveiligingsalerts voor het fintechplatform. De leverancier staat in de inventaris, maar er is geen gedocumenteerd exitplan, geen bewijs van een jaarlijkse beveiligingsbeoordeling en geen bevestiging dat het contract incidentondersteuning of auditrechten bevat.

De auditor registreert een non-conformiteit ten aanzien van leveranciersbeveiliging en cloud-exiteisen. Een zwakke reactie zou zijn: “leveranciersbeoordeling ontbreekt.” Een sterke reactie creëert een bewijsketen voor raamwerkoverschrijdende naleving:

1. Registreer de bevinding in het auditrapport, inclusief steekproefomvang, leveranciersnaam, contractreferentie en ontbrekend bewijs.
2. Voeg een CAPA-vermelding toe met de oorzaak, bijvoorbeeld “de checklist voor leveranciersonboarding bevatte geen criticaliteitsclassificatie of trigger voor een exitplan.”
3. Wijs de leverancierseigenaar en risico-eigenaar toe.
4. Werk het leveranciersregister bij om de dienst aan te merken als ondersteuning van een kritieke of belangrijke functie.
5. Voer een risicobeoordeling uit die dienstonderbreking, gegevenstoegang, concentratierisico, afhankelijkheid voor incidentmelding en contractuele hiaten omvat.
6. Werk het risicobehandelingsplan en de Verklaring van Toepasselijkheid bij waar relevant.
7. Verkrijg een geactualiseerd contractaddendum of een gedocumenteerde risicoacceptatie.
8. Maak of test een exitplan.
9. Audit het leveranciersbewijs opnieuw na remediatie.
10. Rapporteer de bevinding, het risico en de benodigde middelen in de directiebeoordeling.

Deze ene keten ondersteunt meerdere verplichtingen. NIS2 verwacht beveiliging van de toeleveringsketen en aandacht voor kwetsbaarheden van leveranciers, cyberbeveiligingspraktijken en procedures voor veilige ontwikkeling. DORA vereist dat financiële entiteiten ICT-risico’s van derden beheren, registers van contractuele afspraken bijhouden, providers vóór contractering beoordelen, waar passend audit- en inspectierechten opnemen, beëindigingsrechten handhaven en exitstrategieën documenteren voor ICT-diensten die kritieke of belangrijke functies ondersteunen. GDPR kan ook relevant zijn als de leverancier persoonsgegevens verwerkt.

De auditregistratie is dan niet langer alleen nalevingsbewijs. Het is bewijs voor weerbaarheid.

Directiebeoordeling: waar bewijs verantwoordingsplicht wordt

Interne audit brengt de feiten aan het licht. De directiebeoordeling beslist wat ermee gebeurt.

Stap 28 van Zenith Blueprint beschrijft het inputpakket voor de directiebeoordeling:

“ISO 27001 specificeert meerdere vereiste inputs voor de directiebeoordeling. Bereid een kort rapport of presentatie voor waarin deze punten worden behandeld.”

De Blueprint noemt de status van eerdere acties, wijzigingen in externe en interne kwesties, ISMS-prestaties en doeltreffendheid, incidenten of non-conformiteiten, verbetermogelijkheden en benodigde middelen.

Uit Zenith Blueprint, fase Audit, beoordeling en verbetering, stap 28: Directiebeoordeling Zenith Blueprint

Voor NIS2 en DORA is de directiebeoordeling de plek waar verantwoordingsplicht op bestuursniveau zichtbaar wordt. De beoordeling moet niet alleen zeggen: “beveiliging is besproken.” Zij moet laten zien dat de leiding het volgende heeft beoordeeld:

• Wijzigingen in NIS2-, DORA-, GDPR-, klant- en contractuele eisen.
• Scopewijzigingen, waaronder nieuwe landen, producten, gereguleerde klanten of ICT-afhankelijkheden.
• Resultaten van interne audits, inclusief majeure en mineure non-conformiteiten.
• Status van CAPA’s en achterstallige acties.
• Beveiligingsdoelstellingen en metrieken.
• Incidenttrends, bijna-incidenten en geleerde lessen.
• Leveranciers- en cloudconcentratierisico’s.
• Resultaten van bedrijfscontinuïteits- en back-uptests.
• Prestaties op het gebied van kwetsbaarheden en patching.
• Benodigde middelen, waaronder mensen, tooling, training en budget.
• Restrisico’s die formele acceptatie vereisen.
• Verbeterbesluiten en verantwoordelijke eigenaren.

Hier kan Maria een technisch rapport omzetten in strategische assurance. In plaats van te zeggen: “we hebben één hiaat in het incidentproces gevonden”, kan zij zeggen: “De audit heeft één mineure non-conformiteit geïdentificeerd in onze besluitcriteria voor NIS2-incidentmelding. De CAPA actualiseert de procedure, voegt een beslismatrix toe en vereist binnen 30 dagen een tabletopoefening. We hebben managementgoedkeuring nodig voor juridische toetsing en trainingstijd.”

Dat is het soort registratie dat governance, toezicht en verdedigbare besluitvorming ondersteunt.

Corrigerende maatregelen: het verschil tussen een bevinding en volwassenheid

Een interne audit zonder corrigerende maatregelen is slechts een diagnose.

Stap 29 van Zenith Blueprint instrueert organisaties om een CAPA-register te gebruiken:

“Vul het met elk issue: beschrijving van het issue, oorzaak, corrigerende maatregel, verantwoordelijke eigenaar, streefdatum voor voltooiing, status.”

Uit Zenith Blueprint, fase Audit, beoordeling en verbetering, stap 29: Voortdurende verbetering Zenith Blueprint

De stap maakt ook een belangrijk onderscheid:

“In auditterminologie: correctie verhelpt het symptoom, corrigerende maatregel verhelpt de oorzaak. Beide zijn belangrijk.”

Uit Zenith Blueprint, fase Audit, beoordeling en verbetering, stap 29: Voortdurende verbetering

Als bewijs voor back-upherstel ontbreekt, kan de correctie zijn om deze week een hersteltest uit te voeren en te documenteren. De corrigerende maatregel is het wijzigen van de back-upprocedure zodat hersteltests elk kwartaal worden gepland, automatisch als ticket worden aangemaakt, door de service-eigenaar worden beoordeeld en worden opgenomen in de metrieken voor de directiebeoordeling.

Auditors zoeken die volwassenheid. Een ISO 27001-auditor toetst conformiteit met het ISMS en de geselecteerde beheersmaatregelen. Een NIS2-beoordelaar vraagt of maatregelen voor risicobeheer doeltreffend zijn en onder toezicht staan. Een DORA-beoordelaar zoekt integratie van het ICT-risicokader, weerbaarheidstests, beheer van afhankelijkheden van derden en remediatie. Een beoordelaar voor NIST Cybersecurity Framework 2.0 kan vragen of de uitkomsten voor governance, identify, protect, detect, respond en recover operationeel zijn. Een COBIT 2019-auditor kan zich richten op governancedoelstellingen, eigenaarschap, prestatie-indicatoren en assurance.

Dezelfde CAPA-registratie kan aan deze invalshoeken voldoen als zij oorzaak, eigenaar, risico-impact, corrigerende maatregel, vervaldatum, bewijs van implementatie, beoordeling van doeltreffendheid en zichtbaarheid voor het management bevat.

De meerdere invalshoeken van de auditor

Verschillende auditors lezen hetzelfde bewijs op verschillende manieren. Zenith Controls helpt die vragen te anticiperen door te fungeren als cross-compliancegids voor ISO/IEC 27002:2022-beheersmaatregelen en gerelateerde raamwerken.

Beheersmaatregel 5.36 is een goed voorbeeld. De ISO 27001-auditor kan zich richten op de vraag of nalevingsbeoordelingen plaatsvinden en leiden tot corrigerende maatregelen. De NIS2-beoordelaar kan vragen of die beoordelingen wettelijke cyberbeveiligingsmaatregelen toetsen, niet alleen interne regels. De DORA-beoordelaar kan zich richten op de vraag of nalevingsbeoordelingen kritieke ICT-providers en contractuele afdwinging omvatten.

Daarom moet bewijs vanaf het begin voor meerdere lezers worden ontworpen.

Een praktische auditgereedheidssprint van 30 dagen

Als de CEO vraagt of de organisatie binnen 30 dagen auditgereed kan zijn, is het eerlijke antwoord: u kunt een geloofwaardige bewijsbasislijn opbouwen als de leiding de sprint ondersteunt en het toepassingsgebied realistisch is.

Deze sprint vervangt geen langetermijnvolwassenheid. Hij creëert een verdedigbare operationele basislijn. De echte waarde ontstaat wanneer de organisatie de cyclus elk kwartaal of halfjaar herhaalt, niet slechts eenmaal per jaar.

Veelvoorkomende bewijsfouten die Clarysec aantreft

Dezelfde zwaktes komen terug in audits bij SaaS-, cloud- en fintechorganisaties:

• Het auditplan bestaat, maar is niet risicogebaseerd.
• De auditchecklist toetst ISO-clausules maar negeert NIS2-, DORA-, GDPR- en klantverplichtingen.
• Notulen van directiebeoordelingen bestaan, maar tonen geen besluiten, toewijzing van middelen of risicoacceptatie.
• CAPA-registraties vermelden acties maar geen oorzaak.
• Bevindingen worden afgesloten zonder verificatie van doeltreffendheid.
• Leveranciersbeoordelingen worden uitgevoerd, maar kritieke leveranciers worden niet onderscheiden van leveranciers met een laag risico.
• Incidentdraaiboeken bestaan, maar niemand kan aantonen dat de rapportageworkflow van 24 uur of 72 uur zou werken.
• Back-upjobs zijn groen, maar hersteltests zijn niet onderbouwd met bewijs.
• Toegangsrechtenbeoordelingen worden geëxporteerd, maar uitzonderingen worden niet tot afsluiting gevolgd.
• Logboeken worden verzameld, maar niemand kan monitoring, escalatie of respons aantonen.
• Bewijs wordt opgeslagen in persoonlijke mappen in plaats van in een beheerde bewijsrepository.
• Bewaarvereisten zijn onduidelijk of inconsistent met klantcontracten.

Deze fouten zijn herstelbaar. Ze vereisen een gestructureerde ISMS-bewijsarchitectuur, geen documentenzoektocht op het laatste moment.

Hoe goed eruitziet voor het bestuur

Wanneer de CISO terugkomt bij de CEO en CFO, is het sterkste antwoord niet: “we zijn door een auditchecklist gekomen.” Het is:

“We hebben een goedgekeurd auditplan. We hebben een risicogebaseerde interne audit uitgevoerd. We hebben bevindingen geïdentificeerd met objectief bewijs. We hebben CAPA’s goedgekeurd met eigenaren en vervaldatums. We hebben materiële risico’s, incidenten, leveranciersafhankelijkheden en benodigde middelen geëscaleerd naar de directiebeoordeling. We hebben bewijs gemapt aan ISO/IEC 27001:2022, NIS2, DORA en GDPR. We kunnen de audittrail tonen.”

Dat antwoord verandert het gesprek. Het geeft de CEO vertrouwen richting klanten. Het geeft de CFO duidelijkheid over blootstelling aan regelgeving. Het geeft het bestuursorgaan een verdedigbare toezichtregistratie. Het geeft de CISO een geprioriteerde routekaart in plaats van een stapel losstaande verzoeken.

Belangrijker nog: het brengt de organisatie van nalevingstheater naar operationele weerbaarheid.

Volgende stappen met Clarysec

Uw volgende audit mag geen haastklus zijn. Het moet zichtbaar bewijs zijn dat uw ISMS werkt, de leiding betrokken is en de organisatie gereed is voor ISO 27001, NIS2, DORA, GDPR en klantassurance.

Clarysec kan u helpen om:

• Een risicogebaseerd intern auditplan op te bouwen met Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint.
• Auditbewijs te mappen via Zenith Controls: The Cross-Compliance Guide Zenith Controls.
• Auditgovernance voor mkb of grote organisaties te implementeren met Audit and Compliance Monitoring Policy-sme Beleid voor audit en toezicht op naleving voor mkb of Audit and Compliance Monitoring Policy Beleid voor audit en toezicht op naleving.
• Pakketten voor directiebeoordeling voor te bereiden die zijn afgestemd op Information Security Policy Informatiebeveiligingsbeleid en de verwachtingen van ISO/IEC 27001:2022 clausule 9.3.
• Bevindingen om te zetten in CAPA-registraties, managementbesluiten en meetbare verbetering.

Download de Clarysec-toolkits, boek een gereedheidsbeoordeling of vraag een demo aan om uw volgende interne audit om te zetten in bestuursgereed bewijs voor ISO 27001, NIS2, DORA en verder.