Continue compliancemonitoring voor NIS2 en DORA

De vrijdagmiddagvraag die elke CISO nu moet kunnen beantwoorden

Om 16:40 uur op vrijdag ontvangt de CISO van een cloudgebaseerd betaalplatform binnen tien minuten drie berichten.

Het eerste komt van de CFO: “Onze bankpartner wil bijgewerkt bewijsmateriaal dat wij voldoen aan de DORA-verwachtingen voor ICT-risico’s van derden en incidentrapportage.”

Het tweede komt van de juridisch adviseur: “Onze beheerde beveiligingsdienst kan ons onder de nationale NIS2-implementatie binnen de scope brengen. Kunnen we managementtoezicht en de doeltreffendheid van beheersmaatregelen aantonen?”

Het derde komt van het hoofd Engineering: “We hebben de kritieke kwetsbaarheid gepatcht, maar de backlog bevat 38 achterstallige bevindingen met gemiddelde ernst. Moeten we escaleren?”

Dit is het moment waarop jaarlijkse compliance tekortschiet.

Een beleids-PDF, een risicoregister dat voor het laatst vóór de vorige audit is bijgewerkt en een map met screenshots zijn niet voldoende voor NIS2 en DORA. Deze regimes verwachten levende governance, managementtoezicht, incidentworkflows, zicht op leveranciers, weerbaarheidstesten, corrigerende maatregelen en aantoonbare doeltreffendheid van beheersmaatregelen.

Voor veel CISO’s is de druk niet theoretisch. De omzetting van NIS2 in de EU-lidstaten heeft cybersecurity verschoven van een technisch programma naar een kwestie van managementverantwoordelijkheid. DORA is van toepassing vanaf 17 januari 2025 en biedt financiële entiteiten een sectorspecifiek regelgevend kader voor operationele weerbaarheid op het gebied van ICT-risico, incidentrapportage, testen en risico’s van derden. Aanbieders van cloud-, SaaS-, beheerde diensten, beheerde beveiligingsdiensten, datacenters, contentdeliverydiensten, vertrouwensdiensten en openbare elektronische communicatiediensten kunnen ook directe of indirecte verplichtingen hebben, afhankelijk van scope, omvang, sector, nationale classificatie en klantcontracten.

De praktische vraag is niet langer: “Hebben we een beheersmaatregel?”

De vraag is: “Wie is eigenaar van de beheersmaatregel, welke metriek bewijst dat deze werkt, hoe vaak verzamelen we bewijsmateriaal en wat gebeurt er als de metriek faalt?”

Dat is de kern van continue compliancemonitoring voor NIS2 en DORA. In Clarysec-implementaties gebruiken we ISO/IEC 27001:2022 als basis van het managementsysteem, ISO/IEC 27002:2022 als taal voor beheersmaatregelen, Zenith Blueprint: een 30-stappenroadmap voor auditors als implementatiereeks en Zenith Controls: de gids voor cross-compliance als kompas voor cross-compliance dat ISO/IEC 27001:2022-bewijsmateriaal verbindt met NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 en auditverwachtingen.

Waarom NIS2 en DORA periodieke compliance onvoldoende maken

NIS2 en DORA verschillen in juridische structuur, toezichtmodel en scope, maar veroorzaken dezelfde operationele druk. Cybersecurity en ICT-weerbaarheid moeten continu worden bestuurd.

NIS2 vereist dat essentiële en belangrijke entiteiten passende en evenredige technische, operationele en organisatorische maatregelen treffen op basis van een all-hazardsbenadering. Deze maatregelen omvatten risicoanalyse, beleid voor de beveiliging van informatiesystemen, incidentafhandeling, bedrijfscontinuïteit, crisisbeheer, beveiliging van de toeleveringsketen, veilige verwerving en ontwikkeling, afhandeling van kwetsbaarheden, beoordeling van doeltreffendheid, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en multifactorauthenticatie waar passend. Bestuursorganen moeten maatregelen voor cybersecurityrisicobeheer goedkeuren, toezicht houden op de implementatie en training ontvangen.

