The 5 pillars of DORA explained simply (with concrete examples)

The DORA regulation (Digital Operational Resilience Act, Regulation EU 2022/2554) came into application on 17 January 2025. It imposes a common foundation of digital operational resilience on the entire European financial sector — some twenty categories of entities, from large banks to asset managers, payment institutions and insurers.

Behind the acronym lies a clear architecture: five pillars. Understanding them means understanding most of what the regulator expects. Here is each one, explained simply and illustrated.

Pillar 1 — ICT risk management

This is the foundation. DORA requires every entity to have an ICT risk management framework: identifying its IT assets, mapping its dependencies, protecting its systems, detecting anomalies, and organising recovery in the event of failure.

An often underestimated key point: this framework is the responsibility of the management body. It is not a subject to be entirely delegated to IT. The board or management committee must approve the resilience strategy, define the ICT risk appetite and monitor trade-offs.

Concrete example. An asset manager must be able to say which critical functions (valuation, order routing, regulatory reporting) rely on which systems and which providers — and what happens to the business if one of them fails.

Pillar 2 — Managing, classifying and reporting incidents

DORA harmonises the way ICT-related incidents are detected, classified and reported. When an incident is classified as major according to the regulatory criteria, the entity must notify its competent authority on a strict timeline: a rapid initial notification after classification, an intermediate report as the situation evolves, then a final report once root-cause analysis is complete.

The clock starts at the moment of classification, not detection — a technical point with heavy consequences. Without a tooled process, meeting the deadlines mid-crisis becomes improvisation.

Concrete example. A payment institution suffers an outage at its cloud provider affecting its payment services. Even if the incident originates with a third party, it is the financial entity that bears the notification obligation.

Pillar 3 — Digital operational resilience testing

DORA imposes a proportionate testing programme: regular basic tests for all entities, and advanced tests of the TLPT (Threat-Led Penetration Testing) type for the most significant players. The idea: not to wait for the real incident to discover your breaking points.

The regulator expects an annual test plan, credible threat scenarios, traced results and follow-up of corrective measures. A test that is carried out but not documented is worth almost nothing in the supervisor's eyes.

Concrete example. Testing the restoration of your data after a simulated attack, measuring the real recovery time (RTO) and comparing it to the target.

Pillar 4 — Managing ICT third-party risk

This is the pillar that caused the most difficulty, by far. DORA governs the relationship with ICT providers at every stage: due diligence before contracting, mandatory minimum contractual clauses (audit rights, data location, cooperation with authorities, reversibility, subcontracting management), and continuous monitoring.

Two structuring requirements follow: keeping a register of information listing all ICT contractual arrangements, and analysing concentration risk — the fact that several critical functions depend on the same provider, or a small number.

Concrete example. If your management tool, your hosting and your reporting solution all rely on the same technology group, you have a concentration the regulator wants to see identified — before it does.

Pillar 5 — Sharing information on cyber threats

More flexible than the others, this pillar encourages financial entities to exchange, on a voluntary basis, operational information on cyber threats and vulnerabilities. DORA even provides for the possibility of voluntarily notifying a significant cyber threat, before it even materialises as an incident.

Concrete example. An entity detects a sophisticated intrusion attempt stopped by its defences; it may choose to report it to its authority to feed the collective understanding of the threat.

How these pillars fit together in practice

The common mistake is to treat these five pillars as five separate projects. In reality, they share the same data. An incident (pillar 2) often involves a third party (pillar 4), affects an asset managed in the risk framework (pillar 1), and feeds the following year's testing programme (pillar 3). Compartmentalising this information into separate files means condemning yourself to constant reprocessing and to inconsistencies the supervisor spots immediately.

Where Axenia fits in. Instead of handling each pillar in a separate tool, Axenia links evidence across all five pillars: an update on third parties or incidents propagates through the rest of the framework, so it stays demonstrable on an ongoing basis.

---

This article is educational in purpose and does not constitute legal advice. Refer to the official texts for any compliance decision.

See how Axenia links your five DORA pillars. Book a demo →