Je ISO 27001-certificaat start de klokken van DORA niet

Een veelvoorkomende manier om met een DORA-programma te beginnen, is met een spreadsheet. Één kolom bevat de vereisten van Verordening (EU) 2022/2554, een andere kolom de ISO/IEC 27001:2022 Annex A-controles die de organisatie al heeft geïmplementeerd binnen haar gecertificeerde ISMS, en een derde kolom registreert de overlap. Als de koppeling is gemaakt, blijkt de overlap groot: ICT-risicobeheer, toegangscontrole, leveranciersbeheer, bedrijfscontinuïteit, incidentafhandeling. De rest ziet eruit als een schrijfoefening op basis van een bestaand certificaat.

Die benadering is de valkuil. Het is niet onjuist over de overlap, die is echt. Het is wel onjuist over wat de rest inhoudt. De onderdelen van DORA die een gecertificeerde ISO 27001-organisatie nog niet heeft uitgevoerd, zijn niet zomaar documentatie om te schrijven. Verschillende ervan zijn verplichtingen die moeten worden uitgevoerd, volgens een specificatie en op een vastgesteld tijdschema, en een certificaat is het verkeerde instrument om deze te bewijzen.

Een certificaat bevestigt een gescopeerd systeem; een verordening legt verplichtingen op

ISO/IEC 27001:2022 certificeert dat een informatiebeveiligingsmanagementsysteem (ISMS) binnen een gedefinieerde scope voldoet aan de eisen van de standaard. Certificering is geen eenmalig moment: een certificeringsinstantie verstrekt het certificaat na een audit, en dit wordt doorgaans onderhouden gedurende een driejarige cyclus van surveillance-audits en hercertificering. Twee zaken die hierbij belangrijk zijn: het gecertificeerde object is een managementsysteem, begrensd door de scopeverklaring, en de certificeringsvraag is conformiteit: voldoet het ISMS aan de eisen?

DORA is niet op deze manier opgebouwd. Het is van toepassing op financiële entiteiten vanaf 17 januari 2025 (Verordening (EU) 2022/2554), en de bepalingen zijn geen managementsysteem om aan te voldoen, maar verplichtingen om uit te voeren, waarvan verschillende tijdgebonden en gespecificeerd zijn. Je kunt een geldig ISO 27001-certificaat hebben, binnen de scope en actueel, en toch in strijd handelen met DORA, omdat het certificaat een vraag beantwoordt die DORA niet stelt. Drie van DORA’s verplichtingen lopen op klokken of voldoen aan specificaties die een certificaat nooit heeft getest; een vierde verplaatst de verantwoordelijkheid naar een plek die een certificaat nooit controleert.

Het register

Artikel 28(3) vereist dat een financiële entiteit een register bijhoudt met informatie over haar contractuele afspraken voor het gebruik van ICT-diensten die worden geleverd door ICT-dienstverleners van derden, en om informatie over deze afspraken jaarlijks te rapporteren aan de bevoegde autoriteit. Het register is een gestructureerd artefact, geen vrij te formuleren document: Uitvoeringsverordening (EU) 2024/2956 van de Commissie, gepubliceerd in het Publicatieblad op 2 december 2024, legt de standaard sjablonen en datavelden vast. Volgens de rapportageafspraken van de Europese toezichthoudende autoriteiten verzamelen de bevoegde autoriteiten deze registers van onder toezicht staande entiteiten en sturen ze door naar de ESA’s, waarbij de eerste verzameling in 2025 plaatsvindt.

Een gecertificeerde organisatie beheert haar ICT-leveranciers al onder Annex A-controles zoals A.5.19 tot A.5.23, geselecteerd via haar risicobehandeling en vastgelegd in haar Verklaring van Toepasselijkheid. Wat dit op zichzelf niet oplevert, is een register in het voorgeschreven schema, gevuld met de DORA-datavelden, afgestemd op de daadwerkelijke contracten van de organisatie, en raadpleegbaar voor een toezichthouder volgens de verzamelcyclus. Leveranciers beheren en het afleveren van een specifiek gestructureerd artefact aan een toezichthouder zijn verschillende verplichtingen, en de tweede wordt niet bewezen door de eerste.

De incidentklok