DORA maakt dit nog explicieter voor financiële entiteiten. Het vereist interne governance- en beheersingsregelingen voor ICT-risico, een gedocumenteerd kader voor ICT-risicobeheer, verantwoordelijkheid van het bestuursorgaan, beheer en rapportage van ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, beheer van ICT-risico’s van derden, opvolging van audits, training en communicatieafspraken. DORA maakt ook duidelijk dat financiële entiteiten verantwoordelijk blijven voor compliance wanneer zij gebruikmaken van ICT-dienstverleners van derden.

Dit creëert een nieuwe compliancerealiteit. Een CISO kan niet wachten tot de auditmaand om te ontdekken dat:

• toegangsrechtenbeoordelingen voor geprivilegieerde toegang twee kwartalen zijn gemist;
• exitplannen voor leveranciers zijn gedocumenteerd maar nooit getest;
• criteria voor incidenternst niet aansluiten op wettelijke meldingsdrempels;
• back-ups zijn geconfigureerd maar bewijsmateriaal voor herstel ontbreekt;
• het management achterstallige risicobehandelingen nooit heeft beoordeeld;
• cloudcontracten geen auditrechten, zicht op onderaannemers of clausules voor incidentmelding bevatten.

Het oude projectmatige model veroorzaakt paniekcycli. Teams haasten zich vlak voor een audit, verzamelen screenshots, werken beleidsdatums bij en hopen dat het bewijsmateriaal een samenhangend verhaal vertelt. NIS2 en DORA zijn ontworpen om die aanpak te laten falen. Ze richten zich op verantwoordingsplicht, proportionaliteit, weerbaarheid en bewijs van werking.

ISO/IEC 27001:2022 biedt het besturingssysteem voor dit probleem. De clausules vereisen dat organisaties context, belanghebbenden, wettelijke en contractuele eisen, scope, leiderschap, rollen, risicobeoordeling, risicobehandeling, Verklaring van Toepasselijkheid, operationele planning, prestatie-evaluatie, interne audit, directiebeoordeling, afhandeling van non-conformiteiten en voortdurende verbetering begrijpen en beheren. Die structuur is ideaal om NIS2, DORA, GDPR, assurance richting klanten en intern risico te combineren in één continu monitoringmodel.

Continue compliance betekent niet meer dashboards. Het is een beheerste cyclus voor bewijsmateriaal.

Bouw de compliancemotor op ISO/IEC 27001:2022

Veel organisaties zien ISO/IEC 27001:2022 ten onrechte alleen als certificeringskader. In de praktijk is het een risicomanagementsysteem om beveiligingsgovernance herhaalbaar, meetbaar en auditeerbaar te maken.

Dat is relevant omdat NIS2 en DORA geen geïsoleerde checklists zijn. Ze vereisen een operationeel model dat wettelijke eisen kan opnemen, vertalen naar beheersmaatregelen, eigenaarschap toewijzen, prestaties monitoren en verbeteren wanneer hiaten worden vastgesteld.

De basale ISO/IEC 27001:2022-clausules bieden dat model:

Voor een FinTech, SaaS-aanbieder, managed security service of ICT-leverancier aan financiële entiteiten voorkomt deze structuur dubbele complianceprojecten. Eén ISMS kan verplichtingen één keer aan beheersmaatregelen koppelen en vervolgens bewijsmateriaal hergebruiken voor NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, ISO/IEC 27001:2022-certificering en assurancebeoordelingen door klanten.

Begin met eigenaarschap van beheersmaatregelen, niet met tooling

Het eerste faalpatroon bij continue compliance is een implementatie die begint met tooling. Een bedrijf koopt een GRC-platform, importeert honderden eisen, wijst alles toe aan “Security” en noemt dat continue monitoring. Zes maanden later staat het dashboard op rood, betwist Engineering het bewijsmateriaal over kwetsbaarheden, zegt Legal dat leveranciersdocumenten onvolledig zijn en kan het management het restrisico niet helder zien.

