DORA Resilience Checklist for Testing (2026 Guide)

Digital Operational Resilience Act (DORA) testing is often misunderstood as a single annual exercise. In practice, supervisors typically expect a repeatable testing program that is risk-based, evidenced, and governed, with clear links to your critical or important functions, ICT assets, and ICT third-party service providers (ICT TPPs). This dora resilience checklist is designed for compliance officers, CISOs, and ICT risk managers who need a defensible way to plan, execute, and evidence testing across the year. If you need a foundation on scope and terminology first, start with what is digital resilience, then use this checklist to pressure-test your current approach against DORA’s operational expectations.

Contents

What this checklist covers (and what it does not)

1) Set the foundations for DORA testing

2) Build the scope and inventory you will test against

3) Create a risk-based testing plan (not a calendar ritual)

4) Execute tests with governance, evidence, and traceability

5) Manage findings, remediation, and retesting

6) Address ICT third-party and supply-chain testing expectations

7) Prepare management and supervisory-ready outputs

DORA testing minimums, proportionality, and TLPT triggers (what supervisors may look for)

Evidence mapping: how to tie tests to DORA Articles, RTS/ITS expectations, and your audit trail

Where testing connects to major ICT-related incident reporting under DORA

How Dorapp supports evidence-driven DORA programs

Strengths and Challenges

Frequently Asked Questions

Key Takeaways

Conclusion

What this checklist covers (and what it does not)

This checklist focuses on how to operationalize DORA-aligned digital operational resilience testing in a way that stands up to audit and supervisory review. It is structured around the practical problem most financial entities face: testing outputs are often scattered across ticketing tools, penetration test reports, vendor emails, BCM evidence folders, and spreadsheets, while DORA expects coherence across governance, risk, third-party oversight, and continuous improvement.

It does not replace your internal control framework, your detailed security testing methodology, or any threat-led penetration testing (TLPT) program design decisions. TLPT has specific constraints and expectations under DORA and related RTS; this checklist helps you ensure the surrounding governance and evidence chain is complete.

For deeper context on the types of testing and expected program structure, see digital operational resilience testing and dora digital resilience testing. If your stakeholders still need clarity on the regulation itself, align on definitions using digital operational resilience act and what is digital operational resilience act.

1) Set the foundations for DORA testing

A DORA testing program is usually easiest to defend when it is anchored to governance decisions and a documented risk-based rationale. Supervisors may look for clarity on “why these tests,” “why this depth,” and “how you ensured coverage of what matters.”

Checklist: governance and policy prerequisites

Define testing objectives that map to operational resilience outcomes, not only vulnerability discovery (for example: ability to maintain critical services under stress, detection capability, recovery capability, and third-party resilience assurance).

Document roles and accountability across security testing, ICT risk, BCM, and compliance, including who signs off on test scope and who accepts residual risk.

Set decision rules for when testing results trigger: risk register updates, incident watch activities, supplier reassessment, control redesign, or management escalation.

Define evidence standards for each test type (inputs, execution proof, outputs, remediation, retest) and retention expectations aligned to your internal policies.

Clarify independence expectations for higher-assurance tests (for example, separation between system owners and testers) where proportionate.

Practical considerations

If you cannot explain how testing decisions relate to critical or important functions, you will likely struggle to defend coverage and prioritization.

Board and senior management oversight is often less about technical detail and more about consistent governance signals: coverage, critical findings, overdue remediation, and systemic issues.

Make sure your testing vocabulary is consistent across teams; “test,” “exercise,” “simulation,” and “assessment” often mean different things to different stakeholders.

2) Build the scope and inventory you will test against

Most testing programs fail defensibility because the scope is implicit. DORA pushes financial entities toward demonstrable understanding of dependencies, including ICT TPP reliance, and how that reliance affects operational resilience.

Checklist: minimum scoping artifacts to link testing to

List of critical or important functions and the ICT services that support them.

System and application inventory for in-scope services, including ownership and environment boundaries (production, DR, critical shared services).

Dependency mapping to ICT TPPs that deliver or support the service chain, including material subcontracting where relevant.

Known “crown jewels” data and processes (for example: payment processing flows, trading connectivity, policy administration, customer authentication services).

