Article 11 DORA response and recovery: evidence

What DORA Article 11 response and recovery asks financial entities to prove

A supervisor or auditor who asks how your organization keeps critical or important functions running during an ICT disruption is asking for proof, not a description. Article 11 of DORA requires a comprehensive ICT business continuity policy, ICT response and recovery plans, a business impact analysis of exposure to severe disruption, testing at least yearly that includes cyber-attack scenarios and switchovers between primary infrastructure and redundant capacity, backups and facilities, a crisis management function for entities other than microenterprises, and readily accessible records of activities before and during disruption events. Each of these needs a document, an owner, and evidence that it works.

The difficulty is that many entities hold plans that look complete but have never been exercised against the scenario Article 11 names most directly: a failover from primary systems to redundant capacity under stress. A plan that says a service fails over in a stated time has little value until someone has measured the switchover, checked that the secondary environment holds current data, and confirmed that the people on the crisis team know their roles. Ask your team to produce the last switchover test report for each critical function, the scenario it covered, the findings, and the date each finding was closed. If that record does not exist, the gap is the first thing to fix.

Confirm with your competent authority and your independent auditor how they expect the business impact analysis, the test scope and the records to be presented, because supervisory practice on evidence format varies. Article 11 also ties into the technical detail in Delegated Regulation (EU) 2024/1774, whose articles on continuity policy, testing and response and recovery plans set out the components you should be able to show. Read the DORA text on EUR-Lex alongside your own plans before the next supervisory request arrives.

Which systems, teams and providers fall inside Article 11 scope

Article 11 reaches further than a disaster recovery plan for one data center. The scope is set by which critical or important functions the entity runs, which ICT systems keep those functions alive, and which third parties sit in the chain. Each decision below changes who must test, what must be tested and what evidence an assessor will ask to see.

Critical or important functions as the anchor

Article 11 plans are built around the functions that matter most to the entity, so the first step is a documented list of critical or important functions and the business services behind them. Each function needs a recovery objective and a named owner. Check that the list matches the outcome of the business impact analysis and the register of information, because a function left off the list is a function that will not be tested. Ask who signed off the list and when it was last reviewed.

ICT systems that support each function

Once functions are listed, trace each one to the ICT systems, data stores, network paths and identity services it depends on. A payments function may rely on a core ledger, an API gateway, a database cluster, a directory service and a messaging queue, and a switchover test that ignores any one of them proves little. Map these dependencies before choosing test scenarios, and record which dependencies are shared across functions.

Redundant capacity and facilities in scope

Scope must cover the redundant ICT infrastructure, backups and alternate facilities that take over when primary infrastructure fails, not only the primary environment. Article 11 testing expects switchovers between primary infrastructure and redundant capacity, so secondary sites, standby clusters and restore environments belong inside the boundary. Confirm which of these are owned by the entity, which are operated by a provider and whether each one has been exercised recently.

Teams and decision makers in the crisis function

Scope also covers people. The crisis management function, the staff who activate plans, the escalation chain and the communications owner all need defined roles that work during a disruption. Records of activities before and during an event must be kept readily accessible, which means the people responsible for keeping them must be named. Check that deputies exist for each role and that staff outside the core IT team know when to escalate.

Microenterprises and the proportionate regime

Article 11 applies the crisis management function, the full set of testing scenarios and the audit review of recovery plans to entities other than microenterprises. A microenterprise must still have a continuity policy, response and recovery plans and yearly testing, but it can scale down the depth of those obligations. Before deciding how much to build, confirm the entity's classification with its competent authority and document the reasoning, since the scope of work differs materially between the two groups.

ICT third-party providers in continuity scenarios

Providers enter the scope when a critical or important function relies on a cloud service, managed host, SaaS platform or outsourced operator. Article 11 testing must consider the failure or insolvency of an ICT third-party provider, so each provider needs a documented contingency path and an agreed way to exercise it. Ask providers for their own continuity test results and exit assistance terms, and identify where the entity cannot test the provider directly.

How the continuity policy, response plan and recovery plan differ

