TL;DR: Mapping an AI tool to DORA and NIS2 is the easy half. The hard half is that you can only map what you have found, and the AI tools most likely to matter are the ones that never entered the inventory the mapping is built on. Get discovery right first, and the mapping mostly falls out of it. Get it wrong, and you produce a tidy map of the wrong estate.
Most advice on this problem starts in the same place: build one control set, map each control to both regimes, and stop running two compliance programmes side by side. It is good advice. The two regimes really do overlap heavily, and a firm that maps once instead of twice saves itself a great deal of duplicated work.
It also assumes the thing that is least true in practice. It assumes you already have the list.
The half of the work everyone writes about
Take the mapping problem as it is usually framed, because that part is real and worth getting right.
A financial entity in scope for both regimes is answering to two supervisors about substantially the same systems. DORA is the more specific regime for financial-sector ICT risk, so for a bank or an insurer it usually leads on ICT risk management and incident reporting. NIS2 still reaches the same entity for broader cybersecurity governance and supply-chain obligations. One set of systems, two regulators, two overlapping-but-not-identical sets of duties.
The overlap is large. Industry mappings put it at roughly seventy per cent shared controls, with the remaining thirty per cent genuinely distinct. Risk management, incident handling, third-party oversight, logging, governance, most of it serves both regimes at once. Map a control once, and it can produce evidence for both audits.
Where the regimes diverge, they diverge in ways that matter for an AI tool specifically.
Incident reporting runs on two clocks. NIS2 Article 23 sets a 24-hour early warning, a 72-hour notification and a one-month final report, timed from the moment you become aware. DORA runs its own tiered ICT-incident timeline for financial entities. An AI system inside a critical function can trip both, and the two filings are not interchangeable.
Supply-chain scope is drawn differently too. NIS2 Article 21 pulls supply-chain security into its risk-management measures for essential and important entities, while DORA governs ICT third parties through its own third-party regime. An external model provider can fall inside one framing, the other, or both.
And accountability lands on named people under both. Each regime puts responsibility on the management body rather than an abstract "the firm", so an unowned AI tool is a problem in two directions at once.
None of this is controversial, and plenty of tools will help you do it. The mapping is a solved problem - on paper.
Why the map is only as good as the list under it
Here is the part the control-mapping advice skips. Every one of those mappings begins from an inventory. You map the tools you have. The exercise silently assumes the inventory is complete.
For the AI tools that arrived through procurement, it is. Those tools have contracts, owners and a line in the register, and mapping them to DORA and NIS2 is exactly the tidy exercise the guides describe.
For the AI tools that did not, the mapping never runs, because the tool is not on the list to be mapped. The model a team wired in over a weekend, the assistant switched on inside a platform you already licensed, the automation someone built to clear a backlog, none of these generated a procurement event, so none of them reached the inventory.
So none of them reach the mapping. They are not mapped wrong. They are not mapped at all.
This is the failure mode that a clean-looking compliance map hides. The map is accurate for everything on it. What it cannot show is the shape of what was never entered, and the tools most likely to be missing are exactly the ones that grew up outside procurement, which is increasingly where the AI lives.
You cannot map what you have not inventoried. So the real first step in mapping AI tools to DORA and NIS2 is not the mapping. It is finding the tools.
What discovery-first mapping looks like in practice
Reverse the usual order. Instead of starting from the control set and mapping down to tools, start from the estate and work up.
Discovery comes first: read across the systems the firm actually runs - the licensed platforms and their newly enabled AI features, the internal scripts and automations, the external models quietly called by a spreadsheet, and surface every AI tool touching a function that matters, whether or not it ever had a contract. This is the step that decides whether the map is true.
Only then does mapping become the tidy exercise everyone describes. Once a tool is on the list, mapping it to DORA and NIS2 is largely mechanical: identify the function it supports, place it in the DORA asset picture, check it against the NIS2 risk-management measures, and note which incident clock it could trip.
The overlap works in your favour here - most of what you record serves both regimes, and you file the divergences where they belong.
The sequence matters more than the tooling. A disciplined spreadsheet built on a complete inventory beats an expensive GRC platform built on a partial one, because the platform inherits whatever the inventory missed. Discovery is what makes the mapping trustworthy; the mapping is what makes the discovery useful. In that order.
Where to start
You do not need a programme to test whether your mapping rests on solid ground. You need to check the inventory it starts from.
Take one critical function in scope for both DORA and NIS2, and list every AI tool that supports it. Then ask which of those tools has no contract behind it. If the answer is "none", the inventory is probably incomplete rather than clean.
For each AI tool you can name, ask whether it has been placed against both regimes or only the one whose supervisor asked most recently. Tools mapped to DORA but never checked against NIS2's supply-chain measures are a common gap.
Ask when the inventory was last refreshed against the estate, not against itself. An inventory reconciled only to its own last version cannot surface an AI feature switched on since.
For the divergent thirty per cent, the NIS2-only supply-chain duties, the separate incident clocks, ask who owns the evidence, and whether it exists for the AI tools specifically or only for the traditional systems.
I will be honest about the limit. Discovery tells you the tool exists and which function it touches; it does not decide, on its own, how that tool classifies under either regime or which incident clock a given failure would start. That judgement still sits with a person who knows both the tool and the frameworks.
Finding the estate is what we can make reliable. Mapping it remains skilled work, and the map is only ever as honest as the inventory beneath it.
Frequently asked questions
Do I have to map AI tools to DORA and NIS2 separately?
Montro's position is that you map once and file twice. The two regimes share most of their controls, so a single, well-built control record for an AI tool can produce evidence for both supervisors, provided you also capture the roughly thirty per cent that is regime-specific, such as NIS2's supply-chain measures and each regime's distinct incident timeline. The prerequisite is a complete inventory; mapping cannot cover a tool the inventory never captured.
How do DORA and NIS2 incident reporting timelines differ for an AI system?
They run on separate clocks and are not interchangeable. NIS2 Article 23 requires a 24-hour early warning, a 72-hour notification and a one-month final report, timed from awareness. DORA sets its own tiered timeline for significant ICT-related incidents at financial entities. An AI tool inside a critical function can trigger both regimes from a single failure, which is why knowing the tool exists - and which function it sits in, has to come before any reporting logic is built around it.
Which AI tools get missed when mapping to DORA and NIS2?
The ones that never passed through procurement. An AI feature enabled inside an existing licensed platform, an internal automation built on an AI coding tool, or an external model called from a spreadsheet rarely generates a contract or a purchase order, so it rarely reaches the asset inventory that a DORA/NIS2 mapping is built from. These are frequently the tools closest to a critical function, which is what makes their absence from the map consequential.
Does DORA compliance mean I am already covered for NIS2?
No. DORA is the more specific regime for financial-entity ICT risk, but NIS2 can still apply to the same entity for broader governance and supply-chain obligations that DORA does not fully cover. Treating DORA as a complete substitute for NIS2 leaves the regime-specific portion unaddressed - and for AI tools, that portion often includes exactly the supply-chain and third-party questions an external model raises.
