DORA Exit Plans: What Backup Teams Must Be Able to Show

In Veeam’s annual survey of security leaders on data trust and resilience, 90% of the 900-plus security leaders surveyed said they were very to extremely confident they could recover within their defined recovery time objectives. Yet among ransomware victims, only 28% said they fully recovered all affected data. Confidence in a backup is not evidence of a restore, and that gap is exactly what regulators now ask financial entities to close.

Most backup strategy best practices assume the provider stays. The Digital Operational Resilience Act assumes it may not. DORA, set out in the regulation text on EUR-Lex, has applied since 17 January 2025, and the European supervisory authorities have since designated 19 critical ICT third-party providers for direct oversight. The financial entities that use those providers remain fully responsible for their own operational resilience.

A DORA exit plan is a documented, tested procedure that lets a financial entity stop using an ICT third-party service and move the service and its data to another provider or back in-house without disrupting critical operations. This guide turns the legal text into an evidence pack your backup team can show an auditor.

What DORA Article 28(8) Requires of Your Backup and Recovery Plan

Article 28(8) of DORA requires financial entities to put in place exit strategies for ICT services that support critical or important functions. Cloud backup, backup storage and archive services often qualify, because a failed restore stops the functions they protect. A backup and recovery plan that depends on a single provider’s platform therefore becomes a third-party risk in its own right.

The regulation is specific about what an exit must achieve. Financial entities must be able to exit a contractual arrangement without disruption to their business activities, without limiting compliance with regulatory requirements, and without detriment to the continuity and quality of services provided to clients. Exit plans must be “comprehensive, documented” and “sufficiently tested and reviewed periodically.”

Two phrases matter most to a backup team. The first is the duty to develop transition plans that let the entity “remove the contracted ICT services and the relevant data” from the provider and “securely and integrally transfer them to alternative providers or reincorporate them in-house.” Integrally means the data arrives complete and usable, not merely copied. The second is the requirement for contingency measures that maintain business continuity if the exit circumstances arise.

The text covers failure, deterioration, disruption and termination. In practice that describes two situations. A planned exit follows a decision to leave, such as a contract ending, and gives you time. A stressed exit follows a provider failure, and it gives you none. Your evidence needs to cover both.

The Commission’s Delegated Regulation 2024/1773, a 2024 technical standard that remains the current text, adds detail on the policy for contractual arrangements with providers of critical or important services. Its policy covers the whole life of the contract, from planning and approval through monitoring to termination. Read the official text for the exact obligations that apply to your entity.

Designation of critical providers does not shift the burden. The PwC Legal summary of the designation quotes the authorities saying that financial entities remain fully responsible for operational resilience and third-party risk management, including where a provider is directly overseen. The EBA oversight page for DORA shows the EBA, ESMA and EIOPA acting as Lead Overseers, supported by ENISA and national authorities. Oversight of the provider does not replace your own exit plan.

Backup Strategy Best Practices Through an Exit Lens: 3-2-1 Reframed

The 3-2-1 backup strategy means keeping three copies of your data, on two different media types, with one copy offsite. It is the base of nearly every set of backup strategy best practices, and it remains sound. DORA adds a harder question: which of those copies can you still restore if a provider disappears?

Apply the test to each copy. A second copy stored with the same cloud provider, under the same account and the same control plane, is a redundancy measure, not an exit path. At least one copy must be restorable without the original provider’s platform, in a format and on infrastructure you control.

Reading the 3-2-1 backup strategy through an exit lens: copies, media and offsite only count if one copy survives provider loss.

Article 12 of DORA already sets the foundation. Backup policies must specify the scope of the data and the minimum frequency of backup, based on the criticality of the information or the confidentiality level of the data. Testing of backup, restoration and recovery procedures must be undertaken periodically. When restoring with its own systems, the entity must use ICT systems that are physically and logically segregated from the source system. That last rule is an exit-readiness test in disguise: can you restore somewhere that is not the place that failed?