Testing constraints register (what cannot be tested and why), including compensating controls or alternate assurance activities.

Practical considerations

Testing scope should be able to evolve across the year; your evidence should show how scope changes were controlled and approved.

If you cannot consistently link tests back to services and providers, your remediation prioritization may look arbitrary.

For group structures, be explicit about which legal entity is responsible for testing and which shared services are tested centrally.

3) Create a risk-based testing plan (not a calendar ritual)

A credible testing plan is typically a portfolio: different test types, different frequencies, and different depth based on the operational importance of the service and the risk profile. Supervisors may expect you to show that you prioritized testing where impact is highest, and that you did not rely on a single control activity to “cover everything.”

Checklist: build the annual testing portfolio

Define test types you will use (for example: vulnerability scanning, configuration reviews, control testing, incident response exercises, backup restore tests, recovery tests, red teaming or TLPT where applicable).

Set risk-based frequency rules (for example: critical services quarterly, moderate semiannually, low annually), while documenting exceptions.

Define entry criteria for higher-assurance testing (for example: major architecture change, new critical provider onboarding, recurring incidents, or concentration risk flags).

Include both preventive and detective control validation; resilience depends on both.

Design a retesting rule set (for example: all high-severity findings must be retested after remediation, with evidence attached).

Practical considerations

Testing plans that are not linked to remediation capacity often become “report factories” with unresolved findings.

Make it explicit how you treat “inherited controls” from shared service providers or group functions; inherited does not mean untested.

If you use external testing providers, document how you validate their scope, competence, and independence for the test type.

4) Execute tests with governance, evidence, and traceability

Execution quality is not only about the test itself. For DORA defensibility, you typically need evidence that tests were authorized, that scope was controlled, that results were reviewed, and that actions were tracked to closure.

Checklist: execution controls that improve audit readiness

Formal test authorization (who approved, what was approved, and when), including scope and environment boundaries.

Pre-test risk controls (change windows, rollback plans, stakeholder comms) for disruptive tests.

Evidence package for each test: Test plan and scope statement Execution proof (logs, artifacts, screenshots, tool outputs where appropriate) Result classification (severity and impact to services) Review and sign-off evidence Linkage to remediation actions and due dates

Controlled exceptions process (for example: deferrals, accepted risks, scope reductions) with documented rationale and approvals.

Consistent taxonomy for findings so trends can be analyzed across tests and across providers.

Practical considerations

Many institutions have strong testing but weak review gates. A missing approval trail can undermine credibility even if the test work was solid.

Evidence should be structured for reuse in audits, internal assurance, and management reporting, not only stored as a PDF in a shared folder.

Ensure your incident management function can consume testing outcomes that indicate active exploitation or control failure patterns.

5) Manage findings, remediation, and retesting

DORA-oriented supervision tends to focus on continuous improvement. That makes remediation discipline and retesting evidence particularly important for demonstrating “resilience outcomes,” not only activity completion.

Checklist: findings lifecycle and closure criteria

Classify findings consistently (severity, likelihood, impacted services, and affected providers where relevant).

Define ownership for each finding (service owner, control owner, provider manager) and set due dates based on risk appetite and operational constraints.

Track remediation actions (corrective and preventive) and link them back to the original finding and test evidence.

Require validation or retesting before closure for high-impact issues.

Perform trend analysis (recurrence, systemic control weakness, concentration by provider or technology stack) and escalate systemic patterns.

Practical considerations

If overdue findings are common, add governance: escalation rules, management reporting, and explicit decisions to accept or defer risk.

Make sure closure is not “ticket closed” but “risk reduced and validated,” with evidence.

Use recurring findings as triggers for deeper testing (including supplier reassessment and architecture reviews).

6) Address ICT third-party and supply-chain testing expectations

DORA places explicit emphasis on ICT third-party risk management. While DORA does not require you to “penetration test your provider” in every case, you will typically need a defensible assurance approach, proportionate to the service criticality and provider dependency chain.

Checklist: third-party testing and assurance

Identify which ICT TPPs support critical or important functions and map the dependency chain (including subcontractors where relevant and available).

Define assurance mechanisms for each provider type (for example: audit reports, control attestations, right-to-audit outcomes, security testing evidence, resilience test evidence, incident history).

