Regulatory overlap of DORA, NIS2, ENS and the AI Act: comply without duplicating

In the regulated organisations I work with, almost no one complies with a single regulation. A financial institution has to answer to DORA, NIS2, the GDPR, the EU AI Act and, if it provides services to the public sector, also the ENS, all at once. The mistake I see again and again is tackling each framework as an independent project, with its own team, its own documentation and its own audit. Well-managed regulatory overlap is exactly the opposite: comply once and demonstrate several times.

Why regulatory overlap is an opportunity, not a problem

When you overlay the requirements of DORA, NIS2, the GDPR and the EU AI Act, you find that they share a far larger common base than it seems. Risk management, incident control, business continuity, supplier governance and traceability appear, with nuances, in almost all of them. Dealing with that common core just once saves months of work and, above all, avoids contradictions between documents that an auditor then spots straight away.

In the projects I lead, the first step is always to map that overlap. I do not start with the regulation, I start with the control: I identify which measure satisfies several frameworks at once and document it just once with cross-references. That cross-cutting view is what makes compliance sustainable.

Incident management: the most obvious overlap

The clearest example is incident notification. The GDPR requires notifying a personal data breach within 72 hours. NIS2 imposes an early warning within 24 hours for significant incidents. DORA adds its own deadlines for ICT-related incidents in the financial sector. They are three different clocks on, very often, the same event.

If you manage each deadline separately, chaos reigns on the day of the incident. If you have designed a single detection, classification and notification process that covers the three frameworks, the team knows exactly who to alert and when. Regulatory overlap, here, translates into a single well-rehearsed flow instead of three improvisations.

Risk management and resilience: from the ICT framework to the AI system

The DORA regulation requires a robust ICT risk management framework in the financial sector. NIS2 asks for equivalent cybersecurity risk management measures for essential sectors. The EU AI Act adds its own risk management system for high-risk AI systems. Again, three requirements that can be built on a common risk methodology.

What I recommend is a unified risk matrix that tags each risk with the regulations it responds to. That way, when the DORA audit or the AI Act conformity assessment comes, nothing is rebuilt: you filter the existing matrix. I applied this logic from day one and it is what underpins the compliance tool I am developing.

The ENS and the public sector in the equation

When the organisation provides services to the public administration, the National Security Framework also comes into play. The ENS shares many controls with NIS2 on protection and with DORA on operational continuity. Mapping the ENS alongside the rest prevents the public-sector team and the banking team from duplicating evidence that, deep down, demonstrates the same thing.

How to build a regulatory overlap map

Inventory the controls, not the regulations

The starting point is your own catalogue of controls, independent of the regulations. Each control is described once and tagged with the frameworks it satisfies. This approach, which I also base on my general IT regulations strategy, avoids the classic problem of having five slightly different backup policies.

Cross-reference obligations and detect gaps

With the catalogue built, you cross each obligation of each regulation against your controls. What does not fit is a real gap that must be covered; what fits several frameworks is an efficiency you have gained. This is exactly the overlap-detection function I have built into my compliance platform, because doing it by hand in a spreadsheet does not scale.

Keep the traceability alive

The map is not a one-off deliverable: it changes every time a regulation is updated or a new service is added. That is why regulatory overlap is better managed as a continuous process, with owners and periodic reviews, than as a document that ages in a drawer.

Conclusion: comply once, demonstrate many times

After years dealing with cross audits, my conviction is firm: regulatory overlap is not an additional burden, it is the lever that makes compliance viable in an increasingly dense regulated environment. Whoever understands where DORA, NIS2, GDPR, AI Act and ENS intersect stops dreading every audit and starts managing them as a single coherent discipline.

Frequently asked questions about regulatory overlap