DORA: the European Framework for Operational Resilience

The financial sector has become a dense, interconnected digital ecosystem, heavily dependent on external service providers. A cloud outage, an attack on a software vendor, a failure in a critical service, within minutes, a local incident can now trigger systemic consequences.

It is in this context that the European Union created DORA (Digital Operational Resilience Act), applicable since January 2025, a key milestone, as its requirements are now fully in force. This regulation is not simply about strengthening cybersecurity; it aims to ensure that organisations remain operational, even when their technologies falter.

DORA demands greater control, visibility, and coherence in how organisations manage their digital operations as a whole: information systems, critical processes, external dependencies, risk management, and incident response capabilities. What DORA fundamentally changes is the need to view the entire digital organisation as a living, interconnected, and strategic system, whose mastery directly determines the company’s operational resilience.

In this new paradigm, enterprise architecture and mapping take on a central role. They make dependencies visible, clarify risks, and structure digital governance.

DORA: The New Contract of Digital Resilience

Why DORA? A response to a systemic risk

With the widespread adoption of cloud services, the explosion of SaaS solutions, and the increasing interconnection of financial actors, the European banking system now depends on a growing number of critical service providers. This hyper-dependence creates a structural vulnerability: a failure at a major provider can, within minutes, impact dozens of institutions.

This is exactly what the AMF highlights: ICT providers have become central links in the chain of financial stability. DORA is therefore designed as a safety net, a harmonised European framework to prevent domino effects and strengthen the operational resilience of financial institutions.

Adopted at the end of 2022 (Regulation EU 2022/2554) and applicable since 2025, DORA is part of a broader European effort to regulate digital risk. Alongside NIS2, GDPR, and ISO 27001, it stands as the first regulatory framework specifically dedicated to the operational resilience of the financial sector, with a uniform and binding level of requirements for all entities concerned.

A paradigm shift: from cybersecurity to resilience

DORA does not simply impose additional controls; it changes the way organisations approach risk.

The shift moves from a logic of protection (preventing the incident) to a logic of resilience (continuing to operate despite the incident).

This vision requires:

• living evidence of control over the information system,
• up-to-date mappings,
• a complete and governed ICT asset register,
• regular testing plans (including TLPT),
• continuous governance rather than a periodic audit.

In other words, resilience becomes an operational capability, not merely a compliance objective.

A broad scope… and a regulatory convergence

DORA applies to all financial actors: banks, insurers, asset managers, market infrastructures, crypto-service providers, etc.

But its reach goes further: ICT providers deemed critical also fall under its influence, as their reliability directly conditions that of their clients.

DORA does not operate in isolation. It interacts with:

• NIS2, which covers a broader set of sectors (energy, health, transport, water, digital…) focused primarily on cybersecurity;
• DORA, as a lex specialis, strictly dedicated to the financial sector and centred on operational resilience, the ability to ensure business continuity;
• GDPR, which governs personal data;
• ISO 27001, which frames risk management;
• and other European directives on digital security.

This distinction is crucial: NIS2 protects; DORA ensures continuity.

The Five Pillars of DORA: An Architecture of Resilience

DORA is not a list of obligations; it is a structured architecture of resilience.

The AMF states very clearly: “entities must demonstrate the ability to withstand, respond to, and recover from ICT-related incidents.” (source: AMF - French Market Authority)

This logic rests on five interdependent pillars.

1. ICT Risk Management: a structured framework

DORA imposes a formal framework for ICT risk management.

According to the AEIP, “risk management must cover the entire lifecycle of digital assets and their dependencies.” (source: AEIP)

This includes:

• identifying and assessing risks,
• defining responsibilities,
• implementing prevention and remediation mechanisms.

This pillar requires a systemic vision, not a scattered inventory across Excel files.

2. Incident Management: detect, classify, notify

The AMF states that entities must “rapidly detect major incidents, classify them according to a harmonised taxonomy, and notify the competent authorities.”

The spirit is clear: respond quickly, document correctly, and learn from every incident.

3. Resilience Testing: turning theory into evidence

DORA requires regular testing, including, for some institutions, TLPT (Threat-Led Penetration Testing).

EUR-Lex notes that these tests must be “conducted by qualified teams and aim to reproduce realistic attacks.” (source: Regulation EU 2022/2554)

The goal: to prove resilience, not merely declare it.

4. Third-Party Risk Management: responsibility remains internal

DORA reinforces a simple rule: outsourcing does not remove accountability. Financial institutions must know their providers, monitor their risk levels, analyse concentration risks, and maintain credible exit strategies, a critical requirement in a landscape dominated by a handful of cloud actors.

But DORA’s real shift lies in the notion of risk propagation. A critical service provider may itself rely on other services or subcontractors. A failure anywhere in this chain can ultimately impact the financial institution.

This is why DORA introduces a dual obligation:

• master your own service providers,
• ensure that those providers master their own dependencies.

ICT providers deemed critical are therefore directly subject to DORA, with their own resilience and transparency requirements.

Resilience is no longer assessed at the level of a single institution; it must be evaluated across the entire digital ecosystem.

5. Information Sharing: collective resilience

DORA encourages institutions to exchange information on threats and incidents to reinforce sector-wide resilience.

The AEIP even refers to “necessary operational cooperation in the face of rapidly evolving risks.”

In summary, DORA “completes existing requirements by introducing digital operational resilience covering the end-to-end functioning of financial entities.”

This is not a stricter BCP/DRP: it is an end-to-end view of the IS, including critical ICT-related functions, application dependencies, critical third parties, and cyber scenarios.

DORA does not only ask organisations to continue functioning: it asks them to understand how they function.

Enterprise Architecture: the engine of DORA evidence

If DORA makes one conviction unavoidable, it is this: you cannot demonstrate resilience without understanding your information system in depth.

And this understanding relies on a living Enterprise Architecture capable of providing a clear view of the internal mechanisms that allow the business to operate.

EA as the foundation of systemic vision

DORA requires fine-grained traceability across the chains linking business capabilities, processes, applications, data, infrastructure, external providers, and associated risks.

The AMF insists on the need for “precise knowledge of critical functions and their dependencies”, something impossible to achieve with scattered inventories or static diagrams.

Enterprise Architecture provides this structure: a coherent model linking each part of the IS to its role, interactions, and operational importance.

Living mapping: making the system visible, explainable, and demonstrable

Under DORA, traditional mapping has no value.

What is required is a living, centralised, continuously updated mapping that can be explained. Showing what happens when an application fails, how a critical ICT-related function relies on a cloud provider, or what sensitive data flows through a process.

This ability to tell the real story of the system constitutes the “living proof” DORA expects.

Why Boldo becomes a natural accelerator of compliance

The platform allows teams to rapidly model functions, processes, and applications, then automatically generate a coherent ICT register.

Readable dependencies, impact views, simulated scenarios: teams can easily demonstrate IS mastery. Compliance becomes the natural outcome of a structured architecture.

Conclusion: turning compliance into a strategic advantage

DORA is not just a regulation: it is an opportunity to rethink how the organisation understands, structures, and governs its information system. When used correctly, this approach becomes a strategic lever for both the Executive Committee and the CIO.

But the deepest impact is cultural: DORA imposes a shared language, new clarity, and collective governance.

This is precisely the perspective of our article: Turning DORA & NIS2 into a Sustainable Competitive Advantage.

With Boldo, this transformation becomes tangible: a living, collaborative, understandable architecture that supports DORA requirements while creating long-term value.