DORA Compliance Is Not Proof the Function Will Survive

In 2025, financial entities reported 3,383 major ICT-related incidents under DORA, an average of 0.18 per entity subject to the Regulation. The number that changes the story is 10%.

Only 10% of those incidents were cybersecurity-related. System failures accounted for 51%. External events accounted for 27%. The ECB separately reported that 38% of major incidents reported by banks had “IT change” as their root cause.

The dominant picture was ordinary technology failing in connected ways: systems, changes, external infrastructure and shared providers. The fact that we can see it this clearly is evidence that incident reporting worked.

The ESAs’ first annual incident report is the first common photograph of how European finance breaks. It made patterns visible across firms, sectors and borders. The Regulation also gave the industry a strong common language for continuity, recovery, testing, third-party risk and management responsibility. A photograph records what happened. It cannot establish whether the next critical function will survive.

A firm can complete its ICT risk framework, Register of Information, provider contracts, incident process, testing calendar and board reporting. Every item can be useful and properly maintained. Together, they still may leave unanswered whether a payment, settlement or customer-access function will remain within tolerance during disruption.

DORA is unusually explicit about outcomes. Yet firms can still turn those outcome requirements back into documents and completed controls.

The incident pattern is the warning

Of the 3,383 major incidents, 1,056 had cross-border impact. About 8% affected more than ten countries. Almost one third originated from failures attributable to third parties, including ICT providers, other financial entities and infrastructure providers.

These are patterns of connected failure. A fault begins in one technical or organisational domain, then travels through services, institutions and countries.

The ECB’s finding on IT change brings the same problem inside the firm. Change is necessary. It can be authorised, reviewed and deployed through a controlled process, yet still initiate a major incident.

A control record tells you that an activity happened. Once dependencies begin interacting, it says little about how far failure will travel. Firms need the control evidence DORA requires alongside operational evidence: what failed together, which customer outcome moved, whether recovery worked and what the exercise changed.

A register records contracts, not shared fate

Article 28 requires financial entities to maintain and update a Register of Information covering contractual arrangements for ICT services. The register is essential for oversight and provider designation, and producing a reliable one is substantial work.

In the ESAs’ 2024 voluntary dry run, 1,039 financial entities submitted registers. Of the 947 processed, only 6.5% passed all 116 data-quality checks. The remaining 93.5% had at least one failure, and missing mandatory information accounted for 86% of errors.

That exercise was voluntary, best-effort and conducted before DORA applied. Its findings describe a rehearsal rather than firms’ compliance in 2025. They also show how difficult it was to assemble the underlying contractual data.

Now imagine a technically perfect register. It can tell you who the firm contracted with and for which service. Runtime shared fate remains elsewhere.

Several contracted services may share one region, identity system, DNS dependency or control plane. A subcontractor can sit beneath several direct providers. A primary service and its supposed alternative may rely on common infrastructure. Recovery tooling may share a provider with the production environment it is meant to recover.

At my family’s business, we had four layers of power redundancy. One lightning strike took out all four. The outage was obvious; finding everything else the strike had killed took days. That experience changed what “redundant” means to me. Four layers on a diagram can still share one fate.

Contractual boundaries are useful for governance. Failure follows technical, operational and physical dependencies. The ESAs made concentration visible at Union level when they designated 19 critical ICT third-party providers on 18 November 2025. The list includes AWS, Google Cloud, Microsoft, IBM, Oracle, SAP and Equinix.

That designation turns concentration into a supervisory concern at Union level. Each financial entity still has to understand where those providers sit inside its own critical functions and recovery paths. The register supplies essential facts; a current dependency model connects those facts to shared operational fate.

A full testing calendar can still miss the function

DORA requires more than scheduled tests. Article 24 requires a sound and comprehensive testing programme, with appropriate tests at least yearly on ICT systems and applications supporting critical or important functions. Article 25 explicitly includes scenario-based, performance, end-to-end and penetration testing.

Article 11 connects testing to the operating model. The business impact analysis must consider mapped business functions, support processes, third-party dependencies, information assets and their interdependencies. ICT business continuity plans and ICT response and recovery plans must be tested at least yearly. For firms other than microenterprises, that includes switchovers between primary and redundant capacity.

The weak implementation is easy to recognise. Teams test components independently, record successful completion and aggregate the results into a reassuring status.

The database failed over. The application recovered. The procedure was exercised. Each statement may be true while the critical function remains untested as a whole.

The stronger question is whether the function stays within its agreed tolerance when several dependencies fail or degrade together. Begin with the business outcome, then follow the likely cascade through technology, people, process, facilities, information and third parties.

