DORA Article 12 on Azure: Backup, Restoration, and Recovery Evidence
How DORA Article 12 maps to Azure Backup and Azure Site Recovery: per-workload RTO/RPO, quarterly test failover, and the exact evidence a supervisor asks to see. For platform leads.
Marc Dekeyser |
DORA Article 12 on Azure: Backup, Restoration, and Recovery Evidence
DORA Article 12 requires financial entities to maintain backup policies, restoration procedures, and recovery methods, to activate them without undue delay, and to test them periodically. On Microsoft Azure, that maps to Azure Backup for data, Azure Site Recovery for workload failover, geo-redundant storage for resilience, and a quarterly test failover that produces the evidence. The supervisor does not ask whether you have backups. The supervisor asks for the restore test report.
Article 12 is where DORA stops being about policy and starts being about proof. A backup you have never restored is a hypothesis. The regulation wants evidence.
Key takeaways
- DORA Article 12(1) mandates backup policies and restoration procedures; Article 12(4) requires recovery “without undue delay” and periodic testing.
- RTO and RPO must be documented per workload, mapped to the function’s criticality — not as one global figure.
- Azure Backup covers Azure Virtual Machines, Azure SQL Database, Azure Files, and blob storage; Azure Site Recovery provides failover with configurable RPO down to 30 seconds for supported VMs.
- A quarterly test failover in Azure Site Recovery is the periodic-testing evidence Article 12(4) expects.
- Each tool produces a specific artifact: a backup job report, a recovery point, a test failover report. Those artifacts are what a supervisor examines.
What does DORA Article 12 require for backup and recovery?
DORA Article 12 requires financial entities to develop and document backup policies and procedures specifying the scope and frequency of backups, restoration and recovery procedures, and to test both periodically. Article 12(1) covers the policy. Article 12(2) requires that backup systems be separated from production systems to limit a single point of failure. Article 12(4) requires recovery without undue delay and periodic testing of the procedures.
The structure matters. Article 12 separates three obligations that institutions often collapse into one. Backup — copying data so it survives loss. Restoration — bringing that data back into a usable state. Recovery — returning the function to operation. A successful backup proves nothing about restoration, and a successful restoration proves nothing about recovery if the surrounding workload cannot come back online. DORA Article 12(4)‘s testing requirement exists precisely because these three fail independently.
Article 12(2)‘s separation requirement has a direct Azure consequence: backups should not share a fate domain with production. Geo-redundant storage and a separate backup vault address this. Backups in the same region, same subscription, same fate as production do not satisfy the spirit of 12(2).
How do you document RTO and RPO per workload on Azure?
You document RTO and RPO per workload by mapping each function’s criticality to a recovery time objective and a recovery point objective, then configuring the Azure service that meets it — never as a single global figure. A payments engine and an internal wiki do not share a recovery profile, and a single institution-wide RTO is a finding waiting to be written up.
Recovery Time Objective is how long the function can be down. Recovery Point Objective is how much data you can afford to lose, measured in time. The two are independent. A function might tolerate four hours of downtime (RTO) but no more than thirty seconds of data loss (RPO), or the reverse.
Azure offers different tools for different points on that grid.
| Workload class | Example | Target RTO | Target RPO | Azure mechanism |
|---|---|---|---|---|
| Critical transactional | Payments engine | < 1 hour | < 30 seconds | Azure Site Recovery (continuous replication) |
| Critical data store | Azure SQL Database (system of record) | < 2 hours | < 5 minutes | Azure SQL point-in-time restore + geo-replication |
| Important | Document archive (blob) | < 8 hours | < 24 hours | Azure Backup, geo-redundant storage |
| Supporting | Internal tooling | < 24 hours | < 24 hours | Azure Backup, standard schedule |
Azure Site Recovery supports an RPO as low as 30 seconds for supported Azure Virtual Machines through continuous replication. Azure SQL Database supports point-in-time restore within the configured retention window and active geo-replication for near-real-time secondary copies. The documentation records, per workload, the target and the mechanism that delivers it. That table — populated for your actual estate — is the artifact Article 12(1) expects.
Which Azure services provide the backup and recovery evidence?
The Azure services that provide DORA Article 12 evidence are Azure Backup for data protection, Azure Site Recovery for workload failover, and geo-redundant storage for cross-region durability — each producing a distinct, exportable artifact. The evidence is not the configuration screen. It is the job report and the recovery point the service generates.
Azure Backup protects Azure Virtual Machines, Azure SQL Database (running in VMs or via the managed backup), Azure Files, and blob storage. It runs to a Recovery Services vault, stores recovery points on a schedule, and produces a backup job report showing success, timestamp, and recovery-point availability. That report — exported from the vault — is your Article 12(1) backup evidence. The retention policy you set is the documented frequency the article requires.
Azure Site Recovery replicates workloads to a secondary region and orchestrates failover. Its evidence is the replication health status (showing RPO is being met) and, critically, the test failover report. Azure Site Recovery lets you run a test failover into an isolated network without disrupting production. That test produces a report. The report is the proof.
Geo-redundant storage (GRS / GZRS) replicates blob, file, and other storage to a paired region — West Europe paired with North Europe for Dutch deployments. This satisfies the separation principle of Article 12(2) by ensuring backups survive a regional failure. The evidence is the storage account redundancy configuration and the replication status.
Configuration drift undermines all of this: a backup policy that silently stopped covering a new resource is the gap a supervisor finds. See Azure configuration drift for why the deployed state and the documented state diverge over time.
What does periodic testing under Article 12(4) look like?
Periodic testing under DORA Article 12(4) looks like a scheduled, evidenced restore — on Azure, a quarterly test failover in Azure Site Recovery and a quarterly restore validation from Azure Backup, each producing a dated report. Article 12(4) does not specify a frequency, but quarterly is the defensible cadence for critical functions and aligns with how supervisors read “periodic.”
The quarterly test failover is the centrepiece. You invoke a test failover in Azure Site Recovery, which spins up the replicated workload in an isolated network, you validate that it comes up and functions, and you tear it down. Azure Site Recovery records the test, its duration (your measured RTO against your target), and the outcome. That recorded test is the evidence that recovery works — not that it should work, that it did.
Alongside it, a restore validation from Azure Backup: pick a recovery point, restore it to an isolated location, confirm data integrity. The backup job and the restore both leave records.
A supervisor examining Article 12 compliance asks for three things, in order: the documented per-workload RTO/RPO table, the backup job reports showing the policy runs, and the most recent test failover report showing recovery was tested and met its target. An institution that can produce all three in minutes has Article 12 evidence. An institution that has backups but no test report has a hypothesis. For the broader risk framework these recovery controls sit within, see DORA Article 11 and Azure architecture.
How PAA supports Article 12 evidence
Platform Architecture Authority reads your Azure environment and reports which workloads have Azure Backup configured, which have Azure Site Recovery replication enabled, and which storage accounts use geo-redundant storage — then flags the critical resources that have none of these. The output is a coverage map against your documented RTO/RPO targets, showing where the backup policy and the deployed reality diverge. PAA is read-only; it does not run your test failover or restore your data, and a platform lead’s judgment on recovery sequencing is not something the tool replaces. Crimson Owl Technologies built PAA from roughly a thousand architecture reviews, where the most common Article 12 gap was not missing backups but critical workloads silently outside the backup policy.
Frequently asked questions
Does DORA Article 12 specify how often we must test recovery? No. Article 12(4) requires periodic testing without naming a frequency. For critical or important functions, quarterly test failover is the cadence most institutions adopt and most supervisors expect. The frequency should be proportionate to the function’s criticality and documented in the backup policy, so the cadence itself is a deliberate, defensible choice.
Is a successful Azure Backup job enough to satisfy Article 12? No. A backup job proves data was copied. Article 12 also requires restoration and recovery procedures and their periodic testing. A backup you have never restored does not demonstrate recovery capability. The evidence that satisfies a supervisor is the test failover or restore validation report, not the backup job alone.
What RPO can Azure actually achieve for a critical workload? Azure Site Recovery supports an RPO as low as 30 seconds for supported Azure Virtual Machines through continuous replication. Azure SQL Database active geo-replication achieves near-real-time secondary copies, typically seconds of lag. The achievable RPO depends on the workload and replication mechanism, which is why RPO must be documented per workload rather than as one figure.
How does geo-redundant storage relate to Article 12(2)? Article 12(2) requires backup systems to be separated from production to avoid a single point of failure. Geo-redundant storage replicates data to a paired Azure region — West Europe to North Europe for Dutch entities — so a regional failure does not destroy both production and backup. It is one mechanism for the separation the article requires, not the whole of it.
Article 12 rewards the institution that tests. The backup is the easy part. The dated, successful restore report is the part that holds up under examination.
