Checklist: testing evidence under DORA

• A digital operational resilience testing programme is established, maintained and reviewed as an integral part of the ICT risk management framework.Reference: Art. 24(1), Art. 6
• The programme includes a range of assessments, tests, methodologies, practices and tools under Art. 25 and, where required, Art. 26.Reference: Art. 24(2)
• It follows a risk-based approach that considers the ICT risk landscape, specific risks to the entity and the criticality of information assets and services.Reference: Art. 24(3)
• The ICT systems and applications supporting critical or important functions are identified.Reference: Art. 8(1), Art. 24(6)
• Each of these systems is appropriately tested at least yearly.Reference: Art. 24(6)

• Tests are carried out by independent parties, internal or external.Reference: Art. 24(4)
• For internal testers, sufficient resources are provided and conflicts of interest are avoided throughout design and execution.Reference: Art. 24(4)

• For each critical system it is decided and justified which test types are appropriate.Reference: Art. 25(1)
• Example: vulnerability assessments and scansReference: Art. 25(1)
• Example: open source analysesReference: Art. 25(1)
• Example: network security assessmentsReference: Art. 25(1)
• Example: gap analysesReference: Art. 25(1)
• Example: physical security reviewsReference: Art. 25(1)
• Example: questionnaires and scanning software solutionsReference: Art. 25(1)
• Example: source code reviews where feasibleReference: Art. 25(1)
• Example: scenario-based testsReference: Art. 25(1)
• Example: compatibility testingReference: Art. 25(1)
• Example: performance testingReference: Art. 25(1)
• Example: end-to-end testingReference: Art. 25(1)
• Example: penetration testingReference: Art. 25(1)
• Central securities depositories and central counterparties only: vulnerability assessments before any deployment or redeployment of applications, infrastructure or ICT services supporting critical or important functions.Reference: Art. 25(2)

• Policies and procedures exist to prioritise, classify and remedy all issues revealed by testing.Reference: Art. 24(5)
• Internal validation methodologies ensure that every weakness, deficiency or gap is fully addressed.Reference: Art. 24(5)
• Test plan, test reports, list of findings with status, retests and approvals are filed and retrievable for internal audit and supervisors.Reference: Recommendation, based on Art. 24(1) and (5)

Threat-led penetration testing (TLPT) only applies to financial entities identified by the competent authority. Details are set out in Delegated Regulation (EU) 2025/1190. These items have their own counter.

0 of 8 TLPT items done

• Clarified whether the supervisor has identified your entity for TLPT.Reference: Art. 26(8)
• TLPT at least every three years, on live production systems, covering several or all critical or important functions. The authority may reduce or increase the frequency.Reference: Art. 26(1) and (2)
• Scope assessed and validated by the authority; ICT third-party service providers in scope are involved.Reference: Art. 26(2) and (3)
• Risk management controls for the test against impact on data, assets and critical or important functions.Reference: Art. 26(5)
• Testers meet the requirements: highest suitability and reputation, expertise in threat intelligence, penetration testing and red teaming, certification or code of conduct, independent assurance or audit report, professional indemnity insurance.Reference: Art. 27(1)
• Internal testers only with the authority's approval, after it has checked resources and conflicts of interest; the threat intelligence provider is external to the entity.Reference: Art. 27(2)
• With internal testers, every third test is external; significant credit institutions use external testers only.Reference: Art. 26(8)
• After the test, summary, remediation plans and evidence submitted to the authority, attestation received.Reference: Art. 26(6) and (7)