DORA-incidentrapportage en ISO 27001-beheersmaatregelen in 2026

Het is 08:17 op een dinsdagochtend in 2026. Sarah, de CISO van een Europese fintech, ziet een dashboard oranje knipperen, niet rood. Een kritisch platform voor betalingsafwikkeling wordt trager. Transacties vallen niet volledig uit, maar duren drie keer langer dan de servicelevelagreement (SLA) toestaat. Het SOC ziet ongebruikelijke authenticatiepogingen op een beheerdersaccount. De cloudinfrastructuurprovider meldt verminderde dienstverlening in één beschikbaarheidszone. De klantenservice ontvangt telefoontjes van zakelijke klanten die vragen waarom betalingsbestanden zijn vertraagd.

Niemand weet op dat moment of dit een cyberaanval, een falen van operationele weerbaarheid, een leveranciersstoring, een privacy-incident of alles tegelijk is.

Sarah heeft een DORA-probleem voordat de technische feiten volledig duidelijk zijn. Is dit een ernstig ICT-gerelateerd incident? Raakt het een kritieke of belangrijke functie? Is de interne ernstclassificatie overschreden? Wie moet worden geïnformeerd, wanneer en met welk bewijsmateriaal? Als persoonsgegevens betrokken zijn, is de GDPR-meldingstermijn dan ook gaan lopen? Als een derde ICT-aanbieder onderdeel is van de incidentketen, wie is dan eigenaar van de feiten?

Dit is het moment waarop financiële entiteiten het verschil ontdekken tussen het hebben van een incidentresponsplan (IRP) en het beschikken over een auditeerbaar operationeel model voor DORA-incidentrapportage.

DORA-incidentrapportage in 2026 vereist meer dan snelle escalatie. Zij vereist een verdedigbare keten van detectie naar classificatie, van classificatie naar rapportage aan toezichthouders, van rapportage naar herstelmaatregelen en van herstelmaatregelen naar geleerde lessen. ISO/IEC 27001:2022 biedt de managementsysteemstructuur. ISO/IEC 27002:2022-beheersmaatregelen bieden de praktische verwachtingen voor beheersmaatregelen. De beleidsdocumenten, 30-stappenroadmap en cross-compliancegids van Clarysec zetten die verwachtingen om in een implementatie die bewijsvoering ondersteunt.

Waarom DORA-incidentrapportage onder druk faalt

De meeste tekortkomingen in DORA-incidentrapportage beginnen niet met nalatigheid. Ze beginnen met ambiguïteit.

Een beveiligingsanalist ziet een alert, maar weet niet of deze kwalificeert als een ICT-gerelateerd incident onder DORA. De IT-servicemanager behandelt verminderde prestaties als een technisch serviceprobleem, terwijl Compliance dit als een regelgevende gebeurtenis beschouwt. Juridische Zaken wacht op bevestiging voordat wordt geëscaleerd. De proceseigenaar kan de klantimpact nog niet kwantificeren. De CISO wil bewijsmateriaal, maar de relevante logboeken zijn verspreid over cloudservices, endpoints, identiteitssystemen, de SIEM en leveranciersplatforms.

Tegen de tijd dat de organisatie overeenstemming bereikt over de classificatie, staat het rapportagevenster al onder druk.

DORA artikelen 17 tot en met 21 scheppen een gestructureerde verwachting voor het beheer, de classificatie, de rapportage, de inhoud van rapportages en de toezichthoudende behandeling van ICT-gerelateerde incidenten. Voor financiële entiteiten is de praktische eis duidelijk: ICT-gerelateerde incidenten zodanig monitoren, beheren, loggen, classificeren, rapporteren, actualiseren en ervan leren dat het verloop later kan worden gereconstrueerd.

Het Incidentresponsbeleid [IRP] van Clarysec verankert DORA rechtstreeks in het referentiekader:

EU DORA (2022/2554): artikel 17: vereisten voor rapportage van ICT-incidenten door financiële instellingen aan bevoegde autoriteiten.

Hetzelfde beleid koppelt incidentbeheer aan ISO/IEC 27002:2022-beheersmaatregelen 5.25 tot en met 5.27, met verantwoordelijkheden voor incidentbeoordeling, respons, communicatie en verbetering.

