Article 11: Response and recovery

To meet the article 11: response and recovery requirement, you must put a documented ICT business continuity policy in place as part of your ICT risk management framework, and base it on your identified critical ICT assets, processes, and dependencies. Operationalize it by assigning owners, defining response and recovery playbooks, testing them, and retaining evidence that the policy is live and followed. (Regulation (EU) 2022/2554, Article 11)

Key takeaways:

• Article 11 requires an ICT business continuity policy that is integrated into your broader business continuity approach. (Regulation (EU) 2022/2554, Article 11)
• Your policy must be built from what you identified under your ICT risk framework, especially critical functions and dependencies. (Regulation (EU) 2022/2554, Article 11)
• Examiners will look for operational proof: ownership, exercised procedures, and closed remediation, not a static document. (Regulation (EU) 2022/2554, Article 11)
• Treat third parties as first-class recovery dependencies and evidence that your recovery plans cover them in practice. (Regulation (EU) 2022/2554, Article 11)

Article 11 sits where supervisors expect maturity: the ability to keep operating through ICT disruption and restore services predictably. The legal text is short, but the expectation is operational. You need an ICT business continuity policy that belongs inside your ICT risk management framework, and it must reflect what you already know about your environment (critical systems, key services, single points of failure, and dependencies) from your identification work. (Regulation (EU) 2022/2554, Article 11)

For a CCO or GRC lead, the fastest path is to convert “policy” into a control-backed, testable set of commitments: who declares an ICT disruption, who runs incident response versus service restoration, what the recovery targets are for critical services, how third-party outages are handled, and how you prove all of that to a competent authority. The gap that causes supervisory pain is rarely a missing PDF. It’s unclear ownership across IT, security, operations, and third-party management, plus scattered evidence that no one can assemble under time pressure.

This page gives requirement-level implementation guidance you can execute immediately, with a focus on artifacts and exam-ready traceability.

Regulatory text

Text (excerpt): “As part of the ICT risk management framework referred to in Article 6(1) and based on the identification requirements set out in Article 8, financial entities shall put in place a comprehensive ICT business continuity policy … forming an integral part of the overall business continuity policy of the financial entity.” (Regulation (EU) 2022/2554, Article 11)

Operator interpretation (what you must do):

1. Create and approve an ICT business continuity policy (or a dedicated policy that is clearly part of enterprise business continuity). (Regulation (EU) 2022/2554, Article 11)
2. Anchor that policy in your ICT risk management framework so it is governed, maintained, and evidenced like other ICT risk controls. (Regulation (EU) 2022/2554, Article 11)
3. Base the policy on identified assets/processes/dependencies so recovery planning is scoped to what is truly critical, not generic. (Regulation (EU) 2022/2554, Article 11)

Plain-English requirement summary

You must be able to respond to ICT disruption and restore technology-enabled services in a controlled way, guided by a policy that matches your actual environment. If your identification work says “these systems and providers keep core services alive,” your response and recovery policy has to cover them with real procedures, ownership, and testing evidence. (Regulation (EU) 2022/2554, Article 11)

Who it applies to (entity and operational context)

Applies to: financial entities in scope of DORA that must operate an ICT risk management framework and identify ICT-related assets and dependencies. (Regulation (EU) 2022/2554, Article 11; Regulation (EU) 2022/2554)

Operational contexts where Article 11 becomes exam-critical:

• Customer-facing digital services (payments, trading, onboarding, claims) where outage impact is immediate.
• Core banking/ledger and data platforms where recovery sequencing and integrity checks matter.
• Security operations and incident response where containment actions can conflict with availability goals.
• Third-party delivered ICT (cloud, managed security, SaaS) where your recovery depends on contractual and technical realities.

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

Use this workflow to get from requirement to “audit-ready operation.”

1) Set scope from your identification outputs

• Pull your Article 8-aligned inventory outputs: critical business services, supporting applications/infrastructure, key data stores, and third-party dependencies. (Regulation (EU) 2022/2554, Article 11)
• Create a service-to-system dependency map for the services that would drive the highest operational impact if disrupted. Keep it simple: service → systems → third parties → internal teams.

Deliverable: “ICT continuity scope register” tied to identified critical services and dependencies. (Regulation (EU) 2022/2554, Article 11)

