Picture a CISO at a mid-sized insurer opening her third-quarter plan in July 2026. DORA has applied since January 2025 and the first supervisory questionnaires have landed. NIS2 obligations are approaching as member states finish their national implementations. Meanwhile the AI team wants to know what the AI Act transparency obligations, applicable from 2 August 2026, mean for the chatbot on the claims portal. Three laws, three internal project teams, three spreadsheets. And in all three, in slightly different wording, the same question: do you have an incident process, and who owns it?
The direct answer to how you combine the AI Act, NIS2 and DORA without doing the same work three times: build one integrated control set and treat each law as a view on that set. The three regimes largely regulate the same underlying capabilities: risk management, incident handling, third-party and supply chain control, board-level governance, and logging. If you document, per control, which article of which law it satisfies, you do the work once and report three times. If you build a separate framework per law, you pay three times for the same safeguard and end up with three registers that drift apart.
Why three parallel programmes emerge by default
The fragmentation has an organisational logic. DORA usually lands with operational risk or the CISO, because the supervisor is a financial one. NIS2 lands with security. The AI Act lands with compliance, legal or a data office. Each team reads its own law, buys its own tooling and starts its own risk register. Nobody is doing anything wrong, yet the organisation will soon answer the same audit question three times with three different answers. That is not just inefficient; inconsistent answers to supervisors invite follow-up questions.
The five areas of overlap
Risk management
DORA requires a full ICT risk management framework in Chapter II: identify, protect, detect, recover, learn. NIS2 imposes a duty of care in Article 21, with a list of measures based on an all-hazards approach. The AI Act requires, in Article 9, a risk management system for high-risk AI systems, run as a continuous, iterative process across the entire lifecycle. The skeleton is identical every time: identify, assess, mitigate, monitor and periodically review. What differs is the object: the full ICT estate under DORA, network and information systems under NIS2, a specific AI system under the AI Act. One risk methodology with three scopes is enough.
Incidents
DORA obliges financial entities to classify major ICT-related incidents and report them to the supervisor along a fixed sequence. NIS2 works with an early warning within 24 hours, an incident notification within 72 hours and a final report. The AI Act, in Article 73, requires providers of high-risk AI systems to report serious incidents to the market surveillance authority, with an outer limit of fifteen days and shorter deadlines for the most severe cases. Three reporting regimes, one underlying process: detect, classify, escalate, notify, evaluate. The practical answer is a single incident process with a single classification matrix, in which each incident type is pre-mapped to the reporting tracks it triggers and their deadlines.
Supply chain
DORA is the most explicit here: ICT third-party risk management, mandatory contract provisions and a register of information covering all ICT contracts. NIS2 names supply chain security as part of the duty of care. The AI Act distributes obligations across the value chain between providers and deployers, and most organisations buy AI rather than build it. One vendor register with extra columns (does this party supply ICT services, critical functions, AI systems, GPAI models?) is cheaper and more reliable than three separate lists nobody keeps in sync.
Governance
NIS2 places responsibility squarely with the management body in Article 20: it approves the measures, oversees implementation and must itself be trained. DORA makes the management body ultimately responsible for ICT risk management. The AI Act requires human oversight of high-risk systems (Article 14) and, since February 2025, expects organisations under Article 4 to ensure a sufficient level of AI literacy among people working with AI systems. That last obligation is not a sanction instrument, but it is the precondition for oversight to mean anything: a board that does not understand AI cannot steer it. One governance structure, with one committee covering digital resilience and AI together, prevents three bodies from contradicting each other.
Logging and documentation
DORA and NIS2 both require monitoring and detection, and therefore logs of what happens inside systems. The AI Act goes a step further: high-risk AI systems must be technically capable of automatically recording events (Article 12), and those logs will serve as evidence towards the supervisor. Define one logging and retention standard now, add the AI-specific requirements to it, and you avoid having that debate three times with three different outcomes.
Building the control set with three views
In practice it works like this. Pick a backbone: many organisations use the control structure of ISO 27001, supplemented with ISO 42001 for the AI management system. How those two standards relate to the AI Act is covered in ISO 42001 versus the EU AI Act. Then:
- Write every control once, in law-neutral language. Not "DORA incident process" but "incidents are classified within 24 hours according to matrix X".
- Add mapping columns: which DORA article, which NIS2 article (or its national implementation), which AI Act article this control satisfies.
- Define one view per law: a filter or report showing only the controls and evidence relevant to that supervisor.
- Assign each control to exactly one owner, regardless of how many laws rely on it.
A GRC tool helps, but a disciplined shared spreadsheet works at the start. More important than tooling is sequence: you cannot map what you have not inventoried. On the AI side that starts with a complete inventory of all AI systems and their role in the organisation; how to set one up is covered in our piece on the AI register.
Mind the differences
Integrating is not flattening. The AI Act has a fundamental rights dimension that NIS2 and DORA lack: requirements on data quality and data governance, transparency towards users, and for certain public sector and financial deployers a fundamental rights impact assessment further down the line. Conversely, DORA acts as lex specialis to NIS2 for financial entities: if DORA applies to you, you follow the DORA regime for ICT risk and incident reporting.
The timelines also diverge, and that drives prioritisation. DORA has applied since 17 January 2025. NIS2 national implementations are still being completed in several member states, including the Netherlands, where the Cyberbeveiligingswet is in the legislative process; the prudent assumption is that the obligations are coming, not that national enforcement is already in place everywhere. The AI Act is phased: the prohibited practices have applied since February 2025, the Article 50 transparency obligations become applicable on 2 August 2026 and have not been postponed, and full enforcement of the GPAI model obligations also starts on 2 August 2026. The standalone high-risk obligations of Annex III shift to 2 December 2027 through the Digital Omnibus package, although that package, as of July 2026, is a political agreement endorsed by the European Parliament but not yet published in the Official Journal. The full timeline and article texts are available in our AI Act Explorer.
Where to start tomorrow
Start with the inventory: which AI systems, which ICT vendors, which critical processes. Then place your existing DORA and NIS2 measures next to Chapter III of the AI Act and mark what is already covered; that is usually more than teams expect. Build the mapping, set up one incident process with multiple reporting tracks, and consolidate governance into one committee with a board-level owner. Organisations that want support with this, for instance in setting up the integrated control set or scoping their AI Act exposure, can turn to Embed AI.
The gain goes beyond efficiency. An organisation with one control set gives supervisors consistent answers, spots gaps earlier and prevents the AI Act from landing as a third loose compliance layer on top of an already crowded security programme. Three laws, one reality: the same systems, the same vendors, the same people. Treat them that way.