The ICT business continuity policy is the top-level document. It sets the entity's rules for keeping critical or important functions running during disruption, and it states how the entity intends to respond to incidents, activate containment, estimate preliminary impacts and losses, and handle crisis communication. Article 11 allows it to be a dedicated policy or part of a wider framework, so the choice is an organizational decision, not a regulatory one. Delegated Regulation (EU) 2024/1774 Article 24 sets out the components the policy must cover. The management body approves it, and the ICT risk function and business continuity owners maintain it.

Scope: which critical or important functions and ICT services the policy governs.
Objectives and principles: the continuity goals the entity commits to, linked to its risk tolerance.
Roles and escalation: who declares a disruption and who decides on activation.
Interfaces: how the policy connects to incident management, backup and communication.
Review: how often the policy is reviewed and what triggers an early update.

Check that the policy names an accountable owner and a board-level approver, and that every critical function in the business impact analysis maps to a policy clause.

How a supervisor or auditor tests Article 11

This table lists what a supervisor or independent auditor typically does for each part of Article 11, the evidence they ask for and where organizations most often fall short. Read each row as a checklist of what to prepare before an assessment, and confirm the exact expectations with your competent authority.

Area	Assessor action	Evidence requested	Common finding
Business continuity policy	Read the policy and trace each element to named arrangements covering critical or important functions, incident response, containment, impact estimation and crisis communication	Approved policy, version history, management body approval record, mapping to critical functions	Policy is generic and not linked to the entity's critical or important functions
Business impact analysis	Check that severe disruption scenarios were quantified and qualified, and that recovery priorities follow from the results	BIA workbook, scenario definitions, impact criteria, sign-off and review dates	Impact criteria are undocumented or scenarios do not reflect current ICT dependencies
Response and recovery plans	Confirm plans exist for each critical function, were subject to independent internal audit review, and name owners and steps	Plans, internal audit review reports, owner list, dependency diagrams	No independent internal audit review on record, or plans are out of date with current systems
Yearly testing	Verify that tests ran at least yearly and after substantive changes to systems supporting critical or important functions	Test calendar, test plans, dated results, change records linked to triggered tests	Tests are tabletop only, or post-change tests are missing
Cyber-attack scenarios in testing	Check that test scenarios include cyber-attack cases and that results drive remediation	Scenario scripts, participant logs, findings register with owners and closure evidence	Scenarios repeat earlier exercises without a cyber-attack element or findings stay open
Switchover testing	Observe or review a switch from primary ICT infrastructure to redundant capacity, backups and facilities, and compare achieved timings with stated objectives	Switchover runbooks, timed results, redundancy configuration records, backup restore logs	Switchover is documented but never executed, or failover results are not compared with recovery objectives
Crisis management function	Confirm the function exists, has defined roles and decision rights, and can be activated during a disruption	Crisis management charter, role assignments, escalation contacts, activation records from exercises or live events	Roles are named on paper but the people involved were never exercised or briefed
Records during disruption	Check that activities before and during a disruption are recorded in a readily accessible form once plans are activated	Incident and action logs, timestamps, decision records, access to records during outage conditions	Logs are stored only on systems that were affected by the disruption, or timelines cannot be reconstructed
Cost and loss estimate on request	Ask whether the entity can produce an estimate of aggregated annual costs and losses from major ICT-related incidents when the authority requests it	Cost and loss register, method notes aligned with the ESAs' joint guidelines, gross costs, losses and recoveries	No register exists, so the estimate must be rebuilt from memory during the request

How to build the Article 11 program in sequence

The sequence turns Article 11 from a set of separate documents into a tested program: each step produces an input the next step depends on, so the continuity policy, plans and tests describe the systems the organization actually runs. The order below follows the logic of the requirements rather than a fixed calendar.