Voor kleinere financiële technologiebedrijven en slanke gereguleerde entiteiten maakt het Incidentresponsbeleid - mkb [IRP-SME] van Clarysec de verplichting praktisch door te benadrukken dat DORA financiële entiteiten verplicht ICT-gerelateerde incidenten en verstoringen te classificeren, te rapporteren en op te volgen.

Die formulering is belangrijk. DORA-naleving is niet alleen een rapportagesjabloon. De organisatie moet classificeren, rapporteren en opvolgen. Dat vereist bewijsmateriaal van de initiële gebeurtenis, besluitvormingscriteria, ernstniveau, rapportagebesluit, communicatie, herstelactiviteiten, betrokkenheid van leveranciers en opvolging.

ISO/IEC 27001:2022 als commandocentrum voor DORA-incidenten

Een volwassen ISO/IEC 27001:2022-managementsysteem voor informatiebeveiliging (ISMS) mag geen afzonderlijke compliancesilo naast DORA worden. Het moet het commandocentrum worden voor DORA-incidentrapportage.

Het ISMS vereist al risico-eigenaarschap, selectie van beheersmaatregelen, interne audit, directiebeoordeling, gedocumenteerde informatie, continue verbetering en bewijs van de werking van beheersmaatregelen. DORA voegt sectorspecifieke rapportagedruk toe, maar ISO/IEC 27001:2022 biedt de governancestructuur om het proces herhaalbaar te maken.

De Zenith Blueprint: een 30-stappenroadmap voor auditors [ZB] van Clarysec versterkt deze integratie in stap 13, risicobehandelingsplanning en Verklaring van Toepasselijkheid. De Blueprint beveelt aan beheersmaatregelen te koppelen aan risico’s en clausules voor traceerbaarheid, inclusief het toevoegen van een Bijlage A-beheersmaatregelreferentie aan risico’s en het vastleggen wanneer beheersmaatregelen GDPR, NIS2 of DORA ondersteunen.

Voor Sarahs incident rond betalingsafwikkeling zou de vermelding in het risicoregister kunnen zijn:

“Verstoring of compromittering van het platform voor betalingsverwerking.”

De gekoppelde ISO/IEC 27001:2022 Bijlage A-beheersmaatregelen zouden 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 en 8.16 omvatten, met een DORA-notitie voor classificatie en rapportage van ernstige ICT-gerelateerde incidenten.

De Zenith Controls: de cross-compliancegids [ZC] van Clarysec fungeert vervolgens als kompas voor cross-compliance. In Zenith Controls koppelt Clarysec ISO/IEC 27002:2022-beheersmaatregelen aan andere ISO/IEC 27001:2022-beheersmaatregelen, gerelateerde normen, auditverwachtingen en regelgeving zoals DORA, GDPR en NIS2. Het creëert geen afzonderlijke “Zenith Controls”. Het laat zien hoe de bestaande ISO-beheersmaatregelen samenwerken en hoe zij worden getoetst.

De DORA-rapportageworkflow kan worden gezien als een keten van beheersmaatregelen:

U kunt niet rapporteren wat u niet hebt gedetecteerd. U kunt niet classificeren wat u niet hebt beoordeeld. U kunt een rapportagebesluit niet onderbouwen zonder registraties. U kunt niet verbeteren zonder een post-incident evaluatie.

Beheersmaatregel 6.8: de DORA-klok begint bij mensen

In Sarahs scenario komt het eerste bruikbare signaal mogelijk niet van het SOC. Het kan afkomstig zijn van een relatiemanager die klachten van klanten hoort, een financiële gebruiker die mislukte afwikkelingsbatches ziet, of een engineer die afwijkende latency opmerkt.

Daarom is ISO/IEC 27001:2022 Bijlage A-beheersmaatregel 6.8, Melding van informatiebeveiligingsgebeurtenissen, essentieel voor DORA. Deze beheersmaatregel maakt melding een verantwoordelijkheid van de volledige workforce, niet alleen van de security operations-functie.

In de Zenith Blueprint, stap 16, personele maatregelen II, stelt Clarysec:

