DORA Is Now in Enforcement Mode: What Banks and Fintechs Must Do Differently with Their Data in 2026
When the Digital Operational Resilience Act came into force on 17 January 2025, most financial institutions were still in implementation mode — building frameworks, documenting policies, and mapping ICT dependencies for the first time. Regulators understood this and gave institutions space to find their footing. That space no longer exists. In 2026, DORA has moved firmly into its supervisory enforcement phase. The European Central Bank has confirmed that operational resilience remains a top priority for 2025 to 2027, and national competent authorities across the EU are now actively auditing compliance — not reviewing documentation, but testing whether controls actually run in practice, whether incident reporting pipelines function within mandated timelines, and whether institutions can produce evidence of resilience on demand. The shift, as one regulatory summary put it, is from "what's written in policy" to "proof of what runs."
What DORA Actually Requires — and Where Most Institutions Fall Short
DORA establishes five interconnected pillars of digital operational resilience: ICT risk management and governance, incident classification and reporting, digital operational resilience testing, third-party ICT risk management, and information sharing. Each pillar creates direct demands on how financial institutions manage, govern, and monitor their data environments.
ICT Risk Management and Governance. Financial entities must maintain a formal ICT risk framework integrated with their enterprise risk strategy. Crucially, responsibility for ICT risk sits with the management body — board members and senior executives face personal fines of up to €1 million for compliance failures. This is not a technical team problem. It is a board-level accountability requirement that demands clear data lineage, documented ownership, and continuous visibility into ICT risk exposure.
Incident Classification and Reporting. When a major ICT incident occurs, DORA requires an initial notification to the relevant National Competent Authority within four hours of classification (and no later than 24 hours from detection), an intermediate report within 72 hours, and a final report within one month. Meeting these timelines is operationally impossible without automated incident detection, real-time alerting, and governance frameworks that ensure the right data reaches the right people within minutes — not hours.
Third-Party ICT Risk Management. DORA’s third-party provisions (Articles 28–31) require financial institutions to maintain a Register of Information documenting every ICT service provider, the services they provide, and the data they handle. Critically, DORA’s scope extends beyond EU borders: a US-based cloud provider storing sensitive EU financial data falls under its jurisdiction. The institutions struggling most with this pillar are those with no systematic view of their vendor data flows and dependencies — a data architecture problem masquerading as a compliance problem.
The Data Governance Gap That DORA Exposes
Consider what DORA’s incident reporting timeline actually demands in practice. An ICT incident is detected. Within four hours of classification, a structured initial notification must be filed with the regulator. That notification requires specific information: the nature and scope of the incident, the systems and data affected, the client impact, the geographic spread, and the initial assessment of cause. Assembling that information accurately, within four hours, requires systems that continuously monitor the data environment, classification logic that triggers automatically when defined thresholds are crossed, and an audit trail that captures the incident timeline from detection to response.
None of that is possible without a governed data environment that maintains continuous operational awareness. Institutions still relying on manual processes, disconnected monitoring tools, and nightly batch reporting pipelines cannot meet this standard. The gap between DORA’s requirements and the operational reality of many institutions is a data infrastructure gap.
In 2026, regulators explicitly connect governance effectiveness to security operations. DORA requires ICT incident detection and reporting within hours. BCBS 239 expects data integrity controls to function continuously, not just during audit periods. This convergence means institutions cannot treat governance and security as separate programs any longer.
A rigorous enterprise data governance and privacy strategy — one that establishes clear data ownership, documents lineage across ICT systems, classifies sensitive data, and enables continuous monitoring — is no longer a best-practice recommendation for EU financial institutions. It is the operational foundation DORA requires.
AI Agents, the EU AI Act, and Why the Governance Challenge Is Compounding
The DORA compliance challenge does not exist in isolation. Financial institutions deploying AI — for credit decisioning, fraud detection, regulatory reporting, or customer service — face an overlapping layer of governance obligations under both DORA and the EU AI Act.
Under DORA, AI agents are treated as ICT systems. A credit scoring model, a fraud detection agent, or an automated regulatory reporting workflow is subject to the same ICT risk management, testing, and incident reporting obligations as any other system. Under the EU AI Act, high-risk AI applications — including those used in credit assessment and AML — carry additional obligations around data governance, logging, human oversight, and model explainability.
The institutions navigating this effectively are those that have built a single, unified governance layer that serves both frameworks simultaneously — rather than running separate compliance programs for each regulation. That means one data catalog documenting what AI systems exist and what data they touch, one lineage framework tracing how training data flows through models, one classification system identifying what is sensitive, and one monitoring layer providing continuous operational visibility.
Building that foundation is complex. But it is also the only architecture that scales as regulatory requirements continue to compound — and they will.
Third-Party Risk: The Compliance Gap Most Institutions Haven't Closed
The challenge is not just creating the register. It is maintaining it accurately as vendor relationships change, services evolve, and new providers are onboarded. Institutions without systematic vendor data management — a single, governed view of third-party ICT dependencies, their criticality, their contractual compliance status, and their incident history — find themselves repeatedly rebuilding their Register of Information from scratch for each supervisory review.
DORA also requires institutions to test exit scenarios for critical vendors, maintain data portability provisions in ICT contracts, and participate in vendor security testing programs. These are not one-time implementation tasks. They are ongoing operational capabilities that require the same continuous data governance discipline as internal ICT risk management.
Building a forward-looking data strategy and advisory program that encompasses third-party data flows — not just internal architecture — is increasingly the practical difference between DORA compliance that holds up under supervisory scrutiny and compliance documentation that looks complete until an auditor asks for evidence.
What the Enforcement Phase Means for Your Next Steps
The supervisory phase of DORA in 2026 is characterized by one consistent message from regulators: evidence, not policy. It is no longer sufficient to document what your framework says your institution will do. Auditors want to see that ICT risk management runs continuously, that incident detection and classification work as designed, that third-party oversight is active rather than annual, and that resilience testing has been completed and documented.
For institutions that completed their initial DORA implementation in 2025 but have not yet operationalized these requirements — moving from written frameworks to running systems — 2026 is the year that gap becomes a regulatory exposure.
The path forward is the same in every case: invest in the data infrastructure that makes continuous compliance operationally achievable. Map your ICT environment with genuine precision. Automate your incident classification and reporting workflows. Build your Register of Information as a living, governed data asset — not a spreadsheet. And ensure your third-party risk management extends to the data those vendors handle, not just the services they provide.
Data Geny helps banks, investment firms, and fintech companies build the data governance frameworks, ICT risk management architectures, and compliance analytics capabilities that DORA enforcement demands.