In the second half of 2026, GRC teams at European companies are juggling three regulatory frameworks at once: NIS2 for cybersecurity, DORA for financial operational resilience, and the EU AI Act for AI governance. Each has its own deadlines, supervisory authorities and specific obligations. Yet their areas of overlap are substantial, and organisations that treat them as three separate projects duplicate their efforts, exhaust their teams and create documentary inconsistencies that weaken compliance under each of them. According to a study by the Europe GRC Forum published in 2026, organisations that have integrated their multi-regulation programme reduce their documentation burden by 38 % on average, while improving their maturity score under each framework.
Three regulations, one shared underlying infrastructure
NIS2 requires cybersecurity risk management, third-party supervision and incident notification within 24 hours. DORA requires digital operational resilience, management of ICT third-party providers and targeted penetration testing. The EU AI Act requires governance of high-risk systems, effective human oversight and continuous auditability. These three frameworks share a common foundation that is no accident: risk register, mapping of critical third parties, audit trail, continuous assessment and system documentation. An organisation that handles these obligations in silos produces three separate registers, three third-party policies and three notification processes, with definitions that diverge within the same legal scope.
The source of the problem is often organisational before it is documentary. In many companies, the NIS2, DORA and EU AI Act projects were launched by different teams (security, financial risk, legal department), with different consultants, different tools and no structural coordination. The result: the same cloud provider is assessed three times, under three distinct questionnaires, with results that may contradict each other without anyone noticing.
The four areas of real overlap
Third-party register and subcontracting chain. NIS2 (Article 21(3)), DORA (Articles 28 to 30) and the EU AI Act (Article 25) each require a mapping of critical providers, with varying levels of due diligence. The definition of "critical provider" differs between texts, but the entities concerned overlap considerably. A cloud provider hosting a financial AI system may fall simultaneously within the scope of DORA, NIS2 and the EU AI Act, with internal teams that do not coordinate their assessment and contracts that cover the obligations of only one framework.
Incident notification. NIS2 requires an initial notification to France's national cybersecurity agency (ANSSI) within 24 hours. DORA requires notification to financial supervisory authorities within 4 hours for major incidents. The EU AI Act requires notification "without undue delay" in the event of a serious malfunction of a high-risk system. Three thresholds, three recipients, three forms. The documented error: a cyber incident affecting both financial systems and a decision-support AI tool is handled by three teams in parallel, with statements that describe the same fact differently. During an investigation, this inconsistency is read as a governance failure, even though each individual obligation was technically met.
Documentation of critical systems. NIS2 requires documentation of security measures. DORA requires a detailed inventory of ICT assets. The EU AI Act requires technical documentation for high-risk systems. If your credit-scoring AI runs on infrastructure covered by DORA, you document the same environment three times, under three different terminologies, for three distinct authorities. Duplication is not only inefficient: it multiplies points of desynchronisation.
Resilience testing and audits. Targeted DORA penetration tests, NIS2 security exercises and EU AI Act robustness tests often target the same infrastructure. A well-documented resilience test can feed all three compliance regimes, provided its scope was defined with all three frameworks in mind. Without coordination, the three teams commission three separate tests on the same scope, from different providers, on staggered dates.
The three-layer method
Rationalisation does not mean merging what must remain separate. It means building a three-tier documentation architecture.
Layer 1: Common foundation. Shared risk register, unified third-party management policy with a qualification tree (NIS2 / DORA / AI Act / overlap), catalogue of critical systems and assets, and an incident notification process with a multi-regulation decision tree. These elements feed all three compliance regimes without duplication. A single third-party register, updated once, propagates information to all three frameworks.
Layer 2: Specific modules. Each regulation adds its own obligations on top of this foundation. NIS2: technical cybersecurity measures, business continuity plan, reporting to ANSSI. DORA: TLPT tests, strengthened contractual clauses for critical ICT providers, register of concentrations. EU AI Act: bias assessment, effectiveness of human oversight in production, notification to competent national authorities.
Layer 3: Regulatory interfaces. The final documents, formatted to the requirements of each authority. This is the only layer that is triplicated, and that is acceptable, since it rests on a coherent common base. The classic mistake is to work backwards, starting from the formats regulators expect and building in reverse. This approach inevitably produces silos, because the different formats implicitly encode different definitions that teams end up treating as distinct.
Three signs that your silos are costing you
Your NIS2 lead and your DORA lead do not talk to each other in a structured way. If cyber incident management does not include a systematic decision on which DORA obligations apply to the event, you have an active operational silo.
Your providers receive several distinct due diligence questionnaires from different teams in your organisation. Beyond being inefficient, this signal reveals internal disorganisation to your partners, an image problem for an organisation whose value proposition rests on mastering risk.
Your EU AI Act technical documentation does not reference your NIS2 policies, even though your AI systems run on infrastructure that depends on them. This documentary inconsistency is precisely what the first cross-inspections surface immediately, for example when an AI Act inspector asks to see the security policy of the underlying infrastructure.
Assessing your level of convergence
A convergence diagnosis can be conducted in two weeks: an inventory of systems and providers common to the three scopes, an analysis of the inconsistencies between the definitions used in each project, and a mapping of the tests and audits performed to identify duplicates. Organisations that start this process now, ahead of the first EU AI Act checks planned for autumn 2026, still have time to build the common foundation before being audited against each of the three frameworks separately. Presidio offers a multi-regulation mapping module that automates the propagation of a common risk register to the three frameworks. To qualify your current level of convergence, see also our analysis of third-party governance under NIS2 and structural gaps in EU AI Act documentation governance, or contact our team for a 30 minute interview.
Conclusion
NIS2, DORA and the EU AI Act are not three projects. They are three views of the same digital operational risk. Organisations that understood this before the first cross-inspections have a structural advantage: their teams do not duplicate work, their registers do not contradict each other, and their incident response is consistent whichever regulator asks the question. The second waves of audits in 2026-2027 will only widen the gap between those who architected their GRC programme and those who assembled it in a hurry. The question is not whether you will converge. It is what it will cost you to wait.