Artikel 19 verplicht financiële entiteiten om grote ICT-gerelateerde incidenten te melden aan de bevoegde autoriteit, en de technische standaard legt de tijdschema’s vast. Delegatieverordening (EU) 2025/301 van de Commissie van 23 oktober 2024 vereist een initiële melding binnen vier uur nadat het incident is geclassificeerd als groot en, in de regel, niet later dan 24 uur nadat de entiteit zich bewust werd van het incident; een tussentijds rapport binnen 72 uur na die initiële melding; en een finaal rapport binnen één maand na het tussentijdse rapport (of het meest recente bijgewerkte tussentijdse rapport). Of een incident überhaupt "groot" is, wordt bepaald door de classificatiecriteria in Delegatieverordening (EU) 2024/1772 van de Commissie.

Het referentiepunt is het deel dat het dubbel lezen waard is. DORA’s vieruursklok loopt vanaf het moment dat een incident als groot wordt geclassificeerd, wat maakt dat een accurate en snelle classificatie onderdeel is van de verplichting in plaats van een voorbereidende stap. Dat is een andere structuur dan de incidentmeldingsverplichtingen die financiële teams al kennen: NIS2’s vroege waarschuwing loopt binnen 24 uur nadat men zich bewust wordt van een significant incident (Richtlijn (EU) 2022/2555, Artikel 23), en de GDPR vereist dat een verwerkingsverantwoordelijke een inbreuk op persoonsgegevens die risico’s voor individuen met zich meebrengt, zonder onnodige vertraging en, indien mogelijk, binnen 72 uur na ontdekking meldt (Verordening (EU) 2016/679, Artikel 33). Deze klokken zijn niet uitwisselbaar. Onder Annex A-controles A.5.24 tot A.5.27 plant een gecertificeerde organisatie, beoordeelt, reageert op en leert van informatiebeveiligingsincidenten via het proces dat zij heeft geïmplementeerd, en een auditor heeft dat proces geaccepteerd als conform. Een auditor die accepteert dat het proces conform is, is niet hetzelfde als dat proces binnen vier uur na classificatie een correct geclassificeerde melding oplevert.

De testverplichting

Artikel 26 vereist dat financiële entiteiten die door hun bevoegde autoriteiten zijn geïdentificeerd op basis van omvang, risicoprofiel en systeemrelevantie, ten minste elke drie jaar een dreigingsgestuurde penetratietest uitvoeren op live productiesystemen die kritieke of belangrijke functies ondersteunen. De drie jaar is een minimum dat de bevoegde autoriteit kan aanpassen, en de gedetailleerde methodologie en identificatiecriteria zijn vastgelegd in Delegatieverordening (EU) 2025/1190 van de Commissie, van toepassing vanaf 8 juli 2025. Dit geldt niet voor elke financiële entiteit, en de identificatie is aan de toezichthouder. Maar voor een organisatie binnen de scope is het een terugkerende, bewezen verplichting van een specifieke aard.

ISO/IEC 27001 vraagt een organisatie om de prestaties van haar ISMS te monitoren, meten en evalueren (clausule 9.1) en interne audits uit te voeren (clausule 9.2), en Annex A-controle A.8.29 dekt beveiligingstests in ontwikkeling en acceptatie. Geen van deze, op zichzelf, bewijst een intelligence-gestuurde red-team-oefening tegen productie, herhaald volgens de DORA-cadans en uitgevoerd volgens de toezichthoudende methodologie. Een organisatie kan volledig gecertificeerd zijn en er nooit één hebben uitgevoerd.

De verantwoordelijkheid die een certificaat niet bereikt

Artikel 5(2) legt op het managementorgaan de verplichting om het ICT-risicomanagementkader te definiëren, goed te keuren, te overzien en er verantwoordelijk voor te zijn, en punt (a) stelt dat het "uiteindelijk verantwoordelijk is voor het beheren van het ICT-risico van de financiële entiteit". Artikel 5(4) voegt een persoonlijke verplichting toe: leden van het managementorgaan moeten hun kennis en vaardigheden voldoende actueel houden om ICT-risico’s te begrijpen en te beoordelen. Dit is de enige van de vier die geen klok is. Het is een doorlopende governance-verplichting.

ISO/IEC 27001 clausule 5.1 vereist al leiderschap en inzet van de topmanagement, dus dit is het gebied met de grootste overlap. De kloof is smaller en specifieker dan "ISO negeert het bestuur". DORA legt de uiteindelijke verantwoordelijkheid bij het "managementorgaan", een juridisch gedefinieerde term, en legt een persoonlijke competentieverplichting op aan haar leden. ISO’s "topmanagement" en DORA’s "managementorgaan" zijn niet noodzakelijkerwijs dezelfde personen, en certificering toont leiderschapsinzet voor het ISMS, niet naleving van Artikel 5(2)(a) of 5(4). Een certificaat kan worden verkregen zonder ooit de specifieke verantwoordelijkheid te testen die DORA noemt.

