Contents
Digital operational resilience testing programme
Purpose of the Requirement
The Digital Operational Resilience Testing Programme (DORTP) is the structured, risk-based testing framework through which a financial entity validates the resilience, integrity, availability, and security of its ICT landscape.
It operationalises Articles 24–26 DORA and ensures that ICT tools, systems, processes, and controls operate effectively under normal and stressed conditions.
The purpose is to provide continuous assurance, detect weaknesses before exploitation, validate the effectiveness of ICT controls, and ensure that digital resilience levels meet regulatory requirements and the entity’s risk appetite.
Scope of Application
The testing programme applies to all ICT components supporting:
- business functions and support processes,
- critical or important functions,
- internal ICT services,
- externally provided services (including cloud, intragroup, and outsourced ICT),
- infrastructure, platforms, applications, data flows, networks, and endpoints.
The programme must also cover:
- ICT third-party services (per Article 25(2)(b) RTS RMF),
- ICT response & recovery capabilities (Article 26 RTS RMF),
- scenarios derived from the BIA, ICT risk assessment, and threat intelligence.
The scope must follow the risk-based and proportionality principles under Article 4(2) DORA.
Mandatory Components
Full Coverage of Required Test Types (Article 25(1) DORA)
The testing programme must provide for the execution of appropriate tests, including at least the following (as applicable):
- Vulnerability assessments and scans
- Open-source analysis (including third-party library analysis)
- Network security assessments
- Gap analyses (control design/operating effectiveness gaps)
- Physical security reviews
- Questionnaires and automated scanning tools
- Source code reviews (where feasible and risk-appropriate)
- Scenario-based tests (aligned with BIA and threat intelligence)
- Compatibility testing
- Performance testing (load, stress, capacity)
- End-to-end testing (process & workflow integrity)
- Penetration testing (commensurate to criticality and risk)
Each test type must be selected and applied based on:
- ICT asset classification (Article 8(1) DORA),
- overall risk profile,
- criticality of functions supported,
- specific resilience threats identified.
Programme Structure and Methodological Requirements (Article 24(2) DORA)
The Digital Operational Resilience Testing Programme must include:
- a range of testing methodologies (automated, manual, hybrid),
- structured test design aligned to regulatory, technical, and BIA-derived scenarios,
- minimum testing frequencies,
- testing depth commensurate to criticality and risk,
- independence of testers where required (e.g., advanced testing for critical functions),
- multilayer testing (preventive, detective, corrective controls),
- testing of ICT third-party services where relevant,
- integration with incident detection thresholds and response processes,
- requirements for documentation, follow-up, and remediation.
The programme must form part of the broader ICT risk management framework and align with:
- ICT security measures (Article 9 DORA),
- ICT BCP & response/recovery testing (Articles 11, 12, 25 RTS RMF),
- ICT third-party oversight (Article 28 DORA),
- Threat-led penetration testing requirements (for entities in scope of Article 26).
Interdependencies with Other DORA Requirements
The Digital Operational Resilience Testing Programme must be directly linked to:
- Article 24(5) DORA – prioritisation, classification, remediation, and internal validation of weaknesses and gaps,
- Article 25 RTS RMF – BCP-related testing, including failover and resilience scenarios,
- Article 26 RTS RMF – response & recovery plan testing based on severe disruption scenarios,
- Article 23 RTS RMF – anomalous activity detection and incident thresholds,
- Article 8 DORA – ICT asset classification and dependency mapping,
- Article 6(8) DORA – digital operational resilience strategy,
- Article 28 DORA – testing of ICT services provided by third-party service providers.
The testing programme must feed results into:
- ICT risk assessment updates,
- ICT security hardening activities,
- BIA refinement,
- business continuity enhancements,
- incident detection threshold recalibrations,
- third-party performance and resilience assessments.
Documentation Requirements
The financial entity must document:
- the full structure of the testing programme, including objectives and scope,
- all methodologies, protocols, tools, and types of tests used,
- test selection rationale and risk-based scoping decisions,
- testing schedules and frequencies,
- detailed test results, logs, and artefacts,
- identified weaknesses, gaps, or deficiencies,
- prioritisation, classification, and remediation actions (linked to Article 24(5)),
- internal validation methodologies and evidence of closure,
- independence requirements and tester qualifications,
- integration points with ICT BCP and response/recovery testing.
Documentation must be sufficiently granular to allow supervisory audit, replayability of tests, and traceability of remediation.
Governance and Oversight
The governance framework must ensure:
- management body oversight and periodic review (Article 5 DORA),
- assignment of roles and responsibilities across ICT, security, risk, and internal audit,
- independence of testers for critical or important functions (as required by DORA),
- escalation of critical findings to senior management and, where applicable, the management body,
- alignment of testing activities with the entity’s risk tolerance, resilience strategy, and regulatory expectations.
Where threat-led penetration testing (TLPT) applies (Article 26), governance must include:
- independent external providers,
- red team / blue team separation,
- intelligence-based scenario development,
- mandatory remediation and validation cycles.