Learn
Here’s an uncomfortable question: when was the last time your resilience testing programme found something that genuinely surprised you?
If the answer is “never” - and in my experience, for about 70% of firms, it is - then your testing programme isn’t testing resilience. It’s confirming assumptions. And that’s exactly the problem DORA is trying to fix.
DORA Articles 24 through 27 require a “comprehensive digital operational resilience testing programme.” Those words are doing a lot of heavy lifting. “Comprehensive” means it covers multiple test types, not just your annual pen test. “Digital operational resilience” means it tests your ability to withstand, respond to, and recover from ICT disruptions - not just your ability to block a port scan. And “programme” means it’s a structured, board-approved plan with defined scope, schedule, and feedback mechanisms - not a collection of tests someone remembered to run.
This article breaks down what a compliant testing programme looks like, what test types are required, how to handle TLPT, and - most importantly - how to make the results actually useful rather than filing them in a SharePoint folder nobody opens.
What DORA Requires vs. What Most Firms Currently Do
Let me show you the gap with a simple comparison:
| What DORA Requires | What Most Firms Do |
|---|---|
| Multiple test types: vulnerability assessments, open source analysis, network security, physical security, scenario-based, compatibility, performance, pen testing | Annual pen test + quarterly vulnerability scan |
| Board-approved programme with defined scope and schedule | CISO manages testing; board gets a summary once a year |
| Testing covers all critical ICT systems and applications | Testing covers internet-facing systems only |
| Findings feed back into risk management framework | Findings go into a report. Report goes into SharePoint. |
| Remediation tracked to completion with verification | Findings prioritised, some fixed, no verification that fixes worked |
| TLPT every 3 years for significant entities | “We’re not sure if TLPT applies to us” |
If your current programme fits the right column more than the left, you have work to do. The good news: DORA doesn’t require you to run every test type every year. It requires a programme that covers all necessary test types over a reasonable cycle. But the programme must be intentional, documented, and approved by your management body.
The Test Types, Explained
What each one is, how often it should run, and what it should actually tell you
Vulnerability Assessments
Frequency: At least quarterly, more often for critical systems
Automated scanning of your systems for known vulnerabilities (CVEs). This is table stakes. What DORA adds: the scope must include all critical ICT systems, not just internet-facing ones. Internal systems, databases, middleware, legacy applications - all in scope. And the results must be tracked to remediation, with defined SLAs for patching based on severity.
Open Source Analysis
Frequency: Continuous or at least with each release
Software composition analysis - identifying open source components in your applications and checking them for known vulnerabilities. This is increasingly important as supply chain attacks target widely-used libraries. If your development team is using npm packages with 47 transitive dependencies, you need to know what’s in there. The Log4Shell incident taught everyone this lesson. DORA codified it.
Network Security Testing
Frequency: At least annually, and after significant network changes
Testing of network segmentation, firewall rules, access control lists, and network architecture. This goes beyond “is the firewall configured correctly?” to “if an attacker compromises system A, can they reach system B?” Lateral movement testing. Segmentation verification. The kind of testing that finds the forgotten VLAN that connects the guest Wi-Fi to the trading floor network. (Yes, I’ve seen that.)
Scenario-Based Testing
Frequency: At least annually
This is where testing gets genuinely valuable. Scenario-based testing means: “What happens if our core banking provider goes down for 24 hours?” “What happens if we lose access to our data centre?” “What happens if a ransomware attack encrypts our backup servers?” These are tabletop exercises at minimum, simulation exercises ideally. They test your response capability, not just your technical controls. DORA specifically asks for this because resilience isn’t just about prevention - it’s about recovery.
Compatibility Testing
Frequency: Before significant changes
Testing whether systems continue to work correctly when changes are made to the ICT environment. Operating system upgrades, middleware updates, API version changes. The kind of testing that prevents the Monday morning surprise where a vendor’s patch broke the interface between your payment system and your ledger.
Performance Testing
Frequency: At least annually, and before peak periods
Load testing, stress testing, capacity testing. Can your systems handle peak transaction volumes? What happens at 150% of expected load? At 200%? Performance degradation under stress is an operational resilience concern. If your payment system slows to a crawl on Black Friday, that’s an availability issue that could trigger incident reporting. Test it beforehand.
Penetration Testing
Frequency: At least annually
The one everyone already does. But DORA raises the bar: pen tests should cover critical ICT systems, not just internet-facing assets. They should be performed by qualified independent testers (internal or external, but with demonstrated competence). And the findings must - must - feed into the risk management framework and be tracked to remediation with verification that the fix actually works.
TLPT: The Big One (and Whether It Applies to You)
Threat-Led Penetration Testing (TLPT) under DORA Article 26 is the most intensive testing requirement. It’s based on the TIBER-EU framework and simulates real-world attack scenarios targeting your critical functions, using threat intelligence specific to your organisation.
But TLPT doesn’t apply to everyone. It applies to financial entities that are:
- Identified by their NCA as requiring TLPT (based on systemic importance, risk profile, or ICT maturity)
- Significant institutions under the SSM framework (for eurozone banks)
- Payment institutions or e-money institutions above certain thresholds
If TLPT applies to you, it must be conducted at least every three years by external testers with specific qualifications (certified red team providers). The test must be based on threat intelligence, target your live production environment (with appropriate safeguards), and cover your critical business functions.
TLPT is expensive. A single engagement typically costs €200,000-500,000 depending on scope and complexity. But for entities subject to the requirement, it provides the most realistic assessment of operational resilience available. Unlike a standard pen test, TLPT simulates an actual adversary - with their own objectives, techniques, and time pressure - operating against your real defenses.
If you’re unsure whether TLPT applies to you, ask your NCA. Don’t wait to be told - by the time you’re notified, the three-year clock is already ticking, and procuring a qualified TLPT provider takes months.
The Feedback Loop: Where Most Programmes Break Down
I’ve reviewed testing programmes where, over three years, the same critical vulnerability appeared in every annual pen test report. Same finding. Same severity. Same recommendation. Three years running.
That’s not a testing programme. That’s a documentation programme. You’re documenting the same risk repeatedly without actually managing it.
DORA requires the feedback loop to close:
Test → Conduct the test. Document findings with severity, affected systems, and potential impact.
Assess → Evaluate findings against your risk appetite. Prioritise remediation. Assign ownership. Set deadlines.
Remediate → Fix the issues. Not “create a ticket.” Actually fix them. With defined timelines: critical findings within days, high within weeks, medium within a quarter.
Verify → Confirm the fix works. Retest. Don’t just trust the developer who says “it’s fixed.” Run the test again.
Report → Feed the results back to the management body. What was tested? What was found? What was fixed? What wasn’t fixed yet and why? This is how the board stays informed and how the ICT risk management framework stays current.
A Realistic Annual Programme Structure
Here’s what a well-structured annual testing programme looks like for a mid-sized financial entity. Scale up or down based on proportionality:
Q1: Plan and baseline
Board approves the annual testing programme. Define scope, budget, schedule, and test providers. Conduct baseline vulnerability assessment across all critical systems. Review previous year’s findings - what was remediated, what wasn’t, what recurred.
Q2: Technical testing
Penetration testing of critical systems. Network security assessment. Open source software analysis. Performance testing if peak periods are approaching. Track findings, assign owners, set remediation deadlines.
Q3: Scenario and recovery testing
Scenario-based exercises (tabletop or simulation). Business continuity plan testing. Disaster recovery testing - actually fail over to backup systems and verify recovery works. This is the quarter where you test organisational resilience, not just technical controls.
Q4: Verify and report
Verification testing on remediated findings. Year-end vulnerability scan comparing against Q1 baseline. Compile annual testing report for the board. Identify improvements for next year’s programme.
Continuous: Vulnerability scanning
Quarterly at minimum, monthly for critical systems. Automated where possible. Results triaged and tracked continuously, not batched for quarterly review.
Testing Your Third Parties (Because Your Resilience Depends on Theirs)
Here’s something DORA requires that many firms haven’t grappled with yet: your testing programme should, where appropriate, include ICT third-party service providers. Article 30 requires contracts to include provisions for the financial entity (and its regulators) to conduct audits and testing of the provider.
In practice, this means:
- Requesting and reviewing your providers’ own testing reports (SOC 2 reports, pen test summaries, resilience testing results)
- Including critical providers in your scenario-based testing (“What happens if Provider X is unavailable?”)
- For your most critical providers, exercising audit rights to commission independent testing of the services they deliver to you
Large cloud providers will resist entity-specific testing requests. That’s where pooled auditing arrangements and industry-level TLPT exercises come in - mechanisms the ESAs are actively encouraging. But the minimum expectation is that you’re reviewing your critical providers’ testing posture, not just assuming they’re resilient because they’re big.
Board Governance: Why Your Management Body Needs to Care About Testing
DORA is explicit: the management body must approve the digital operational resilience testing programme. Not “be informed of.” Approve. That means someone has to present the programme to the board in terms they understand and get a formal sign-off.
This creates a healthy tension. Most boards don’t want to sit through a presentation about vulnerability scanning schedules. But DORA requires them to understand what’s being tested, why, and whether the results are acceptable. The board should be asking questions like:
- What were the most significant findings from last year’s testing programme?
- How many findings remain open beyond their target remediation date?
- Are there any critical systems that haven’t been tested in the last 12 months?
- Did we test our disaster recovery capability? Did the failover actually work?
- Does this year’s programme address the gaps identified in last year’s results?
If your board has never asked any of these questions, the presentation format needs to change. The testing programme report to the board should focus on risk outcomes, not technical details. Don’t show them CVE counts. Show them which critical business functions are exposed and what’s being done about it.
DORA also requires that the board allocate “adequate resources” for testing. If your testing budget hasn’t increased since DORA went live, and your testing scope has expanded to meet DORA’s requirements, someone is being asked to do more with less. That’s a board-level resource allocation decision, not a CISO problem to absorb silently.
Testing Is Only Useful If You Act on It
I’ll leave you with this thought: the purpose of a resilience testing programme is not to produce reports. It’s to find problems before they find you.
If your testing programme consistently produces clean results, one of two things is true: either your ICT environment is exceptionally well managed (possible but rare), or your tests aren’t hard enough (much more common). Good testing should make you uncomfortable. It should reveal things you didn’t know, challenge assumptions you’d rather not question, and force remediation you’d rather defer.
DORA understands this. That’s why it requires board oversight of the testing programme - because if the board isn’t seeing findings that require action, either the testing is insufficient or the reporting is filtered. Neither is acceptable. Build a programme that finds problems, report them honestly, fix them verifiably, and learn from them continuously. That’s operational resilience. Everything else is theater.
Structure Your Testing Programme Right
Venvera helps you plan, track, and report on your resilience testing programme - with finding remediation tracking, board reporting, and integration with your risk management framework. Across 13 frameworks, starting at €399/month.
Learn More →Last updated: March 2026. DORA testing requirements referenced from Regulation (EU) 2022/2554, Articles 24-27, and associated RTS.