DORA Compliance and Data Governance: What Every Financial Institution Needs to Know

What Is DORA and Who Does It Apply To?

The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — establishes binding requirements for the ICT risk management, incident reporting, resilience testing, and third-party oversight of financial entities operating in the European Union. It entered into force in January 2023 and became fully applicable on January 17, 2025.

DORA applies to a broad scope of financial institutions: banks and credit institutions, investment firms, insurance companies, payment and e-money institutions, crypto-asset service providers, central securities depositories, and critical ICT third-party service providers (CTPPs) — including major cloud providers like AWS, Microsoft Azure, and Google Cloud that serve EU financial entities.

The regulation is enforced by national competent authorities (NCAs) in each EU member state, coordinated at the EU level by the European Supervisory Authorities (EBA, ESMA, and EIOPA). Non-compliance exposes institutions to administrative penalties, supervisory measures, and reputational consequences that no compliance team wants to explain to a board.

DORA's Five Pillars — and Where Data Governance Intersects Each One

DORA is organized around five core requirements. Each one has a direct data governance dimension that is often underappreciated in ICT-led implementation programs.

Pillar 1: ICT Risk Management

DORA requires financial institutions to implement a comprehensive ICT risk management framework covering identification, protection, detection, response, and recovery across all ICT systems that support critical or important functions.

The data governance dimension is immediate: you cannot manage ICT risk for a system you have not documented. DORA expects institutions to maintain an up-to-date inventory of ICT assets, map data flows between systems, identify critical functions and their technology dependencies, and document what data lives where and how it moves through third-party services.

This is not a one-time exercise. DORA requires continuous monitoring and regular review. Organizations that rely on static spreadsheets or point-in-time audits will find themselves unable to answer supervisory questions accurately — particularly as cloud adoption and third-party integrations accelerate the pace of change in technology landscapes.

Pillar 2: ICT-Related Incident Management, Classification, and Reporting

DORA mandates the establishment of processes to detect, manage, classify, and report ICT-related incidents. Major incidents must be reported to the relevant NCA within defined timeframes: an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month.

Meeting these reporting deadlines requires something that many institutions currently lack: the ability to rapidly trace which data, systems, and business functions were affected by an incident. Without data lineage — a documented map of how data flows from source systems through processing pipelines to business outputs — incident classification is a manual and error-prone process.

Consider what happens when a cloud storage outage affects a payment processing pipeline. Can your team immediately answer: which specific data was inaccessible, which downstream reports and decisions were affected, which customers were impacted, and whether personal data was at risk? Without data lineage and a governed data catalog, answering these questions takes days, not hours — and DORA does not allow days.

Pillar 3: Digital Operational Resilience Testing

DORA requires financial institutions to conduct regular resilience testing of their ICT systems, including threat-led penetration testing (TLPT) for significant institutions every three years. The purpose is not just to identify vulnerabilities but to demonstrate that critical functions can be maintained or rapidly restored.

Resilience testing produces value only when institutions understand what they are testing. A penetration test on a system whose data flows and dependencies are undocumented will produce findings that cannot be prioritized correctly. Testing a recovery procedure for a data pipeline requires knowing what that pipeline does, what data it handles, and which business processes depend on it.

Data governance — specifically, a maintained asset inventory with documented dependencies and data classifications — is what transforms resilience testing from a compliance checkbox into a genuine risk reduction exercise.

Pillar 4: ICT Third-Party Risk Management

DORA imposes detailed requirements on the management of third-party ICT providers, including contractual requirements for critical providers, exit strategies, and — for critical third-party providers (CTPPs) — direct supervisory oversight by EU authorities.

The data governance challenge here is significant. Financial institutions must know: which third parties process their data, what data categories are shared with each provider, where data is stored geographically, what contractual protections govern each relationship, and whether critical functions have viable alternatives if a provider fails or is sanctioned.

According to EBA guidance, institutions must maintain a register of information on all contractual arrangements with ICT third-party providers. This register is not optional — it is subject to regulatory review and must reflect the actual state of third-party relationships, not an approximation from the last audit cycle.

Pillar 5: Information and Intelligence Sharing

DORA encourages — and in some contexts requires — financial institutions to share threat intelligence about ICT vulnerabilities and incidents with peers and regulators. For intelligence sharing to be safe and effective, institutions must be able to classify and control information carefully: distinguishing proprietary data from shareable threat indicators, identifying personal data that cannot be shared without consent, and documenting the legal basis for any data exchange.