Ensure contract and governance pathways allow you to obtain evidence, track remediation, and escalate issues.

Include concentration risk considerations in your testing focus (single provider dependencies, systemic SaaS reliance, shared infrastructure).

Integrate third-party assurance findings into internal remediation and risk decisions, not as a standalone vendor file.

Practical considerations

Provider assurance is often fragmented between procurement, IT, and security. You need a single governance story.

Be realistic about what evidence you can obtain from large providers; define compensating controls where direct testing is not feasible.

Supply-chain visibility is an ongoing program, not a one-time due diligence questionnaire.

7) Prepare management and supervisory-ready outputs

Management bodies and competent authorities rarely want raw test artifacts. They typically want evidence that the testing program covers critical services, produces actionable results, and drives measurable remediation within agreed timelines.

Checklist: reporting outputs that tend to be requested

Coverage view: which critical or important functions and supporting services were tested, and how (including rationales for gaps).

Top findings and systemic themes: recurring control weaknesses, technology stack hotspots, provider concentration issues.

Remediation discipline metrics: overdue high-severity actions, time-to-fix by severity band, retest completion rate.

Exception register: accepted risks, deferred remediation, scope exceptions, with approval trail.

Linkage evidence: how testing outcomes updated risk records, third-party assessments, and operational resilience decisions.

If stakeholders still debate baseline resilience concepts, align terminology using what is digital resilience to reduce misinterpretation between “security testing” and “operational resilience testing.”

DORA testing minimums, proportionality, and TLPT triggers (what supervisors may look for)

Here’s the thing: DORA testing expectations are not only about running more tests. What the regulation actually requires is that your digital operational resilience testing program is risk-based, proportionate, and capable of demonstrating that ICT systems and controls can support continuity of critical or important functions under stress. These expectations sit under Chapter IV of Regulation (EU) 2022/2554, and they are further shaped by Regulatory Technical Standards and Implementing Technical Standards developed by the European Supervisory Authorities (EBA, ESMA, and EIOPA) through the Joint Committee.

DORA has applied since 17 January 2025. In supervisory reviews, the question is often whether your approach can be justified end-to-end: your scoping rationale, test selection, evidence standards, and how testing outcomes drive remediation and risk decisions.

Checklist: “minimum defensibility” signals supervisors may expect

A documented testing policy or program standard that describes how you select test types, define frequency, and decide depth for critical services.

Evidence that you cover both technical security validation and operational resilience validation (for example: recovery, backup restore, and crisis or incident response exercises) for critical or important functions.

Clear governance for independence and competence of testers where higher assurance is needed (for example: penetration testing and red-team style exercises).

Consistent treatment of ICT third-party dependencies in scope decisions, including how provider constraints are managed and how compensating assurance is obtained.

Board or management body visibility into testing outcomes for critical services, including overdue remediation and material risk acceptance decisions.

How TLPT typically fits into a DORA resilience checklist

Threat-Led Penetration Testing is a distinct requirement for certain financial entities, typically those designated as significant under the DORA framework and subject to competent authority expectations. TLPT is not “just a pen test,” it is intelligence-led, scenario-driven, and designed to test detection and response capabilities against realistic threat actors, often with strict controls on scope, execution, and oversight.

Whether TLPT applies to you, and the exact execution requirements, could depend on the applicable RTS and supervisory interpretation. Even when TLPT is not mandatory for your institution, supervisors may still question whether your testing portfolio is sufficiently challenging for your highest-risk service chains.

Regulatory note

This content is for informational purposes only and does not constitute legal advice. Your TLPT applicability, testing frequency, and governance expectations may vary based on your entity type, risk profile, and competent authority guidance. Consult qualified legal or regulatory counsel for institution-specific guidance under Regulation (EU) 2022/2554 and applicable RTS/ITS.

Evidence mapping: how to tie tests to DORA Articles, RTS/ITS expectations, and your audit trail

What many compliance teams overlook is that “testing evidence” is not a single artifact. Under DORA, evidence is the traceability chain that lets you demonstrate, under challenge, that tests were planned and executed as part of a controlled program, and that outcomes were acted on. In most institutions, audit issues arise because evidence exists, but it is not mapped to DORA obligations, not linked to critical services, or not presented in a reviewable structure.