Een doeltreffend incidentresponssysteem begint niet met tools, maar met mensen.

Stap 16 beveelt duidelijke meldkanalen, bewustwordingstraining, een blame-free cultuur, triage, vertrouwelijkheid en periodieke simulaties aan. De nuttigste praktische boodschap is eenvoudig:

“Bij twijfel: melden.”

Dat is een DORA-beheersingsprincipe. Als medewerkers wachten tot zij zeker zijn, verliest de organisatie tijd. Als zij vroeg melden, kan de organisatie beoordelen, classificeren en besluiten.

In Zenith Controls wordt 6.8 gekoppeld als detectieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. De beheersmaatregel is verbonden met 5.24 omdat meldkanalen onderdeel moeten zijn van het incidentplan. Zij voedt 5.25 omdat gebeurtenissen alleen kunnen worden beoordeeld als ze zijn gemeld. Zij activeert 5.26 omdat formele respons start nadat meldingen zijn geëvalueerd.

Voor DORA ondersteunt dit artikelen 17 en 18, waar financiële entiteiten ernstige ICT-gerelateerde incidenten en significante cyberdreigingen moeten beheren, classificeren en rapporteren. Het ondersteunt ook GDPR artikel 33 en overweging 85, omdat interne melding bepaalt hoe snel een inbreuk in verband met persoonsgegevens wordt geïdentificeerd en geëscaleerd.

Een praktische Clarysec-implementatie is een instructieblad van één pagina: “Hoe meld ik een ICT-incident”. Dit moet bevatten:

• Wat moet worden gemeld, waaronder uitval, verdachte e-mails, verloren apparaten, ongebruikelijk systeemgedrag, vermoedelijke leverancierscompromittering, ongeautoriseerde toegang, datalekken en serviceverslechtering met klantimpact.
• Hoe moet worden gemeld, via een bewaakte mailbox, ticketcategorie, hotline, samenwerkingskanaal of SOC-portaal.
• Wat moet worden opgenomen, zoals tijdstip, systeem, gebruiker, bedrijfsproces, waargenomen impact, schermopnamen indien veilig, en of klanten of persoonsgegevens mogelijk zijn geraakt.
• Wat niet moet worden gedaan, waaronder geen logboeken verwijderen, kritieke systemen niet herstarten tenzij daartoe geïnstrueerd, geen extern klantcontact zonder goedkeuring en geen onderzoek buiten de eigen rol.
• Wat daarna gebeurt, waaronder triage, classificatie, escalatie, respons, bewaring van bewijsmateriaal en mogelijke regelgevende beoordeling.

Het doel is niet om iedere medewerker tot onderzoeker te maken. Het doel is iedere medewerker tot een betrouwbare signaalbron te maken.

Beheersmaatregel 5.25: het DORA-besluitpunt voor classificatie

De melding van ernstige ICT-gerelateerde incidenten onder DORA staat of valt met classificatie. Hier wordt ISO/IEC 27001:2022 Bijlage A-beheersmaatregel 5.25, Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, centraal.

De Zenith Blueprint, stap 23, beschrijft de praktische uitdaging:

Niet iedere anomalie is een ramp. Niet iedere waarschuwing wijst op compromittering.

Vervolgens beschrijft zij het doel van 5.25 als:

het onderscheiden van onschadelijke en schadelijke gebeurtenissen, en weten wat escalatie vereist.

Voor DORA is dit het moment waarop een beveiligingsgebeurtenis, serviceverslechtering, leveranciersstoring, gegevensblootstelling of operationele verstoring wordt beoordeeld aan de hand van criteria voor ernstige incidenten. De organisatie moet de operationele impact, getroffen diensten, kritieke of belangrijke functies, getroffen klanten en transacties, duur, geografische spreiding, gegevensimpact, reputatiegevolgen en economische impact in aanmerking nemen.

In Zenith Controls wordt 5.25 rechtstreeks gekoppeld aan DORA artikel 18, classificatie van ernstige ICT-incidenten. Het is het gestructureerde evaluatieproces om te bepalen of een waargenomen gebeurtenis kwalificeert als een beveiligingsincident. Het is ook verbonden met 8.16, Monitoringactiviteiten, omdat waarschuwingen en loggegevens moeten worden getriageerd, en met 5.26, omdat classificatie de respons activeert.