ISO/IEC 27001:2022 voorkomt dit door te vereisen dat verantwoordelijkheden en bevoegdheden worden toegewezen en gecommuniceerd. NIS2 en DORA versterken dezelfde verwachting via managementverantwoordelijkheid, gedefinieerde rollen en toezicht.

Clarysec’s Beleid inzake governancerollen en -verantwoordelijkheden - SME bepaalt:

Elke rol met een beveiligingsverantwoordelijkheid moet worden vastgelegd in een centraal register en schriftelijk worden bevestigd.

Die clausule is belangrijker dan de meeste dashboards. Als back-uptesten, remediatie van kwetsbaarheden, leveranciers-due diligence, incidentclassificatie en beoordeling van geprivilegieerde toegang geen benoemde eigenaars hebben, is er geen betrouwbare bewijsmateriaalcyclus.

Het Informatiebeveiligingsbeleid maakt dit operationeel voor enterprise-omgevingen:

Verzamel en bewaar auditbewijsmateriaal voor audits en beoordelingen van beheersmaatregelen.

Het vereist ook dat eigenaars van beheersmaatregelen:

Prestaties van beheersmaatregelen en eventuele hiaten of problemen rapporteren aan de ISMS-manager.

In Zenith Controls wordt dit onderwerp direct gekoppeld aan ISO/IEC 27002:2022-beheersmaatregel 5.2 Rollen en verantwoordelijkheden voor informatiebeveiliging, 5.35 Onafhankelijke beoordeling van informatiebeveiliging en 5.36 Naleving van beleid, regels en normen voor informatiebeveiliging.

De Zenith Blueprint biedt een praktisch startpunt in de fase ISMS Foundation & Leadership, stap 4: Rollen en verantwoordelijkheden in het ISMS. Deze adviseert formele benoeming, actualisatie van functieomschrijvingen, afstemming op KPI’s, organisatiebrede communicatie en verantwoordelijkheid op afdelingsniveau.

Een typische benoemingsregistratie kan luiden:

“Met onmiddellijke ingang wordt u benoemd tot Information Security Officer, met de verantwoordelijkheid om toezicht te houden op het ISMS en de coördinatie daarvan te voeren, inclusief risicobeheer, implementatie van beheersmaatregelen en compliancemonitoring.”

Die benoeming is geen bureaucratie. Het is auditbewijsmateriaal voor leiderschap en roltoewijzing onder ISO/IEC 27001:2022. Het ondersteunt ook managementtoezicht onder NIS2 en governance onder DORA. Toezichthouders, certificeringsauditors en bancaire klanten willen zien dat verantwoordelijkheid niet impliciet is. Zij is toegewezen, bevestigd, voorzien van middelen en gemonitord.

Een praktisch register voor eigenaarschap van beheersmaatregelen moet deze velden bevatten:

Dit register wordt de brug tussen beleid en bewijs.

Definieer KPI’s en KRI’s die doeltreffendheid van beheersmaatregelen aantonen

Zodra eigenaars bestaan, moeten zij weten hoe “goed” eruitziet. Continue compliancemonitoring draait op betekenisvolle indicatoren, niet op brede intenties.

“Patching verbeteren” is geen KPI. “Leveranciers regelmatig beoordelen” is geen bewijsmateriaal. “Weerbaarheid handhaven” is geen meetbare beheersmaatregel.

Clarysec onderscheidt de twee typen indicatoren duidelijk:

• KPI, een Key Performance Indicator, meet of het proces werkt zoals verwacht.
• KRI, een Key Risk Indicator, signaleert toenemend risico of een drempeloverschrijding die escalatie vereist.

Het enterprise Beleid inzake risicobeheer bepaalt:

KRI’s (Key Risk Indicators) en beveiligingsmetrieken moeten worden gedefinieerd voor kritieke risico’s en maandelijks worden gemonitord.

Het vereist ook escalatielogica:

Escalatietriggers moeten worden opgenomen in de monitoringlogica (bijvoorbeeld wanneer het restrisico met meer dan één niveau toeneemt of termijnen voor risicobehandeling worden gemist).

Voor kleinere organisaties hanteert Clarysec’s Beleid inzake risicobeheer - SME een proportionele benadering:

De voortgang van risicobeperking moet per kwartaal worden beoordeeld.

Het staat ook lichtgewicht metrieken toe:

Informele metrieken mogen worden gevolgd (bijvoorbeeld het aantal open risico’s, achterstallige acties, nieuwe incidenten).

Die proportionaliteit is belangrijk. Een multinationale bank en een FinTech-leverancier met 60 medewerkers hebben geen identieke telemetrie nodig, maar beide hebben toegewezen eigenaarschap, herhaalbare meting, escalatiedrempels en bewijsmateriaal voor corrigerende maatregelen nodig.

Een praktisch KPI- en KRI-model voor NIS2 en DORA ziet er als volgt uit:

Deze metrieken ondersteunen meer dan ISO/IEC 27001:2022-certificering. Ze ondersteunen ook NIS2-maatregelen voor cybersecurityrisicobeheer, gereedheid voor NIS2-incidentrapportage, DORA ICT-risicobeheer, DORA-risico’s van derden, GDPR-verantwoordingsplicht, governance-uitkomsten van NIST CSF 2.0 en COBIT-achtig prestatiemanagement.

Richt een bewijsmateriaalcyclus in voordat de audit erom vraagt

Veel organisaties verzamelen bewijsmateriaal willekeurig. Een screenshot verschijnt in een Teams-kanaal. Een Jira-ticket wordt in een e-mail gelinkt. Een leveranciersvragenlijst wordt bij inkoop opgeslagen. Een back-uptest wordt mondeling beschreven. Tijdens de auditweek wordt de ISMS-manager een forensisch onderzoeker.

Continue compliance vereist een geplande cyclus en zorgvuldige omgang met bewijsmateriaal.

Clarysec’s Beleid voor audit en toezicht op naleving - SME bepaalt:

Elke audit moet een gedefinieerde scope, doelstellingen, verantwoordelijke medewerkers en vereist bewijsmateriaal omvatten.

Het bepaalt ook:

Bewijsmateriaal moet ten minste twee jaar worden bewaard, of langer wanneer certificering of klantovereenkomsten dit vereisen.

Voor enterprise-organisaties voegt het Beleid voor audit en toezicht op naleving automatiseringsverwachtingen toe:

Geautomatiseerde tools moeten worden ingezet om naleving van configuratie, kwetsbaarhedenbeheer, patchstatus en geprivilegieerde toegang te monitoren.

Automatisering moet gericht worden toegepast. Beheersmaatregelen met hoog risico en hoge frequentie mogen niet afhankelijk zijn van handmatige screenshots. Het beste model voor bewijsmateriaal combineert geautomatiseerde telemetrie, attestaties door eigenaars, registraties van uitzonderingen, ticketregistraties, testresultaten en notulen van directiebeoordelingen.

Een naamgevingsconventie is eveneens belangrijk. Bewijsmateriaal moet zonder buitengewone inspanning terug te vinden zijn. Bijvoorbeeld:

• wekelijks kwetsbaarhedenrapport: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• maandelijkse beoordeling van geprivilegieerde toegang: YYYY-MM_IAM-Privileged-Review_Attestation
• kwartaalbeoordeling van leveranciers: YYYY-QX_Critical-Supplier-Review
• incidentpakket: INC-YYYY-###_Timeline-Classification-RCA-CAPA

Hier wordt beleid operationeel. Bewaring van bewijsmateriaal is geen archieftaak. Het is onderdeel van de beheersmaatregel.

Koppel één bewijsmateriaalitem aan meerdere verplichtingen

Continue compliance wordt krachtig wanneer één bewijsmateriaalitem aan meerdere raamwerken voldoet. Daarom staat Zenith Controls centraal in Clarysec’s aanpak voor cross-compliance.