Scope the critical or important functions
Start by listing the business functions the organization runs and marking which ones are critical or important, with the ICT systems, data and third-party services each one depends on. The financial entity owns this decision and should document who approved it, typically the management body or a delegated senior owner. This step is done when every in-scope function has a named owner, a list of supporting ICT assets and a recorded rationale for its classification. These lists feed the asset inventory and the business impact analysis that follow.
Run the business impact analysis
For each critical or important function, assess what a severe business disruption would cost in impact, customers affected and regulatory exposure. Use both quantitative and qualitative criteria and test the results against several scenarios, including a cyber-attack. Record the recovery priorities and the tolerable downtime each function can accept. The output is an approved analysis that names the systems and dependencies the recovery plans must restore first, and it is complete when the scenarios and criteria are documented and signed off.
Write the continuity policy and response and recovery plans
Draft the ICT business continuity policy, which may be a dedicated document, and the ICT response and recovery plans that implement it. Cover continuity arrangements for critical functions, incident response, activation of containment plans, preliminary impact and loss estimates, and crisis communication actions. Delegated Regulation (EU) 2024/1774 sets the components these documents must contain, so map each required element to a section before review. The step closes when the policy is approved by the management body, the plans have named owners, and each plan points to the recovery objectives from the impact analysis.
Set up the crisis management function
Define who decides during a disruption, who speaks for the organization, and how decisions are escalated to senior management. Assign roles, deputies and contact routes that work when the primary systems or staff are unavailable, and agree the points at which the plans are activated. Entities other than microenterprises must maintain this function. It is complete when the roles are documented, people have acknowledged them, and the escalation path has been checked against the contact directory.
Configure recovery and record-keeping tooling
Set up the systems that make recovery and evidence possible. Backup tools such as Bareos can schedule backups, restores and verification jobs and keep a catalog of what was backed up, while restic's check command can confirm that stored backup data is unmodified. A wiki such as XWiki keeps version history for plans and runbooks, and a case platform such as DFIR-IRIS keeps incident records and timelines. The step is done when a test restore has been run, the plan documents are under version control, and the records needed during activation are readily accessible even when production is down.
Run the first test with a switchover
Test the plans against the scenarios in the impact analysis, including a cyber-attack and a switchover from primary ICT infrastructure to redundant capacity, backups and facilities. Article 11(6) requires testing at least yearly and after substantive changes to critical systems, so schedule the first run early and record what was tested, who took part, the timings observed and the gaps found. The test is complete when the switchover has been performed or simulated against real recovery objectives and the results are written up for the management body.
Review findings and close the loop
Assign each gap from the test, the impact analysis and any post-activation review to an owner with a due date. Update the policy, plans, impact analysis and tooling where the test showed they were wrong, and record the change history. Entities other than microenterprises must have the response and recovery plans reviewed by internal audit, so give auditors the test evidence and the closure records. The step is complete when every finding is closed or formally accepted by the owner, and the next test date is set.

Which evidence satisfies Article 11 and how to keep it current

Article 11 is tested by documents and records, not by intent. The artifacts below are what an assessor or supervisor will ask to see, and each one goes stale in a different way when systems change. Keep them under version control and tie each refresh to a dated trigger.

Signed continuity policy

The ICT business continuity policy must be a comprehensive document that covers continuity of critical or important functions, incident response, containment, impact estimation and crisis communication. Check that the management body or its delegate has approved it with a date and version, and that it names owners for each arrangement. Review it at least yearly and whenever the scope of critical functions changes, since an out-of-date policy will not match the plans beneath it.

Approved response and recovery plans

Response and recovery plans set out the steps, roles and decision points for returning ICT services to an acceptable state. Each plan should carry an approval record, an independent internal audit review for entities other than microenterprises, and a link to the systems and recovery objectives it covers. Confirm the plan names the people who can activate it, because an assessor will test that the named roles exist.

Business impact analysis

The business impact analysis measures exposure to severe disruption using quantitative and qualitative criteria and scenario analysis. Keep the workings, not only the conclusions, so that an assessor can trace how each critical function was ranked. Rerun the analysis when a system supporting a critical or important function changes substantially, or when a third-party dependency is added or replaced.

Test reports with scenario records

Yearly tests must cover cyber-attack scenarios and switchovers between primary infrastructure and redundant capacity, backups and facilities. Each report should record the scenario, the participants, the expected and actual results, the failures and the remediation owner and date. Retesting after a substantive change to a critical system is required, so keep a trigger log that links each change to the test that followed it.