Hier falen veel organisaties bij audits. Ze hebben tickets, maar geen classificatieregistraties. Ze hebben ernstlabels, maar geen criteria. Ze hebben rapportages aan toezichthouders, maar geen besluitvormingstrail die aantoont waarom een incident wel of niet als ernstig is beschouwd.

Clarysec ondervangt dit door DORA-classificatie op te nemen in het model voor incidenternst. In het enterprise-Incidentresponsbeleid bevat clausule 5.3.1 een helder Tier 1-voorbeeld:

Tier 1: Kritiek (bijv. bevestigd datalek, ransomware-uitbraak, compromittering van productiesystemen)

Voor kleinere organisaties voegt het Incidentresponsbeleid - mkb een scherpe operationele verwachting toe:

De algemeen directeur moet, met input van de IT-dienstverlener, alle incidenten binnen één uur na kennisgeving classificeren naar ernst.

Die classificatiedoelstelling van één uur is krachtig omdat zij governancediscipline afdwingt. Een kleinere gereguleerde entiteit heeft mogelijk geen 24/7 SOC, maar kan wel definiëren wie classificeert, wie adviseert en hoe snel het besluit moet worden genomen.

Een DORA-naar-ISO-incidenttriageregistratie

Maak, om de classificatie verdedigbaar te maken, een DORA-incidenttriageregistratie in uw ticketing-, GRC- of incidentbeheersysteem. De registratie moet worden aangemaakt voor elke mogelijk materiële ICT-gebeurtenis, ook als deze later wordt afgewaardeerd.

Voeg een besluitvormingsnotitie toe:

“Op basis van een verstoring van de betalingsdienst die een kritisch bedrijfsproces raakt, een nog onbekende oorzaak en potentiële klantimpact wordt de gebeurtenis geëscaleerd als potentieel ernstig ICT-gerelateerd incident. Compliance en Juridische Zaken beoordelen de vereisten voor meldingen aan toezichthouders. Bewaring van bewijsmateriaal is gestart.”

Deze ene registratie ondersteunt opvolging onder DORA artikel 17, classificatie onder artikel 18, rapportagebesluiten onder artikel 19, ISO/IEC 27001:2022 Bijlage A 5.25-beoordeling, 6.8-melding, 5.26-respons en 5.28-bewijsbehandeling.

Beheersmaatregelen 5.24 en 5.26: planning, rollen en respons

Wanneer een DORA-incident plaatsvindt, moet het responsplan al antwoord geven op ongemakkelijke vragen.

Wie heeft de bevoegdheid om te classificeren? Wie neemt contact op met de bevoegde autoriteit? Wie keurt de initiële melding goed? Wie communiceert met klanten? Wie neemt contact op met de derde ICT-aanbieder? Wie beslist of het incident ook een GDPR-melding activeert? Wie bewaart bewijsmateriaal? Wie is eigenaar van het eindrapport?

ISO/IEC 27001:2022 Bijlage A-beheersmaatregel 5.24, Planning en voorbereiding van informatiebeveiligingsincidentbeheer, beantwoordt deze vragen vóór de crisis. Beheersmaatregel 5.26, Respons op informatiebeveiligingsincidenten, zorgt ervoor dat het plan tijdens het incident wordt omgezet in gecontroleerde actie.

In Zenith Controls is 5.24 gekoppeld aan DORA artikelen 17 tot en met 21 omdat het gedocumenteerde, geteste en beoordeelde incidentrespons operationaliseert, inclusief interne escalatie, externe rapportage aan toezichthouders, communicatie met stakeholders en geleerde lessen.

ISO/IEC 27035-1:2023 ondersteunt dit door incidentbeheer uit te breiden voorbij responsprocedures naar beleid, planning, capabilities, relaties, ondersteuningsmechanismen, bewustwording, training en regelmatige tests. ISO/IEC 27035-2:2023 werkt het incidentbeheerproces verder uit van voorbereiding tot en met geleerde lessen.

