DORA Explained: The EU’s New Digital Resilience Rulebook

This is part of an 18-day series building an open-source EU banking data governance pipeline that produces a valid EBA XBRL COREP submission. Today’s deep dive: DORA — the regulation that makes IT resilience as mandatory as capital adequacy.

On 17 January 2025, every bank, payment institution, insurer, investment firm, and crypto-asset service provider in the EU became subject to a new regulation that most of their IT departments were not ready for.

DORA — the Digital Operational Resilience Act — is EU Regulation 2022/2554. It does for ICT risk what CRR did for capital risk: replaces a patchwork of national guidelines with a single, directly applicable, binding EU framework.

If you are a data engineer building pipelines for financial services, DORA affects what data you must capture, how long you must keep it, what incidents you must log, and how the systems you build must be documented. This post covers everything you need to know — the five pillars, the data requirements behind each one, and what it means in practice for a team building a regulatory reporting pipeline.

Why DORA Exists: The Problem It Solves

The 2008 financial crisis taught regulators to focus on capital adequacy. Banks needed more capital, better quality capital, and liquidity buffers. The Basel III framework delivered all of that through CRR and CRD.

But by 2015 it was clear that a different category of risk was growing faster than capital frameworks could address: technology failure.

Consider what happened in the decade before DORA:

• 2016 — Bangladesh Bank SWIFT hack: Attackers gained access to the central bank’s SWIFT messaging system and stole $81 million by sending fraudulent payment instructions. The vulnerability was not a capital shortfall — it was an ICT access control failure.
• 2017 — WannaCry ransomware: Spread across EU banks, telecoms, hospitals, and government systems simultaneously. Banks with unpatched Windows systems had their operations frozen within hours. No amount of CET1 capital helped.
• 2019 — Capital One cloud misconfiguration: A single misconfigured firewall rule exposed 106 million customer records. The vulnerability had been present for months before discovery.
• 2020 — SolarWinds supply chain attack: Thousands of financial institutions were compromised via a trusted software vendor. The attack bypassed every perimeter security control because it entered through legitimate software updates.
• 2021 — EBA cyberattack: The European Banking Authority itself — the regulator that writes the rules — had its email system compromised. Personal data was potentially accessed.

Meanwhile, EU banks operated under a fragmentation problem. A bank with operations in Germany, France, the Netherlands, and Italy faced four different ICT risk frameworks:

• Germany: BaFin’s BAIT (Bankaufsichtliche Anforderungen an die IT)
• France: ACPR’s own supervisory guidelines
• Netherlands: DNB’s Guidance on Cloud
• Italy: Banca d’Italia’s Circolare 285

Each had different definitions of what constituted a major incident, different reporting timelines, different third-party risk requirements. Compliance was expensive, inconsistent, and impossible to benchmark across the EU.

DORA ends all of that. It is a single regulation, directly applicable without national implementation, covering the entire EU financial sector. It came into force in January 2023 and became fully applicable — meaning enforceable — on 17 January 2025.

Who DORA Applies To

DORA has the broadest scope of any EU financial regulation ever passed. It applies to:

That last category is the most significant. For the first time in EU regulatory history, cloud providers are subject to direct financial supervisory oversight for the services they provide to financial entities. The ESAs (EBA, ESMA, EIOPA) can designate a cloud provider as a Critical Third-Party Provider and conduct on-site inspections of their data centres. This was unimaginable before DORA.

DORA also applies proportionately — smaller financial entities face lighter requirements than large, systemically important institutions. But the five pillars apply to everyone.

The Five Pillars of DORA

DORA is structured around five pillars, each covering a different dimension of digital operational resilience. Together they create a complete framework: identify your risks, detect incidents, test your defences, manage your suppliers, and share intelligence.

Pillar 1 — ICT Risk Management Framework (Art. 5–16)

What the Regulation Requires

The most important governance statement in DORA is in Article 5: the board of directors is personally accountable for ICT risk management. This mirrors BCBS 239 Principle 1 applied to technology risk. The board must approve the ICT risk management framework, review it at least annually, ensure adequate budget is allocated, and receive regular reports on the bank’s ICT risk posture.

This is not a delegation to the CTO. The board is accountable. When an ECB Joint Supervisory Team arrives for an on-site inspection, they will ask board members directly what they know about the bank’s ICT risk profile. Boards that cannot answer are in breach of DORA Art. 5.

The core operational requirement of Pillar 1 is Article 8 — Identification: banks must maintain a complete, continuously updated inventory of all ICT assets, their functions, their interconnections, and their dependencies on other systems and third parties.

Additional requirements cover:

