DORA Articles 11 & 12: Backup and Recovery Compliance Guide

Your supervisory review is scheduled. The examiner's request list arrived three weeks ago, and somewhere between item 14 ("evidence of backup integrity verification") and item 19 ("documented cyberattack scenario test results"), your stomach dropped. You have backups. You run them nightly. But you have never been asked to prove they work under adversarial conditions, and you have certainly never assembled the evidence into a format that satisfies a National Competent Authority.

This is where most financial institutions are right now. According to research cited by compliance practitioners tracking DORA adoption, only around 50% of EU financial entities reached full compliance by end of 2025, with 38% still remediating into 2026. The grace period is over. Supervisors are examining, not advising.

Articles 11 and 12 of the Digital Operational Resilience Act are the two provisions that bite hardest in a backup-and-recovery review. This guide works through both of them line by line, then gives you the architecture, the test methodology, the evidence pack, and the gap list you need to walk into that review with confidence.

Key Takeaways

• DORA Articles 11 and 12 impose testable, evidence-backed obligations on backup architecture, RPO/RTO targets, immutability controls, and cyberattack scenario testing.
• A backup policy document is not evidence. Configuration records, restoration test logs, timestamped metrics, and contractual clauses together constitute evidence.
• Immutability must be enforced at the storage layer, not just through access control policy.
• RTO and RPO targets are regulatory commitments that must be validated by documented restoration tests, not aspirational figures in a policy document.
• Third-party cloud provider contracts must contain specific DORA Article 30 clauses covering durability, audit rights, data portability, and incident notification.
• Assembling your audit evidence pack before the review request arrives is the single most effective risk-reduction action available to you right now.

Table of Contents

• Why DORA Backup Enforcement Changed in 2026: From Grace Period to Active Supervision
• What Articles 11 and 12 Actually Mandate: Line by Line
• The Four Technical Controls You Must Prove: Isolation, Immutability, Integrity Checks, and Remote Restore
• How to Map RPO and RTO Targets to DORA's Resilience Testing Requirements
• Designing the Backup Architecture: Cloud Storage Tiers, Automated Backup, and Off-Site Recovery
• Running and Documenting Cyberattack Scenario Tests That Satisfy Your NCA
• Third-Party ICT Risk: What Your Cloud Provider Must Contractually Guarantee
• The Audit Evidence Pack: What to Produce Before the Regulator Arrives
• Common Gaps Found in 2026 Supervisory Reviews and How to Close Them
• Building a Defensible Compliance Position Before the Review

Why DORA Backup Enforcement Changed in 2026: From Grace Period to Active Supervision

DORA became applicable on 17 January 2025. The first twelve months were, in practice, a supervised implementation window. National Competent Authorities (NCAs) in most member states were issuing guidance, accepting remediation roadmaps, and treating gaps as findings rather than violations. That posture has shifted.

In 2026, NCAs are conducting full supervisory reviews against the completed regulatory technical standards. The European Banking Authority (EBA), ESMA, and EIOPA published their joint RTS packages in 2024, and those standards are now the benchmark against which your ICT risk management framework is measured. Backup and recovery controls appear explicitly in those RTS documents, not as aspirational principles but as testable requirements with specific evidence expectations.

The practical consequence is this: a backup policy document is not evidence. A signed attestation from your IT director is not evidence. What constitutes evidence is a combination of configuration records, test logs, restoration metrics, and third-party contractual clauses, all of which can be cross-referenced against each other during an examination.

If your organisation operates in multiple EU jurisdictions, the picture is more complex. Your home-state NCA leads the review, but host-state authorities can request information independently. Any inconsistency between what you tell one authority and what your cloud provider's contract says creates a finding.

What Articles 11 and 12 Actually Mandate: Line by Line

Article 11 covers ICT business continuity policy. It requires financial entities to implement a documented, tested, and regularly reviewed business continuity plan that covers ICT systems. The key obligations are:

• Identify critical or important functions and map the ICT assets supporting them
• Define recovery time objectives and recovery point objectives for each function
• Establish procedures for activating backup systems and switching to redundant infrastructure
• Test continuity arrangements at least annually, and after any major ICT incident or significant change to the environment
• Ensure staff responsible for continuity procedures are trained and the procedures are accessible during an incident

Article 12 covers backup policies specifically. The requirements under Article 12 are more granular:

• Maintain backup copies of data and systems sufficient to restore operations to defined RPO and RTO targets
• Ensure backups are stored in locations physically and logically separate from the production environment
• Test backup restoration regularly and document the results
• Protect backup copies from ransomware and other cyberattacks, which in practice means immutability controls
• Ensure backup and recovery procedures are included in the ICT incident response process

