Learn
Somewhere between the Register of Information and the ICT incident classification framework, most financial entities lose sight of one of DORA’s most consequential requirements: the annual digital operational resilience testing programme.
This is not a nice-to-have. Article 24 of Regulation (EU) 2022/2554 requires every in-scope financial entity - from banks and insurers to payment institutions and crypto-asset service providers - to establish, maintain, and review a comprehensive testing programme as an integral part of their ICT risk management framework. The management body must approve this programme. They must receive reports on its outcomes. They must sign off on remediation plans when testing uncovers weaknesses.
Yet in practice, many organisations treat resilience testing as a disconnected set of ad-hoc penetration tests and vulnerability scans run by InfoSec. That will not survive regulatory scrutiny. DORA demands a structured, risk-based, board-approved programme that covers far more than just pen tests - and it demands evidence that the programme is actually followed.
This article walks through every component of the annual testing programme, the specific testing types DORA requires, the board governance obligations, and how to build a programme structure that satisfies both the letter and spirit of the regulation.
📜
The Legal Basis
What DORA Requires for Resilience Testing
DORA’s testing requirements span Articles 24 through 27, forming Chapter IV of the regulation. Together, they create a two-tier testing framework: basic testing that applies to all financial entities, and advanced threat-led penetration testing (TLPT) required for significant institutions.
Article 24 sets the overarching requirement. Financial entities must establish, maintain, and review a “sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework.” This programme must:
- Cover all ICT systems and applications supporting critical or important functions
- Follow a risk-based approach when determining which systems to test and how
- Be reviewed and updated at least annually
- Include a variety of testing types - not just penetration testing
- Be approved by the management body (board of directors or equivalent)
Article 25 specifies the testing types for all entities. Articles 26-27 define the advanced TLPT requirements for significant entities identified by competent authorities. The Regulatory Technical Standards (RTS) under Article 24(2) further detail the criteria for testing methodologies, scope, and frequency.
Key Principle: Risk-Based, Not Tick-Box
DORA explicitly requires a “risk-based approach” to testing. This means your programme cannot simply run the same vulnerability scan on every system quarterly and call it compliant. The testing types, frequency, and depth must be proportionate to the criticality of each system and the risks it faces. A core banking platform supporting payment processing demands fundamentally different testing than an internal HR portal.
🔍
Article 25 Requirements
Types of Testing Required Under DORA
Article 25(1) provides an explicit list of testing types that financial entities must include in their programme. This is not a menu to pick from - the regulation uses “shall include” language, meaning all applicable types must be addressed. Where a specific type is not feasible (e.g., source code review for vendor-provided applications), the entity must document the rationale for exclusion.
| Testing Type | What It Covers | Typical Frequency | Applies To |
|---|---|---|---|
| Vulnerability assessments & scans | Automated scanning of infrastructure, applications, and endpoints for known vulnerabilities (CVEs, misconfigurations) | Monthly / Continuous | All entities |
| Network security assessments | Review of network architecture, segmentation, firewall rules, access controls, and traffic analysis | Quarterly / Semi-annual | All entities |
| Gap analyses | Comparison of current controls against DORA requirements, industry standards (ISO 27001, NIST), and internal policies | Annual | All entities |
| Physical security reviews | Assessment of data centre access controls, environmental protections, and physical security of ICT infrastructure | Annual | All entities |
| Source code reviews | Static and dynamic code analysis of in-house developed applications; review of critical vendor code where feasible | Per release / Semi-annual | Where feasible |
| Scenario-based testing | Tabletop exercises and simulation of plausible adverse scenarios (ransomware, cloud provider outage, key person loss) | Semi-annual / Annual | All entities |
| Compatibility testing | Verification that system updates, patches, and migrations do not introduce interoperability failures or degradation | Per change / Quarterly | All entities |
| Performance testing | Load testing, stress testing, and capacity analysis under normal and peak conditions | Quarterly / Semi-annual | All entities |
| End-to-end testing | Validation of complete business process chains across systems, including failover, backup restoration, and disaster recovery | Semi-annual / Annual | All entities |
| Penetration testing | Authorised simulated attacks on systems, networks, and applications to identify exploitable vulnerabilities | Annual (minimum) | All entities |
Proportionality Matters
Microenterprises benefit from a simplified testing regime under Article 25(3) - they may apply a “simplified ICT risk management framework” and are exempt from some advanced testing requirements. However, the core obligation to test critical systems remains. If you are unsure whether the simplified regime applies, consult your NCA’s guidance or legal counsel.
📅
Programme Structure
Building the Annual Testing Programme
A compliant programme is not a list of tests. It is a governed document that links testing activities to your ICT risk landscape, assigns responsibilities, sets timelines, and defines how findings flow from discovery to remediation to board reporting. Here is the structure we recommend, aligned with the RTS requirements.
1. Scope Definition
Start by identifying every ICT system and application that supports a critical or important function. DORA defines these in Article 3(22) as functions whose disruption would materially impair financial performance, the soundness of services, or the continuity of regulated activities. Your scope must include:
- Core banking, payment processing, and trading systems
- Client-facing digital channels (mobile banking, online portals)
- ICT services provided by third-party providers (especially critical ones)
- Supporting infrastructure: identity management, DNS, email, backup systems
- Business continuity and disaster recovery arrangements
2. Testing Calendar
Map each testing type to a cadence. Not everything runs annually - vulnerability scans should be continuous or monthly, while TLPT runs every three years. A well-structured calendar prevents both gaps and fatigue.
| Cadence | Testing Activities |
|---|---|
| Continuous / Monthly | Automated vulnerability scanning, SAST/DAST on new releases, configuration drift monitoring |
| Quarterly | Network security assessments, performance/load testing, compatibility testing for major changes |
| Semi-annual | Scenario-based tabletop exercises, end-to-end DR testing, source code reviews of critical systems |
| Annual | Full penetration testing, physical security reviews, comprehensive gap analysis, programme review and board re-approval |
| Every 3 years | Threat-Led Penetration Testing (TLPT) - significant entities only, per Art. 26 |
3. Resource Allocation
The programme must define who performs each test. DORA requires that penetration testing be carried out by independent testers - either an independent internal team or qualified external providers. For TLPT specifically, Article 27 mandates the use of external threat intelligence providers and testers certified under the TIBER-EU framework or equivalent.
Budget accordingly: external pen tests for critical systems typically cost €15,000-€50,000 per engagement, while a full TLPT exercise can range from €150,000 to €500,000. Internal teams handle continuous scanning and routine assessments, but the programme must clearly delineate internal versus external responsibilities.
4. Risk Prioritisation Methodology
Not all systems warrant the same testing intensity. Your programme must document a methodology for prioritising testing based on:
- Business criticality: Does the system support a critical or important function?
- Threat exposure: Is the system internet-facing? Does it process sensitive data?
- Change velocity: Has the system undergone significant changes since the last test?
- Historical findings: Have previous tests uncovered significant vulnerabilities?
- Third-party dependency: Is the system reliant on critical ICT providers?
5. Findings Management Process
DORA Article 24(5) requires that “all identified weaknesses, deficiencies or gaps” be “promptly fully addressed.” Your programme must define:
- How findings are classified (Critical / High / Medium / Low)
- Remediation timelines per severity (e.g., Critical: 72 hours, High: 2 weeks, Medium: 30 days, Low: 90 days)
- Escalation paths when remediation deadlines are missed
- Re-testing requirements to confirm remediation effectiveness
- Risk acceptance process for findings that cannot be immediately remediated
6. Board Reporting Cadence
Define how and when the management body receives testing information. We recommend a three-tier approach:
- Immediate: Critical findings that pose an imminent threat to operational continuity
- Quarterly: Summary dashboard of testing activities, findings trends, remediation status
- Annual: Full programme review with effectiveness assessment and proposal for the next year’s programme
Programme Document Tip
Your testing programme should be a living document - not a PDF gathering dust on SharePoint. It should be versioned, linked to your risk register, and updated whenever your ICT landscape changes materially (new systems, new providers, major incidents). Regulators will ask to see the current version and evidence that it was followed.
🏛️
Governance
Board Oversight Requirements Under Art. 5(2)
DORA places ICT risk governance firmly at the board level. Article 5(2) states that the management body shall “bear the ultimate responsibility for managing the financial entity’s ICT risk.” This is not delegable. Individual board members can face personal accountability for failures in ICT risk management, including inadequate testing programmes.
“The management body of the financial entity shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework.”
- DORA Article 5(2)(a)
In practical terms, this means the board must:
| Board Obligation | DORA Reference | What This Means in Practice |
|---|---|---|
| Approve the testing programme | Art. 5(2), Art. 24 | Formal board resolution approving the annual programme, documented in board minutes with individual accountability noted |
| Receive testing outcome reports | Art. 5(2)(e) | Regular board reporting on test results, findings severity distribution, and trend analysis - not just a green/red dashboard |
| Approve remediation plans | Art. 5(2), Art. 24(5) | Board must sign off on how critical and high-severity findings will be addressed, including timelines and resource allocation |
| Ensure adequate resources | Art. 5(2)(b) | Allocate sufficient budget and personnel for the testing programme - underfunding is itself a governance failure |
| Maintain personal competence | Art. 5(4) | Board members must keep their ICT knowledge up to date, including understanding of testing methodologies and their limitations |
Personal Accountability Is Real
DORA Article 5(4) requires board members to “actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk.” This includes understanding the testing programme they are approving. A board member who rubber-stamps a testing programme without understanding its scope, limitations, or findings is personally exposed. Competent authorities can and will hold individual members accountable under Article 50’s administrative penalties.
📈
Testing Tiers
From Basic to Advanced: The DORA Testing Progression
DORA creates a clear two-tier testing structure. Understanding which tier applies to your entity is essential for programme design and budgeting.
Tier 1: Basic Testing (All Entities - Article 25)
Every financial entity in scope of DORA must perform the testing types listed in Article 25. This is the baseline - the minimum your programme must deliver. It includes all ten testing types from the table above, performed at appropriate frequencies based on your risk assessment.
The key requirement at this tier: all testing of ICT systems and applications supporting critical or important functions must be carried out at least annually. Penetration testing must be performed at least every three years, but best practice (and what regulators expect) is annual.
Tier 2: Threat-Led Penetration Testing (Significant Entities - Articles 26-27)
Competent authorities identify entities that must carry out TLPT at least every three years based on the entity’s systemic importance, ICT maturity, and risk profile. TLPT goes far beyond standard penetration testing:
- Must be based on real-world threat intelligence specific to the entity
- Must test live production systems (not just staging environments)
- Must be carried out by external, qualified testers (TIBER-EU framework or equivalent)
- Must involve the competent authority (notification and attestation)
- Results must be reported to the competent authority and the management body
How to determine if you need TLPT: Your competent authority (e.g., BaFin, ACPR, DNB, CBI) will notify you if you are identified for TLPT. The criteria under Article 26(8) include systemic importance, the nature of your ICT risk profile, and the level of ICT maturity. If you are a significant credit institution, a central counterparty, or a major payment institution, assume you will be designated. Even if not yet notified, building TLPT readiness into your programme demonstrates maturity to supervisors.
TLPT Budget Reality Check
A full TLPT exercise - from threat intelligence scoping through red team execution to purple team debrief - typically takes 6-12 months and costs €150,000-€500,000 depending on scope. This must be budgeted separately from your standard testing programme. Board members need to understand this cost when approving the multi-year testing strategy.
🔧
After Testing
Findings Remediation and Tracking
Testing without follow-through is compliance theatre. DORA makes this explicit: Article 24(5) requires that findings be “promptly fully addressed” and that the entity can demonstrate how it has done so. Here is the remediation lifecycle your programme must support:
1
Discovery & Classification
Each finding is assigned a severity (Critical/High/Medium/Low), linked to the affected system, mapped to the relevant DORA article, and assigned an owner within the first and second lines of defence.
2
Remediation Planning
A remediation plan is developed with concrete actions, responsible parties, target dates, and resource requirements. For critical findings, this plan must be escalated to the management body.
3
Implementation & Tracking
Remediation actions are tracked against deadlines. Overdue items trigger automatic escalation. Status is visible to both operational teams and compliance/risk functions.
4
Verification & Re-Testing
Once remediation is complete, the finding is re-tested to confirm the vulnerability has been effectively addressed. Only after successful re-testing can a finding be closed.
5
Risk Acceptance (Exception Path)
Where immediate remediation is not feasible, a formal risk acceptance must be documented with compensating controls, an expiration date, and senior management (or board) approval depending on severity.
“Financial entities shall establish mechanisms to promptly fully address all issues revealed during the execution of [digital operational resilience] tests and shall establish methodologies to prioritise the implementation of related corrective measures.”
- DORA Article 24(5)
⚡
Platform Capabilities
How Venvera Manages Your Testing Programme
Venvera was purpose-built for DORA compliance. Our platform provides the tools to plan, execute, track, and report on your entire resilience testing programme - from board-level oversight to individual vulnerability remediation.
Testing Calendar & Programme Management
Define your annual programme with structured testing schedules mapped to each critical system and business function. Track completion status against planned dates, and surface overdue tests automatically. The programme links directly to your ICT risk register, ensuring coverage aligns with your assessed risk landscape.
Findings Tracking & Remediation Workflows
Every test finding flows into a centralised findings register with severity classification, assigned ownership, remediation deadlines, and status tracking. Automated escalation alerts prevent findings from going stale. Re-testing requirements are built into the workflow - a finding cannot be closed without verification evidence.
Board-Ready Reports
Generate board reporting packs that summarise testing activities, findings distribution by severity, remediation progress, and risk trends - all formatted for non-technical audiences. Quarterly dashboards and annual programme reviews are pre-structured to meet Art. 5(2) reporting obligations.
TLPT Coordination
For entities subject to TLPT, Venvera provides a dedicated coordination workspace: threat intelligence documentation, red team scope definition, purple team findings capture, competent authority communication tracking, and the full remediation plan through to NCA attestation.
Gap Analysis & Risk Assessment Integration
Testing results feed directly into your DORA gap assessment and risk assessment modules. When a penetration test reveals a control weakness, the corresponding gap assessment item is updated automatically. This closed-loop approach ensures your risk picture always reflects your actual test results - not last year’s assumptions.
💡
Next Steps
Your Board Meeting Is Coming - Be Ready
DORA is not a future obligation. It has been applicable since 17 January 2025. If your board has not yet approved an annual digital operational resilience testing programme, you are already operating outside the regulation’s requirements.
The good news: building a compliant programme is achievable. It requires structure, not perfection. Start with the six components outlined above: scope, calendar, resources, risk prioritisation, findings management, and board reporting. Document it. Get board approval. Execute it. Report on it. Improve it next year.
The alternative - a collection of ad-hoc tests with no formal programme, no board oversight, and no remediation tracking - will not survive a supervisory examination. And under DORA’s administrative penalty regime, the consequences extend beyond the institution to individual board members.
Disclaimer: This article is for informational purposes only and does not constitute legal or regulatory advice. The interpretation of DORA requirements may vary by jurisdiction and entity type. Always consult your competent authority’s guidance and qualified legal counsel for entity-specific compliance obligations. Article references are to Regulation (EU) 2022/2554.
