DORA Resilience Testing: Requirements and TLPT Explained
DORA mandates regular testing of ICT systems to validate that financial entities can withstand disruptions. Testing requirements range from basic vulnerability assessments for all entities to advanced threat-led penetration testing (TLPT) for systemically important institutions.
Testing is not optional under DORA. It serves as the validation mechanism for your entire ICT risk management framework, proving that your controls actually work under realistic conditions.
Key Takeaways
| Point | Summary |
|---|---|
| All entities tested | Every in-scope entity must conduct regular testing appropriate to their risk profile |
| Annual testing program | Non-microenterprises need annual testing covering critical systems |
| TLPT for significant entities | Systemically important institutions must undergo threat-led penetration testing every 3 years |
| Third-party inclusion | ICT providers supporting critical functions must participate in testing |
| Independent testing | Certain tests must be performed by independent parties |
Quick Answer: DORA requires all financial entities to test their ICT systems regularly, with testing sophistication scaled to entity size and systemic importance. Basic requirements include vulnerability assessments, network security tests, and gap analyses. Larger entities must implement comprehensive annual testing programs. The most significant institutions must undergo threat-led penetration testing (TLPT), a controlled red team exercise against live production systems, at least every three years.
Testing Requirements Overview
DORA establishes tiered testing requirements based on entity characteristics:
| Entity Type | Testing Requirements |
|---|---|
| All in-scope entities | Appropriate testing based on risk profile |
| Non-microenterprises | Annual testing program covering critical systems |
| Significant/systemically important | Threat-led penetration testing (TLPT) at least every 3 years |
Proportionality in Testing
Testing requirements scale with:
- Entity size and complexity
- Nature and criticality of services
- ICT risk profile
- Potential impact on financial stability
A small fintech will have different testing obligations than a systemically important bank, but both must test appropriately.
Basic Testing Requirements
All in-scope entities must conduct testing appropriate to their risk profile.
Types of Basic Tests
| Test Type | Description |
|---|---|
| Vulnerability assessments | Systematic identification of security weaknesses in systems and applications |
| Network security assessments | Evaluation of network architecture, configurations, and controls |
| Gap analyses | Comparison of current state against requirements and best practices |
| Physical security reviews | Assessment of data center and facility security |
| Software security testing | Source code reviews, application security testing |
| Scenario-based testing | Simulation of specific incident scenarios |
| Compatibility testing | Verification that systems work together correctly |
| Performance testing | Assessment of system behavior under load |
Testing Frequency
While DORA does not prescribe specific frequencies for all test types, testing should be:
- Regular and risk-appropriate
- Triggered by significant changes
- Updated based on emerging threats
- Documented and tracked
Annual Testing Program
Non-microenterprises must establish and maintain a comprehensive annual testing program.
Program Requirements
| Element | Description |
|---|---|
| Scope | All critical ICT systems and applications |
| Coverage | Range of test types based on risk assessment |
| Independence | Testing by parties without conflict of interest |
| Documentation | Test plans, results, and remediation tracking |
| Reporting | Management reporting on testing results |
Risk-Based Approach
The testing program should prioritize:
- Systems supporting critical or important functions
- Internet-facing systems
- Systems processing sensitive data
- Recently changed systems
- Systems with known vulnerabilities
Testing Methodology
Tests should follow recognized standards and methodologies:
- Industry-standard vulnerability scanning tools
- Recognized penetration testing frameworks
- Documented test procedures
- Consistent reporting formats
Threat-Led Penetration Testing (TLPT)
TLPT represents the most advanced form of testing under DORA, required for systemically important financial entities.
What Is TLPT?
TLPT is defined in DORA Article 3(17) as:
"A framework that mimics the tactics, techniques and procedures of real life threat actors perceived as posing a genuine cyber threat, that delivers a controlled, bespoke, intelligence-led (red team) test of the financial entity's critical live production systems."
Key Characteristics
| Characteristic | Description |
|---|---|
| Intelligence-led | Based on current threat intelligence specific to the entity |
| Red team execution | Adversary simulation by skilled offensive testers |
| Live production | Testing against actual production systems, not test environments |
| Full scope | Covers the entire organization, not just specific systems |
| Defenders unaware | Blue team (defenders) not informed during testing |
| Controlled | Managed with appropriate safeguards |
TLPT vs. Traditional Penetration Testing
| Aspect | Traditional Pentest | TLPT |
|---|---|---|
| Scope | Specific systems or applications | Entire organization |
| Approach | Vulnerability identification | Adversary simulation |
| Intelligence | Generic threat assumptions | Bespoke threat intelligence |
| Duration | Days to weeks | Months |
| Defenders | May be informed | Not informed (stealth) |
| Objective | Find vulnerabilities | Test resilience end-to-end |
Who Must Undergo TLPT?
Competent authorities designate financial entities for TLPT based on:
- Systemic importance
- Impact on financial stability
- ICT risk profile
- Maturity of cyber defenses
- Criticality of services provided
Criteria include:
- Significant credit institutions under ECB supervision (as defined in Article 6(4) of Regulation (EU) No 1024/2013)
- Central counterparties and central securities depositories
- Large payment institutions
- Critical infrastructure operators
TLPT Frequency
Designated entities must undergo TLPT at least every 3 years. Competent authorities may adjust this frequency based on:
- Risk profile changes
- Significant incidents
- Testing results
- Organizational changes
TLPT Scope
TLPT must cover:
- Critical or important functions
- Live production systems supporting those functions
- ICT services provided by third parties (with their participation)
- Relevant organizational processes and people
Testing Teams
TLPT involves multiple teams:
| Team | Role |
|---|---|
| Control team | Internal team managing the test, ensures safety |
| Threat intelligence provider | Delivers bespoke threat intelligence |
| Red team | Executes the adversary simulation |
| Blue team | Defenders (unaware during testing) |
Internal vs. External Testers
DORA allows internal testers but with conditions:
- Internal testing is allowed for 2 of every 3 TLPTs
- External testers must be used every third TLPT
- Threat intelligence must always come from external providers
- Significant credit institutions must always use external red teams
- Internal testers must meet independence requirements
Purple Teaming
DORA mandates a purple teaming phase after TLPT completion:
- Red team shares findings with blue team
- Joint analysis of attack paths and defenses
- Knowledge transfer to improve future defenses
- Training opportunity for defenders
TLPT Results and Remediation
Following TLPT:
| Activity | Description |
|---|---|
| Report submission | Summary report to competent authority |
| Remediation planning | Plan to address identified vulnerabilities |
| Attestation | Competent authority confirms TLPT completion |
| Follow-up | Supervisory review of remediation progress |
Third-Party ICT Provider Testing
When critical or important functions are supported by ICT third-party providers:
Provider Participation
- Providers must participate in testing, including TLPT
- Contractual arrangements must require testing cooperation
- Pooled testing may be used where individual testing is impractical
- Testing results must be available to the financial entity
Contractual Requirements
Ensure contracts with ICT providers include:
- Testing cooperation obligations
- Access for testing activities
- Participation in TLPT where applicable
- Remediation commitments
Testing Documentation and Reporting
Documentation Requirements
All testing must be documented:
- Test plans and scope
- Methodologies used
- Findings and severity ratings
- Recommendations
- Remediation plans
- Status tracking
Management Reporting
Test results should be reported to:
- ICT risk management function
- Senior management
- Management body (for significant findings)
- Audit committee
Regulatory Reporting
For TLPT:
- Summary reports submitted to competent authority
- Remediation plans shared upon request
- Attestation of completion obtained
Common Questions
How do I know if my company needs TLPT under DORA?
Your competent authority will notify you if you are designated for TLPT. Designation criteria include systemic importance, risk profile, and potential impact on financial stability. If you believe you may be designated, engage proactively with your supervisor.
Can we use the same testers for consecutive tests?
DORA does not prohibit using the same testing firm, but you should rotate testers to ensure fresh perspectives. For TLPT, external testers must be used every third test.
What qualifications must testers have?
Testers must have appropriate professional qualifications and experience. For TLPT, testers should meet criteria established in the RTS, including technical competence, independence, and professional indemnity insurance.
How do we coordinate TLPT with ICT providers?
Contractual arrangements should require provider participation in TLPT. Coordinate timing and scope with providers in advance through the control team. Ensure non-disclosure agreements protect sensitive findings.
What happens if testing reveals critical vulnerabilities?
Critical vulnerabilities discovered during testing must be remediated according to risk-based priorities. Document the findings, develop a remediation plan, track progress, and verify remediation effectiveness through retesting.
How Bastion Helps
Bastion supports financial entities in meeting DORA testing requirements:
- Testing program design: Development of comprehensive annual testing programs
- Vulnerability assessments: Coordination and oversight of vulnerability scanning
- Penetration testing: Management of penetration testing engagements
- TLPT preparation: Readiness assessment and preparation for threat-led testing
- Remediation support: Guidance on addressing identified vulnerabilities
- Testing governance: Establishment of testing policies and procedures
Ready to strengthen your resilience testing capabilities? Talk to our team
Sources
- DORA Articles 24-27 - Digital operational resilience testing requirements
- ESA RTS on TLPT - Technical standards for threat-led penetration testing
- TIBER-EU Framework - ECB framework that influenced DORA TLPT requirements