The 5 Pillars of DORA Explained – Building Digital Resilience in Financial Services

DORA (the Digital Operational Resilience Act) is now in force across the EU. From January 17, 2025, financial entities have moved from awareness to action. Supervisors are aligning how major incidents are reported, how resilience testing runs, and how critical ICT providers are overseen. If you work in EU financial services—or support it as an ICT provider—this is the time to turn plans into proof.

In our Complete Guide to DORA, we explained who DORA affects. Here, we’ll unpack how it works in practice—through its five foundational pillars—so you can assign owners, put the right controls in place, and keep audit-ready evidence without overbuilding.

For the full source text, see Regulation (EU) 2022/2554 on EUR-Lex.

DORA organizes its duties into five working parts you can run as a program:

1. ICT Risk Management

2. Incident Reporting

3. Digital Operational Resilience Testing

4. Third-Party Risk Management

5. Information Sharing

These DORA pillars give teams a simple structure for day-to-day compliance and a shared language with auditors and supervisors.

What DORA Expects

1. Governance: an executive owner, clear decision rights, named control owners, and board reporting
   
   
2. Identification: a live register of business services, supporting systems, data, and ICT third parties (with criticality and dependencies)
   
   
3. Protection: preventive controls across identity and access management (IAM), configuration/change, hardening, backups, and secure development
   
   
4. Detection: monitoring for key events and control health; thresholds for “major” vs. routine issues; reliable logging and retention
   
   
5. Response & recovery: tested playbooks, RTO/RPO targets, contact lists, and post-incident reviews with tracked fixes

This is the engine of the DORA framework. Supervisors expect proof of operation, not policy alone, so design for evidence from day one.

The Operational Checklist

1. One register: keep services, systems, data, and ICT suppliers in a single view with owners, criticality, and dependencies
   
   
2. Lean control library: start with access, configuration/change, backup/restore, logging/monitoring, vulnerability, and secure development
   
   
3. Map once: tag each control to DORA requirements and to ISO/IEC 27001 Annex A so you can test once and reuse evidence
   
   
4. Cadence: define method, frequency, pass/fail, and retest after fixes
   
   
5. Evidence first: store approvals, tickets, logs, configuration exports, restore results, and review notes where auditors can find them
   
   
6. Close the loop: feed incident and testing findings back into risk; update owners and controls; track time-to-close and retest pass rates

Why This Matters

When governance, identification, protection, detection, and recovery run as one cycle, you reduce incident impact, shorten audits, and create repeatable DORA ICT risk management with audit-ready proof.

The Reporting Clocks

DORA harmonizes major ICT incident reporting with EU-wide timelines and templates:

1. Initial notification: within 4 hours of classifying as major and no later than 24 hours from detection
2. Intermediate report: within 72 hours
3. Final report: within 1 month

Use the ESAs major-incident reporting RTS/ITS templates as the field model so your forms and workflow align cleanly from detection to authority.

Harmonized Thresholds (What Counts as “Major”)

The ESAs define classification criteria and materiality thresholds (service impact, customers affected, data affected, and time to recover). Your internal thresholds, forms, and dashboards should align to the ESAs field names. That way, analysts don’t re-key under pressure, and leadership sees the same numbers that go to the authority.

What’s New For 2026

Unified templates and procedures from the ESAs reduce national variation. As national tooling matures through 2026, expect more consistent content and timing, and fewer one-off forms.

Runbook Basics

1. Pre-build the 4h/24h/72h/1-month data fields
2. Rehearse quarterly with a timed tabletop; capture how long evidence takes to assemble
3. Maintain a living incident evidence pack: timeline, root cause, business impact, containment/recovery actions, and lessons learned
4. After the final report, close corrective actions and retest controls tied to the root cause

Why This Matters

Getting the clocks and fields right cuts rework in the first 24 hours, keeps leadership and regulators on the same facts, and reduces the risk of late corrections. Aligning to the ESAs template names and keeping a ready evidence pack also shortens audit cycles and avoids divergence as national tooling converges in 2026.

What DORA Expects

DORA defines two types of operational resilience testing:

1. Baseline testing: vulnerability scans, configuration reviews, restore/failover drills, and tabletop exercises on a defined cadence
2. Threat-Led Penetration Testing (TLPT): required for entities designated by their competent authority. TLPT aligns to TIBER-EU, with scope and frequency set by that authority

