Building Your DORA Testing Programme: A Practical 12-Month Roadmap

The Gap Between Framework and Execution

When the ECB published the results of its first cyber resilience stress test in July 2024, the headline finding was diplomatic: response frameworks generally exist, but recovery capabilities need improvement. The subtext was less polite: most of the 109 tested banks had documents describing what they would do during a cyber incident. Far fewer had demonstrated the ability to actually do it.

This gap between documented frameworks and validated capabilities is precisely what DORA's Pillar III — Digital Operational Resilience Testing (Art. 24-27) — is designed to close. Art. 24(1) requires every in-scope financial entity to establish, maintain, and review "a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework." The operative words are "sound" and "comprehensive" — not "documented" and "filed."

Building a testing programme that meets DORA requirements is a 12-month effort for most institutions. Not because the testing itself takes 12 months, but because the foundation work — inventory, scoping, risk-based prioritization, resource allocation, and integration with existing processes — must precede the testing, or the testing produces compliance artifacts rather than operational insights.

The Testing Pyramid Under DORA

Art. 25(1) enumerates the testing types that must be included in the programme. These form a testing pyramid — each layer builds on the one below, and skipping foundational layers undermines the value of advanced testing:

Art. 25(3) applies the proportionality principle: the testing programme shall be "proportionate to the size and the overall risk profile of the financial entity, taking into account the nature, scale and complexity of its services, activities and operations." Proportionality calibrates the depth and breadth of each tier — it does not eliminate tiers. A small payment institution still needs vulnerability assessments and scenario testing; the scope is narrower, but the requirement is not waived.

Figure 1: The 12-month DORA testing programme roadmap. Foundation work in months 1-3 must precede testing, or the testing produces compliance artifacts rather than operational insights.

Month 1-3: Foundation (Inventory, Scoping, Governance)

Month 1: ICT Asset and Function Inventory

You cannot test what you have not inventoried. The first month is dedicated to building (or validating) the inventory that scopes the entire testing programme.

Critical and important functions (Art. 3(22)). List every function whose disruption would materially impair the entity's financial performance, service continuity, or regulatory standing. For a bank: payment processing, lending origination, customer onboarding, regulatory reporting, treasury management. For an insurer: claims processing, policy administration, underwriting, actuarial computation.

Supporting ICT systems. Map each critical function to the ICT systems that support it: applications, databases, infrastructure components, network segments, third-party integrations. This mapping directly supports Art. 25(2), which requires the programme to cover "all ICT systems and applications supporting critical or important functions."

Third-party dependencies. Identify which critical functions depend on ICT third-party service providers. These dependencies must be included in scenario testing (Art. 25(1)(g)) — a scenario that assumes all internal systems are available while ignoring the fact that three critical functions depend on a single cloud provider is not realistic.

Month 2: Risk-Based Prioritization

With the inventory complete, prioritize based on risk:

Impact assessment. For each critical function, assess the impact of disruption: financial loss per hour, customer impact, regulatory consequences, reputational damage. This drives testing priority — the functions with the highest disruption impact are tested first and most thoroughly.

Threat landscape. Map the entity's threat landscape to specific ICT systems. Which systems are most exposed to the current threat environment? The ENISA Threat Landscape report documented 488 significant incidents affecting the EU financial sector between January 2023 and June 2024, with banks representing 46% of incidents. Ransomware, supply chain attacks, and credential theft are the dominant vectors — testing scenarios should reflect these realities.

Current testing baseline. Assess what testing already exists. Most financial institutions have some vulnerability scanning, some penetration testing, and some DR testing. The gap analysis identifies what DORA requires that is not currently performed, at the required frequency, at the required scope.

Month 3: Programme Governance and Resource Allocation

Governance structure. Define who owns the testing programme (typically the CISO or CTO, with board-level reporting via Art. 14), who coordinates test execution (testing team or managed service provider), who reviews results (risk committee), and who tracks remediation (second line of defense).

Resource plan. Estimate the resources required for each testing tier across the 12-month cycle:

Evidence framework. Define from the start how testing evidence will be collected, stored, and reported. DORA Art. 24(5) requires that testing results and remediation plans be "validated by the competent authority." Evidence must be structured, retrievable, and audit-ready — not scattered across email threads and consultant reports.

Month 4-6: Foundational Testing (Tiers 1-3)

Month 4: Continuous Vulnerability Management

Deploy or validate continuous vulnerability assessment covering:

• External attack surface (internet-facing systems, APIs, web applications)
• Internal infrastructure (servers, databases, network devices, endpoints)
• Cloud infrastructure (configuration assessment, IAM review, storage exposure)
• Third-party integrations (API security, certificate management)

The key distinction: DORA does not require occasional vulnerability scanning. Art. 25(1)(a) requires vulnerability assessments as a programme element, which supervisors interpret as continuous or at minimum quarterly for critical systems.

Month 5: Network Security and Architecture Assessment

Art. 25(1)(c) requires network security assessments. This includes:

• Network segmentation validation (can a compromise in one zone reach critical systems?)
• Firewall rule review (are rules still appropriate, or have they accumulated exceptions?)
• Access control assessment (least privilege validation, privileged access management)
• Encryption posture (TLS configuration, certificate management, data-at-rest encryption)

Month 6: Open Source and Dependency Analysis

Art. 25(1)(b) requires "open source analyses." This reflects the systemic risk that open source dependencies create — as demonstrated by Log4j (2021), the XZ Utils backdoor attempt (2024), and numerous other supply chain incidents.

Deploy Software Composition Analysis (SCA) tooling across:

• Application dependencies (libraries, frameworks, packages)
• Container images (base images, layer dependencies)
• Infrastructure-as-code templates (Terraform modules, Helm charts)
• Transitive dependencies (dependencies of dependencies — the hidden attack surface)

Month 7-9: Advanced Testing (Tiers 4-6)

Month 7-8: Scenario-Based Testing

This is where the testing programme transitions from technical validation to operational resilience assessment. Art. 25(1)(g) requires scenario-based testing — testing that simulates realistic adverse events and assesses the entity's ability to respond, recover, and communicate.

Minimum scenario set for a mid-size financial entity:

Scenario 1: Ransomware attack on core systems. All critical systems encrypted. Backups must be validated. Recovery prioritization must be exercised. NCA notification timelines must be met. Customer communication must be executed. This is the scenario the ECB stress test used, and it revealed the most significant gaps.

Scenario 2: Critical third-party provider outage. Your most critical ICT provider is unavailable for 72 hours. Can you operate? Can you switch to alternatives? Do your contracts specify the provider's recovery obligations?

Scenario 3: Data breach with exfiltration. Customer data has been stolen and published. Incident response, regulatory notification (Art. 19 timelines), customer notification, media management, and forensic investigation must all be exercised simultaneously.

Scenario 4: Insider threat. A privileged administrator has exfiltrated data and sabotaged systems. Detection, containment, and recovery must operate without the usual assumption that internal access is trusted.

For each scenario, document: participants, scenario narrative, decisions made, recovery actions taken, timelines achieved vs. target, evidence collected, gaps identified, and remediation actions.

Month 9: Source Code Review and Performance Testing

Source code reviews (Art. 25(1)(f)) for critical in-house applications. Focus on: authentication and authorization logic, data handling (input validation, output encoding), cryptographic implementations, session management, and API security. Static application security testing (SAST) tooling provides continuous baseline; manual expert review provides depth for the most critical code paths.

Performance testing (Art. 25(1)(i)) validates that critical systems perform under load conditions that reflect peak business scenarios. A payment system that processes 1,000 transactions per second during normal operations but fails at 3,000 TPS during month-end peak has a resilience gap that technical testing alone would not reveal.

Month 10-11: Integration Testing and TLPT Preparation

Month 10: End-to-End Testing

Art. 25(1)(j) requires end-to-end testing that validates the full transaction chain from input to output, including third-party integration points. This testing bridges the gap between component-level technical testing and operational resilience:

• Payment chain: customer initiation → authentication → authorization → clearing → settlement → confirmation
• Claims chain: FNOL submission → registration → assessment → approval → payment
• Regulatory reporting chain: data extraction → aggregation → validation → submission → acknowledgment

End-to-end testing must include third-party integration points operating in test mode or with coordinated vendor participation. A payment chain test that mocks the clearing house is not end-to-end.

Month 11: TLPT Preparation (If Designated)

For entities designated by their NCA for TLPT under Art. 26:

• Engage with the NCA on scoping (which critical functions will be included)
• Pre-qualify external threat intelligence providers
• Pre-qualify external red team providers (for the mandatory external cycle)
• Assess internal red team readiness (for the two permitted internal cycles)
• Establish the governance framework for TLPT coordination, purple teaming, and remediation

Month 12: Programme Review, Reporting, and Continuous Improvement

Consolidation and Board Reporting

Art. 14 requires annual reporting to the management body on ICT risk. The testing programme results are a core component of this report. The annual board report should include:

• Testing programme coverage (which critical functions tested, by which methods)
• Key findings by severity and remediation status
• Trend analysis (are findings decreasing? Are new risk areas emerging?)
• Resource utilization vs. plan
• Programme maturity assessment against the target model
• Recommendations for the next 12-month cycle

Programme Maturity Self-Assessment

Use the following maturity model to assess programme progress:

Most institutions should aim to reach Level 4 by the end of Year 1. Level 5 is a continuous improvement objective that evolves with the threat landscape and regulatory expectations.

Continuous Improvement Integration

Art. 13 requires that financial entities establish "mechanisms to identify and incorporate lessons learned from ICT-related incidents, including during and after implementation of recovery plans." Testing findings feed directly into this requirement:

• Vulnerability findings update the risk register and inform next-cycle testing priorities
• Scenario testing gaps trigger remediation projects and updated recovery plans
• Performance testing results inform capacity planning and architecture decisions
• TLPT findings (when applicable) drive strategic security investment

The Testing Programme as Evidence

Figure 2: The evidence chain from testing programme to NCA validation. Every link must be documented: plan, execution, findings, remediation, retest, and board reporting.

Under DORA, the testing programme is not just a security activity — it is a compliance evidence artifact. Art. 24(5) specifies that "financial entities shall document and report all findings resulting from the testing and shall draw up and implement a remediation plan." The NCA can request testing programme documentation, results, and remediation evidence at any time.

This means the programme must produce structured, auditable evidence at every step:

• Inventory and scoping documentation (what was in scope and why)
• Testing plans and schedules (what was tested, when, by whom)
• Testing results and findings (what was found, severity classification)
• Remediation plans and tracking (what is being fixed, by when, evidence of closure)
• Board reporting (what the management body was told and when)

A testing programme that produces excellent security findings but poor evidence fails the DORA compliance test. A testing programme that produces excellent evidence of shallow testing fails the operational resilience test. The objective is both: substantive testing that produces auditable evidence of genuine operational resilience assessment and continuous improvement.

---

This roadmap reflects DORA Regulation (EU) 2022/2554 Articles 24-27 testing requirements and incorporates findings from the ECB's 2024 cyber resilience stress test. Specific resource estimates are indicative and vary by institution size and complexity.

---