From a practical standpoint, your evidence model should be designed so you can answer three supervisory questions quickly: what did you test, why was that sufficient for the risk, and what changed as a result.

Checklist: a practical evidence map to maintain

Obligation mapping: a simple matrix linking your testing program components to Chapter IV of DORA, and where relevant to Chapter II (ICT Risk Management) and Chapter V (ICT third-party risk), because testing evidence is often reviewed alongside governance and third-party oversight.

Service linkage: for every test, a reference to the critical or important function and the service chain impacted, including supporting applications, infrastructure, and key ICT TPP dependencies.

Control objective linkage: a statement of what capability you were validating (for example: detection, containment, recovery time objectives, backup integrity, access control effectiveness), not only which tool was used.

Review trail: who reviewed results, what decisions were made (remediate, accept, defer), and who approved exceptions. If decisions are made in committees, retain minutes or decision records as part of the evidence package.

Remediation traceability: links from the test finding to remediation tasks, verification steps, and retest results, with dates and responsible owners.

Third-party traceability: where provider evidence is used, track what was requested, what was received, gaps or limitations, and compensating assurance (for example: additional internal controls or alternate testing).

How this helps in a supervisory review

You can demonstrate that testing is not an isolated security activity, but part of the ICT Risk Management Framework under DORA.

You can show continuous improvement, which is often the real focus: repeated weaknesses, systemic issues, and how management decisions reduced risk over time.

You can answer “why not tested” questions with a controlled constraints register and approved exceptions, rather than informal explanations.

Regulatory note

This content is for informational purposes only and does not constitute legal advice. Evidence expectations can vary by competent authority, entity type, and supervisory focus, and may be influenced by RTS/ITS specifications and ESA guidance. Consult qualified legal or regulatory counsel for institution-specific advice.

Where testing connects to major ICT-related incident reporting under DORA

DORA treats resilience testing and ICT-related incident management as connected capabilities. Under Chapter III of DORA, financial entities must have processes to manage, classify, and report major ICT-related incidents, and may voluntarily notify significant cyber threats. Testing is one of the most credible ways to prove that your detection, response, and recovery capabilities are not only documented, but exercised and improved.

Consider this: if your incident reporting playbooks assume certain telemetry, escalation paths, or recovery steps, your testing program is where those assumptions should be challenged. If you cannot evidence that critical incident workflows have been tested against realistic scenarios, you can end up with a gap between “policy compliance” and “operational readiness,” which supervisors may probe after an incident.

Checklist: align testing outcomes with incident reporting readiness

Scenario coverage: include test scenarios that reflect plausible disruptions to critical or important functions (for example: identity compromise, ransomware affecting service chains, cloud region outage, corrupted backups, third-party operational outage).

Classification readiness: validate that incident classification criteria and thresholds can be applied quickly in practice, including who makes the classification decision and how it is evidenced.

Reporting workflow rehearsal: test that your internal notification and escalation chain can produce accurate, timely information for competent authority reporting, subject to the applicable ITS templates and timelines.

Third-party coordination: test communication and evidence exchange with ICT TPPs for incidents affecting shared service delivery, including what data you can realistically obtain within early reporting windows.

Post-incident improvement loop: ensure incident learnings feed back into testing scope adjustments and control redesign, and that this linkage is visible in governance reporting.

Practical considerations

Testing that reveals “near miss” conditions (for example: detection gaps, incomplete asset ownership, unclear on-call accountability) should be treated as operational resilience signal, not only as security hygiene.

If incident reporting depends on data that lives with third parties, document that dependency and your compensating approach. Supervisors may focus on the realism of your plan.

Regulatory note

This content is for informational purposes only and does not constitute legal advice. Major incident classification, reporting timelines, and content requirements may depend on the final ITS and competent authority processes applicable to your institution. Consult qualified legal or regulatory counsel for institution-specific guidance under Regulation (EU) 2022/2554 and ESA standards.

How Dorapp supports evidence-driven DORA programs

