De samenloop van incidentmeldplichten uit NIS-2, DORA, de AVG en de Cyber Resilience Act (CRA) confronteert compliance officers met een meervoudig juridisch probleem: elk regime kent een eigen termijn, een eigen ontvanger en een eigen inhoudelijke drempel. Wie per wet een apart meldproces inricht, raakt verstrikt in dubbel werk, verhoogde foutrisico’s en, bij gebruik van Amerikaanse cloudtooling, ook nog eens jurisdictierisico’s. Dit artikel beschrijft hoe organisaties in gereguleerde sectoren één geïntegreerd, soeverein meldproces bouwen dat tegelijk voldoet aan alle toepasselijke regimes.
De vier meldregimes naast elkaar
Elk van de vier relevante regimes heeft een eigen juridische grondslag, eigen termijnen en een eigen bevoegde autoriteit. Begrijpen waar ze van elkaar afwijken is de eerste stap naar integratie.
| Regime | Grondslag | Initiële termijn | Ontvanger (NL) | Trigger |
|---|---|---|---|---|
| NIS-2 | Artikel 23 Richtlijn (EU) 2022/2555 / Cbw Artikel 12 | 24 uur (eerste melding) | NCSC / sectorale CSIRT | Significant incident dat diensten beïnvloedt |
| DORA | Artikel 19 Verordening (EU) 2022/2554 + RTS | 4 uur (major incident) | DNB of AFM | Major ICT-gerelateerd incident bij financiële entiteit |
| AVG | Artikel 33 Verordening (EU) 2016/679 | 72 uur | Autoriteit Persoonsgegevens (AP) | Inbreuk op persoonsgegevens |
| CRA | Artikel 14 Verordening (EU) 2024/2847 | 24 uur (actief misbruik) | ENISA + nationale autoriteit | Actief misbruikte kwetsbaarheid in product met digitale elementen |
De kortste termijn bepaalt de operationele urgentie van het gehele meldproces. Omdat DORA bij majeure incidenten een initiële melding binnen 4 uur vereist, moeten financiële instellingen die tevens essentiële dienstaanbieder zijn hun detectie- en escalatieprocedures zo inrichten dat alle meldingen vanuit die 4-uurs-discipline opereren, ook als de AVG-melding pas 72 uur later hoeft te volgen.
De Cyberbeveiligingswet en de DORA-afstemming voor financiële cloudproviders
De Nederlandse Cyberbeveiligingswet (Cbw) implementeert NIS-2 in nationaal recht; Artikel 12 Cbw regelt de meldplicht voor aanbieders van essentiële en belangrijke diensten richting het NCSC. Dit creëert een bijzondere complicatie voor financiële instellingen die tevens cloudprovider zijn.
Een bank die ook een intern cloudplatform exploiteert voor dochtermaatschappijen, valt mogelijk onder DORA als financiële entiteit én onder de Cbw als aanbieder van digitale infrastructuur. Bij één en hetzelfde ransomware-incident moet deze organisatie dus melden bij DNB (DORA), bij het NCSC (Cbw/NIS-2) en bij de AP (als persoonsgegevens zijn geraakt). De inhoud van die meldingen overlapt grotendeels, maar de formele adressering, de indieningskanalen en de classificatiecriteria verschillen.
Juhan Lepassaar, uitvoerend directeur van ENISA, stelde hierover: “Organisaties moeten stoppen met incidentmelding te beschouwen als een juridische verplichting achteraf; het is een operationeel proces dat vanaf de detectie start.”
Praktisch betekent dit dat de Cbw-melding en de DORA-melding uit dezelfde primaire incidentregistratie moeten worden gegenereerd, met een exportfunctie per toezichthouder die automatisch de juiste veldmapping toepast.
Het Digital Omnibus-voorstel: één ENISA-meldpunt als toekomstperspectief
Het vereenvoudigingspakket dat de Europese Commissie in 2025 presenteerde onder de naam Digital Omnibus voorziet in een centraal meldpunt bij ENISA, het zogeheten “single entry point”. Organisaties zouden in de toekomst via één digitaal loket kunnen melden, waarna ENISA de informatie distribueert naar de bevoegde nationale autoriteiten.
Dit voorstel bevindt zich nog in de wetgevingsprocedure en is op het moment van schrijven niet in werking getreden. Organisaties die nu hun meldinfrastructuur bouwen, doen er verstandig aan een modulaire architectuur te kiezen: de interne incidentregistratie blijft ongewijzigd, en alleen de uitgaande koppeling naar toezichthouders wordt geconfigureerd als een uitwisselbare adapter. Zo kan een toekomstige ENISA-API worden aangesloten zonder het gehele meldproces te herbouwen.
Soevereine meldinfrastructuur: geen Big Tech in het kritieke pad
Een structureel probleem bij de huidige incidentmeldpraktijk is dat veel organisaties hun SIEM, SOAR en ticketsystemen afnemen van Amerikaanse cloudproviders. Platforms als Microsoft Sentinel, Splunk Cloud of ServiceNow vallen onder de reikwijdte van de CLOUD Act. Dit betekent dat Amerikaanse autoriteiten onder bepaalde voorwaarden toegang kunnen vorderen tot data die op deze platforms staat, inclusief incidentlogs die gedetailleerde informatie bevatten over beveiligingslekken, getroffen systemen en reactiemaatregelen.
Frank Elderson, lid van de Directieraad van de Europese Centrale Bank en voormalig DNB-directeur, formuleerde het als volgt: “De samenloop van meldregimes vereist dat financiële instellingen één geïntegreerd operationeel raamwerk bouwen in plaats van parallelle silo’s per toezichthouder.”
Dat geïntegreerde raamwerk moet, voor organisaties in gevoelige sectoren, ook soeverein zijn. Concrete alternatieven voor een soevereine SIEM- en SOAR-stack zijn onder andere:
- Wazuh: open-source SIEM/XDR die volledig on-premise of in een EU-soevereine omgeving kan draaien, met ingebouwde compliance-rapportagemodules voor NIS-2 en AVG.
- OpenSearch (Opensearch.org): open-source zoek- en analyseplatform als alternatief voor Elasticsearch-gebaseerde cloudoplossingen, zelf te hosten op Europese infrastructuur.
- TheHive + Cortex: open-source SOAR-platform voor incidentrespons, ontwikkeld door het Franse beveiligingsbedrijf StrangeBee, geschikt voor on-premise inzet.
- Zammad: open-source ticketsysteem voor incidentopvolging, zelf te hosten, met een audittrail die meerdere toezichthouders kan bedienen.
Het gaat er niet om dat commerciële tooling per definitie ongeschikt is, maar dat de incidentregistratie van een organisatie, het meest gevoelige document in een crisis, niet afhankelijk mag zijn van een jurisdictie die buiten de EU-rechtsorde valt.
Eén registratie, geldig voor drie toezichthouders
Het centrale architectuurprincipe voor soevereine incidentdocumentatie is: registreer eenmaal, rapporteer meervoudig. Dit vereist dat het interne incidentrecord alle velden bevat die elk van de drie Nederlandse toezichthouders (NCSC, DNB, AP) nodig heeft, gestructureerd in een gemeenschappelijk datamodel.
Een praktisch datamodel voor incidentregistratie bevat minimaal de volgende blokken:
- Feitenblok: tijdstip detectie, tijdstip melding, getroffen systemen, aanvalstype of oorzaak, geografische impact.
- Impactblok: aantal getroffen gebruikers, financiële impact (relevant voor DORA-drempelwaarden), betrokken persoonsgegevens (categorie en omvang, relevant voor AVG Artikel 33).
- Maatregelenblok: genomen containmentmaatregelen, herstelstappen, tijdlijn.
- Toezichthouderblok: per toezichthouder een afzonderlijk veld met de meldstatus, het meldtijdstip en de ontvangstbevestiging.
Het toezichthouderblok is het enige deel dat per ontvanger verschilt. De rest van het record is gedeeld en vormt de gecontroleerde bron van waarheid. Exportsjablonen voor NCSC, DNB en AP worden gegenereerd vanuit dit gemeenschappelijke record, niet handmatig ingevuld per instantie.
Statistisch beeld van de meldpraktijk
Drie relevante cijfers verduidelijken hoe urgent een gestructureerde aanpak is:
- 63% van de Europese middelgrote organisaties gaf in 2023 aan de NIS-2-meldtermijnen niet binnen de vereiste tijd te kunnen naleven (ENISA Threat Landscape 2023).
- Organisaties detecteren een inbreuk gemiddeld pas na 194 dagen (IBM Cost of a Data Breach Report 2023), waardoor de feitelijke meldtermijn begint op een moment dat het incident al lang actief is.
- In 2023 bedroegen AVG-boetes gerelateerd aan meldplichtverzuim gezamenlijk meer dan 1,6 miljard euro (European Data Protection Board, 2023).
De detectiekloof van gemiddeld 194 dagen maakt duidelijk dat de termijnen van 4, 24 of 72 uur niet ingaan op het moment van het incident, maar op het moment van ontdekking. Dit onderstreept het belang van continue monitoring via een soevereine SIEM: hoe eerder detectie, hoe meer speelruimte er is om correct te melden voordat toezichthouders zelf contact opnemen.
Van meldproces naar meldcultuur
Een technisch correct meldproces is niet voldoende als de organisatiecultuur incidentmelding behandelt als reputatierisico. NIS-2 Artikel 23 en de Cbw leggen meldplichten op aan het managementniveau: bestuurders zijn persoonlijk verantwoordelijk voor tijdige melding. Dit verschuift de verantwoordelijkheid van de IT-afdeling naar de bestuurstafel.
Compliance officers in gereguleerde sectoren, overheid, juridische dienstverlening en financiële instellingen, doen er goed aan de meldprocedure minimaal jaarlijks te oefenen in een tabletop-oefening die alle vier de regimes simuleert. De oefening toetst niet alleen of de tooling werkt, maar ook of de beslissingslijn van detectie naar bestuurlijke goedkeuring van de melding binnen de kortste toepasselijke termijn (4 uur bij DORA) realistisch is.
Een soevereine meldinfrastructuur is geen eindpunt maar een raamwerk dat meegroeit met nieuwe regelgeving. Het Digital Omnibus-voorstel voor een centraal ENISA-meldpunt, de uitwerking van de CRA-meldplicht voor kwetsbaarheden en de Nederlandse uitvoering van de Cbw zijn alle drie nog in beweging. Organisaties die hun meldproces nu op modulaire, soevereine grondslagen bouwen, zijn het best gepositioneerd om die veranderingen op te vangen zonder elk keer het gehele systeem te herbouwen.
FAQ: veelgestelde vragen over meldplichten en samenloop
Geldt de 4-uurs DORA-termijn voor alle financiële instellingen?
Nee. De DORA RTS maakt onderscheid naar ernst en categorie van het incident. Alleen als een incident wordt geclassificeerd als ‘major’ op basis van drempelwaarden voor impact, duur en getroffen gebruikers, geldt de initiële melding binnen 4 uur aan DNB of AFM.
Mag een organisatie voor incidentregistratie gebruikmaken van Microsoft Sentinel of Splunk Cloud?
Dat is juridisch niet verboden, maar het brengt jurisdictierisico’s mee omdat beide platforms onder de CLOUD Act vallen. Voor organisaties in gereguleerde sectoren of de overheid is een EU-soevereine of on-premise SIEM-oplossing sterk te overwegen.
Wat is het verschil tussen een NIS-2-melding en een AVG-melding bij hetzelfde incident?
NIS-2 Artikel 23 richt zich op de impact op netwerk- en informatiesystemen en de continuïteit van diensten; de melding gaat naar het NCSC of de sectorale CSIRT. AVG Artikel 33 richt zich specifiek op inbreuk in verband met persoonsgegevens; die melding gaat naar de Autoriteit Persoonsgegevens. Bij één incident kunnen beide meldingen verplicht zijn, met een verschillende ontvanger, termijn en inhoudelijke focus.
Wanneer treedt het Digital Omnibus-voorstel voor een enkel ENISA-meldpunt in werking?
Het voorstel van de Europese Commissie uit 2025 bevindt zich nog in de wetgevingsprocedure. Tot het in werking treedt, moeten organisaties blijven melden bij de bestaande nationale autoriteiten. Ontwerp de meldinfrastructuur modulair, zodat slechts een configuratiewijziging nodig is om naar een toekomstig centraal punt te schakelen.
Telt een CRA-melding van een actief misbruikte kwetsbaarheid ook mee als NIS-2-melding?
Niet automatisch. De CRA-meldplicht (Artikel 14 van Verordening (EU) 2024/2847) geldt voor fabrikanten van producten met digitale elementen en richt zich op ENISA en nationale autoriteiten. NIS-2 Artikel 23 richt zich op aanbieders van essentiële en belangrijke diensten. Als een organisatie beide rollen vervult, zijn beide meldingen afzonderlijk verplicht, ook al kunnen dezelfde technische feiten als basis dienen.