Threat data explains why independence matters. In Sophos’s latest ransomware survey of IT and security teams, 56% of attacks succeeded in encrypting data, up from 50% the year before. Backup-based recovery rose to 66% of encrypted-data cases, up 12 percentage points. Backups are doing more of the recovery work, which makes any dependency in the backup path more costly when it fails.

The CISA #StopRansomware Guide advises maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. It explains that ransomware variants try to delete or encrypt accessible backups, and it suggests multi-cloud approaches to avoid vendor lock-in for cloud-to-cloud backups. The guide dates from September 2023, but its core advice has not changed.

Six Pieces of Evidence Every Backup Strategy Should Be Able to Produce

DORA does not publish a checklist for backup teams, so the entity defines what sufficient evidence looks like and defends it. The six items below map the legal phrases to artifacts you can hand over. A backup and recovery plan that can produce all six is ready for scrutiny.

1. A service inventory. List every backup, replication and archive service you use, the critical or important functions each supports, and the provider behind each one.
2. Proof of portability. Show the format your backup data is held in, how it is exported, and that a second platform can read it. This answers the “securely and integrally transfer” requirement.
3. An independent, immutable copy. Identify the copy that survives provider loss, where it lives, and how it is protected against deletion and overwrite. Include its segregation from the source environment.
4. A transition plan. Document the alternative providers or in-house options, the sequence of steps, who owns each step, and the contingency measures that keep services running during the move.
5. A dated test record. Record the scope, scenario, measured recovery time and recovery point, issues found and remediation, signed by the owner.
6. A review trail. Link the plan to the contract, record who reviews it, how often, and what triggers an unscheduled review.

The six pieces of evidence a backup team can produce for a DORA exit review, from service inventory to review trail.

Two things make this evidence credible. The first is measurement. A test record that states a measured recovery time beats a statement that recovery is expected to work. The second is independence from the provider’s own reporting. A dashboard showing green jobs says the backup ran, not that the restore works.

The Veeam survey shows how far the gap can run. Although 90% of respondents were confident about meeting their recovery time objectives, among ransomware victims only 28% said they fully recovered all affected data, and 44% recovered less than 75% of it. The sample and the questions differ across the two measures, so treat them as context rather than a direct comparison. Even so, a recovery claim can be no better than the last restore your team actually performed.

Veeam’s 2026 survey: 90% of security leaders were confident of meeting recovery objectives, yet 28% of ransomware victims fully recovered all data.

Building a Cloud Backup Plan With a Portable Exit Path

A cloud backup plan that can survive an exit starts with portability. Prefer open, documented formats and standard protocols for backup data, and confirm that your backup software can read repositories without the original provider’s service in the loop. If restoring requires a proprietary service that only the provider runs, the exit plan is paper.

Next, choose what exit means for each workload. Repatriation moves data back on-premises. A switch-over moves it to another provider. Each has a different time and cost profile, and neither is instant. Egress charges, available bandwidth and the physical time to move large datasets are real constraints, and your transition plan must account for them using your own measured figures rather than assumptions.

Concentration risk deserves a place in the plan too. If your primary data, your backups and your recovery environment all sit with one provider, a single event can remove all three. Keeping at least one copy elsewhere is the practical expression of the 3-2-1 backup strategy applied to third-party risk.

Immutability must travel with the data. Protection that exists only inside the provider’s platform disappears when you leave it, so recreate it at the destination. The AWS documentation on S3 Object Lock is a useful reference for what to replicate. Object Lock follows a write-once-read-many model, works only in buckets that have versioning enabled, and offers two modes. In compliance mode, a protected object version cannot be overwritten or deleted by any user, including the root user. In governance mode, users with special permissions can alter the settings. Whatever your destination, decide which behavior you need and verify it holds.

A cloud-to-on-premises copy is one concrete way to gain independence. A locally held copy of cloud-hosted data, separated from the source cloud environment, gives you something to restore from if the source becomes unavailable.

How Often Should Backup Teams Test Their Backup and Recovery Plan?

Article 28(8) requires exit plans to be sufficiently tested and reviewed periodically, and it fixes no interval. There is no mandated number of days or months. The cadence is therefore your decision, and you need to be able to justify it by pointing to the criticality of the function and how often the environment changes.