Dorapp is a DORA-focused compliance platform designed to help financial entities run controlled, auditable workflows rather than relying on email and spreadsheets. Based on currently available platform documentation, Dorapp is modular and includes DORApp ROI (Register of Information) and DORApp TPRM (Third-Party Risk Management and Questionnaire Automation). Additional modules are on the roadmap, including DORApp IM (Incident Management and Reporting), DORApp RMG (ICT Risk Management and Governance), and DORApp IIS (Information and Intelligence Sharing). Dorapp also describes an Execution Governance Engine with configurable review gates and sign-off, plus an Audit Trail for workflow and record changes.

For testing programs, the practical value is typically in traceability: linking what you tested, what you found, who approved decisions, and how third-party dependencies affected scope and remediation. If you are building a program that must be repeatable and supervisor-ready, it can be worth evaluating whether a DORA-dedicated workflow layer reduces evidence gaps and rework versus spreadsheet-based coordination.

To explore Dorapp directly, you can review the DORApp Modules, see DORApp Functions, or book a demo to walk through how Dorapp structures DORA evidence and approvals in practice.

Strengths and Challenges

Strengths

Workflow governance and sign-off discipline: Dorapp documentation describes configurable review gates and single- or multi-user sign-off, which can improve defensibility for testing approvals, exceptions, and closure decisions.

Audit trail and traceability: A comprehensive audit trail of record changes, workflow transitions, and approvals can support audit and supervisory evidence needs when testing artifacts are questioned.

Modular approach aligned to DORA pillars: ROI and TPRM are available, with additional modules planned, which may fit institutions that want phased adoption rather than a single “big bang.”

Third-party oversight orientation: The TPRM module is described as more than questionnaires, including risk scoring, monitoring, and reporting connected to oversight and governance expectations.

Implementation Considerations

Roadmap dependencies: Several modules referenced in documentation (IM, RMG, IIS) are planned releases, so you should validate availability and timelines for your testing-related use cases before committing to a program design.

Testing evidence still needs technical sources: A workflow and evidence layer does not replace security testing tools, engineering remediation capability, or BCM recovery testing execution. Integration and operating model design still matters.

Governance overhead can increase if overcontrolled: Review gates and maker-checker controls can improve defensibility, but if applied too broadly they may slow remediation or create bottlenecks. Proportionate configuration is important.

Frequently Asked Questions

What does DORA require for digital operational resilience testing?

DORA expects financial entities to run a risk-based testing program that validates ICT resilience and security controls across critical or important functions and supporting ICT assets. In most cases, this means multiple test types across the year, not a single annual exercise. Specific supervisory expectations can depend on your entity type, size, and risk profile, and relevant RTS may shape how certain testing activities are evidenced and governed.

How is TLPT different from standard penetration testing under DORA?

Threat-led penetration testing (TLPT) is typically more scenario-driven and intelligence-led than standard penetration testing, and it is commonly treated as a higher-assurance activity. Whether TLPT applies to your financial entity depends on the supervisory designation and applicable RTS. Even if TLPT does not apply, you still need a coherent testing portfolio, evidence of governance, and closure discipline for findings.

What evidence should we retain from resilience tests?

Evidence usually needs to cover authorization, scope, execution artifacts, findings classification, review and approvals, remediation actions, and retesting results. The goal is to show traceability from test intent to outcome and improvement. Evidence retention and detail should be proportionate, but for critical services you typically need enough granularity to support audit challenge and demonstrate management oversight decisions.

How do we link testing to critical or important functions?

Most institutions start by mapping critical or important functions to the ICT services, applications, and infrastructure that enable them, then linking tests to those service chains. The testing plan can then show coverage by function, including gaps and exceptions with rationale. Where third-party services support the chain, your assurance approach should be integrated into the same coverage view rather than stored separately.

What are common weaknesses supervisors may identify in testing programs?

Common issues include unclear scope, weak linkage to critical services, lack of approval trail, findings that do not convert into tracked remediation, and inconsistent retesting before closure. Another recurring issue is fragmented third-party assurance that is not integrated into the institution’s risk decisions. Supervisory focus may evolve as the European Supervisory Authorities (EBA, ESMA, and EIOPA) publish further guidance.

How should third-party testing be handled under DORA?