2) Draft the ICT business continuity policy with enforceable statements

Your policy should read like commitments you can test. Include:

• Governance: policy owner, approving authority, review triggers tied to material ICT change. (Regulation (EU) 2022/2554, Article 11)
• Roles and decision rights: who declares an ICT crisis, who leads incident response, who leads service restoration, and who communicates to customers/regulators (even if the detailed notification duties sit elsewhere).
• Minimum operational capabilities: backup/restore expectations, recovery procedures coverage, resilience requirements for critical services, and third-party continuity expectations.

Tip: Avoid purely aspirational verbs (“seek to,” “where possible”). Examiners treat them as non-commitments.

Deliverable: Approved ICT business continuity policy embedded in your broader business continuity policy set. (Regulation (EU) 2022/2554, Article 11)

3) Convert policy into playbooks and runbooks

Policy is the “what.” Supervisors will ask for the “how.”

• Incident response playbook: triage, containment, escalation, evidence handling, and handoff to restoration.
• Service recovery playbook: restore priorities, sequencing, data integrity checks, fallback procedures, and acceptance criteria to return to normal operations.
• Third-party outage playbook: how you detect third-party issues, engage the provider, switch to alternates, and document decisions.

Deliverables: Playbooks mapped to critical services and the dependency map created earlier. (Regulation (EU) 2022/2554, Article 11)

4) Assign accountable owners and escalation paths

Common failure mode: continuity “belongs to everyone,” so it belongs to no one.

• Assign a single accountable owner for the ICT business continuity policy (often within ICT risk, resilience, or security governance).
• Assign service owners for each critical service and technical owners for each critical system.
• Document the escalation tree and on-call expectations so execution does not depend on tribal knowledge.

Deliverables: RACI matrix, on-call/escalation documentation, and committee reporting line into the ICT risk management framework. (Regulation (EU) 2022/2554, Article 11)

5) Exercise the capability and track remediation to closure

You need proof that the policy is operational.

• Run readiness drills that test decision-making, communications, and restoration steps.
• Capture gaps as corrective actions with owners, due dates, and validation steps.
• Require evidence of fix effectiveness, not just “completed” status.

Deliverables: Exercise plans, exercise results, after-action reports, remediation tracker, and validation evidence. (Regulation (EU) 2022/2554, Article 11)

6) Build an examiner-ready evidence package (single-click retrieval)

A common exam hangup is evidence scattered across tooling: ticketing, SOC platform, BCP repository, and third-party management.

• Create a single register that maps:
  • Requirement → policy section → playbook/runbook → owner → evidence location.
• If you use Daydream, treat this as a control-and-evidence register you can keep current as systems and third parties change, so you are not rebuilding an evidence narrative during an exam.

Deliverable: Requirement-to-control-to-evidence mapping register aligned to Article 11. (Regulation (EU) 2022/2554, Article 11)

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Governance and scope

• ICT business continuity policy (approved, versioned, review history). (Regulation (EU) 2022/2554, Article 11)
• Scope register tied to identified critical ICT assets/services/dependencies. (Regulation (EU) 2022/2554, Article 11)
• RACI and escalation matrix.

Operational procedures

• Incident response and recovery playbooks/runbooks for in-scope services and systems.
• Dependency maps, including third parties and internal shared services.

Testing and improvement

• Drill/exercise plans, attendance, scenarios, outputs.
• After-action reports and remediation tracker with closure evidence. (Regulation (EU) 2022/2554, Article 11)

Third-party continuity

• Contractual continuity expectations where available (SLAs, support escalation, outage communication, recovery support).
• Evidence you tested assumptions about third-party recovery in exercises (even tabletop).

Common exam/audit questions and hangups

Expect questions like:

• “Show me how your ICT business continuity policy is part of the ICT risk management framework.” (Regulation (EU) 2022/2554, Article 11)
  Hangup: policy exists, but governance is unclear (no owner, no risk committee reporting, no linkage to ICT risk register).
• “How did you determine what systems and third parties are in scope for recovery?” (Regulation (EU) 2022/2554, Article 11)
  Hangup: scope is based on org chart or legacy BCP lists, not on identification outputs.