Waarom de koppeling alle vier verbergt

De spreadsheet faalt op een consistente manier: hij vergelijkt controletekst met controletekst, en DORA’s extra gewicht zit niet alleen in de tekst. Een controle luidt "de organisatie moet informatiebeveiligingsincidenten beheren", en hetzelfde geldt voor het ISO-bewijs van de organisatie, en de cellen matchen. Wat de cel niet laat zien, is dat DORA een referentiepunt-klok van vier uur, een voorgeschreven registersjabloon, een verplichting tot ten minste elke drie jaar testen en een juridisch genoemde verantwoordelijke instantie heeft gekoppeld aan activiteiten die ISO beschrijft als capaciteiten. Twee vereisten kunnen bijna identieke woorden gebruiken en toch worden voldaan door verschillende handelingen, omdat de ene vraagt of een conform systeem bestaat binnen een scope en de andere of een gespecificeerde verplichting is uitgevoerd.

Dit is het bezwaar dat serieus genomen moet worden, en het is de reden waarom veel programma’s op het documentatietrack blijven. Annex A, zo luidt het argument, dekt al incidentbeheer, leveranciersbeheer en testen, dus DORA is dezelfde inhoud met een compliance-omhulsel. Het antwoord is dat een specificatie en een deadline geen omhulsel zijn rond een controle. Een referentiepunt, een inleverformaat, een aanpasbare testcadans en een genoemde juridische verantwoordelijkheid zijn nieuwe verplichtingen die het bestaan van een controle niet afdoet, en het zijn precies deze die een controle-op-controle-koppeling onzichtbaar maakt.

De regel die de moeite waard is om te behouden

Als je een certificering koppelt aan een verordening, koppel dan de operationele verplichtingen, niet de controletekst. Een certificaat bevestigt dat een managementsysteem voldeed aan een standaard, binnen een scope, gedurende een auditcyclus. Een verordening zegt wat dat systeem moet doen, volgens welke specificatie en tegen wanneer. Waar de twee dezelfde activiteit beschrijven, controleer dan of de verordening een referentiepunt-klok, een formaat, een cadans of een genoemde verantwoordelijkheid heeft gekoppeld, want dat zijn de toevoegingen die een controle-op-controle-koppeling onzichtbaar maakt en waar een toezichthouder waarschijnlijk op zal testen.

Deze instelling is breder toepasbaar dan alleen DORA, hoewel de details per regime verschillen. NIS2 vereist dat lidstaten zowel governance-verplichtingen voor het managementorgaan opleggen (Richtlijn (EU) 2022/2555, Artikel 20) als een 24-uurs vroege waarschuwingsplicht (Artikel 23), bovenop activiteiten die bestaande controles al beschrijven. De Cyber Resilience Act koppelt tijdgebonden meldingen van actief uitgebuite kwetsbaarheden en ernstige incidenten aan fabrikanten van producten met digitale elementen, waarbij deze meldingsplichten gelden vanaf 11 september 2026 (Verordening (EU) 2024/2847, Artikel 14). De accountability-modellen zijn niet identiek, maar de leesdiscipline is hetzelfde: vind het werkwoord, vind de klok of de specificatie, en behandel elke verplichting met een deadline of een gedefinieerde geadresseerde als een operationele verplichting in plaats van een document om te schrijven.

Als je taak op korte termijn het scheiden is van de echte overlap tussen ISO 27001 en DORA en de tijdgebonden en gespecificeerde verplichtingen die een certificaat niet bewijst, dan is dat kruisverwijzen naar de daadwerkelijke artikelen en technische standaarden het soort werk waarvoor ISMS Copilot is gebouwd. Een grote overlap in de koppeling is echt. Het is ook herbruikbaar bewijs dat nog steeds DORA-specifieke validatie nodig heeft, niet compliance die je ongewijzigd kunt overnemen – en daarom is het niet het deel dat je plan zou moeten bepalen.

Dit is praktische compliance-analyse, geen juridisch advies. Bevestig de scope en verplichtingen van je entiteit aan de hand van de verordening en de technische standaarden, en waar nodig met je bevoegde autoriteit of juridisch adviseur.