Data classification metadata is the governance layer that makes this possible. Without it, institutions either share too little — forgoing the network effects of collective intelligence — or too much, creating GDPR exposure in the process.

The Four Data Governance Capabilities DORA Demands

Across all five DORA pillars, four data governance capabilities emerge as consistently critical. Organizations that have invested in these capabilities are finding DORA compliance manageable. Those that have not are discovering that technology investments alone — better SIEM tools, more sophisticated monitoring — cannot compensate for the absence of a governed data foundation.

1. A Governed ICT Asset Inventory

DORA's ICT risk management requirements begin with asset identification. Article 8 requires institutions to identify, classify, and document all ICT assets that support critical or important functions — including hardware, software, data, and external services.

This inventory must be maintained continuously, not updated annually. It must be accurate enough to support incident response decisions in hours. And it must capture the relationships between assets — which systems feed which pipelines, which applications depend on which databases — not just their existence.

A data catalog that maps ICT assets alongside their data flows, business owners, criticality classifications, and third-party dependencies is the practical implementation of what DORA Article 8 requires.

2. End-to-End Data Lineage

Data lineage — the documented trace of where data originates, how it is transformed, and where it flows — is the capability that makes DORA's incident reporting timelines achievable. Without it, impact assessments for ICT incidents require manual investigation across multiple teams, multiple systems, and multiple documentation sources.

With automated data lineage, impact assessment becomes a query, not an investigation. When an incident affects a source system, the organization can immediately see which downstream reports, dashboards, regulatory submissions, and business decisions are affected — and communicate that impact accurately within DORA's four-hour initial reporting window.

Data lineage also supports DORA's resilience testing requirements. Test scenarios become more realistic when they are based on documented data flows rather than assumed dependencies. Recovery procedures become more reliable when they account for all downstream consumers of a restored system, not just the most visible ones.

3. Data Classification and Access Control Metadata

DORA requires institutions to classify their data and ICT assets according to criticality. Article 9 specifically requires institutions to implement data classification policies and maintain documentation of where sensitive and critical data resides.

This classification serves multiple compliance purposes simultaneously: it informs incident severity assessments under DORA, supports GDPR compliance for personal data, enables appropriate third-party contract provisions, and underpins the access controls that DORA's protection requirements mandate.

Classification metadata that lives only in spreadsheets is a liability. Classification embedded in a governed data catalog — associated with each dataset, updated when classifications change, and accessible to the systems that enforce access policies — is what DORA's continuous monitoring requirements actually demand.

4. Documented Data Ownership and Accountability

DORA's incident response requirements assume that financial institutions can identify, quickly and accurately, who is responsible for specific ICT systems and data assets. Ownership metadata — the documented assignment of accountability for each critical dataset and system — is the governance layer that makes this possible.

Ownership is not just about who maintains a system. For DORA compliance, ownership must extend to data: who is accountable for the accuracy of the data flowing through a critical pipeline, who is authorized to declare an incident involving specific data categories, and who is responsible for communicating with the relevant NCA when a reportable incident occurs.

Organizations that have defined data ownership clearly — and maintained that documentation as personnel and responsibilities change — respond to DORA audits and incident investigations significantly faster than those that treat ownership as implicit organizational knowledge.

The BCBS 239 Parallel: Why Financial Institutions Have Seen This Before

For banks subject to the Basel Committee's BCBS 239 principles, the data governance requirements of DORA should feel familiar. BCBS 239, adopted in 2013, established requirements for risk data aggregation and risk reporting that rest on the same foundations: complete data inventories, end-to-end lineage, documented ownership, and audit-grade traceability.

The uncomfortable truth is that most banks still do not fully meet BCBS 239. The Basel Committee's own assessments consistently find that data aggregation capabilities, lineage documentation, and data governance maturity remain below the standard the principles establish — more than a decade after their adoption.

DORA does not make BCBS 239 compliance less urgent. It makes it more urgent, by adding operational resilience requirements that draw on the same data governance infrastructure. Banks that accelerate their data governance programs in response to DORA will, as a byproduct, close BCBS 239 gaps that regulators have been flagging for years.

DORA and the EU AI Act: A Compounding Compliance Burden