• Art. 9 — Protection: Access controls, data integrity measures, encryption, change management
• Art. 10 — Detection: Systems to detect anomalous activity and potential security incidents
• Art. 11 — Response and Recovery: Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for every critical system
• Art. 12 — Backup: Geographically separate backups, regularly tested restoration
• Art. 13 — Learning: Incorporate lessons from incidents and tests back into the framework

The Data This Requires: The ICT Asset Register

The ICT asset register is the foundational data requirement of DORA. Without it, none of the other pillars work. You cannot report incidents affecting unknown systems. You cannot test systems you have not identified. You cannot manage third-party risk for services you have not catalogued.

Every ICT asset — every server, every software system, every cloud service, every API — must have a record containing:

For a COREP reporting pipeline specifically: the RTO of 4 hours is set relative to the 12-business-day submission deadline imposed by the EBA’s ITS on supervisory reporting. If the system is down for more than 8 hours during the reporting window, the bank risks missing the regulatory deadline — which is itself a CRR breach on top of the DORA breach.

DORA Pillar 1 and BCBS 239 — Two Regulations, One Engineering Requirement

BCBS 239 Principle 2 requires banks to have robust data architecture and documented data flows between systems. DORA Art. 8 requires banks to document all ICT assets and their interconnections. They are describing the same requirement from different regulatory angles.

A data lineage graph in Marquez — showing how data flows from raw source tables through dbt transformations to the XBRL output file — contributes evidence for both requirements simultaneously. Build it once, satisfy two regulators.

Pillar 2 — ICT Incident Management, Classification and Reporting (Art. 17–23)

What the Regulation Requires

Every ICT-related incident must be logged. Major incidents — those meeting EBA-defined materiality thresholds — must be reported to the national competent authority on a strict timeline:

The 4-hour initial notification deadline is one of the most operationally demanding requirements in DORA. From the moment an incident is classified as Major, the clock starts. This means the classification decision itself must be made quickly — which requires an automated classification system, not a manual committee review.

What Makes an Incident “Major”

An incident is classified as Major if it crosses materiality thresholds on at least one dimension (Art. 18). The EBA has published draft RTS specifying the exact thresholds. Key criteria include:

• Services unavailable: Duration exceeds a threshold (typically 2 hours for critical services like payments)
• Clients affected: Number of clients unable to access services exceeds a threshold
• Data loss: Any personal data loss — automatically Major and also triggers GDPR Art. 33 notification within 72 hours
• Reputational impact: Media coverage, market reaction, regulatory attention
• Critical function unavailable: Payment processing, regulatory reporting, trading systems down beyond threshold
• Economic impact: Estimated direct financial loss above a defined threshold

The classification decision must be documented. If a supervisor later determines an incident should have been classified as Major but was not, the bank must demonstrate its classification methodology was reasonable and documented at the time. “We did not think it was major” without documentation is a supervisory finding.

The Data This Requires: The Incident Log

Every ICT incident — Major or not — must be captured in a structured log. For Major incidents, every field is regulatory evidence:

Every timestamp on this table is evidence in a potential supervisory investigation. Were you within the 4-hour window? Can you prove it? The answer must come from an automated, immutable log — not from someone’s memory or an email trail.

The Vulnerability Register

Alongside the incident log, DORA Pillar 2 requires tracking vulnerabilities from discovery to remediation. This is particularly relevant for a data engineering team: every dependency in your pipeline (PostgreSQL, Apache Airflow, dbt, Arelle) publishes CVE advisories when vulnerabilities are found. DORA requires you to track them:

A pattern of slow patching on critical vulnerabilities is a DORA finding even if no incident ever occurred. The regulator will analyse the distribution of time-to-patch across the vulnerability register during an inspection.

Pillar 3 — Digital Operational Resilience Testing (Art. 24–27)

What the Regulation Requires

Knowing your risks and documenting your incidents is not enough. DORA requires you to actively test whether your defences work — before an attacker or a system failure does it for you.

Basic testing programme (Art. 24 — all financial entities): Annual testing of all ICT systems supporting critical or important functions. Tests include vulnerability assessments, network security scans, gap analyses, source code reviews, scenario-based tests (what happens if this system fails?), and compatibility testing after major changes.

Advanced testing — TLPT (Art. 25 — significant institutions): Threat-Led Penetration Testing is required for the largest and most complex financial entities, at least every three years. TLPT simulates real threat actor behaviour using intelligence-led scenarios developed from actual threat intelligence about adversaries targeting the financial sector. It must:

• Cover production systems — not test environments. Real systems, real consequences if something goes wrong.
• Use the TIBER-EU framework — the ECB and EBA’s standardised intelligence-led red teaming methodology
• Be conducted by certified external testers who are genuinely independent from the bank
• Results shared with the national competent authority
• A remediation plan required for every finding

