Article 24: General requirements for the performance of digital operational resilience testing

Article 24 requires you to establish, operate, and periodically review a digital operational resilience testing programme that sits inside your ICT risk management framework, so you can prove preparedness for ICT incidents and drive timely corrective action. Build a risk-based testing plan, execute tests, track remediation to closure, and retain evidence that links test results to fixes. (Regulation (EU) 2022/2554, Article 24)

Key takeaways:

• You need a documented, risk-based testing programme that is part of ICT risk management, not an ad hoc set of technical tests. (Regulation (EU) 2022/2554, Article 24)
• Testing must produce actionable findings and verified remediation, with traceable evidence from test to fix. (Regulation (EU) 2022/2554, Article 24)
• Governance matters: defined ownership, review cadence, and audit-ready artifacts are as examinable as the tests themselves. (Regulation (EU) 2022/2554, Article 24)

A common failure mode under DORA is treating “testing” as a security team activity (penetration tests, vulnerability scans, DR exercises) with no single programme view, no risk-based rationale, and no clean line of sight from a finding to a verified corrective measure. Article 24 closes that gap: you must run a sound and comprehensive digital operational resilience testing programme, integrated into your ICT risk management framework, to assess preparedness for ICT-related incidents, identify weaknesses, and promptly implement corrective measures. (Regulation (EU) 2022/2554, Article 24)

For a Compliance Officer, CCO, or GRC lead, operationalizing Article 24 means building a governance-and-evidence wrapper around technical testing. You are orchestrating scope, prioritization, accountability, and proof. Examiners will look for consistency over time: a programme that is maintained and reviewed, tests that are selected based on risk, and remediation that is tracked and validated.

This page gives you requirement-level implementation guidance: who must comply, what to build, how to run it, what artifacts to retain, and where teams typically get stuck during internal audit and supervisory reviews.

Requirement: article 24: general requirements for the performance of digital operational resilience testing requirement

Operator intent: Stand up a single, governed testing programme that continuously measures ICT resilience and forces remediation discipline across systems, processes, and third parties in scope.

Plain-English interpretation

Article 24 expects you to:

1. Have a testing programme (not a pile of independent tests).
2. Embed it in ICT risk management so test selection, frequency, and depth reflect your risk profile.
3. Use it to prove preparedness for ICT-related incidents.
4. Identify gaps and drive corrective measures quickly, with follow-through evidence. (Regulation (EU) 2022/2554, Article 24)

Think of this as “test-to-fix” governance: plan tests based on risk, run them, document results, remediate, and verify remediation.

Who it applies to (entity + operational context)

In-scope entities

• Financial entities other than microenterprises must establish, maintain, and review the programme. (Regulation (EU) 2022/2554, Article 24)

In-scope operations

Your programme should cover ICT services and processes that materially affect:

• incident detection/response capability,
• continuity of critical business services,
• dependencies on third parties that support ICT services (for example, cloud, managed security providers, core banking platforms, payment processors).

Article 24 ties programme design to your risk profile (“taking into account the criteria set out in Article 4(2)”), so scope and intensity should align to what would cause business disruption or regulatory impact if it failed. (Regulation (EU) 2022/2554, Article 24)

Regulatory text

DORA requires that, to assess preparedness for handling ICT-related incidents, identify weaknesses/deficiencies/gaps in digital operational resilience, and promptly implement corrective measures, financial entities (other than microenterprises) must establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk-management framework, taking into account relevant risk criteria. (Regulation (EU) 2022/2554, Article 24)

What the operator must do from this text:

• “Establish” = define programme scope, governance, testing types, methodology, and ownership.
• “Maintain” = execute the plan, update it when your environment changes, and keep evidence current.
• “Review” = periodically re-evaluate whether testing still matches risk and whether remediation is effective.
• “Promptly implement corrective measures” = treat findings as control failures requiring tracked remediation and validation, not optional improvements. (Regulation (EU) 2022/2554, Article 24)

What you actually need to do (step-by-step)

1) Create a single testing programme charter (governance first)

Build a short charter that answers:

• Accountable owner: named function (often CISO/Head of ICT Risk) with Compliance oversight.
• Approval: who signs the annual plan and material changes.
• Scope: systems, environments, and third parties included.
• Testing universe: list categories you run (for example, vulnerability management outputs, incident response exercises, backup/restore tests, DR tests, access control testing, configuration compliance testing, penetration tests).
• Risk-based prioritization method: how you decide what gets tested and how often.
• Remediation governance: severity definitions, target closure expectations (qualitative), escalation path, and validation rules.

Practical control: keep this charter mapped into your ICT risk management framework documentation so Article 24 reads as “already embedded,” not bolted on. (Regulation (EU) 2022/2554, Article 24)

2) Build and maintain a risk-based testing plan

Create an annual (or rolling) plan that includes:

• Asset/service mapping: critical services → supporting applications/infrastructure → third parties.
• Risk drivers: changes, incident learnings, known control weaknesses, major third-party changes.
• Test catalogue selection: which tests apply to each service layer.
• Schedule + owners: test name, scope, owner, planned window, required approvals.

Keep the plan explainable: an examiner should understand why a given service gets deeper testing than another based on operational impact.

3) Standardize execution with test runbooks

For each test type, define:

• Preconditions (environment, access, data handling)
• Method (tools or manual steps)
• Success criteria and what “failure” means
• Evidence to capture (screenshots, logs, tickets, test reports)
• Required participants (security, IT ops, business owners, third-party contacts)
• Reporting template (findings, root cause hypothesis, affected assets, recommended corrective measures)

4) Run tests and produce decision-grade reporting

Your report pack should support management decisions:

• Finding statement: what failed and where.
• Impact framing: which service/process is exposed.
• Root cause: process gap, misconfiguration, missing control, third-party deficiency.
• Corrective measure: specific change, owner, and verification method.
• Residual risk: what remains until fixed (qualitative).

5) Drive remediation to closure with validation evidence

This is where many programmes fail. Put findings into a single workflow:

• ticketing system record,
• owner acceptance,
• target closure expectation (qualitative),
• evidence of fix (change record, configuration state, policy update),
• validation test confirming the weakness no longer exists.

If you use Daydream, treat it as the control plane for Article 24: map Article 24 to your testing controls, assign owners, and attach evidence artifacts to each testing cycle so you can answer supervisory questions without assembling binders by hand. (Regulation (EU) 2022/2554, Article 24)

6) Review and refresh the programme

Programme review should trigger when:

• you onboard or materially change a critical third party,
• you introduce major architecture changes,
• you experience a significant incident,
• audits identify recurring issues.

The output is a revised plan and documented rationale for changes, plus evidence that overdue remediation is escalated and resolved. (Regulation (EU) 2022/2554, Article 24)

Required evidence and artifacts to retain (audit-ready)

Keep artifacts in a single register (even if evidence lives in multiple tools). Minimum set:

• Testing programme charter (scope, governance, methodology, ownership) (Regulation (EU) 2022/2554, Article 24)
• Risk-based testing plan with mapping to critical services and ICT assets (Regulation (EU) 2022/2554, Article 24)
• Test runbooks/procedures per test type
• Completed test reports ¹
• Findings log with severity, owner, status, and approvals
• Remediation records (change tickets, configuration diffs, third-party communications)
• Validation evidence (re-test results, control testing outcomes)
• Programme review minutes and management sign-off evidence (Regulation (EU) 2022/2554, Article 24)

Common exam/audit questions and hangups

Expect these questions, and pre-build the answer pack:

1. Show me your testing programme. Where is it documented and who owns it? (Regulation (EU) 2022/2554, Article 24)
2. How did you decide what to test? Demonstrate risk-based rationale tied to critical services. (Regulation (EU) 2022/2554, Article 24)
3. Prove remediation is prompt and effective. Show test finding → corrective measure → validation evidence chain. (Regulation (EU) 2022/2554, Article 24)
4. How do third parties fit? Show tests or assurance activities that cover outsourced ICT dependencies.
5. How do you review and improve the programme? Provide review records and updates after incidents or major changes. (Regulation (EU) 2022/2554, Article 24)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails under Article 24	How to fix it
Testing is scattered across teams with no programme owner	You can’t show a “sound and comprehensive” programme	Assign a single accountable owner; create one programme charter and register. (Regulation (EU) 2022/2554, Article 24)
Results live in PDFs with no remediation workflow	“Promptly implement corrective measures” becomes unprovable	Require every finding to become a tracked item with closure and validation evidence. (Regulation (EU) 2022/2554, Article 24)
Plan is calendar-driven, not risk-driven	Examiners ask “why this test, why now?”	Tie selection to critical services, changes, incidents, and third-party dependencies. (Regulation (EU) 2022/2554, Article 24)
Retests are informal	You can’t prove the weakness is gone	Define validation methods per finding and capture re-test artifacts.
Third parties are ignored	Outages often originate outside your perimeter	Include third-party dependencies in scope mapping and testing/assurance activities.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 24, so you should assume supervisory review will focus on demonstrable operation and evidence quality, not policy statements. The practical risk is avoidable findings: “programme exists” but no traceability, or remediation is late and unverified. (Regulation (EU) 2022/2554, Article 24)

Practical execution plan (30/60/90)

A timed plan would imply calendar-day commitments without a cited basis, so use phases you can start immediately and measure by deliverables.

Immediate (foundation)

• Name the programme owner, define RACI across ICT risk, security ops, IT ops, business continuity, and third-party management.
• Draft the testing programme charter and align it to your ICT risk management framework. (Regulation (EU) 2022/2554, Article 24)
• Build a single evidence register: where each artifact lives and who maintains it.

Near-term (operate)

• Create the risk-based testing plan mapped to critical services and major third parties.
• Standardize runbooks and reporting templates for your main test types.
• Start execution on the highest-risk areas and open remediation items with owners and validation steps. (Regulation (EU) 2022/2554, Article 24)

Ongoing (prove and improve)

• Run periodic programme reviews; update scope after incidents and major changes.
• Trend recurring findings and require root-cause fixes (process/control improvements, not repeated patches).
• Use Daydream to keep requirement-to-control-to-evidence traceability current so supervisory requests become a structured export, not a scramble. (Regulation (EU) 2022/2554, Article 24)

Frequently Asked Questions

Does Article 24 require specific testing types (pen tests, DR tests, etc.)?

Article 24 sets a general requirement to establish, maintain, and review a testing programme and to implement corrective measures; it does not, in the provided excerpt, enumerate specific test types. Your plan should be risk-based and integrated into ICT risk management. (Regulation (EU) 2022/2554, Article 24)

We already run security testing. What changes for compliance?

You need programme governance and evidence: a single documented programme, risk-based selection, and a provable remediation-and-validation workflow from finding to corrective measure. That is usually the gap between “security activity” and “Article 24 compliance.” (Regulation (EU) 2022/2554, Article 24)

How do we show “promptly implement corrective measures” without a regulatory timeline?

Define internal remediation expectations by severity and document escalation rules, then show consistent adherence through tickets, change records, and re-test evidence. Examiners typically accept your internal standards if they are risk-based and followed. (Regulation (EU) 2022/2554, Article 24)

Are third parties in scope for the testing programme?

Article 24 focuses on your preparedness and resilience; in practice, that includes outsourced ICT dependencies that can disrupt your services. Include third-party supported services in scope mapping and capture assurance/testing evidence relevant to those dependencies. (Regulation (EU) 2022/2554, Article 24)

What is the minimum evidence set we should be able to produce on request?

Produce the programme charter, the current testing plan with risk rationale, recent test reports, the findings log, and a sample of closed items showing corrective action and validation. That package answers most initial supervisory probes. (Regulation (EU) 2022/2554, Article 24)

How do we keep this from becoming a yearly paperwork exercise?

Tie programme updates to operational triggers (major changes, incidents, onboarding critical third parties) and require every test to end with a remediation decision and validation step. A living register in a system like Daydream helps keep evidence current across teams. (Regulation (EU) 2022/2554, Article 24)

Footnotes

1. Regulation (EU) 2022/2554, Article 24