ECB Cyber Stress Test Lessons: What 109 Banks Revealed About Recovery Gaps

The Test That Assumed Prevention Fails

On a Friday afternoon in early 2024, the European Central Bank sent 109 directly supervised banks a scenario they had hoped was theoretical: every preventive cybersecurity measure in your organization has failed. An advanced threat actor has penetrated your perimeter, escalated privileges, and is now inside your core banking systems. Your firewalls did not stop them. Your endpoint detection did not catch them. Your access controls were bypassed. Now what?

This was not a penetration test. The ECB did not send red teams to probe bank defenses. Instead, it was a recovery-focused stress test — the first of its kind in European banking supervision. The question was not whether banks could prevent a cyberattack (the scenario assumed they could not), but whether they could respond to one, contain the damage, restore operations, and communicate effectively under pressure.

Of the 109 banks, 28 underwent extensive testing that included hands-on recovery exercises and on-site assessments. The remaining 81 completed a self-assessment questionnaire covering the same domains. The results were integrated into the 2024 Supervisory Review and Evaluation Process (SREP), directly influencing capital and operational requirements for the assessed institutions.

The headline finding was deceptively measured: "Banks generally have response and recovery frameworks in place, but further work is needed." Behind that diplomatic phrasing lies a set of specific, systemic gaps that map directly to DORA's Pillar III testing requirements — requirements that are now legally binding.

What the ECB Actually Tested

Figure 1: ECB cyber stress test sequence. The scenario assumed all preventive measures fail, forcing banks to demonstrate actual recovery capability rather than documented plans.

The stress test was structured around four recovery capability domains, each probing a different dimension of operational resilience:

The scenario was deliberately severe: the attacker has compromised Active Directory, encrypted database servers, and exfiltrated customer data. The bank must simultaneously manage incident response, regulatory notification (Art. 19 timelines now in force), customer communication, and system recovery — while operating under the assumption that the compromised systems cannot be trusted until rebuilt from verified clean backups.

The Five Recovery Gaps

Figure 2: The five systemic recovery gaps identified by the ECB stress test, each mapped to corresponding DORA articles. All gaps fed into the 2024 SREP process with capital and operational consequences.

The ECB's findings, published in aggregate (individual bank results remained confidential and fed into bilateral SREP discussions), identified five systemic gaps that recurred across institutions of different sizes and geographies.

Gap 1: Backup Integrity Is Assumed, Not Verified

The most consequential finding was that banks' confidence in their backup and recovery capabilities exceeded their validated ability to restore from backups. Stated RTOs of 4-8 hours for core banking systems were, in many cases, aspirational rather than tested. Several banks in the extensive testing group discovered during the exercise that their backup restoration procedures had not been executed end-to-end in recent memory — or that restoration from backups took significantly longer than their BCP documents stated.

This is the gap that DORA Art. 11(6) directly addresses: financial entities must "test the ICT business continuity plans and the ICT response and recovery plans" at least annually. Art. 11(7) goes further, requiring that entities "record the results of the testing" and "verify that ICT business continuity plans and ICT response and recovery plans are effective." Testing that confirms backup integrity on paper but has never attempted a full system restoration from backup to production-ready state does not meet this standard.

Gap 2: Recovery Prioritization Under Pressure

When multiple systems are compromised simultaneously, which ones do you restore first? The stress test revealed that many banks had defined recovery priorities in their BCP documentation but had not validated these priorities under realistic conditions. When the scenario forced simultaneous decisions — restore the payment system or the customer portal? Rebuild Active Directory or restore database servers? — decision-making slowed, escalation paths became unclear, and recovery sequencing deviated from documented plans.

Art. 11(3) requires that ICT response and recovery plans "take into account the criticality of the affected ICT services and the functions supported." In practice, this means recovery prioritization must be pre-decided, tested, and validated — not negotiated in real-time during an incident.

Gap 3: Third-Party Dependencies in Recovery

A recurring theme was that recovery plans assumed in-house capability for restoration — but actual recovery depended on third-party vendors (managed service providers, cloud infrastructure operators, core banking platform vendors). When the scenario included vendor response time as a variable, recovery timelines extended significantly. Banks that had not contractually specified vendor recovery support obligations (Art. 30(2)(f) requirements) found themselves dependent on best-effort vendor assistance during their most critical hours.

Gap 4: Communication Breakdown Under Stress

The communication dimension revealed a consistent pattern: banks had documented communication plans, but execution under scenario pressure was significantly weaker than documentation suggested. Customer notification templates existed but had not been pre-approved by legal and compliance. NCA notification procedures were documented but had not been practiced. Internal coordination between IT, risk, compliance, legal, and business units was designed for normal operations, not crisis conditions.

Gap 5: Evidence Collection During Incidents

This gap is particularly relevant to DORA compliance. During the scenario exercise, banks focused (understandably) on containment and recovery. Evidence collection — preserving forensic artifacts, maintaining audit trails of decisions made, recording recovery actions and their outcomes — was consistently deprioritized. Yet DORA Art. 17(2) requires that the ICT incident management process include provisions for evidence preservation, and Art. 19 requires detailed incident reporting that depends on evidence collected during the incident.

