Prepare a DORA testing record that separates the general from advanced threat-led penetration testing.
This page helps ground annual critical-function testing, eligibility checks, authority validation points, provider selection, closure evidence, remediation plans, and attestation records.
DORA has applied since 17 January 2025, and testing readiness starts with a split record. One track covers the required for financial entities other than microenterprises. A narrower track covers only for financial entities identified for advanced testing by the relevant authority. Keep the two tracks separate so vulnerability scans, business-continuity tests, penetration tests, and TLPT are not treated as interchangeable evidence.
DORA requires financial entities other than microenterprises to establish, maintain, and review a as part of the ICT risk management framework. Financial entities must use the programme to assess preparedness for ICT-related incidents, identify weaknesses, deficiencies, and gaps, and promptly implement corrective measures.
Microenterprises do not have the Article 24 programme duty, but Article 25(3) still requires them to perform appropriate ICT tests using a risk-based approach and strategic planning that balances resources, urgency, risk, and the criticality of information assets and services.
Financial entities must conduct the testing programme using a risk-based approach that reflects the entity's ICT risk profile, critical information assets, criticality of services, and the evolving ICT risk landscape. DORA lists examples of appropriate tests, including vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.
DORA and Delegated Regulation 2025/1190 are binding. The readiness inventories and evidence packs below are practical implementation records; they do not replace an authority's identification decision, scope validation, or attestation.
Sources (1)
Supports DORA Articles 24 and 25 on the digital operational resilience testing programme, listed test types, independent testing, remediation, and annual testing for ICT systems supporting critical or important functions.
digital operational resilience testing programme
is not a label for every penetration test. DORA reserves advanced testing by means of threat-led penetration testing for financial entities identified under Article 26 and the TLPT regulatory technical standard. Microenterprises and the financial entities covered by Article 16(1) are outside this TLPT requirement. For other entities, the authority assessment considers impact, systemic character, financial-stability concerns, ICT risk profile, ICT maturity, technology features, critical services, interconnectedness, substitutability, and dependence on ICT systems and third-party or intra-group ICT services.
For readiness, keep a eligibility file even before a formal authority notification. It should explain whether the entity falls into a category that may be assessed for TLPT, which could be in scope, which live production systems support those functions, and which outsourced or contracted ICT services would need provider participation.
Sources (2)
Supports DORA Article 26 on TLPT frequency, live production systems, critical or important functions, ICT third-party participation, authority validation, and external-tester requirements.
advanced testing by means of TLPT
Specifies criteria used by TLPT authorities to identify financial entities required to perform TLPT and defines TLPT authority, TCT, test managers, control team, blue team, red team, threat intelligence provider, leg-ups, flags, pooled TLPT, and joint TLPT concepts.
Identification of financial entities required to perform TLPT
DORA testing evidence should lead to corrective action. For the general testing programme, keep procedures for prioritising, classifying, remedying, and validating issues found during tests. For , the evidence set is more structured because the closure phase produces red team, blue team, summary, remediation, and attestation records.
The remediation plan should be usable by accountable technology, security, resilience, and risk owners. For each finding, it must describe the shortcoming, proposed remediation measures, prioritisation and expected completion, root cause analysis, responsible staff or functions, and risks associated with not implementing and, where relevant, implementing the measures.
Sources (2)
Supports the requirement to prioritise, classify, remedy, and validate issues revealed through resilience testing and to provide TLPT findings, remediation plans, and compliance documentation to the authority.
remedy all issues revealed
Supports the required contents of red team reports, blue team reports, TLPT summary reports, remediation plans, and attestations.
high level plan for remediation
Use this checklist to prepare evidence for a supervisor, auditor, or management body. Start with the entity's testing duties, the 's identification and notification, and the RTS process records.
The strongest readiness file shows the difference between routine resilience testing, penetration testing, and authority-supervised , then connects every finding to ownership, remediation, and validation.
No. applies only to financial entities identified for advanced testing using impact, systemic, financial-stability, ICT-risk, ICT-maturity, and technology criteria; Article 16 entities and microenterprises are excluded. Financial entities other than microenterprises must maintain the broader . Microenterprises instead follow Article 25(3)'s proportionate, risk-based ICT testing rule.
For entities identified for , DORA sets an at-least-every-3-years TLPT frequency, but the competent authority may require a shorter or longer frequency based on the entity's risk profile and operational circumstances. Do not apply that cadence to entities that have not been identified for TLPT.
For ordinary testing, keep the programme, scope, test results, weakness classification, remediation actions, and validation. For , also keep authority-validated scope, provider evidence, targeted threat intelligence report, red team test plan, red and blue team reports, summary findings, remediation plan, and attestation.
Sources (2)
Supports the distinction between the general testing programme and advanced TLPT, including the yearly critical-function testing requirement and the TLPT frequency rule for identified entities.
at least every 3 years
Supports the TLPT process evidence expected across preparation, threat intelligence, red team testing, closure, remediation, attestation, and authority cooperation.
remediation plans and the documentation
Sorena can help connect DORA testing obligations, TLPT authority interactions, provider evidence, closure reports, remediation plans, and attestation records to the cited sources on this page.
Ask official source questions about DORA testing, TLPT eligibility, authority validation, remediation evidence, and attestation records using the cited sources on this page.
Walk through your DORA testing programme, TLPT eligibility file, provider evidence, authority interaction points, and remediation plan structure with Sorena.
"threat-led penetration testing"
"Identification of financial entities required to perform TLPT"
"the TLPT authority shall approve"
"high level plan for remediation"
"remediation plans and the documentation"
"Digital operational resilience testing"
"digital operational resilience testing programme"
"advanced testing by means of TLPT"
"remedy all issues revealed"
"at least every 3 years"
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider oversight milestones.
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
Official source DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
Official source guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
Official source DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
Official source DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
Map DORA register fields to official templates for ICT contracts, provider chains, critical functions, dates, statuses, reporting, and evidence.
Compare binding DORA ICT third-party risk duties with the EBA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
Test DORA applicability against official sources for financial-entity scope, ICT services, critical or important functions, exclusions, proportionality, and evidence.
Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.
Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
Official source guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
An official source overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
DORA proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.