TLPT is the most demanding and expensive DORA requirement. A full TLPT exercise for a large EU bank typically costs €1–3 million, involves months of preparation, and can identify vulnerabilities that have been present for years undetected.

The Data This Requires: The Testing Register

Every resilience test must be logged and tracked to remediation:

The finding-to-remediation tracking is critical: DORA does not just require you to find vulnerabilities — it requires you to fix them and prove you fixed them. An open critical finding past its remediation deadline is itself a reportable situation to the supervisor.

Pillar 4 — ICT Third-Party Risk Management (Art. 28–44)

What the Regulation Requires

This is the most operationally complex pillar and, arguably, DORA’s most significant contribution to EU financial regulation. It addresses a risk that the 2020 SolarWinds attack made impossible to ignore: your security is only as strong as your weakest supplier.

Before DORA, banks managed third-party risk through internal policies that varied widely in quality. Some banks had rigorous vendor assessment programmes. Others relied on a one-page questionnaire sent annually. DORA imposes a binding minimum standard for everyone.

Key requirements:

• Register of Information (Art. 28): A comprehensive register of all ICT third-party arrangements, submitted annually to the national competent authority. The EBA published a standardised template — every field is specified.
• Pre-engagement risk assessment: Before engaging any third party for ICT services, the bank must assess their security posture, financial stability, and sub-outsourcing practices.
• Mandatory contractual provisions (Art. 29): Every ICT contract must include audit rights, exit strategy provisions, data portability guarantees, sub-outsourcing restrictions, incident notification SLAs, business continuity requirements, and specific security standards. No DORA-compliant contract means no compliant vendor relationship.
• Critical ICT Third-Party Providers (Art. 31): The ESAs designate the most critical cloud providers as CTPPs. AWS, Microsoft Azure, and Google Cloud are expected to be among the first designations. CTPPs face direct supervisory oversight — the Lead Overseer can conduct on-site inspections of their data centres, require audits, and mandate remediation of weaknesses.

The Data This Requires: The Register of Information

The Register of Information is the most demanding data collection exercise in all of DORA. It covers every ICT vendor arrangement — not just cloud providers, but software vendors, data providers, network providers, outsourced service providers. For a large EU bank, this can mean hundreds of entries.

Key fields per vendor arrangement:

Notice the sub-outsourcing chain field. DORA requires banks to map not just their direct vendor, but the full chain of dependencies behind that vendor. When AWS hosts your regulatory reporting system, you must know that AWS itself depends on Equinix for data centre space, and Equinix depends on local power suppliers. A failure four layers deep in that chain can affect your ability to submit COREP on time — and DORA says you are responsible for understanding that risk.

Concentration Risk — The Systemic Issue DORA Addresses

One of the most important concepts in DORA Pillar 4 is ICT concentration risk: what happens if the entire EU financial sector runs on the same three cloud providers and one of them has a major outage?

As of 2026, approximately 65% of EU financial institutions use one of three cloud providers for critical ICT services. This creates a systemic risk that no individual bank can manage — if AWS eu-central-1 goes down for 6 hours, dozens of EU banks simultaneously lose access to their core systems. No amount of individual bank resilience planning addresses this.

DORA requires banks to measure and report their concentration exposure per provider: what percentage of critical functions depend on each provider, what the estimated financial impact of a 4-hour outage would be, and what the substitutability timeline is. Regulators use this data to monitor systemic ICT concentration risk at the EU-wide level.

Pillar 5 — Information and Intelligence Sharing (Art. 45–49)

What the Regulation Requires

The final pillar formalises something that many banks were already doing informally: sharing cyber threat intelligence with each other. Before DORA, this sharing existed in a legal grey area — competition law and confidentiality obligations made banks nervous about sharing information about incidents or attacker tactics, even anonymously.

DORA Art. 45 explicitly permits and encourages financial entities to share cyber threat information and intelligence through trusted community arrangements, even if this involves sharing otherwise confidential information. The conditions:

• Sharing happens within a trusted, defined community — not publicly
• Sharing does not violate competition law
• Confidentiality agreements govern the community
• TLP (Traffic Light Protocol) classifications govern what can be shared and with whom

The primary existing community is FS-ISAC — the Financial Services Information Sharing and Analysis Center — which already connects thousands of financial institutions globally. DORA formalises this and encourages national regulators (particularly ENISA, the EU Cybersecurity Agency) to support the creation of EU-specific sharing arrangements.

The Data This Requires: The Threat Intelligence Log

Every piece of threat intelligence received — and every piece shared — must be logged:

