Imagine a major European bank wakes up to find that a core cloud service provider has suffered a catastrophic cyberattack. Trading halts. Payments stop. Customers cannot access their funds. The damage ripples across borders within hours. This scenario — increasingly plausible in our hyperconnected financial ecosystem — is precisely what the Digital Operational Resilience Act (DORA) was designed to prevent.

DORA is Regulation (EU) 2022/2554, published by the European Parliament and Council on 14 December 2022, and fully applicable from 17 January 2025. It is part of the EU’s broader Digital Finance Package — a legislative ambition to modernise financial services while making them more resilient against digital threats.

DORA establishes a unified framework for digital operational resilience across all financial entities in the EU — ensuring they can withstand, respond to, and recover from all types of ICT-related disruptions and threats.

European Parliament · Recital 1, DORA Regulation

Before DORA, each EU Member State had its own patchwork of guidelines and expectations on ICT risk. A bank operating in seven countries would face seven different sets of rules — or sometimes no rules at all on certain topics. DORA replaces this fragmented landscape with a single, directly applicable rulebook that is the same in every EU country, with no need for national transposition.

DORA casts a remarkably wide net. Article 2 covers over 20 categories of financial entities and — critically — their critical third-party ICT service providers. This is a significant departure from previous frameworks, which focused only on the financial entities themselves.

DORA’s requirements are organised around five interconnected pillars, each addressing a distinct dimension of digital operational resilience. Think of them as the five legs of a stool — remove one, and the whole structure becomes unstable.

The ICT Risk Management Framework (ICTRMF) is the spine of DORA compliance. Articles 5–16 mandate that management bodies (boards and senior management) take direct ownership of ICT risk — ending the era of “that’s an IT department problem.”

The ICTRMF must cover the full lifecycle of ICT risk across six functional areas:

DORA introduces Europe’s most prescriptive ICT incident reporting regime yet. When a major ICT-related incident occurs, the clock starts immediately. Miss a deadline, and you face regulatory consequences regardless of whether the incident itself caused actual harm.

But what qualifies as a “major” incident? The RTS on major incident classification defines materiality thresholds across multiple dimensions:

• Clients affected: Number of clients impacted and whether critical services were unavailable
• Duration: Length of time the incident persisted or service was disrupted
• Geographical spread: Whether the incident crosses Member State borders
• Data losses: Integrity, confidentiality, or availability losses for critical data
• Reputational impact: Potential for significant reputational damage
• Economic impact: Direct and indirect financial losses to the entity

Importantly, DORA also introduces the concept of Significant Cyber Threats — not just actual incidents, but threats that have high potential to realise into major incidents. Entities may proactively report these to the NCA, supporting the wider threat intelligence picture.

DORA mandates a tiered testing programme. All entities must perform basic resilience testing (vulnerability scans, business continuity tests, network assessments). But for entities identified as significant — typically the largest banks, CCPs, and payment infrastructures — comes the headline requirement: Threat-Led Penetration Testing (TLPT).

/* ─── Phase 1: Scoping & Preparation ─────────────────────── */
scope = {
  critical_functions: ["payments_processing", "custody_management", "trading_systems"],
  included_tpsp:       ["core_banking_saas", "cloud_infra_provider"],
  environment:         "LIVE PRODUCTION",  // ← mandatory under DORA Art.26(2)
  nca_sign_off:        required            // ← NCA approves scope before testing begins
}

/* ─── Phase 2: Threat Intelligence ───────────────────────── */
threat_intel = {
  provider:  "accredited_CTI_provider",       // must hold NCA accreditation
  output:    "Targeted_Threat_Intelligence",  // entity-specific TTI report
  actors:    ["nation_state", "organised_crime", "insider_threat"]
}

/* ─── Phase 3: Red Team Execution ────────────────────────── */
red_team = {
  provider:            "accredited_external_tester",
  techniques:          ["initial_access", "lateral_movement", "exfiltration"],
  frequency_years:     3,               // every 3 years per Art.25(1)
  blue_team_aware:     false,           // defenders kept unaware — genuine test
  mutual_recognition: true             // one TLPT satisfies multiple NCAs
}

/* ─── Phase 4: Closure & Reporting ───────────────────────── */
output = {
  findings_report:    "detailed — shared with NCA",
  remediation_plan:   "mandatory — milestones agreed with NCA",
  submitted_to:       "National Competent Authority",
  recognition:        "valid across all relevant EU Member States"
}

A key DORA innovation: results from one TLPT exercise can be mutually recognised across NCAs in different Member States — meaning a bank operating in five EU countries can conduct a single TLPT and satisfy requirements in all five, rather than running five separate exercises. This is a significant cost and complexity reduction.

DORA’s third-party provisions are arguably its most operationally complex. Article 28 mandates that contracts between financial entities and ICT third-party service providers must include a mandatory set of contractual clauses. No clause, no contract — or at least, no compliant one.

At minimum, contracts must specify:

• Service levels: Clear SLAs with measurable availability, performance, and quality targets tied to business criticality
• Audit rights: The financial entity and its regulator must be able to audit the ICT provider — including on-site inspections
• Data location: Where data is stored, processed, and backed up — particularly relevant for non-EU cloud providers
• Sub-outsourcing: Notification requirements and consent mechanisms when the provider sub-outsources critical services
• Termination rights: Ability to exit the contract in case of serious failure, insolvency, or regulatory direction
• Incident reporting: The provider must report incidents to the financial entity without undue delay
• Business continuity: Provider’s BCP/DRP obligations and participation in the entity’s testing programme

DORA does not mandate specific technologies — it mandates outcomes and capabilities. That said, a typical DORA-compliant organisation will build around several technology pillars. Here’s a practical architecture view:

┌─────────────────────────────────────────────────────────────────┐
│  GOVERNANCE LAYER                                              │
│  GRC Platform  │  Policy Mgmt  │  Risk Register               │
└────────────────────────────┬────────────────────────────────────┘
                             │
┌────────────────────────────▼────────────────────────────────────┐
│  DETECTION & RESPONSE                                          │
│  SIEM (log aggregation)  │  SOAR (automated response)        │
│  EDR  (endpoint detect)  │  NDR  (network detection)        │
│  Threat Intel Platform   │  Vulnerability Management       │
└────────────────────────────┬────────────────────────────────────┘
                             │
┌────────────────────────────▼────────────────────────────────────┐
│  RESILIENCE LAYER                                              │
│  BCP/DRP Tooling  │  Backup Orchestration  │  DR Testing  │
│  Change Mgmt ITSM │  CMDB (asset inventory) │  Config Mgmt │
└────────────────────────────┬────────────────────────────────────┘
                             │
┌────────────────────────────▼────────────────────────────────────┐
│  THIRD-PARTY RISK MANAGEMENT                                   │
│  Vendor Portal  │  Contract Repository  │  Audit Workflow    │
│  Concentration Risk Dashboard  │  CTPP Register               │
└────────────────────────────┬────────────────────────────────────┘
                             │
┌────────────────────────────▼────────────────────────────────────┐
│  REPORTING LAYER                                               │
│  Incident Classification Engine  │  NCA Reporting Portal     │
│  Regulatory Dashboard            │  DORA Metrics KPI Tracker │
└─────────────────────────────────────────────────────────────────┘

Critically, DORA requires these systems to be integrated, not siloed. An incident detected in the SIEM must automatically feed the GRC platform’s incident register, trigger the classification engine, and populate the draft regulatory report — all within the tight 4-hour initial notification window.

DORA leaves penalty-setting primarily to Member State law, but establishes the minimum requirements for supervisory powers. Competent authorities must be empowered to issue:

DORA does not operate in isolation. It intersects with — and in some areas supersedes — existing frameworks and regulations. Understanding the relationship is essential for a lean, non-duplicative compliance programme.

Whether you’re a compliance officer, a CISO, an IT architect, or a vendor trying to understand what your financial-sector clients need from you — here is a practical starting checklist:

• Confirm your in-scope status — Check Article 2 against your entity type and size. Micro-enterprise exemptions may apply.
• Complete an ICT asset inventory — You cannot manage what you cannot see. A CMDB covering hardware, software, data, and dependencies is your first deliverable.
• Map critical business functions to ICT assets — Feed this into a Business Impact Analysis (BIA) to identify which assets truly need the highest level of protection.
• Review all ICT vendor contracts — Against the mandatory clauses in Article 30. Create a remediation plan for non-compliant agreements.
• Establish an incident classification and reporting process — Build your 4-hour / 72-hour / 1-month reporting capability before you need it.
• Engage your board — Prepare a board briefing on DORA governance obligations. Obtain formal approval of the ICT risk management framework.
• Run a basic resilience testing cycle — Vulnerability assessments, pen tests, BCP/DRP tabletop exercises to identify gaps before regulators do.
• Assess TLPT applicability — If you are a significant entity, begin planning a TIBER-EU/TLPT exercise in coordination with your NCA.
• Monitor for RTS/ITS updates — The ESAs continue to publish technical standards. Assign a regulatory tracking function.

The most important thing to understand about DORA is its spirit. This regulation is not designed to generate paperwork — it is designed to make the European financial system genuinely harder to break. The financial crisis of 2008 showed the world how interconnected financial vulnerabilities can cascade catastrophically. DORA is the EU’s answer to ensuring that the digital equivalent of that crisis — a cyber-induced systemic collapse — never happens.

Done well, DORA compliance is an opportunity. Organisations that build mature ICT risk management capabilities, develop robust incident response muscles, and genuinely understand their third-party dependencies will be more resilient, more trustworthy, and better placed to weather whatever the evolving threat landscape throws at them.

Resilience is not a state you achieve and maintain — it is a discipline you practise, continuously, until it becomes reflex.

Principle of Operational Resilience

DORA has arrived. The question is no longer whether to comply — it is how deeply you understand it, how intelligently you implement it, and how genuinely it transforms your organisation’s relationship with digital risk.