Frequency At A Glance

Note: exact TLPT scope and cadence are set by your TLPT authority; align your plan and supplier participation early.

Operating Approach

1. Maintain a rolling plan tied to critical business services and risks
   
   
2. Link each test to the specific control(s) it proves; record results, owners, deadlines, and retests
   
   
3. For TLPT, focus on critical functions and realistic threat scenarios; pre-agree legal/safety guardrails and involve key suppliers
   
   

Why This Matters

Planned, repeatable testing turns assumptions into evidence. It shows controls work in practice, focuses fixes where risk is highest, and prepares you for TLPT without last-minute scrambling.

What DORA Expects

DORA introduces EU-level oversight for critical ICT third-party providers (CTPPs)—cloud, SaaS, and infrastructure platforms many firms rely on. A designated Lead Overseer (one of the ESAs) coordinates examinations with Joint Examination Teams (JETs). Your firm stays accountable for outcomes even when services are outsourced.

Contracts, Evidence, and the Shared Boundary

1. Flow-down obligations: embed terms for incident cooperation (timelines that support regulatory reporting), participation in testing where relevant (including TLPT support), resilience outcomes (RTO/RPO targets), reporting/audit rights, data-location controls, change notifications, and exit/substitution rights
   
   
2. Evidence on a cadence: request supplier artifacts on a schedule (pen-test summaries, recovery drill results, certifications, uptime/incidents, sub-processor lists) and track expiries
   
   
3. Concentration oversight: monitor exposure by provider, region, and service; set mitigations for “too-big-to-fail” scenarios
   
   
4. Shared accountability boundary: you carry the regulatory duty; suppliers must cooperate and evidence their part so you can meet it

Why This Matters

Most resilience gaps hide in the supply chain. Clear flow-down terms, recurring evidence, and visibility of concentration risk turn third-party reliance into managed, provable DORA compliance.

Purpose

DORA encourages cyber-threat information sharing so firms can spot attacks earlier and respond faster. The goal is collective resilience: one entity’s signal becomes everyone’s head start.

Guardrails

Sharing should happen in trusted communities and follow confidentiality, data-protection, and competition-law rules. Keep legal and privacy teams involved. Define what can be shared (e.g., indicators of compromise, TTPs, hardening guidance) and what must be withheld or anonymized.

How it Looks in Practice

Join a sector body like FS-ISAC or a national financial-sector sharing group. Set owners for ingest → assess → act:

1. Ingest: pull daily threat feeds and alerts
   
   
2. Assess: validate relevance against your estate and suppliers
   
   
3. Act: update detections, block indicators, and harden configurations; record what changed and why

Keep a short log of items received and actions taken—this shows value and supports audits.

Why This Matters

Turning shared intelligence into detections and hardening actions cuts time-to-detect and keeps firms on the same facts during sector-wide campaigns. Anchoring participation to Article 45 and documenting the steps makes the practice safe, repeatable, and audit-ready. 

The closed-loop

The five pillars operate as a loop you run every day:

1. Identify services, systems, data, and suppliers (Pillar 1).
   
   
2. Protect with mapped controls and ownership (Pillar 1).
   
   
3. Test those controls on a cadence; run TLPT where required (Pillar 3).
   
   
4. Report major incidents on time with consistent fields (Pillar 2).
   
   
5. Improve by closing actions, updating risks, and applying shared intelligence (Pillars 1 & 5), including supplier follow-through (Pillar 4).

Pillars 4 and 5 (third-party oversight and threat intelligence) overlay the entire loop, shaping control priorities, tests, and incident handling end-to-end.

Link to ISO 27001 and NIS2 

ISO/IEC 27001: many controls overlap (access, logging, backup, change, vulnerability). Keep one control library and tag each control to DORA and Annex A so you test once and reuse evidence across frameworks.

NIS2: incident timing and escalation are similar in spirit. Align data fields and playbooks so teams don’t duplicate effort when one event touches both regimes.

Practical rule: if a control or process already exists, map it; only create new ones where DORA adds a clear requirement (e.g., major-incident thresholds, supplier registers, TLPT governance).

SureCloud gives you one place to run the DORA framework day to day. Keep a single register, map controls once, automate evidence, and report with confidence.