From Stress Test to SREP: How Findings Affected Banks

The ECB integrated stress test results into the 2024 SREP cycle through two channels:

Quantitative adjustment. Banks with significant recovery gaps faced qualitative overlays on their Pillar 2 capital requirements. While the ECB did not publish the methodology for translating cyber resilience deficiencies into capital adjustments, the signal was clear: operational resilience deficiencies have capital consequences.

Qualitative requirements. Banks received institution-specific findings and recommendations. For banks that underwent extensive testing, these recommendations were detailed and binding through the SREP process. Common qualitative requirements included: conducting end-to-end backup restoration tests within 6 months, documenting and testing recovery prioritization, and establishing contractual recovery support obligations with critical ICT vendors.

The SREP integration is significant because it transforms cyber resilience from a compliance checkbox into a capital and supervisory matter. A bank with a €50 billion balance sheet facing a 10-basis-point Pillar 2 overlay due to cyber resilience deficiencies is paying approximately €50 million in additional capital costs. That concentrates board attention.

DORA Art. 25: From Voluntary Stress Test to Mandatory Testing Programme

The ECB's 2024 stress test was a supervisory exercise — participation was mandatory for the 109 selected banks, but the exercise itself was ad hoc. DORA Art. 24-27 transforms this into a permanent, structured obligation.

Art. 25(1) establishes the baseline: financial entities must establish and maintain a "digital operational resilience testing programme" that is "an integral part of the ICT risk management framework." This programme must include:

Vulnerability assessments and scans (Art. 25(1)(a)). Not once — continuously. The programme must be risk-based, addressing known and emerging threats.

Open source analyses (Art. 25(1)(b)). Assessment of open source components in the technology stack. The SolarWinds, Log4j, and more recently the XZ Utils backdoor discovery (2024) demonstrated why.

Network security assessments (Art. 25(1)(c)). Architecture review, configuration analysis, segmentation testing.

Gap analyses (Art. 25(1)(d)). Comparison of current posture against standards, benchmarks, and regulatory expectations.

Physical security reviews (Art. 25(1)(e)). Data center access controls, environmental controls, and physical infrastructure resilience.

Source code reviews (Art. 25(1)(f)). Where feasible and applicable, particularly for in-house developed critical applications.

Scenario-based testing (Art. 25(1)(g)). Including the scenario-based approach that the ECB stress test piloted — but now as a permanent programme element, not a one-off exercise.

Compatibility testing (Art. 25(1)(h)). Integration and interoperability testing between systems.

Performance testing (Art. 25(1)(i)). Load testing, stress testing under peak conditions.

End-to-end testing (Art. 25(1)(j)). Full chain testing from input to output, including third-party integration points.

The testing programme must cover "all ICT systems and applications supporting critical or important functions" (Art. 25(2)) and must be conducted "by independent parties, whether internal or external" (Art. 25(4)). For entities required to perform TLPT under Art. 26, the programme must also include threat-led penetration testing at least every three years.

A Recovery Maturity Model

The ECB stress test findings, mapped to DORA requirements, suggest a five-level recovery maturity model that institutions can use for self-assessment:

The ECB stress test revealed that most banks operate between Level 2 and Level 3. DORA demands at minimum Level 4 for entities with critical or important functions, and Level 5 is the supervisory expectation for systemically important institutions.

What This Means for 2025 and Beyond

The ECB has indicated that cyber resilience stress testing will become a recurring element of its supervisory toolkit. The 2024 exercise was the baseline — future iterations will assess progress against the gaps identified and will benefit from DORA's now-binding framework to set clear expectations.

For banks, the actionable takeaways are concrete:

Test backup restoration, not backup creation. The gap between "backups are running" and "we can restore from backups within our stated RTO" is the most consequential finding. Validate end-to-end restoration quarterly for critical systems.

Pre-decide and rehearse recovery prioritization. When 15 systems are down simultaneously, the decision about which to restore first must be made in advance, validated by business stakeholders, and rehearsed under scenario conditions.

Contractualize vendor recovery support. Art. 30(2)(f) is not a paperwork exercise. Your recovery plan must account for vendor response time, and your contracts must specify vendor obligations during your crisis.

Integrate evidence collection into incident playbooks. Evidence is not an afterthought. Build evidence collection (screenshots, decision logs, timeline records, forensic preservation) into the incident response procedures so it happens automatically, not as a post-incident scramble.

Report results to the board. Art. 14 requires annual reporting to the management body on ICT risk. Testing results — including gaps identified and remediation timelines — are a core element of this reporting obligation.

The ECB's first cyber stress test established a precedent: supervisors will test recovery capability, not just review documentation. DORA makes this permanent. The 109 banks that participated in 2024 received an early preview of the supervisory expectations that now apply to every in-scope financial entity in the EU. The question is no longer whether your recovery plans look good on paper. The question is whether they work.

---

This analysis is based on ECB Banking Supervision's published results of the 2024 cyber resilience stress test, integrated with DORA Regulation (EU) 2022/2554 requirements effective January 17, 2025.

---