Switchover and restore logs

Switchover logs prove that failover happened in practice, with timestamps, the systems involved and the time to resume service. Backup tools can supply supporting records: Bareos keeps a SQL catalog of backed-up files and job history, and restic check can read pack files back to confirm stored data is unmodified. Ask your platform team which logs are retained, for how long, and who can export them for an assessor.

Crisis records and version history

Article 11 expects readily accessible records of activities before and during disruption events, and a crisis management function for entities other than microenterprises. Incident timelines, decision logs and crisis communications should live in a case tool with an audit trail, and the plan documents should sit in a wiki that keeps every change with its author and date. Test that you can produce a prior version of any plan as it stood during a past test or event.

What meeting Article 11 costs in money and effort

This table breaks the cost of meeting Article 11 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No figures are given because none are supplied for this topic, so use the drivers to frame a written scope and quote request. The main takeaway is that the largest recurring costs come from testing frequency and system count, while self-hosted open source mainly removes licence spend.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Continuity policy and plan drafting	Internal risk and continuity staff, plus any implementation partner preparing templates	One-time, then recurring on review	Number of critical or important functions in scope and how many plans must be written
Business impact analysis	Business owners and risk staff, with external support if quantitative criteria and scenario analysis are new	One-time, refreshed when systems change	Number of business functions, interdependencies with ICT third parties and depth of the scenario set
Recovery and switchover engineering	Platform and infrastructure engineers, often the largest internal effort	One-time build, recurring upkeep	Number of systems supporting critical functions, degree of redundancy, and whether switchover is automated
Tooling and licences	Software vendors for proprietary backup, case management or wiki tools	Recurring licence and support fees	Platform choice; self-hosted open-source tools such as Bareos, restic, DFIR-IRIS and XWiki remove most licence spend but still need hosting and staff time
Hosting for backup and recovery environments	Cloud or data center providers, or the entity's own infrastructure team	Recurring	Data volume, retention periods, number of redundant sites and the size of isolated restore environments
Test execution (yearly and after substantive change)	Internal test team, business staff who take part, and any external test facilitator	Recurring	Test frequency, number of scenarios (including cyber-attack and switchover), and how often major changes trigger extra tests
Internal audit review of plans	Internal audit function	Recurring, per review cycle	Number of plans, size of the audit sample and whether audit must review each response and recovery plan
External testing or independent review	Specialist testing firm or consultant, quoted from a written scope	Recurring, usually per test cycle	Scope of systems tested, whether third-party providers are included and whether the work is fixed-scope or a retainer
Assessor time	Competent authority or independent assessor, where examined	Varies by supervisory request	Whether the authority asks for the annual cost and loss estimate under Article 11(10) and how well records are kept

Which self-hosted tools produce Article 11 evidence

Article 11 expects records of activities before and during a disruption, and the crisis response needs a single place where the sequence of events is kept. DFIR-IRIS, licensed under LGPL-3.0-or-later, can serve as that case record. It keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail, which supports the readily accessible records the Article requires.

Consolidated timeline: The tool builds an investigation timeline from case data, which helps reconstruct when a disruption began, escalated and was contained.
Alert triage: It takes alerts from SIEM, EDR and REST sources into cases, so the trigger for each activation can be traced.
Evidence handling: Evidence is logged with SHA-256 verification and chain of custody, which matters if records are later used in a post-incident review.
Generated reports: Reports can be produced from case data for the management body or the competent authority on request.
Task ownership: Tasks attached to each case show who acted and when during crisis management.

Confirm that your alerting sources can feed the tool, that your crisis roles map to its task model, and that retention settings meet your own record-keeping rules. The tool does not decide what counts as a major incident, and your classification process must still do that.

Testing under Article 11 includes switchovers to redundant capacity and backups, so an entity needs logs and verification output that show restores actually work. Bareos (AGPL-3.0-only) and restic (BSD-2-Clause) both produce that kind of evidence, though they suit different estates. Bareos is a centralized backup system, while restic works on individual repositories.