The phrase that matters most in Article 12 is "sufficient to restore operations." Sufficiency is not self-defined. Your NCA will interpret it against your stated RPO and RTO targets, your criticality classification, and the actual results of your restoration tests. If your stated RTO for a critical payment processing function is four hours but your last restoration test took nine hours, you have a gap regardless of what your policy document says.

The Four Technical Controls You Must Prove: Isolation, Immutability, Integrity Checks, and Remote Restore

These four controls map directly onto Article 12's requirements and are the areas where supervisory reviewers spend the most time.

Isolation means your backup environment cannot be reached from the production environment through normal network paths. An attacker who compromises your production systems must not be able to encrypt or delete your backups through the same access vector. This requires network-level separation, not just different credentials on the same storage cluster. A private network segment with no route advertisement into the production VLAN is the minimum. A physically separate storage environment in a geographically distinct facility is stronger.

Immutability means backup data cannot be modified or deleted for a defined retention period, even by a privileged administrator. Object-lock configurations on cloud storage, WORM (write once, read many) tape, or immutable snapshot policies on block storage all satisfy this requirement. The key is that immutability must be enforced at the storage layer, not just by access control policy. Access control can be circumvented. Storage-layer immutability cannot be overridden without vendor involvement and an audit trail.

Integrity checks mean you verify that backup data has not been corrupted between the time it was written and the time you need to restore it. Hash verification at write time and re-verification on a schedule is the standard approach. Without automated integrity checking, you cannot assert to a regulator that your backups are restorable. You can only assert that the backup job completed.

Remote restore means you can actually recover systems and data from a location other than the primary production environment, within your stated RTO. This requires a documented runbook, pre-provisioned or rapidly provisionable compute in the recovery environment, and tested network connectivity between the recovery environment and the dependent systems that need to reconnect after restoration.

PlusClouds Automated Backup tracks RPO and RTO targets per workload and logs restoration test results against those targets, which gives you the timestamped evidence record that supervisors expect to see rather than a spreadsheet you assembled the week before the review.

How to Map RPO and RTO Targets to DORA's Resilience Testing Requirements

RPO and RTO are not aspirational figures. Under DORA, they are commitments that must be validated through testing. Here is how to structure that mapping.

Start with your criticality classification. DORA requires you to identify critical or important functions. Each function should have a documented ICT dependency map showing which systems, databases, and network paths it relies on. For each system in that map, assign an RPO (maximum acceptable data loss, measured in time) and an RTO (maximum acceptable downtime before restoration).

A payment processing core system might carry an RPO of 15 minutes and an RTO of two hours. A regulatory reporting system might carry an RPO of four hours and an RTO of 24 hours. These figures must be defensible against the actual impact of a disruption to that function.

Once you have the targets, your resilience testing schedule must validate them. DORA Article 11 requires testing at least annually. For critical functions, testing once a year is the floor, not the ceiling. Many NCAs expect to see test results for critical functions from multiple test cycles, not a single annual exercise.

The test must demonstrate that you can restore from backup to a clean environment within the stated RTO, with data loss no greater than the stated RPO. This means:

1. Initiate a simulated failure at a defined point in time (the "incident time")
2. Identify the most recent backup created before the incident time
3. Provision a clean recovery environment
4. Restore data and configuration from backup
5. Verify application functionality and data integrity
6. Record the elapsed time from step 1 to step 6

If that elapsed time exceeds your stated RTO, you have a gap. Fix the gap before the review, not during it.

Designing the Backup Architecture: Cloud Storage Tiers, Automated Backup, and Off-Site Recovery

A DORA-compliant backup architecture for a financial institution typically has three layers.

Layer 1: Frequent local snapshots. These are taken every 15 to 60 minutes depending on the RPO for each workload. They live on fast storage close to the production environment and support rapid recovery from operational errors (accidental deletion, configuration mistakes). They are not your ransomware recovery mechanism.

Layer 2: Daily off-site backups to isolated cloud storage. These are transferred to a storage environment that is network-isolated from production, with immutability enforced at the object or block layer. Retention periods of 30 to 90 days are typical for financial services, though your specific regulatory obligations under MiFID II, PSD2, and local data retention laws may require longer. PlusClouds Cloud Storage provides tiered persistence across HDD, SSD, and NVMe, which lets you match storage cost to recovery priority: NVMe for the most recent backups you are most likely to need quickly, HDD for long-retention compliance archives.