Neem incidentafhandeling. Onder NIS2 vereisen significante incidenten gefaseerde rapportage, waaronder een vroege waarschuwing binnen 24 uur na bewustwording, een melding binnen 72 uur en een eindrapportage binnen één maand, afhankelijk van nationale implementatie en de incidentfeiten. DORA vereist dat financiële entiteiten grote ICT-gerelateerde incidenten beheren, classificeren, escaleren en rapporteren met voorgeschreven processen en sjablonen. GDPR vereist dat verwerkingsverantwoordelijken datalekken beoordelen en beheren wanneer de vertrouwelijkheid, integriteit of beschikbaarheid van persoonsgegevens wordt geraakt.

Eén incidentbewijspakket kan alle drie ondersteunen als het het volgende bevat:

• incidenttijdlijn en tijdstip van bewustwording;
• classificatiemotivering;
• getroffen diensten en jurisdicties;
• impact op klanten, transacties of gebruikers;
• impactbeoordeling van persoonsgegevens;
• oorzaakanalyse;
• mitigerende maatregelen en herstelacties;
• communicatie en meldingen;
• registratie van managementescalatie;
• vermelding van corrigerende maatregel.

Dezelfde cross-compliancelogica geldt voor leveranciersrisico. NIS2 vereist beveiliging van de toeleveringsketen en aandacht voor directe relaties met leveranciers en dienstverleners. DORA vereist een strategie voor ICT-risico’s van derden, registers, precontractuele due diligence, contractuele clausules, auditrechten, serviceniveaus, exitstrategieën en monitoring van concentratierisico. NIST CSF 2.0 behandelt risico’s in de toeleveringsketen als een governancediscipline gedurende de levenscyclus. ISO/IEC 27001:2022 verbindt deze vereisten met scope, eisen van belanghebbenden, risicobehandeling en operationele beheersing van extern geleverde processen.

Een praktische bewijsmateriaalmatrix helpt eigenaars van beheersmaatregelen begrijpen waarom bewijsmateriaal belangrijk is:

Deze aanpak voorkomt dubbel compliancewerk. De organisatie verzamelt één sterke set bewijsmateriaal en koppelt die vervolgens aan meerdere verplichtingen.

Het Clarysec-monitoringmodel, van verplichting naar eigenaar naar bewijs

Een robuust monitoringmodel volgt een eenvoudige volgorde.

Ten eerste: definieer de verplichting. DORA vereist bijvoorbeeld dat ICT-risico’s van derden worden beheerd als onderdeel van ICT-risicobeheer, met registers, due diligence, contractuele eisen, auditrechten en exitstrategieën voor kritieke of belangrijke functies. NIS2 vereist beveiliging van de toeleveringsketen en passende corrigerende maatregelen.

Ten tweede: vertaal de verplichting naar ISO/IEC 27001:2022 ISMS-eisen. Dit omvat eisen van belanghebbenden, scope, risicobeoordeling, risicobehandeling, Verklaring van Toepasselijkheid, operationele beheersing, monitoring, interne audit, directiebeoordeling en verbetering.

Ten derde: selecteer operationele beheersmaatregelen. In Zenith Controls omvatten de kernbeheersmaatregelen voor governance bij continue compliance ISO/IEC 27002:2022-beheersmaatregelen 5.2, 5.35 en 5.36. Ondersteunende beheersmaatregelen omvatten vaak 5.19 Informatiebeveiliging in leveranciersrelaties, 5.21 Beheer van informatiebeveiliging in de ICT-toeleveringsketen, 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten, 5.23 Informatiebeveiliging voor het gebruik van clouddiensten, 5.24 Planning en voorbereiding van informatiebeveiligingsincidentbeheer, 5.26 Respons op informatiebeveiligingsincidenten, 5.30 ICT-gereedheid voor bedrijfscontinuïteit, 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen, 8.8 Beheer van technische kwetsbaarheden, 8.13 Informatieback-up, 8.15 Logging, 8.16 Monitoringactiviteiten en 8.9 Configuratiebeheer.