Scheduled job records: The Bareos Director schedules and supervises backup, restore, verify and archive jobs, and the job history is evidence of what ran and when.
Catalog of backed-up files: Bareos keeps a SQL catalog of backed-up files, which lets a tester show what a restore selected.
Point-in-time restores: Bareos restores files selected from the current backup or from one before a given date and time, which supports scenario tests that assume older data.
Structural and data checks: restic check verifies the consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified.
Repeatable test output: Saved check output from each scheduled test gives an assessor dated proof of the test cycle.

Confirm that restore tests are run against isolated targets, that verification covers the systems that support critical or important functions, and that the scope of switchover tests is documented. Backup tools prove data can be restored, not that the business can resume operations within its own objectives.

Where Article 11 programs usually fall short

Article 11 programs tend to look complete on paper and fail under test. The gaps below cluster around whether plans have been exercised, kept current and backed by records that show what happened during a disruption. Each card pairs a gap with a practical fix and a check you can run before an assessor or supervisor does.

Switchover to redundant capacity never tested

Many entities document a failover to secondary infrastructure but have never moved live workloads across it under test conditions. Article 11(6) expects yearly testing that includes switchovers between primary ICT infrastructure and redundant capacity, backups and facilities for entities other than microenterprises. Fix it by scheduling a planned switchover with defined success criteria, measuring how long services take to resume, and recording any data or configuration drift found afterwards. Confirm the test covers facilities and backups, not only a single server.

Plans not updated after system changes

Continuity and recovery plans often describe an architecture that has since been replaced, so the runbook points to decommissioned hosts or outdated contacts. Article 11(6) requires testing after substantive changes to systems supporting critical or important functions, which makes change records a direct input to plan maintenance. Fix it by linking each change request affecting a critical or important function to a plan review step. Check that the version history of each plan shows when it was last validated against the live environment.

No cyber-attack scenario in testing

Test programs frequently rehearse power loss or hardware failure but leave out a scenario where attackers encrypt systems, tamper with backups or move laterally before detection. Article 11(6) asks entities other than microenterprises to include cyber-attack scenarios in their testing. Fix it by writing a scenario that assumes compromised credentials and corrupted backup sets, then testing whether the recovery path restores clean data. Ask the team to show which backup snapshot they would restore from and how they verified it was unmodified.

Backups not verified before restore

A recovery plan that assumes backups are usable fails when a restore reveals missing or damaged data. Verification sits between backup and recovery: tools can check structural consistency of backup sets and read stored data back to confirm it is unmodified. Fix it by scheduling verification jobs separate from backup jobs and recording the results as test evidence. Confirm that restore tests run against a segregated environment rather than production.

Missing crisis and activity records

During a disruption, teams often rely on chat threads, personal notes and memory, which leaves no reliable account of decisions or timings. Article 11(8) requires readily accessible records of activities before and during disruption events when plans are activated. Fix it by assigning a scribe role in each crisis team, keeping a timestamped incident timeline in a case or wiki system, and preserving evidence with a chain of custody. Ask for a sample record from the last exercise and check that it shows who decided what and when.

No annual cost estimate prepared

Supervisors can request an estimate of aggregated annual costs and losses caused by major ICT-related incidents, and many entities have no working method to produce one. The ESAs' Joint Guidelines JC 2024 34 ask for gross costs and losses and financial recoveries, and they apply from 19 May 2025. Fix it by tagging incident costs, recoveries and losses to a common register from the start, and assigning an owner who can produce the estimate on request. Confirm with your competent authority how and when they expect the estimate to be delivered.

How long and how much work does Article 11 take

What drives the cost and effort of meeting DORA Article 11?

The biggest drivers are how many critical or important functions the entity runs, how many ICT systems support them, how mature the existing continuity documentation is, and how many third parties sit in the recovery chain. An entity with a documented business impact analysis and tested backups starts far closer to the target than one building the continuity policy, plans and test programme from nothing. No public figure for effort applies across entities, so ask any provider for a scope-based estimate that lists the functions, systems, scenarios and test cycles covered.