Financial institutions navigating DORA cannot afford to treat it in isolation. The EU AI Act, with high-risk obligations for financial services AI applications taking effect on August 2, 2026, imposes requirements that overlap significantly with DORA's data governance demands.

AI systems used in credit scoring, fraud detection, KYC, and risk management are classified as high-risk under the EU AI Act. For each such system, institutions must document training data provenance, data quality validation procedures, model versioning, bias mitigation controls, and audit logging. These requirements are not separate from DORA's ICT asset inventory and lineage requirements — they are an extension of them into the model layer.

Organizations that build their data governance infrastructure with both regulations in mind — rather than implementing DORA compliance in one program and EU AI Act compliance in another — will find the overlapping requirements additive rather than duplicative. The metadata foundation that supports DORA incident reporting is the same foundation that supports EU AI Act audit trails.

Where Dawiso Fits: Data Governance for DORA-Ready Financial Institutions

Dawiso helps financial institutions build the data governance foundation that DORA requires — not as a compliance tool, but as the operational infrastructure that makes compliance sustainable.

The platform addresses each of the four critical data governance capabilities DORA demands:

• ICT Asset Inventory: Dawiso's Data Catalog provides a centralized, continuously updated inventory of data assets, systems, and their relationships — including third-party data flows and dependencies that DORA Article 8 requires institutions to document.
• End-to-End Data Lineage: Dawiso's Interactive Data Lineage automatically traces data from source systems through transformations to downstream reports and decisions. When an ICT incident occurs, impact assessment becomes a query — not a multi-day investigation across siloed documentation.
• Data Classification and Access Metadata: Dawiso's Business Glossary and classification capabilities provide the documented, maintained data classification that DORA Article 9 requires — integrated with the catalog and lineage layers rather than maintained separately in spreadsheets.
• Ownership and Accountability: Dawiso assigns and tracks data ownership at the dataset and term level, providing the accountability chain that DORA's incident response and reporting requirements depend on.

Critically, Dawiso is designed to be maintained by business users, not just data engineers. DORA compliance is not a one-time project — it is an ongoing operational requirement. Data governance that requires specialist technical resources to keep current will fall behind the pace of change in any real-world financial institution. Dawiso's business-friendly interface means that ownership assignments, classification updates, and glossary changes can be made by the people closest to the data, reducing the governance debt that accumulates in organizations that rely on IT-mediated updates.

A Practical DORA Data Governance Checklist

For compliance and data governance teams assessing their DORA readiness, the following capabilities represent the minimum data governance foundation that DORA's requirements assume:

• ☐ Complete ICT asset register covering systems, data assets, and third-party services that support critical or important functions — maintained continuously, not point-in-time
• ☐ Documented data flows between systems, including to and from ICT third-party providers, with clear identification of data categories at each stage
• ☐ End-to-end data lineage for critical business processes, enabling rapid impact assessment when source systems are affected by incidents
• ☐ Data classification scheme applied across all critical data assets, with documented criteria distinguishing personal data, sensitive business data, and critical operational data
• ☐ Named data owners for all critical datasets and systems, with documented escalation paths for incident response and regulatory communication
• ☐ Third-party register mapping contractual relationships, data categories shared, geographic storage locations, and exit strategy status for each critical ICT provider
• ☐ Incident impact assessment capability — the ability to determine, within hours, which data assets and business functions are affected by a given ICT incident
• ☐ Audit trail for data governance decisions — when classifications changed, who approved ownership transfers, when lineage documentation was last validated

Conclusion: DORA Is a Data Governance Mandate, Not Just an IT Project

The financial institutions that will navigate DORA most successfully are those that recognize what the regulation is actually asking for: not better monitoring tools, not more extensive penetration testing, but a governed, documented, continuously maintained view of their data and technology landscape.

That is a data governance problem. And it is exactly the kind of problem that gets harder — not easier — the longer it is approached as an IT project rather than an organizational capability.

The good news is that the data governance infrastructure that makes DORA compliance sustainable is the same infrastructure that supports BCBS 239, the EU AI Act, GDPR, and the AI-powered compliance workflows that are increasingly redefining what efficient financial operations look like. The investment compounds rather than duplicates.

For financial institutions still working to close the gap, the starting point is the same as it has always been: know your data, document who owns it, and trace where it flows. DORA has not changed what good data governance looks like. It has simply made the consequences of the absence more visible — and more immediate.