DORA: what it means for bank data platforms

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied to EU banks, insurers, investment firms and other financial entities since 17 January 2025. It is often discussed as a security or vendor-management topic, but a large share of the evidence it needs comes from the data platform: what systems exist, what depends on what, whether you can restore them, and which cloud providers run them.

Not legal advice. Confirm your obligations with your compliance team and the texts in the sources below.

The five pillars, from a data team’s view

Pillar	What it asks	What the data team supplies
ICT risk management	A documented framework to identify, protect, detect, respond and recover	Inventory of data platforms, pipelines and their dependencies; backup policies and restore evidence
Incident reporting	Classify ICT incidents and report major ones to the competent authority	Monitoring and logs that show what failed, when, which data and services were affected, and for how long
Resilience testing	Regular testing of ICT systems, plus threat-led penetration testing for some firms	Restore and failover tests for critical data systems, with results recorded
Third-party risk	Manage ICT providers, keep a register of information, plan exits	Details of every cloud, SaaS and data vendor contract the platform depends on; exit plans
Information sharing	Voluntary exchange of cyber threat intelligence	Usually led by security, not data teams

1. Know what you run: the asset and dependency inventory

You cannot show resilience for systems you have not listed. For the data platform, that means:

• Every data platform, warehouse, lakehouse and pipeline tool, with an owner.
• Which business functions depend on each, especially critical or important functions such as regulatory reporting, payments analytics or risk calculations.
• Upstream and downstream dependencies. Here data lineage earns its keep: it shows which reports and processes break if a source or pipeline fails.

2. Prove you can recover

Having backups is not the same as being able to restore. For each critical data system:

• Define a recovery time and recovery point objective that matches the business function it supports.
• Test the restore, not only the backup job, and keep the result: how long it took, what was missing.
• Include cloud region or provider outages in scenarios, and record what would happen to pipelines and reports.

3. Make incidents measurable

DORA requires entities to classify ICT-related incidents and report major ones within set timelines. The classification criteria are in Delegated Regulation (EU) 2024/1772; the reporting content and time limits are in Delegated Regulation (EU) 2025/301, with templates in Implementing Regulation (EU) 2025/302. Check those texts for the exact deadlines that apply to you.

Data teams make this possible by having:

• Monitoring and alerting on pipelines and platforms, so incidents are detected, not discovered by users.
• Logs with timestamps for failures, affected datasets and recovery, retained long enough to support reports.
• A clear way to tell which clients, transactions and data were affected, which again depends on lineage and good metadata.

4. Feed the register of information

Article 28 requires a register of information covering all contractual arrangements with ICT third-party providers, using the templates in Implementing Regulation (EU) 2024/2956. Typical data platform entries:

• Cloud data platforms (Databricks, Snowflake, Microsoft Fabric, BigQuery, Redshift).
• Cloud infrastructure underneath them, and the regions used.
• Managed ETL, ingestion, BI, catalog and observability tools.
• Data providers whose feeds support critical functions.

For each, record which functions depend on it, and keep an exit plan: how data and logic would move if the contract ended. Open table formats and portable transformation code make that plan credible.

A checklist for bank data teams

1. List every data platform and pipeline tool, its owner and the business functions it supports.
2. Map dependencies from source to report for critical functions.
3. Set recovery objectives and run a recorded restore test for each critical system.
4. Add monitoring and alerting with logs that show impact and duration.
5. Send your ICT vendor list, with contract and region details, to whoever maintains the register of information.
6. Write an exit plan for each critical cloud data provider.
7. Review all of the above at least annually and after major changes.

The short version

DORA turns operational resilience into evidence. For data platforms that means an inventory with dependencies, tested restores, incident logs that show impact, and a complete record of cloud and data vendors with exit plans. Most of it is good platform engineering written down. Our data platform assessment reviews these areas, and our data quality and governance service helps put lineage and monitoring in place.

Related: what is data lineage, BCBS 239 and data lineage, PCI DSS for data platforms, Databricks vs Snowflake for financial services and our financial services page.

Sources

• Regulation (EU) 2022/2554 (DORA), EUR-Lex
• Digital Operational Resilience Act (DORA), EIOPA overview with links to the technical standards
• Implementing Regulation (EU) 2024/2956: register of information templates, EUR-Lex
• Delegated Regulation (EU) 2024/1772: incident classification, EUR-Lex

Further reading from other practitioners

• What is DORA compliance? Navigating the EU regulation for digital resilience in finance, Innowise