DORA One Year On: The Five Pillars Regulators Are Actually Testing

DORA · Digital Operational Resilience · Financial Services · ICT Risk · Third-Party Risk · TLPT Register of Information · EU Regulation

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — became applicable on 17 January 2025 for virtually the entire EU financial sector: banks, payment and e-money institutions, investment firms, insurers, fund managers, trading venues, and crypto-asset service providers under MiCA. Unlike a directive, DORA needed no national transposition; it applies directly and identically across the Union. A year and a half in, supervisory reviews have moved past awareness campaigns into gap findings. The regulation rests on five pillars, and the maturity bar for each is now visible.

Pillar 1: ICT risk management (Articles 5–16). DORA's foundation is a documented, board-owned ICT risk management framework. Article 5 is deliberately blunt: the management body bears ultimate responsibility for ICT risk, must approve the ICT security policies, set the digital risk appetite, and secure adequate budget and training. The most common finding here is structural — the framework exists, but it is a CISO document the board has never formally approved. Beneath governance sit the operational articles: a complete ICT asset register mapped to critical functions (Art. 8), access control and patching (Art. 9), detection capability (Art. 10), business continuity with defined RTO/RPO (Art. 11), and backups that are stored separately and tested for restorability (Art. 12). Untested backup restores remain one of the most frequently cited gaps.

Pillar 2: Incident management and reporting (Articles 17–23). DORA imposes the tightest reporting clock in EU law. Once an incident is classified as major — using the quantitative thresholds in the classification RTS (CDR (EU) 2024/1772) — three deadlines fire: an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report with root-cause analysis within one month. Four hours is unforgiving. It requires a pre-agreed classification matrix, a named decision-maker, and templates aligned with the reporting ITS ready before anything burns. If your incident runbook still says "notify legal, who will assess," you will miss it.

Pillar 3: Resilience testing (Articles 24–27). Every in-scope entity needs an annual testing programme — vulnerability assessments, scenario tests, and network security assessments performed by independent parties. Significant entities face the harder requirement: threat-led penetration testing (TLPT) every three years against live production systems, using external red teams and threat intelligence to mimic real adversaries, aligned with the TIBER-EU model. TLPT is not a pen test with a new name; it is an intelligence-led adversarial simulation with competent-authority involvement before and after, ending in a formal attestation.

Pillar 4: ICT third-party risk (Articles 28–44). This pillar generates the most work by volume. Entities must maintain a Register of Information — a structured inventory of every ICT service arrangement with mandatory fields (provider LEI, service type, data locations, substitutability, sub-processor chains) defined in CIR (EU) 2024/2956 — and submit it to their supervisor. A vendor spreadsheet does not qualify. Contracts supporting critical functions must contain the Article 30(2) provisions: audit and access rights for the entity and the regulator, exit and termination rights, data portability, and sub-contracting consent. Legacy cloud contracts almost never contain these clauses, which is why contract remediation has dominated DORA programmes. Add concentration-risk assessments (is one hyperscaler under three of your critical functions?) and documented exit strategies, and you have the pillar most likely to be under-resourced. The counterweight: the largest providers are themselves designated as critical ICT third-party service providers and placed under direct ESA oversight.

Pillar 5: Information sharing (Article 45). The gentlest pillar — a legal safe harbour for financial entities to exchange cyber threat intelligence within trusted communities, provided confidentiality and competition rules are respected.

One boundary worth stating plainly: DORA is lex specialis for finance. If DORA covers you, its requirements displace the equivalent NIS2 obligations — do not run two parallel incident-reporting programmes for the same event.

Where should a lagging programme focus? Three places. Get board fingerprints on the framework, because Article 5 findings are governance findings and land at the top. Rehearse the 4-hour classification-to-notification path until it is boring. And treat the Register of Information as a living data product, not an annual scramble — it is the artefact your supervisor will ask for first, and its quality signals everything about the programme behind it.