Suppose primary capacity becomes unavailable while identity is degraded and customer connectivity is intermittent. The recovery procedure exists, but a required step relies on a control plane affected by the same event. Separate component tests cannot establish the outcome of that combination.

A useful annual exercise can stop short of recreating a catastrophe. What matters is an explicit prediction: which dependencies should be affected, what should stop propagation, how recovery should proceed and what the customer should experience. The test can then challenge that prediction.

Threat-led penetration testing belongs in this picture, but it is only one part. Selected entities must perform TLPT at least every three years under Article 26, and the 2025 technical standards are in force. Annual operational testing applies more broadly. The first-year incident mix gives firms good reason to keep resilience testing broader than cyber exercises. Test completion is useful management information; the observed outcome provides evidence of survivability.

The reporting clock is not the customer’s clock

DORA’s incident standards set clear deadlines: an initial notification within four hours after classification and no later than 24 hours after awareness, an intermediate report within 72 hours, and generally a final report within one month of the intermediate report.

Those clocks improve supervisory visibility and comparability. Customer recovery runs on a different clock. In February, a rare hardware malfunction affected a core storage component at TARGET2. Securities settlement, payments, ancillary processing and liquidity transfers were suspended for several hours. Restoration required failover and integrity checks.

The recovery question was therefore larger than whether redundant capacity could start. Processing also had to resume safely.

During the Iberian blackout in April, major banks’ data centres continued on backup power. Yet internet access, telecommunications, branches and point-of-sale channels were disrupted. Applications could remain available and functional while customers lost access to them.

One incident shows a core component interrupting several connected market functions. The other shows healthy applications inside a broken delivery path. Both expose the limits of a red-or-green system status.

Operational resilience has to be measured where the business outcome occurs. Reporting speed belongs in the incident picture; recovery speed and customer access complete it.

Third-party oversight still leaves responsibility with the firm

Article 28 is direct: financial entities remain fully responsible for their DORA obligations when they use ICT third-party providers. It also requires them to assess concentration risk.

The first-year data turns that legal principle into an operating problem. Nearly one third of major incidents originated from third parties or external infrastructure, and roughly one third crossed borders.

Due diligence, contractual clauses, exit plans and ESA oversight are necessary controls. None automatically provides a live view of one firm’s blast radius.

That view should answer practical questions. Which critical functions rely on the provider? Which apparently separate services share the dependency? Which alternatives have worked under test? Can teams recover if identity, communications or recovery tooling shares the affected provider?

An exit plan deserves the same scrutiny. Its existence shows that a route has been documented. Exercising the route under degraded conditions provides evidence that it can be used.

A provider can restore its own service. Only the financial entity can determine whether its critical function remained available to the people and markets that depended on it.

Give the board a connected claim

Article 5 gives the management body ultimate responsibility for ICT risk. It must approve, oversee and periodically review the resilience strategy, continuity policy, response and recovery plans, audits, budget and third-party arrangements.

A board can receive every required item and still lack an operating view of resilience. Five accurate reports can conceal the gaps between them.

Which critical function has the largest untested failure path? Which provider creates the broadest correlated exposure? What did the latest scenario reveal beyond the register? Which remediation measurably reduced expected customer impact?

These are governance questions. Directors can answer them without inspecting service diagrams, provided they have a connected chain of evidence across topology, scenario, observed impact, recovery and remediation.

The useful unit of reporting is a claim with evidence: we believe this critical function can withstand this scenario, for these reasons, with these known gaps.

Run DORA as an evidence loop

The practical answer is a repeatable loop, run first on one critical or important function.

1. Map the function as it operates now. Connect the business outcome to its technical, human, process, facility, information and third-party dependencies. Keep the boundary around the function rather than an arbitrary application or supplier.
2. Write down the expected impact. For a severe but plausible scenario, state what should fail, how disruption should propagate, which controls should interrupt it and what the customer or market should experience.
3. Run the scenario and observe the cascade. Exercise or simulate the conditions. Capture the actual dependency path, recovery actions and business outcome alongside the first component that alerted.
4. Compare prediction with observation. The delta is missing knowledge. It may expose an unknown dependency, an unavailable workaround, a slower recovery step or an assumption that held only while systems were healthy.
5. Remediate, retest and update the artifacts. Feed the same evidence into the Register of Information, BIA, recovery plan and board view. Then run the scenario again and determine whether the change reduced impact.

This is the loop we are building Failcast to support: a living dependency model derived from infrastructure data, with failure-cascade simulation that helps teams compare expected and observed impact.

The loop changes the role of the artifacts DORA already requires. The register becomes a source challenged by runtime evidence. The BIA becomes a testable hypothesis. The recovery plan becomes an exercised route. Board reporting shows what the firm learned and which exposure it reduced.