Layer 3: Geographic redundancy. At least one copy of your backups must be in a physically separate location from your primary data center. This protects against facility-level failures (power loss, flooding, fire) that would affect both production and Layer 1 snapshots simultaneously.

Here is what a basic backup policy configuration might look like in a structured format:

backup_policy:
  workload: payment-processing-core
  criticality: critical
  rpo_minutes: 15
  rto_hours: 2
  schedule:
    snapshot_interval_minutes: 15
    daily_offsite: "02:00 UTC"
    weekly_archive: "Sunday 03:00 UTC"
  retention:
    snapshots_days: 7
    daily_backups_days: 90
    weekly_archives_years: 7
  storage:
    primary_tier: nvme
    offsite_tier: ssd
    archive_tier: hdd
  immutability:
    enabled: true
    lock_period_days: 90
  integrity_check:
    on_write: sha256
    verification_schedule: "weekly"
  restore_target: isolated-recovery-environment

The recovery environment itself needs pre-provisioned or rapidly deployable compute. Waiting for a server to be provisioned after an incident starts adds directly to your RTO. PlusClouds Cloud Servers deploy in 60 seconds, which means your recovery runbook can include a provisioning step without blowing your two-hour RTO window.

Running and Documenting Cyberattack Scenario Tests That Satisfy Your NCA

DORA Article 11 specifically requires testing against cyberattack scenarios, not just hardware failure scenarios. This is the part most organisations have not done.

A cyberattack scenario test for backup and recovery purposes simulates a ransomware infection that has encrypted production systems and attempted to reach backup storage. The test must demonstrate that:

• Backup copies were unaffected by the simulated attack (immutability held)
• The organisation can detect the attack and isolate affected systems within a defined time window
• Recovery can proceed from clean backup copies to a clean environment
• The recovered environment can be validated before reconnecting to production

Document every step with timestamps. The NCA reviewer will look for a test report that shows the scenario description, the test date, the participants, the timeline, the results against each stated objective, and any gaps identified with remediation actions assigned.

For organisations subject to DORA's threat-led penetration testing requirements (TLPT, which applies to significant financial entities), the bar is higher. TLPT exercises must be conducted by qualified external testers and follow the TIBER-EU framework. But for the backup-specific resilience testing under Articles 11 and 12, internal testing with documented methodology is accepted by most NCAs.

The documentation format that tends to satisfy reviewers is a structured test report with five sections: scope and objectives, test scenario description, timeline and participants, results against each acceptance criterion, and findings with remediation owners and target dates. Keep it factual and specific. Vague language ("backup restoration was successful") without supporting metrics is a finding in itself.

For broader context on how infrastructure isolation supports your cyberattack scenario testing, the 3-2-1-1 backup rule architecture guide covers the underlying design principles in detail.

Third-Party ICT Risk: What Your Cloud Provider Must Contractually Guarantee

If your backups are stored with a cloud provider, or if your recovery environment is cloud-hosted, that provider is a third-party ICT provider under DORA. Article 30 of DORA specifies what your contract with that provider must contain. For backup and recovery specifically, the contract must include:

• Defined service levels for backup storage availability and durability
• Explicit RPO and RTO commitments for the cloud infrastructure layer (separate from your application-level targets)
• Data portability and exit provisions, so you can migrate backup data to another provider if the relationship ends
• Audit rights, meaning you can request evidence of the provider's own controls
• Incident notification obligations, including notification timelines for events that affect your backup data

A contract that says "99.9% storage availability" without specifying durability (the probability that stored data is not lost) is insufficient. Ask for explicit durability figures (typically expressed as "eleven nines" or similar for object storage) and get them into the contract, not just the marketing materials.

The PlusClouds Datacenter infrastructure operates from Tier 3 facilities with N+1 redundancy and a 40 Gbps backbone, which supports the availability and durability commitments your contract needs to reference. Tier 3 certification means concurrent maintainability: no single planned maintenance event should take the facility offline.

For financial institutions managing data residency requirements alongside DORA compliance, the data sovereignty guide covers how to structure your cloud contracts to keep workloads inside specific national boundaries.

The Audit Evidence Pack: What to Produce Before the Regulator Arrives

Assemble this before the review request arrives. Assembling it under time pressure after the request lands means you will miss things, and gaps in the evidence pack look worse than gaps in the controls.

The evidence pack for Articles 11 and 12 should contain the following:

Policy documents:

• ICT business continuity policy (current version with approval date and owner)
• Backup and recovery policy (current version, showing RPO and RTO targets per criticality tier)
• Incident response procedure (showing how backup activation integrates with incident response)

Technical configuration records:

• Backup job schedules and configurations for all critical systems
• Storage configuration records showing isolation and immutability settings
• Network diagrams showing separation between production and backup environments
• Integrity check configuration and verification schedules

Test records:

• Restoration test reports for the past 24 months, including dates, scenarios, results, and metrics
• Cyberattack scenario test reports (at least one in the past 12 months)
• Any gaps identified in testing and the remediation actions taken

Third-party contracts:

• Cloud provider agreements with service level terms for backup storage
• Evidence of audit rights exercised (or a record that you requested and received the provider's compliance certifications)

Training records:

• Evidence that staff responsible for recovery procedures have been trained
• Date of most recent continuity exercise involving those staff

Incident history:

• Records of any ICT incidents in the review period that triggered backup or recovery activation
• Post-incident reviews showing what worked and what was remediated

If you have gaps in any of these categories, identify them now. A gap with a documented remediation plan and a target date is manageable. A gap with no evidence that you knew about it is a supervisory finding.

For organisations that also operate under PCI DSS 4.0.1, the PCI DSS cloud compliance guide covers the overlap between payment security controls and backup requirements, which can help you build a single evidence pack that satisfies both frameworks.

Common Gaps Found in 2026 Supervisory Reviews and How to Close Them

Based on patterns reported by compliance practitioners and DORA implementation advisors, these are the gaps appearing most frequently in 2026 reviews.

Gap 1: Backup scope does not match the criticality map. The ICT asset register lists 40 critical systems. The backup policy covers 31 of them. The other nine were added after the backup policy was last reviewed. Close this by running a reconciliation between your asset register and your backup configuration at least quarterly.

Gap 2: Immutability is policy-based, not storage-layer-enforced. The backup policy says backups cannot be deleted for 90 days. But the storage configuration allows an administrator with elevated privileges to delete objects. Close this by enabling object-lock or WORM settings at the storage layer and removing administrative override capability.

Gap 3: RTO targets have never been validated under realistic conditions. The policy says two hours. The only restoration test ever run was a single file recovery from a snapshot, which took 12 minutes. A full system restoration to a clean environment has never been timed. Close this by running a full restoration test, documenting the elapsed time, and either confirming the RTO is achievable or revising the target to reflect reality.

Gap 4: The recovery environment is not pre-tested. Backups exist. The recovery environment (a cloud account, a secondary data center) exists. But no one has ever actually restored into it. The network routes, authentication configurations, and application dependencies in the recovery environment have never been validated. Close this by running a full restoration drill in the recovery environment, not in a simulated environment that differs from the real one.

Gap 5: Third-party contracts do not contain required DORA clauses. The cloud provider agreement was signed in 2022 and has not been updated since DORA became applicable. It contains no audit rights, no data portability provisions, and no incident notification timelines. Close this by engaging the provider to amend the agreement, or by triggering the contract review cycle that DORA Article 30 requires.

Gap 6: Test documentation is too vague to satisfy a reviewer. The test report says "restoration successful." It does not say which system was restored, from which backup, to which environment, in how many minutes, and against which acceptance criteria. Close this by adopting a structured test report template and applying it retroactively to any recent tests you plan to include in the evidence pack.

Building a Defensible Compliance Position Before the Review

DORA Articles 11 and 12 are not ambiguous. They tell you what to implement, what to test, and what to document. The organisations that struggle in supervisory reviews are not the ones with bad infrastructure. They are the ones with good infrastructure that was never formally tested, documented, or mapped against the regulatory requirements.

The technical controls, the backup architecture, the test methodology, and the evidence pack described in this guide give you a complete framework. Start with the gap analysis in the section above. Close the gaps in order of criticality. Assemble the evidence pack before the review request arrives.

For the infrastructure layer, PlusClouds Automated Backup provides the RPO and RTO tracking, immutable storage integration, and restoration logging that translate directly into the evidence records your NCA will request. Pair it with PlusClouds Cloud Storage for tiered, geographically redundant backup retention, and PlusClouds Cloud Servers for a pre-tested recovery environment that deploys fast enough to stay inside a two-hour RTO window.

If your 2026 review is already scheduled, start the evidence pack today. If it is not yet scheduled, assume it will be. The supervisors are working through their portfolios, and financial institutions that have their documentation ready when the request arrives are the ones that close reviews without remediation orders.