Een CISO van een middelgrote verzekeraar opent in juli 2026 haar planning voor het derde kwartaal. DORA geldt al sinds januari 2025 en de eerste toezichtsvragen zijn binnen. De Cyberbeveiligingswet, de Nederlandse implementatie van NIS2, hangt boven de markt. En het AI-team wil weten wat er moet gebeuren voor de transparantieverplichtingen van de AI Act die op 2 augustus 2026 van kracht worden. Drie wetten, drie interne projectteams, drie spreadsheets. En in alle drie staat, in net iets andere woorden, dezelfde vraag: heeft u een incidentproces, en wie is er verantwoordelijk?
Het directe antwoord op de vraag hoe je AI Act, NIS2 en DORA combineert zonder drie keer hetzelfde werk te doen: bouw een geïntegreerde controlset en behandel elke wet als een view op die set. De drie regimes reguleren voor een groot deel dezelfde onderliggende capabilities: risicomanagement, incidentafhandeling, beheersing van de leveranciersketen, governance op bestuursniveau en logging. Wie per control vastlegt welk artikel uit welke wet erdoor wordt afgedekt, doet het werk een keer en rapporteert drie keer. Wie per wet een eigen framework optuigt, betaalt drie keer voor dezelfde beheersmaatregel en krijgt drie registers die uit elkaar gaan lopen.
Waarom drie parallelle trajecten vanzelf ontstaan
De versnippering is organisatorisch verklaarbaar. DORA landt meestal bij operational risk of de CISO, omdat de toezichthouder financieel is. NIS2 landt bij security. De AI Act landt bij compliance, legal of een data office. Elk team leest zijn eigen wet, koopt zijn eigen tooling en begint zijn eigen risicoregister. Niemand doet iets fout, en toch beantwoordt de organisatie straks drie keer dezelfde auditvraag met drie verschillende antwoorden. Dat is niet alleen inefficiënt, het is ook een risico: inconsistente antwoorden richting toezichthouders roepen vervolgvragen op.
De vijf overlapgebieden
Risicomanagement
DORA eist in hoofdstuk II een volwaardig ICT-risicobeheerkader: identificeren, beschermen, detecteren, herstellen, leren. NIS2 kent in artikel 21 een zorgplicht met een lijst van maatregelen op basis van een all-hazards risicobenadering. De AI Act eist in artikel 9 een risicomanagementsysteem voor hoog-risico AI-systemen, als doorlopend en iteratief proces gedurende de hele levenscyclus. Het skelet is telkens hetzelfde: risico's identificeren, beoordelen, mitigeren, monitoren en periodiek herzien. Wat verschilt is het object: het volledige ICT-landschap bij DORA, netwerk- en informatiesystemen bij NIS2, een specifiek AI-systeem bij de AI Act. Eén risicomethodiek met drie scopes volstaat.
Incidenten
DORA verplicht financiële entiteiten om ernstige ICT-incidenten te classificeren en langs vaste stappen te rapporteren aan de toezichthouder. NIS2 werkt met een vroege waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapport. De AI Act verplicht in artikel 73 aanbieders van hoog-risico AI-systemen om ernstige incidenten te melden bij de markttoezichthouder, met als uiterste termijn vijftien dagen en kortere termijnen bij zeer ernstige gevallen. Drie meldregimes, maar één onderliggend proces: detecteren, classificeren, escaleren, melden, evalueren. De praktische oplossing is één incidentproces met één classificatiematrix, waarin per incidenttype is voorgeprogrammeerd welke rapportagesporen opengaan en binnen welke termijn.
Leveranciersketen
DORA is hier het meest expliciet: risicobeheer voor ICT-diensten van derden, contractuele minimumbepalingen en een informatieregister van alle ICT-contracten. NIS2 benoemt de beveiliging van de toeleveringsketen als onderdeel van de zorgplicht. De AI Act verdeelt verplichtingen over de waardeketen tussen aanbieders en gebruiksverantwoordelijken, en veel organisaties nemen AI vooral af in plaats van dat ze het bouwen. Eén leveranciersregister met extra kolommen (levert deze partij ICT-diensten, kritieke diensten, AI-systemen, GPAI-modellen?) is goedkoper en betrouwbaarder dan drie losse lijsten die niemand synchroon houdt.
Governance
NIS2 legt in artikel 20 de verantwoordelijkheid nadrukkelijk bij het bestuur: het keurt de maatregelen goed, houdt toezicht op de uitvoering en moet zelf getraind zijn. DORA maakt het leidinggevend orgaan eindverantwoordelijk voor het ICT-risicobeheer. De AI Act eist menselijk toezicht op hoog-risico systemen (artikel 14) en verwacht sinds februari 2025 via artikel 4 dat organisaties zorgen voor voldoende AI-geletterdheid bij mensen die met AI-systemen werken. Dat laatste is geen sanctie-instrument maar wel de voorwaarde om toezicht betekenisvol te maken: een bestuur dat AI niet begrijpt, kan er ook niet op sturen. Eén governance-structuur, met één comité dat digitale weerbaarheid en AI samen behandelt, voorkomt dat drie gremia elkaar tegenspreken.
Logging en documentatie
DORA en NIS2 eisen monitoring en detectie, en dus logging van wat er in systemen gebeurt. De AI Act gaat een stap verder: hoog-risico AI-systemen moeten technisch in staat zijn tot automatische logging van gebeurtenissen (artikel 12), en die logs zijn straks bewijsmateriaal richting toezichthouder. Wie nu één logging- en retentiestandaard definieert en daar de AI-specifieke eisen aan toevoegt, hoeft die discussie niet drie keer te voeren met drie verschillende uitkomsten.
Zo bouw je de controlset met drie views
Praktisch werkt het zo. Kies een ruggengraat: veel organisaties gebruiken de controlstructuur van ISO 27001, eventueel aangevuld met ISO 42001 voor het AI-managementsysteem. Hoe die twee normen zich tot de AI Act verhouden, staat uitgewerkt in ISO 42001 versus de EU AI Act. Vervolgens:
- Formuleer elke beheersmaatregel één keer, wetneutraal. Niet "DORA-incidentproces" maar "incidenten worden binnen 24 uur geclassificeerd volgens matrix X".
- Voeg mappingkolommen toe: welk DORA-artikel, welk NIS2-artikel (straks Cyberbeveiligingswet), welk AI Act-artikel dekt deze control af.
- Definieer per wet een view: een filter of rapport dat alleen de controls en het bewijs toont die voor die toezichthouder relevant zijn.
- Beleg elke control bij één eigenaar, ongeacht hoeveel wetten erop leunen.
Dit kan in een GRC-tool, maar een gedisciplineerd gedeeld spreadsheet werkt in het begin ook. Belangrijker dan de tooling is de volgorde: je kunt pas mappen als je weet wat je hebt. Voor de AI-kant begint dat bij een sluitende inventarisatie van alle AI-systemen en hun rol in de organisatie; hoe je die opzet staat in ons stuk over het AI-register.
Let op de verschillen
Integreren is niet gelijkschakelen. De AI Act heeft een grondrechtendimensie die NIS2 en DORA missen: eisen aan datakwaliteit en datagovernance, transparantie richting gebruikers, en voor bepaalde publieke en financiële gebruiksverantwoordelijken straks een grondrechteneffectbeoordeling. Omgekeerd is DORA voor financiële entiteiten lex specialis ten opzichte van NIS2: wie onder DORA valt, volgt voor ICT-risico en incidentmelding het DORA-regime.
Ook de tijdlijnen lopen uiteen, en dat bepaalt je prioritering. DORA geldt al sinds 17 januari 2025. Voor NIS2 loopt de Nederlandse implementatie via de Cyberbeveiligingswet nog; de zorgvuldige aanname is dat de verplichtingen eraan komen, niet dat er nu al Nederlandse handhaving staat. De AI Act is gefaseerd: de verboden praktijken gelden sinds februari 2025, de transparantieverplichtingen van artikel 50 worden op 2 augustus 2026 van kracht en zijn niet uitgesteld, en de handhaving van de GPAI-modelverplichtingen start eveneens op 2 augustus 2026. De zelfstandige hoog-risico verplichtingen van bijlage III schuiven via het Digital Omnibus-pakket naar 2 december 2027, al is dat pakket per juli 2026 politiek akkoord maar nog niet gepubliceerd in het Publicatieblad. De volledige tijdlijn en artikelteksten staan in onze AI Act Explorer.
Waar je morgen begint
Begin met de inventarisatie: welke AI-systemen, welke ICT-leveranciers, welke kritieke processen. Leg daarna je bestaande DORA- en NIS2-maatregelen naast hoofdstuk III van de AI Act en markeer wat al gedekt is; dat is doorgaans meer dan teams verwachten. Bouw de mapping, richt één incidentproces in met meerdere rapportagesporen, en breng governance samen in één comité met een bestuurlijke eigenaar. Organisaties die hier hulp bij willen, bijvoorbeeld bij het opzetten van de geïntegreerde controlset of het bepalen van de AI Act-scope, kunnen terecht bij Embed AI.
De winst is groter dan efficiency alleen. Een organisatie met één controlset geeft toezichthouders consistente antwoorden, ziet gaten eerder en voorkomt dat de AI Act als derde losse compliance-laag bovenop een toch al vol securityprogramma valt. Drie wetten, één werkelijkheid: het zijn dezelfde systemen, dezelfde leveranciers en dezelfde mensen. Behandel ze dan ook zo.