• “Prove you tested response and recovery and fixed what you found.” (Regulation (EU) 2022/2554, Article 11)
  Hangup: tabletop notes exist, but no tracked corrective actions or validation evidence.

Frequent implementation mistakes (and how to avoid them)

1. Policy written by one team, executed by another.
   Fix: require joint sign-off from ICT risk + security operations + IT operations + business continuity, with named owners per playbook.

2. Recovery plans assume third parties will behave a certain way.
   Fix: document third-party assumptions explicitly (contact paths, restoration dependencies) and test those assumptions in drills.

3. Evidence is not retrievable under pressure.
   Fix: maintain a living Article 11 evidence index with pointers to the current policy, latest tests, and remediation closure proof.

4. No linkage to identification work.
   Fix: include a section in the policy that states the source-of-truth inventories and how scope updates occur after material change. (Regulation (EU) 2022/2554, Article 11)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite case outcomes. The practical supervisory risk is still predictable: inability to demonstrate that continuity planning is rooted in identified critical dependencies, plus weak evidence of testing and remediation. That combination turns a “policy requirement” into a control effectiveness finding during reviews. (Regulation (EU) 2022/2554, Article 11)

Practical 30/60/90-day execution plan

Exact time-to-implement varies by complexity, but this sequence works even in mature environments because it forces evidence readiness.

First 30 days (stabilize and make it auditable)

• Confirm scope using existing identification outputs (critical services, systems, third parties). (Regulation (EU) 2022/2554, Article 11)
• Assign an accountable policy owner and publish a RACI for response and recovery.
• Draft or refresh the ICT business continuity policy and route it for approval with explicit linkage to the enterprise BCP. (Regulation (EU) 2022/2554, Article 11)
• Start the Article 11 mapping register: requirement → controls → owners → evidence locations.

Days 31–60 (make it operational)

• Produce playbooks/runbooks for the highest-impact services first.
• Validate third-party contact and escalation paths; record gaps as remediation items.
• Run a drill that tests escalation, decision rights, and a basic restoration sequence; capture after-action findings.
• Stand up the remediation tracker with validation requirements for closure.

Days 61–90 (prove reliability and close gaps)

• Run a second exercise that includes a third-party outage or dependency failure scenario.
• Close priority findings and attach validation evidence (screenshots, tickets, change records, approvals).
• Package your examiner evidence set (policy, scope, tests, remediation, mapping register) so it can be produced quickly.

Frequently Asked Questions

Do we need a separate ICT business continuity policy, or can it be part of our enterprise business continuity policy?

Article 11 allows a dedicated ICT policy or an ICT-specific policy that forms an integral part of the overall business continuity policy. The key is clear ICT scope, governance, and operational procedures that can be tested and evidenced. (Regulation (EU) 2022/2554, Article 11)

How do we prove our policy is “based on identification requirements” in practice?

Show traceability from identified critical services/systems/dependencies into continuity scope and recovery playbooks. Keep a scope register that references the inventories and maps each critical service to its recovery procedures. (Regulation (EU) 2022/2554, Article 11)

What do auditors typically reject as insufficient evidence for Article 11?

A policy with no owners, no testing records, or no remediation closure evidence is usually treated as paper compliance. Auditors also flag scope that is not tied to identified dependencies and criticality. (Regulation (EU) 2022/2554, Article 11)

How should third parties be handled under response and recovery?

Treat third parties as dependencies that must appear in your continuity scope, playbooks, and exercises. Retain evidence of escalation paths, service restoration assumptions, and how you would operate during provider disruption. (Regulation (EU) 2022/2554, Article 11)

We already have incident response. What’s new here?

Incident response often focuses on containment and investigation; Article 11 pushes you to also evidence service recovery and continuity as part of ICT risk governance. Align the two with clear handoffs and shared exercises, then retain the artifacts. (Regulation (EU) 2022/2554, Article 11)

What’s the fastest way to become exam-ready without rewriting everything?

Build a requirement-to-evidence mapping register, identify the top gaps (scope traceability, ownership, testing, remediation), and fix those first. Tools like Daydream help keep the mapping and evidence pointers current as systems and third parties change. (Regulation (EU) 2022/2554, Article 11)