De Zenith Blueprint, stap 23, geeft een directe implementatie-instructie:

Zorg voor een actueel incidentresponsplan (5.24), dat voorbereiding, escalatie, respons en communicatie omvat.

Een DORA-gereed incidentresponsplan moet definiëren:

• Het ICT-incidentresponsteam en plaatsvervangers.
• Bevoegdheid voor ernstclassificatie en escalatie van DORA-rapportage.
• Verantwoordelijkheden van Juridische Zaken, Compliance, Privacy, Communicatie, IT, Security, leveranciers en proceseigenaren.
• Criteria voor classificatie van ernstige ICT-gerelateerde incidenten.
• Procedures voor initiële, tussentijdse en finale rapportage aan toezichthouders.
• Beoordeling van meldtriggers voor GDPR, NIS2, contracten, cyberverzekering en bestuur.
• Stappen voor indamming, verwijdering, herstel en validatie.
• Vereisten voor bewaring van bewijsmateriaal.
• Procedures voor leveranciersescalatie en toegang tot logboeken.
• Opvolging van geleerde lessen en corrigerende maatregelen.

Het Incidentresponsbeleid - mkb koppelt responstermijnen ook aan wettelijke vereisten:

Responstermijnen, waaronder gegevensherstel en meldingsverplichtingen, moeten worden gedocumenteerd en afgestemd op wettelijke vereisten, zoals de GDPR-vereiste om een inbreuk in verband met persoonsgegevens binnen 72 uur te melden.

Dit is essentieel omdat één ICT-incident kan uitgroeien tot een ernstig DORA-incident, een GDPR-inbreuk in verband met persoonsgegevens, een significant NIS2-incident, een contractuele klantmelding en een leveranciersmanagementkwestie. Het plan moet deze lagen coördineren in plaats van ze als gescheiden werelden te behandelen.

Beheersmaatregelen 8.15 en 8.16: logboeken maken het rapport verdedigbaar

DORA-incidentrapportage is afhankelijk van feiten. Feiten zijn afhankelijk van logging en monitoring.

In het scenario rond betalingsafwikkeling moet Sarah weten wanneer de verslechtering begon, welke systemen waren getroffen, of geprivilegieerde accounts zijn gebruikt, of gegevens de omgeving hebben verlaten, of de uitval bij de cloudprovider overeenkomt met interne telemetrie en wanneer het herstel was voltooid.

ISO/IEC 27001:2022 Bijlage A-beheersmaatregel 8.15, Logging, en 8.16, Monitoringactiviteiten, ondersteunen deze bewijsbasis. In Zenith Controls zijn beide verbonden met 5.24 omdat incidentresponsplanning bruikbare loggegevens en monitoringcapaciteit moet omvatten. Beheersmaatregel 8.16 is ook verbonden met 5.25 omdat waarschuwingen moeten worden getriageerd tot besluiten.

Het Beleid voor logging en monitoring - mkb [LMP-SME] van Clarysec bevat een praktische escalatievereiste:

Waarschuwingen met hoge prioriteit moeten binnen 24 uur worden geëscaleerd naar de algemeen directeur en privacycoördinator

Voor DORA-gereguleerde entiteiten vereisen potentieel ernstige ICT-incidenten doorgaans een sneller operationeel escalatiemodel, vooral wanneer kritieke of belangrijke functies zijn geraakt. Toch is het governancepatroon juist: waarschuwingen met hoge prioriteit mogen niet binnen IT blijven. Ze moeten bedrijfs-, privacy- en managementrollen bereiken.

Een DORA-gereed loggingmodel moet omvatten:

• Gecentraliseerde logging voor kritieke systemen, identiteitsplatformen, endpoints, cloudservices, tools voor netwerkbeveiliging en bedrijfsapplicaties.
• Tijdsynchronisatie tussen systemen, zodat incidenttijdlijnen betrouwbaar zijn.
• Categorisering van waarschuwingen die is afgestemd op incidenternst en DORA-classificatie.
• Logretentie die is afgestemd op regelgevende, contractuele en forensische behoeften.
• Toegangscontroles die de integriteit van logboeken beschermen.
• Procedures voor het vastleggen van momentopnamen van logboeken tijdens ernstige incidenten.
• Vereisten voor toegang tot leverancierslogboeken voor kritieke ICT-diensten.