Ten vierde: wijs de eigenaar en cyclus toe. Leveranciersrisico kan Inkoop, Legal, Security en de eigenaar van de bedrijfsdienst omvatten, maar één verantwoordelijke eigenaar moet het register onderhouden en uitzonderingen rapporteren.

Ten vijfde: definieer KPI’s, KRI’s en bewijsmateriaal. Leveranciers-KPI’s kunnen het percentage kritieke ICT-leveranciers met afgeronde due diligence omvatten, het percentage met goedgekeurde contractclausules, het aantal zonder geteste exitplannen en het aantal achterstallige leveranciersbeoordelingen. KRI’s kunnen bestaan uit onopgeloste leveranciersbevindingen met hoog risico, concentratierisico boven tolerantie of ontbrekende auditrechten voor een dienst die een kritieke of belangrijke functie ondersteunt.

Ten zesde: rapporteer en escaleer. Maandelijkse ISMS-dashboards mogen niet alleen een groene status tonen. Ze moeten achterstallig bewijsmateriaal, risicobeweging, gemiste termijnen voor risicobehandeling en vereiste managementbesluiten identificeren.

Ten zevende: audit en verbeter. Hiaten in bewijsmateriaal worden corrigerende maatregelen, geen excuses.

Dit sluit aan op de fase Audit, Review & Improvement van de Zenith Blueprint. Stap 25, Intern auditprogramma, adviseert relevante ISMS-processen en beheersmaatregelen gedurende de auditcyclus af te dekken, met een jaarlijkse audit over de volledige scope en kleinere kwartaalgewijze steekproeven voor hoogrisicogebieden waar passend. Stap 28, Directiebeoordeling, vraagt om input zoals wijzigingen in eisen, monitoring- en meetresultaten, auditresultaten, incidenten, non-conformiteiten, verbetermogelijkheden en middelenbehoeften. Stap 29, Voortdurende verbetering, gebruikt het CAPA-logboek om omschrijving van de kwestie, oorzaak, corrigerende maatregel, verantwoordelijke eigenaar, streefdatum en status vast te leggen.

Dat is continue compliance in de praktijk.

Een praktisch scenario: kritieke kwetsbaarheid op een publieke API

Om 02:15 uur gaat een SIEM-waarschuwing af. Een kwetsbaarheidsscan heeft een kritieke kwetsbaarheid voor remote code execution vastgesteld op een publiek toegankelijke API-gateway die een gereguleerde betaaldienst ondersteunt.

Het continue monitoringmodel moet reageren zonder op overleg te wachten.

Ten eerste classificeert de inventaris van bedrijfsmiddelen de gateway als kritiek. De KPI-klok voor kwetsbaarhedenbeheer start. De KRI voor ongepatchte kritieke kwetsbaarheden loopt op. Als het bedrijfsmiddel vanaf internet bereikbaar is en de exploit actief is, wordt de escalatiedrempel onmiddellijk geactiveerd.

Ten tweede wordt het ticket gerouteerd naar het dienstdoende DevOps-team. Het hoofd DevOps ontvangt als eigenaar van de beheersmaatregel voor kwetsbaarhedenbeheer een geautomatiseerde melding. De SOC-manager volgt of er indicatoren van exploitatie bestaan. De ISMS-manager monitort of aan incidentcriteria wordt voldaan.

Ten derde wordt bewijsmateriaal als bijproduct van de workflow verzameld. De SIEM-waarschuwing, kwetsbaarheidsscan, classificatie van het bedrijfsmiddel, ticket-tijdstempels, responschat, patchregistratie, validatiescan en sluitingsgoedkeuring worden aan het bewijspakket toegevoegd.