Can an internal team meet the Article 11 requirements on its own?

Often yes, provided it has people who understand both the business functions and the ICT infrastructure, and an independent reviewer for the response and recovery plans. Article 11 requires the plans to be subject to independent internal audit review for entities other than microenterprises, so internal audit must be separate from the team that wrote them. Teams that lack recovery engineering experience, or that need to run cyber-attack and switchover tests across complex infrastructure, often bring in outside help for specific parts while keeping ownership internally.

What does the entity itself need to provide before outside help starts?

The entity owns its continuity policy, its critical or important functions and its risk appetite, so those decisions must come from management, not from a consultant. It also needs a current inventory of ICT systems and their dependencies, access to the people who run each function, records of past disruptions, and the backup and recovery tooling it already operates. Without these inputs, any partner will spend the early weeks rebuilding facts the entity should already hold.

How often must DORA continuity and recovery plans be tested?

Article 11(6) requires the ICT business continuity plans and response and recovery plans to be tested at least yearly, and again after substantive changes to systems supporting critical or important functions. For entities other than microenterprises, the tests must include cyber-attack scenarios and switchovers between primary infrastructure and redundant capacity, backups and facilities. Delegated Regulation (EU) 2024/1774 adds detail on severe but plausible scenarios, including failure or insolvency of ICT third-party providers, so plan the test calendar around those scenarios.

What will a supervisor ask for on annual costs and losses?

Under Article 11(10), entities other than microenterprises must be able to give their competent authority, on request, an estimate of aggregated annual costs and losses caused by major ICT-related incidents. The ESAs' Joint Guidelines JC 2024 34 apply from 19 May 2025 and ask for gross costs and losses and financial recoveries. The practical requirement is a traceable incident cost register, so finance, IT and operations record costs as incidents happen rather than reconstructing them later.

What scope should be agreed in writing before buying help with Article 11?

Agree the list of critical or important functions in scope, the systems and third parties supporting each, the continuity policy and plan documents to be produced, the business impact analysis method, the test scenarios and number of test cycles, and the evidence the entity will keep. Also agree who signs off each deliverable and who owns decisions on recovery objectives. For most engagements, a fixed scope with written deliverables and timelines makes costs comparable across quotes, and DeployOpen works on that basis, with a quote following from the written scope.

Does the work end once the first plans and tests are done?

No. The plans must be reviewed after substantive changes, tested at least yearly, and kept current as systems, providers and critical functions change. Recurring work includes test execution, updating runbooks, reviewing backup restores, recording incidents for the cost estimate and reporting results to the management body. Ask any partner which of these recur, what they cost in effort each cycle, and whether ongoing support is offered as a retainer.

How DeployOpen prepares Article 11 evidence

DeployOpen plans, implements and documents the continuity and recovery systems that Article 11 Response and recovery requires, inside the client's own infrastructure. The organization owns its policies, plans and decisions, while DeployOpen prepares the systems, testing records and evidence that an assessor or competent authority would review.

How we scope

Engagements are fixed-scope, with systems, plans and deliverables agreed in writing before work starts.
The written scope names which critical or important functions and supporting ICT systems the continuity and recovery work covers.
Scope also states which yearly test scenarios, including cyber-attack and switchover cases, are included and who signs each document.

How we build

We configure backup, restore and verification tooling so recovery plans can be exercised against the systems they protect.
We set up incident case records and version-controlled documentation so activity logs are kept before and during disruption.
We help structure the business impact analysis inputs and crisis management roles that the plans depend on.

How we hand over

Handover includes the written continuity policy, response and recovery plans, and test reports the organization can present to auditors.
Test results record scenarios run, findings, remediation owners and the dates the organization approved each follow-up.
Documentation is delivered in the client's own environment, so the organization keeps full control of its evidence after the engagement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Retainers can cover yearly and post-change plan testing, so evidence stays current when critical systems change.
Confirm with DeployOpen which assessor-facing questions fall under support, since independent auditors and competent authorities issue any formal assessment.