Auditors zullen “de SIEM heeft het” niet als voldoende bewijsmateriaal accepteren. Zij zullen vragen of de juiste logboeken bestonden, of waarschuwingen zijn beoordeeld, of escalatie op tijd heeft plaatsgevonden en of logboeken zijn bewaard zodra het incident mogelijk meldingsplichtig werd.

Beheersmaatregel 5.28: bewijsverzameling en chain-of-custody

Bij een ernstig ICT-gerelateerd incident dient bewijsmateriaal drie doelen: technisch onderzoek, verantwoordingsplicht richting toezichthouders en juridische verdedigbaarheid.

Als bewijsmateriaal onvolledig, overschreven, gewijzigd of ongedocumenteerd is, kan de organisatie moeite hebben te bewijzen wat er is gebeurd. Zij kan ook moeite hebben haar classificatiebesluit te rechtvaardigen.

Het Beleid inzake bewijsverzameling en forensisch onderzoek [ECF] van Clarysec bepaalt:

Een chain-of-custody-logboek moet al het fysieke of digitale bewijsmateriaal vergezellen vanaf het moment van verwerving tot en met archivering of overdracht en moet documenteren:

De mkb-versie, Beleid inzake bewijsverzameling en forensisch onderzoek - mkb [ECF-SME], houdt de eis eenvoudig:

Elk item van digitaal bewijsmateriaal moet worden vastgelegd met:

De operationele les is direct. Evidence handling kan niet beginnen nadat Juridische Zaken erom vraagt. Het moet in de incidentrespons zijn ingebed.

ISO/IEC 27006-1:2024 versterkt deze auditverwachting door nadruk te leggen op procedures om bewijsmateriaal uit informatiebeveiligingsincidenten te identificeren, te verzamelen en te bewaren. Voor DORA kan dezelfde set bewijsmateriaal de initiële melding, tussentijdse updates, het eindrapport, de post-incident evaluatie en vragen van toezichthouders ondersteunen.

Een praktische checklist voor bewijsmateriaal bij DORA-gerelateerde incidenten moet omvatten:

• Incidentticket en triagenotities.
• Tijdlijn van detectie, escalatie, classificatie, rapportage, indamming, herstel en afsluiting.
• SIEM-alerts en gecorreleerde logboeken.
• Endpoint- en serverartefacten.
• Identiteits- en PAM-activiteitenlogboeken.
• Samenvattingen van netwerkverkeer.
• Status- en auditlogboeken van de cloudprovider.
• Leverancierscommunicatie en incidentverklaringen.
• Registraties van bedrijfsimpact, waaronder klanten, diensten, transacties en downtime.
• Concepten en indieningen van meldingen aan toezichthouders.
• Managementbesluiten en goedkeuringen.
• Oorzaakanalyse.
• Geleerde lessen en corrigerende maatregelen.

Het bewijsmateriaal moet zowel technische feiten als governancebesluiten aantonen. DORA-rapportage gaat niet alleen over wat er met systemen is gebeurd. Zij gaat ook over hoe het management het incident heeft herkend, beoordeeld, geëscaleerd, beheerst en gebruikt voor verbetering.

Beheersmaatregel 5.27: geleerde lessen en continue verbetering

Een DORA-incident is niet afgesloten wanneer het eindrapport is ingediend. Het is afgesloten wanneer de organisatie ervan heeft geleerd, corrigerende maatregelen heeft toegewezen, beheersmaatregelen heeft geactualiseerd en verbetering heeft geverifieerd.

ISO/IEC 27001:2022 Bijlage A-beheersmaatregel 5.27, Leren van informatiebeveiligingsincidenten, verbindt DORA-rapportage met de cyclus van continue verbetering in ISO/IEC 27001:2022. In Zenith Controls is 5.24 gekoppeld aan 5.27 omdat incidentbeheer onvolledig is zonder oorzaakanalyse, geleerde lessen en verbetering van beheersmaatregelen.

