DORA testing checklist: how to prepare and stay compliant

How to use this checklist

Every item below carries the article it comes from, because that is the level at which a supervisory conversation happens. Work through the stages in order: scope decides what the programme covers, the programme decides what gets tested, and everything after that is execution and proof. The underlying obligations are set out in our guide to DORA testing requirements; this page is the operational version.

Stage 1 — Scope

• Map your critical or important functions and the ICT systems and applications that support them. This mapping is what the yearly testing obligation in Article 24(6) attaches to, so an error here propagates through everything else.
• Record the risk-based rationale behind the scope: the Article 4(2) criteria, the evolving ICT risk landscape, the specific risks you face and the criticality of information assets and services — the four inputs Article 24(3) names.
• Identify the ICT third-party providers inside those functions. Their systems can fall within testing scope even though they are not yours.
• Check whether you are in one of the special cases: microenterprise (outside Article 24, with Article 25(3) instead), Article 16(1) simplified framework, or a CSD or CCP with the additional Article 25(2) duty.

Stage 2 — Write the programme

• Document a digital operational resilience testing programme as an integral part of your ICT risk-management framework, and give it a review cycle — Article 24(1) requires it to be established, maintained and reviewed.
• Include a genuine range of assessments, tests, methodologies, practices and tools, as Article 24(2) requires. One test type repeated annually does not satisfy it.
• Choose your mix from the twelve types enumerated in Article 25(1) and write down why. The two most often missed are physical security reviews and compatibility testing.
• Set frequencies per system, with the Article 24(6) yearly floor for anything supporting critical or important functions.

Stage 3 — Execute

• Run the tests on schedule and keep the scope, methodology, dates, tooling and findings for each one. An undated report proves nothing.
• Cover the whole path, not only the components: Article 25(1) names scenario-based tests and end-to-end testing precisely because failure usually appears between systems.
• If you are a central securities depository or a central counterparty, run a vulnerability assessment before any deployment or redeployment of applications, infrastructure components and ICT services supporting critical or important functions (Article 25(2)) — that trigger is event-driven and easy to miss in a release pipeline.
• Keep continuous vulnerability assessment running underneath the annual cycle. Exploitation of internet-facing weakness moves faster than a yearly calendar.

Stage 4 — Independence

• Confirm that tests are undertaken by independent parties, whether internal or external (Article 24(4)). DORA does not require an external firm for the baseline programme.
• If you use internal testers, document the resources dedicated to them and how conflicts of interest are avoided throughout the design and execution phases — scoping and success criteria included, not just fieldwork.
• Keep the independence assessment as a document. "We used a third party" is not an answer to Article 24(4); it is one possible way of satisfying it.

Stage 5 — Remediate and validate

1. Prioritise and classify every issue revealed by the tests, under the procedures and policies Article 24(5) requires you to establish.
2. Fix, with an owner and a date, and record what changed.
3. Validate with an internal validation methodology — a defined method for ascertaining that each weakness, deficiency or gap is fully addressed. This is the specific wording of Article 24(5), and it means a retest, not a status change.
4. Report to the management body and feed the results back into the ICT risk-management framework and next year’s programme.

Stage 6 — TLPT, if you are identified

• Wait to be identified rather than self-declaring: Article 26(8) puts that decision with your competent authority.
• If identified, plan on the three-year cycle in Article 26(1) and expect the scoping assessment to be validated by the authority (Article 26(2)).
• Budget for the statutory clocks in Commission Delegated Regulation (EU) 2025/1190 — including management body approval of the scope specification and at least twelve weeks of active red team testing.
• Where a shared ICT third-party provider is in scope and single-entity testing would harm other customers, use pooled testing under Article 26(4).
• Keep the attestation, the summary of findings and the remediation plans (Article 26(6) and (7)) — the attestation is what makes the test recognisable across competent authorities.

The evidence a supervisor will ask for

A test that happened but cannot be evidenced counts for very little. This is the mapping between what you do at each stage and what you should be able to produce on request.

Common gaps

These are the failures that show up repeatedly, and none of them is a matter of effort — each is a specific requirement that the programme silently skipped.

• Components tested, the path never tested. Individual systems get their scan and their pen test, but the end-to-end resilience path Article 25(1) names — detect, decide, respond, recover — is never exercised as a whole.
• No internal validation methodology. Findings are marked resolved without a defined method for proving they no longer reproduce, so remediation is asserted rather than demonstrated. Article 24(5) asks for the method, not the status field.
• "We use an external firm" as the independence answer. Article 24(4) asks about independence and conflicts of interest across design and execution. An external firm scoped entirely by the team that owns the system has not answered it.
• Article 25(2) forgotten in the release pipeline. CSDs and CCPs owe a vulnerability assessment before any deployment or redeployment; a quarterly scan cycle does not satisfy an event-driven trigger.
• Third parties left outside scope. ICT third-party providers can fall within TLPT scope under Article 26(3), with pooled testing under Article 26(4) as the release valve when direct testing would affect their other customers.

That last gap is the one the data argues hardest for. In the Verizon 2026 DBIR, breaches with third-party involvement rose 60% year on year to 48% of all breaches, and ransomware was present in 48%. A testing scope drawn at your own network boundary now excludes nearly half of the way in.

A realistic first year

If you are starting from nothing, do not attempt everything at once. Get the scope mapping and the programme document written first, because they are what the rest hangs off. Then run the cheap breadth items from Article 25(1) — vulnerability assessments and scans, open source analyses, questionnaires — while you schedule the deeper work. Add scenario-based and end-to-end testing on the highest-criticality functions before you spread it wider, and build the validation methodology at the same time as the first remediation cycle rather than after it. A programme that is narrow, documented and evidenced beats a broad one nobody can prove happened.