A tiered approach is easy to defend. For every in-scope service, hold a tabletop review each period to walk through the transition plan and update contacts, contracts and dependencies. For services that support important functions, run partial restore tests more often, restoring a defined dataset onto segregated systems and recording the measured times. For the most critical functions, rehearse a full switch-over to the alternative platform on a schedule that matches the risk you have accepted.

Triggers should override the calendar. Rehearse again after a contract change, a major architecture change, a failed test, or the addition of a new critical function. Each rehearsal should leave a record with the scope, the scenario, the measured recovery time and recovery point, the issues found and the remediation owner.

The recovery speed data shows what is at stake. The Sophos 2026 survey press release reports that, among 2,158 IT and cybersecurity decision-makers across 17 countries whose organizations were hit by ransomware, 55% recovered within one week and 16% in less than a day. Sophos recommends that backups be tested regularly and stored offline or in immutable formats. Under a day is the minority outcome, so a rehearsed procedure is what separates a short outage from a week-long one.

Four practices hold up under an exit review:

• Keep at least three copies on two media types, with one offsite and at least one independent of the primary provider.
• Make one copy immutable or offline so that deletion or encryption of the production environment cannot reach it.
• Restore to segregated systems on a schedule, and record measured results rather than job status.
• Review the plan whenever the contract, architecture or critical functions change.

For plan structure, NIST contingency planning guidance in SP 800-34 remains a foundational reference for how to develop and format a contingency plan. It supports the discipline, while DORA supplies the obligation.

Where StoneFly Fits in a Cloud Backup Plan With a Controlled Copy

Backup teams subject to DORA often ask where a controlled, independent copy can live. This is the problem StoneFly addresses: keeping a copy of backup data on infrastructure you control, protected against deletion, and available for restore tests. StoneFly does not claim that any product makes an organization DORA-compliant, and none performs or automates an exit. These are building blocks for the evidence described above.

StoneFly DR365V is a Veeam Ready air-gapped and immutable backup and disaster recovery solution. For teams that want a turnkey Veeam Ready backup and disaster recovery appliance, it combines immutable repositories, the patented Air-Gapped Vault, a tape tier and cloud connectivity in one system. Immutable FileLock protects file repositories, and immutable Object Lock protects AWS-compatible S3 object repositories. The cloud storage gateway reaches Microsoft Azure, AWS and StoneFly Private Cloud Storage, and supports offsite immutable copies.

The evidence pack needs dated test records, and DR365V provides an isolated sandbox for backup validation and DR plan testing. Tests can run daily, weekly, monthly or on a custom schedule, with reporting on the results. The schedule you choose remains your own decision, based on the criticality of the workload.

StoneFly AWS-compatible S3 object storage stores object data on StoneFly appliances and does not require AWS cloud storage to operate. It gives you direct control over data and hardware, with Object Lock available. StoneFly’s article on object lock and data protection explains the AWS-compatible S3 object lock approach, and the guide to setting up immutable file-level WORM covers the file side.

For workloads already in the cloud, StoneFly Veeam Cloud Backups supports cloud-to-on-premises backup. That gives the organization a locally controlled copy of cloud-hosted data and can separate recovery data from the source cloud environment, which maps directly to the independent copy in the evidence checklist.

Conclusion: Backup Strategy Best Practices Start With a Tested Exit

DORA Article 28(8) turns exit from a contract clause into an operating capability. Scope the services that support critical or important functions, assemble the six pieces of evidence, and rehearse on a cadence you can defend. The 3-2-1 backup strategy still applies, but read it through one question: which copy survives the loss of your provider?

Backup strategy best practices that cannot answer that question are incomplete under DORA, however many copies they list. The surveys show that confidence is common and complete recovery is not. Only a dated restore with measured recovery time and recovery point gives an auditor something to check.

Start with the inventory, identify your independent copy, and schedule the first restore test. If you want to discuss a controlled, immutable copy for your own environment, talk to StoneFly about a controlled immutable copy.