De Zenith Blueprint, stap 23, instrueert organisaties het plan te actualiseren met geleerde lessen en gerichte training te bieden over incidentrespons en bewijsbehandeling. Dit is vooral belangrijk voor DORA, omdat terugkerende classificatievertragingen, ontbrekend leveranciersbewijsmateriaal, zwakke logboeken of onduidelijke communicatie aandachtspunten voor toezichthouders kunnen worden.

Een sjabloon voor geleerde lessen moet vastleggen:

• Wat is gebeurd en wanneer.
• Welke kritieke of belangrijke functies waren getroffen.
• Of classificatie tijdig en accuraat was.
• Of DORA-rapportagebesluiten met voldoende bewijsmateriaal zijn genomen.
• Of meldtriggers voor GDPR, NIS2, contracten of klanten zijn beoordeeld.
• Of leveranciers binnen overeengekomen termijnen hebben gereageerd.
• Of logboeken en forensisch bewijsmateriaal zijn bewaard.
• Welke beheersmaatregelen hebben gefaald of ontbraken.
• Welke beleidsdocumenten, draaiboeken, trainingen of technische beheersmaatregelen moeten worden verbeterd.
• Wie eigenaar is van elke corrigerende maatregel en per wanneer.

Dit voedt ook de ISO/IEC 27001:2022-directiebeoordeling. Incidenttrends moeten door de leiding worden beoordeeld, niet worden begraven in technische evaluaties achteraf.

Cross-compliance: DORA, GDPR, NIS2, NIST en COBIT 2019

DORA is het hoofdthema voor financiële entiteiten, maar incidentrapportage behoort zelden tot slechts één raamwerk.

Eén ICT-incident kan betrekking hebben op DORA-melding van ernstige ICT-gerelateerde incidenten, GDPR-melding van een inbreuk in verband met persoonsgegevens, NIS2-melding van een significant incident, contractuele verplichtingen richting klanten, melding aan cyberverzekeraars en rapportage aan het bestuur.

Zenith Controls helpt deze complexiteit te verminderen door ISO/IEC 27002:2022-beheersmaatregelen over raamwerken heen te koppelen. Bijvoorbeeld:

Vanuit NIST-perspectief ondersteunt hetzelfde model de uitkomsten Detect, Respond en Recover. Vanuit COBIT 2019- en ISACA-auditperspectief gaat het om governance: of incidentbeheer, continuïteit, risico, compliance, leveranciersverantwoordelijkheden en prestatiemonitoring worden beheerst.

De meest volwassen organisaties maken geen afzonderlijke workflows voor ieder raamwerk. Zij creëren één incidentbeheerproces met regelgevende lagen. Het ticket legt dezelfde kernfeiten één keer vast en vertakt vervolgens, waar vereist, naar DORA, GDPR, NIS2, contractuele, verzekerings- of sectorspecifieke rapportage.

Hoe auditors uw DORA-incidentproces zullen toetsen

Een DORA-gereed incidentrapportageproces moet verschillende auditperspectieven kunnen doorstaan.

Een ISO/IEC 27001:2022-auditor onderzoekt of het ISMS relevante Bijlage A-beheersmaatregelen heeft geselecteerd en geïmplementeerd, of de Verklaring van Toepasselijkheid deze beheersmaatregelen ondersteunt, of incidentregistraties bestaan en of interne audit en directiebeoordeling incidentprestaties omvatten.

Zenith Controls verwijst naar ISO/IEC 19011:2018-auditmethodologie voor 5.24, 5.25 en 6.8. Voor 5.24 onderzoeken auditors het incidentresponsplan op incidenttypen, ernstclassificaties, toegewezen rollen, contactlijsten, escalatiepaden, instructies voor rapportage aan toezichthouders en communicatieverantwoordelijkheden. Voor 5.25 onderzoeken zij of gedocumenteerde classificatiecriteria bestaan, zoals ernstmatrices of beslisbomen op basis van systeemimpact, gegevensgevoeligheid en duur. Voor 6.8 beoordelen zij meldmechanismen, metrieken voor tijd tot melding en bewijsmateriaal dat gemelde gebeurtenissen worden gelogd, getriageerd en opgelost.