You typically need a proportionate assurance approach for ICT third-party service providers, especially where they support critical or important functions. That may include contractual assurance, control reports, resilience evidence, and structured follow-up on weaknesses. The feasibility of direct testing can vary, particularly with large cloud or SaaS providers, so institutions often combine multiple assurance mechanisms and document compensating controls.

How often should we test under a “DORA resilience checklist” approach?

Frequency is usually risk-based. Critical services and high-risk technology stacks often warrant more frequent testing and more rigorous retesting of high-severity findings. Lower-risk services may follow lighter cycles. What matters is that you can justify the frequency, show that it is reviewed, and demonstrate that testing results drive remediation and governance decisions rather than being “check-the-box” outputs.

How can a platform help with DORA testing compliance if tests are executed in other tools?

Even when tests are executed in specialized tools, financial entities still need governance, evidence management, sign-off, exception handling, and reporting that ties results back to services and providers. A DORA-oriented platform can help centralize those workflows and create consistent audit trails. It should be evaluated on its ability to enforce review gates, maintain traceability, and support management reporting without overstating automation.

Is Dorapp a replacement for our existing GRC or security testing stack?

Not necessarily. Based on available documentation, Dorapp is positioned as a DORA-focused platform with modules for Register of Information and third-party risk management, and with an execution governance approach for controlled workflows and evidence. Many financial entities will still keep their existing GRC, security testing, and ticketing systems. The practical question is whether Dorapp can reduce DORA-specific fragmentation and evidence gaps.

What are the “5 pillars” of DORA, and where does testing sit?

DORA is commonly explained through five areas: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information and intelligence sharing arrangements. Testing sits alongside governance, incident management, and third-party oversight, and supervisors often assess whether these areas reinforce each other rather than operating as separate workstreams.

Is vulnerability scanning alone enough to satisfy DORA testing expectations?

Typically not. Vulnerability scanning is useful for identifying known weaknesses, but DORA’s testing expectations are broader and risk-based. Most institutions need a portfolio that includes at least some combination of technical testing (for example: penetration testing or configuration review) and operational resilience exercises (for example: backup restore and recovery testing, incident response exercises), proportionate to the criticality of the service.

How do we decide whether we are “significant” for TLPT purposes under DORA?

Whether TLPT applies can depend on the criteria and designation processes applied by competent authorities and the relevant RTS. In practice, you typically need to engage your compliance, risk, and regulatory affairs functions to determine your status, confirm supervisory expectations, and document your rationale. This content is for informational purposes only and does not constitute legal advice. Consult qualified legal or regulatory counsel for institution-specific guidance.

Does DORA require annual testing of critical systems?

DORA establishes a programmatic testing expectation under Chapter IV rather than a single uniform frequency for every system. Supervisors commonly expect regular testing for critical services, and many institutions operate at least annual cycles for key control validations, with more frequent testing for higher-risk areas. Your defensible position is the documented rationale for frequency and depth, plus evidence that it is reviewed and updated.

Key Takeaways

A defensible DORA testing program is usually a portfolio of test types tied to critical or important functions, not a single annual test.

Scope clarity and traceability (services, assets, providers, approvals) are often the difference between “testing happened” and “testing is governed.”

Findings management matters as much as test execution: remediation, retesting, and exception approvals must be evidenced.

Third-party assurance should be integrated into the same coverage and reporting model as internal testing.

DORA-dedicated workflow governance and audit trail capabilities may reduce evidence gaps, but they do not replace technical testing tools or engineering remediation capacity.

Conclusion

A practical digital operational resilience checklist is less about enumerating test types and more about proving governance: what you tested, why you tested it, what you found, who approved decisions, and how you improved resilience outcomes across services and ICT third parties. If your current evidence is split across tools and teams, that fragmentation can become the real compliance risk during audit or supervisory review.

If you want to assess whether a DORA-focused workflow layer could help your institution structure testing evidence and approvals more consistently, review the DORApp Functions and DORApp Modules, or book a demo to discuss your testing governance and documentation approach with the Dorapp team.

Disclaimer: This article is intended for informational purposes only and does not constitute legal advice. DORA compliance obligations vary depending on the classification and size of your financial institution. Consult qualified legal or regulatory counsel to assess your specific obligations under the Digital Operational Resilience Act and applicable regulatory technical standards.