The time between receiving intelligence and acting on it is itself a metric. Supervisors will assess whether banks respond to threat intelligence promptly — a 2-week delay between receiving an alert about a threat targeting your COREP reporting system and blocking the associated indicators would be difficult to defend.

DORA and Your Data Pipeline: The Practical Impact

If you are building data pipelines for a financial institution, DORA creates specific obligations for the systems you build. Let me walk through the COREP pipeline I am building in this series and show exactly where DORA requirements appear.

Your Pipeline Is an ICT Asset

The corep-governance-pipeline — Apache Airflow, PostgreSQL, dbt, Arelle, OpenMetadata, Marquez, Trino, Apache Ranger — is a collection of ICT assets under DORA. Each component needs an entry in the ICT asset register with its criticality classification, dependencies, RTO, and RPO.

The pipeline as a whole supports a Critical function (regulatory reporting). That means it gets the full DORA treatment: annual resilience testing, documented recovery procedures, and a third-party risk assessment for every open-source component and any cloud hosting involved.

Pipeline Failures Are Potential Major Incidents

If the Airflow DAG fails during the Q3 COREP reporting window and the pipeline is down for more than 4 hours, that is a potential DORA Major Incident. The incident classification algorithm needs to check: is the COREP submission deadline at risk? If yes, it may be Major.

The audit.pipeline_run_log table in this project serves double duty: it is a BCBS 239 audit trail AND it provides the timestamps needed for DORA incident classification. Every module writes its start and completion time. A gap in the log is detectable automatically.

Open-Source Dependencies Are Third-Party Arrangements

This is the most counter-intuitive DORA implication for data engineers. Every open-source tool in the pipeline — Apache Airflow, dbt, PostgreSQL, Arelle, OpenMetadata — is technically a third-party ICT arrangement under DORA, even though it is free software.

The DORA third-party register needs entries for these. The key fields are different from commercial vendors (no LEI for Apache Software Foundation, no SLA contract), but the risk assessment still applies: who maintains this software? How quickly are CVEs patched? What happens if the project is abandoned? Is there a supported commercial distribution?

In practice, many banks respond to this by using commercially supported distributions — Red Hat OpenShift instead of plain Kubernetes, Astronomer instead of plain Airflow, Collate instead of plain OpenMetadata — specifically to get contractual SLAs and professional support that satisfy DORA third-party requirements.

The DORA Audit Dashboard in This Pipeline

In Day 16 of this series, I build two Superset dashboards. The second — the Governance Audit Dashboard — includes a DORA panel showing:

• Open critical and high vulnerabilities vs. SLA compliance (days to patch vs. target)
• Incidents in the last 90 days by type and Major/Minor classification
• Third-party SLA compliance (actual uptime vs. contracted uptime per vendor)
• DR test results — RTO achieved vs. RTO target
• Threat intelligence actions — received vs. actioned in SLA

This dashboard is not just for internal governance — it is the evidence base for a DORA supervisory inspection. When an ECB examiner asks “show me your ICT resilience posture,” this is what you show them.

Key Dates and Where Banks Are Now (May 2026)

As of May 2026, DORA has been enforceable for 16 months. Most large EU banks are in the implementation and gap remediation phase. The first Register of Information submissions revealed significant gaps — many banks discovered they had hundreds more ICT third-party arrangements than their internal records showed, and that sub-outsourcing chains were largely undocumented. The next 12 months will see intensive supervisory scrutiny of Pillar 4 compliance in particular.

The One Thing That Connects All Five Pillars

Every DORA pillar generates data. The ICT asset register, the incident log, the vulnerability register, the testing register, the third-party register, the threat intelligence log — these are all data products. They must be stored, governed, searchable, and reportable on demand.

Banks that treat DORA as a compliance exercise — producing the minimum required documentation and storing it in a SharePoint folder — will struggle when a supervisor asks an ad hoc question: “What was your average time to patch critical vulnerabilities in Q3 2025?” or “How many ICT incidents affected your regulatory reporting function in the last two years?”

Banks that treat DORA as a data engineering problem — building a structured DORA data store alongside their financial data governance infrastructure — will be able to answer those questions in minutes, from a dashboard, without any manual preparation.

That is the architecture this series is building toward. Not compliance for its own sake — operational intelligence that makes the bank genuinely safer and demonstrably compliant at the same time.

What’s Next

In the next post I go into COREP itself — downloading the actual EBA templates, understanding the XBRL taxonomy, and opening a real sample XBRL instance file in Arelle. By the end of that post I will know exactly what data needs to come out of the pipeline and in precisely what format the regulator expects to receive it.

All code for this project will be open source on GitHub. Follow along for the remaining days in the series.