Een DORA-toezichthoudende beoordeling richt zich op de vraag of ernstige ICT-gerelateerde incidenten worden gedetecteerd, geclassificeerd, gerapporteerd, geactualiseerd en afgesloten volgens de verwachtingen van toezichthouders. De beoordelaar kan om een voorbeeldincident vragen en dit volgen van eerste waarschuwing tot eindrapport.

Een privacyauditor richt zich op de vraag of het risico van een inbreuk in verband met persoonsgegevens is beoordeeld en of verplichtingen onder GDPR artikel 33 en artikel 34 zijn geactiveerd. BS EN 17926:2023 is hier relevant omdat deze norm privacy-incidentverantwoordelijkheden, meldcriteria, timing en afstemming met toezichthoudende openbaarmakingsverwachtingen toevoegt.

Hetzelfde bewijsmateriaal kan meerdere auditvragen beantwoorden als het vanaf het begin correct is gestructureerd.

Checklist voor DORA-incidentrapportagegereedheid in 2026

Toets uw organisatie vóór de volgende tabletop-oefening, interne audit of toezichthoudende beoordeling aan deze checklist:

• Weten medewerkers hoe zij vermoedelijke ICT-incidenten moeten melden?
• Is er een eigen incidentmeldkanaal?
• Worden beveiligingsgebeurtenissen consistent gelogd en getriageerd?
• Is er een gedocumenteerde ernstmatrix en DORA-classificatiematrix voor ernstige incidenten?
• Is classificatie verplicht binnen een gedefinieerde tijd na kennisgeving?
• Zijn kritieke of belangrijke functies gekoppeld aan systemen en leveranciers?
• Worden DORA-, GDPR-, NIS2-, contractuele, verzekerings- en klantmeldingstriggers in één workflow beoordeeld?
• Zijn incidentrollen gedefinieerd voor IT, Security, Juridische Zaken, Compliance, Privacy, Communicatie en proceseigenaren?
• Zijn logboeken voldoende om incidenttijdlijnen te reconstrueren?
• Wordt bewijsmateriaal bewaard met chain-of-custody?
• Worden verplichtingen van leveranciers bij incidenten en toegangsrechten tot logboeken getest?
• Worden tabletop-oefeningen uitgevoerd met realistische DORA-scenario’s?
• Worden geleerde lessen opgevolgd tot corrigerende maatregelen?
• Worden incidentmetrieken beoordeeld in de directiebeoordeling?
• Is de Verklaring van Toepasselijkheid gekoppeld aan voor DORA relevante ISO/IEC 27001:2022-beheersmaatregelen?

Als het antwoord op een van deze vragen “gedeeltelijk” is, is het probleem niet alleen compliance. Het is operationele weerbaarheid.

Bouw een DORA-incidentrapportagemodel dat bewijsvoering ondersteunt

DORA-incidentrapportage in 2026 is een test van governance onder druk. De organisaties die goed presteren, zijn niet de organisaties met de langste incidentresponsdocumenten. Het zijn de organisaties met duidelijke meldkanalen, snelle classificatie, betrouwbare logboeken, bewaard bewijsmateriaal, getrainde mensen, geteste leveranciersescalatie en traceerbaarheid over raamwerken heen.

Clarysec kan u helpen dit operationele model te bouwen.

Begin met het in kaart brengen van uw incidentrisico’s en Verklaring van Toepasselijkheid met de Zenith Blueprint: een 30-stappenroadmap voor auditors. Stem vervolgens uw incidentbeheersmaatregelen af met Zenith Controls: de cross-compliancegids. Operationaliseer het proces met Clarysec’s Incidentresponsbeleid, Incidentresponsbeleid - mkb, Beleid voor logging en monitoring - mkb, Beleid inzake bewijsverzameling en forensisch onderzoek en Beleid inzake bewijsverzameling en forensisch onderzoek - mkb.

Als uw managementteam zekerheid wil vóór het volgende echte incident, voer dan met Clarysec’s toolkit een tabletop-oefening uit voor een ernstig ICT-gerelateerd DORA-incident en produceer het bewijspakket dat een auditor of toezichthouder verwacht te zien.