Ten vierde beoordeelt het team of de gebeurtenis alleen een kwetsbaarheid, een beveiligingsgebeurtenis of een incident is. Als er impact op dienstverlening, indicatoren van compromittering, klantimpact of blootstelling van persoonsgegevens bestaat, activeert de incidentworkflow de beoordelingen voor NIS2-, DORA-, GDPR- en contractuele rapportage.

Ten vijfde ontvangt het management een beknopt rapport. Als de kwetsbaarheid binnen vier uur is verholpen, ondersteunt het bewijsmateriaal de doeltreffendheid van de beheersmaatregel. Als de SLA is gemist, registreert het CAPA-logboek oorzaak, corrigerende maatregel, eigenaar, streefdatum en status.

Deze ene gebeurtenis genereert bruikbaar bewijsmateriaal voor kwetsbaarhedenbeheer, incidentgereedheid, monitoring, toegang tot kritieke bedrijfsmiddelen, directiebeoordeling en voortdurende verbetering.

Hoe auditors en toezichthouders hetzelfde monitoringmodel zullen toetsen

Een volwassen programma voor continue compliance moet verschillende auditlenzen kunnen doorstaan. Het bewijsmateriaal verandert niet, maar de vragen wel.

Voor ISO/IEC 27002:2022-beheersmaatregel 5.35 Onafhankelijke beoordeling van informatiebeveiliging zal een ISO/IEC 27001:2022-auditor zich richten op het interne auditplan, de scope, competentie, bevindingen en corrigerende maatregelen. Een NIS2- of DORA-toezichthouder zal zich richten op de vraag of het management de bevindingen heeft begrepen, remediatie heeft gefinancierd en systemisch risico heeft verminderd. Een NIST CSF 2.0-beoordelaar kan de beoordeling koppelen aan de GOVERN-functie, inclusief toezicht en prestatiebijsturing.

Dezelfde set bewijsmateriaal bedient al deze partijen als deze volledig, actueel en gekoppeld is aan eigenaarschap.

Veelvoorkomende valkuilen die continue compliance verzwakken

De eerste valkuil is NIS2 en DORA behandelen als afzonderlijke projecten. Dat leidt tot dubbele registers, conflicterende metrieken en overbelaste eigenaars van beheersmaatregelen. Gebruik ISO/IEC 27001:2022 als ISMS-basis en map verplichtingen via één beheersmaatregelenbibliotheek.

De tweede valkuil is beheersmaatregelen toewijzen aan teams in plaats van aan personen. “IT is eigenaar van back-ups” is niet voldoende. Een benoemde eigenaar moet attesteren, uitzonderingen rapporteren en risico escaleren.

De derde valkuil is bewijsmateriaal verzamelen zonder doeltreffendheid te evalueren. Een screenshot van een succesvolle back-up bewijst geen herstelbaarheid. Een hersteltest doet dat wel. Een leveranciersvragenlijst bewijst geen weerbaarheid van derden. Contractuele clausules, auditrechten, voorwaarden voor incidentmelding, prestatierapportages en exitplanning vormen sterker bewijsmateriaal.

De vierde valkuil is activiteit meten in plaats van risico. Kwetsbaarheden tellen is nuttig. Achterstallige kritieke kwetsbaarheden op systemen die vanaf internet bereikbaar zijn volgen is beter. Leveranciers tellen is nuttig. Kritieke leveranciers zonder exitplannen volgen is beter.

De vijfde valkuil is zwakke discipline rond corrigerende maatregelen. Stap 29 van de Zenith Blueprint is duidelijk: bevindingen vereisen een omschrijving van de kwestie, oorzaak, corrigerende maatregel, verantwoordelijke eigenaar, streefdatum en status. Als het CAPA-logboek niet wordt beoordeeld, wordt continue compliance een voortdurende opstapeling van bekende zwaktes.

Wat het management elke maand moet zien

Bestuursorganen onder NIS2 en DORA hebben geen ruwe scannerexports nodig. Zij hebben een besluitvormingsgericht beeld van cyber- en ICT-risico nodig.

Een maandelijks bestuurs- of managementdashboard moet het volgende bevatten:

• belangrijkste cyber- en ICT-risico’s met beweging in restrisico;
• achterstallige risicobehandelingen en gemiste termijnen;
• significante incidenten, kandidaten voor grote ICT-gerelateerde incidenten en geleerde lessen;
• uitzonderingen op kritieke leveranciersrisico’s;
• SLA-prestaties voor kwetsbaarheden op kritieke bedrijfsmiddelen;
• status van back-up- en hersteltests;
• uitzonderingen bij beoordeling van geprivilegieerde toegang;
• voltooiingsgraad van compliancebewijsmateriaal;
• auditbevindingen en CAPA-status;
• vereiste besluiten over middelen.

Dit ondersteunt direct de ISO/IEC 27001:2022-directiebeoordeling en de governanceverwachtingen van NIS2 en DORA. Het sluit ook aan op NIST CSF 2.0, waarin leidinggevenden prioriteiten, verantwoordingsplicht, middelen en risicobereidheid vaststellen, terwijl managers die prioriteiten vertalen naar doelprofielen en actieplannen.

Bouw deze week uw NIS2- en DORA-bewijsmateriaalritme op

U hoeft niet alles tegelijk aan te pakken om te starten. Een nuttige eerste week kan eenvoudig zijn.

Dag 1: maak een register van eigenaars van beheersmaatregelen voor vijf domeinen: governance en risicobeheer, incidentbeheer en rapportage, kwetsbaarheden- en patchbeheer, leveranciers- en cloudrisico, en bedrijfscontinuïteit en herstel.

Dag 2: definieer één KPI en één KRI voor elk domein. Houd ze specifiek, meetbaar en gekoppeld aan de risicobereidheid.

Dag 3: koppel elk bewijsmateriaalitem aan waarde voor NIS2, DORA, ISO/IEC 27001:2022, GDPR en assurance richting klanten.

Dag 4: stel bewijsmateriaalcyclus, opslaglocatie, naamgevingsconventie, bewaartermijnregel en beoordelaar vast.

Dag 5: voer een tabletop-oefening voor escalatie uit. Gebruik een scenario met uitval van een clouddienst of een kritieke kwetsbaarheid. Bevestig classificatie, beoordeling van wettelijke rapportageverplichtingen, klantcommunicatie, opslag van bewijsmateriaal en CAPA-aanmaak.

Als uw organisatie NIS2 en DORA nog steeds beheert via spreadsheets, jaarlijkse workshops en verspreide bewijsmateriaalmappen, is dit het moment om over te stappen naar een gemonitord operationeel ritme.

Begin met drie acties:

1. Bouw een register van eigenaars van beheersmaatregelen voor uw domeinen met het hoogste risico.
2. Definieer per beheersmaatregel één KPI, één KRI, één bewijsmateriaalitem en één cyclus.
3. Voer een beoordeling van bewijsmateriaal van 30 minuten uit en open CAPA-items voor alles wat ontbreekt.

Clarysec kan u helpen deze overstap te versnellen met de Zenith Blueprint voor implementatievolgorde, Zenith Controls voor cross-compliancemapping en Clarysec’s beleidsbibliotheek, waaronder het Informatiebeveiligingsbeleid, Beleid inzake risicobeheer, Beleid voor audit en toezicht op naleving, Beleid inzake governancerollen en -verantwoordelijkheden - SME, Beleid inzake risicobeheer - SME en Beleid voor audit en toezicht op naleving - SME.

Het doel is niet meer compliancepapierwerk. Het doel is de vrijdagmiddagvraag met vertrouwen te kunnen beantwoorden:

“Ja, we weten wie eigenaar is van de beheersmaatregel, we kennen de KPI, we hebben het bewijsmateriaal, we kennen de uitzonderingen en het management heeft het risico beoordeeld.”

Neem contact op met Clarysec om een model voor continue compliancemonitoring te bouwen dat auditgereed, bestuursgeschikt en weerbaar genoeg is voor NIS2, DORA en de volgende regelgeving die volgt.