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
The supervisor does not ask whether you have backups. They ask for the restore test report.
That is Article 12 in one sentence. It requires financial entities to maintain backup policies, restoration procedures, and recovery methods, to activate them without undue delay, and to test them periodically. On Azure the list is short: Azure Backup for data, Azure Site Recovery for workload failover, geo-redundant storage for resilience, and a quarterly test failover that produces the paperwork.
A backup you have never restored is a hypothesis. This is where DORA stops being about policy and starts wanting proof.
What Article 12 actually requires
Three obligations sit inside Article 12, and institutions keep collapsing them into one.
Backup is copying data so it survives loss. Restoration is bringing that data back into a usable state. Recovery is returning the function to operation. A successful backup proves nothing about restoration. A successful restoration proves nothing about recovery if the workload around it cannot come back online. Article 12(4) mandates testing precisely because these three fail independently.
The specifics. Article 12(1) covers the policy: scope and frequency of backups, plus restoration and recovery procedures. Article 12(2) requires backup systems to be separated from production so a single failure cannot take both. Article 12(4) requires recovery without undue delay and periodic testing of the procedures.
That separation clause has teeth on Azure. Backups sharing a region, a subscription, and a fate with production do not meet the spirit of 12(2). Geo-redundant storage and a separate backup vault are how you answer it.
RTO and RPO belong to the workload
One institution-wide RTO is a finding waiting to be written up. A payments engine and an internal wiki do not share a recovery profile.
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 move independently. A function might tolerate four hours of downtime but no more than thirty seconds of data loss. Or the reverse.
Azure has a different tool for each point 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 gives you point-in-time restore inside the configured retention window and active geo-replication for near-real-time secondary copies. Your documentation records, per workload, the target and the mechanism that hits it. That table, populated for your real estate, is the artifact Article 12(1) expects.
The Azure services that leave evidence
The evidence is not the configuration screen. It is the job report and the recovery point.
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. Export that report from the vault and it is your Article 12(1) backup evidence. The retention policy you set is the documented frequency the article asks for.
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 the test failover report. You can 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 with North Europe for Dutch deployments). It is how backups survive a regional failure, and it is one answer to the separation principle in Article 12(2). The evidence is the storage account redundancy configuration and the replication status.
One thing quietly breaks all of it: a backup policy that stopped covering a resource nobody thought to add. That silent gap is exactly what a supervisor finds. See Azure configuration drift for why deployed state and documented state drift apart over time.
Periodic testing under 12(4)
Article 12(4) never names a frequency. Quarterly is the defensible cadence for critical functions, and it is how supervisors read “periodic.” Pair a quarterly test failover in Azure Site Recovery with a quarterly restore validation from Azure Backup, and date both reports.
The test failover is the centrepiece. You invoke it in Azure Site Recovery, the replicated workload spins up in an isolated network, you confirm it comes up and functions, you tear it down. Azure Site Recovery records the test, its duration (your measured RTO against your target), and the outcome. That record is the evidence that recovery worked. Not that it should. That it did.
Run the restore validation alongside it. 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 asks for three things, in order. The per-workload RTO/RPO table. The backup job reports showing the policy runs. The most recent test failover report showing recovery was tested and hit its target. Produce all three in minutes and you have Article 12 evidence. Have backups and no test report, and you have a hypothesis. For the risk framework these recovery controls sit inside, 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 it 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 it does not replace a platform lead’s judgment on recovery sequencing. 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 sitting 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.
The short version
- Article 12(1) mandates backup policies and restoration procedures. Article 12(4) requires recovery “without undue delay” and periodic testing.
- Document RTO and RPO per workload, mapped to each function’s criticality. Never as one global figure.
- Azure Backup covers Azure Virtual Machines, Azure SQL Database, Azure Files, and blob storage. Azure Site Recovery gives 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 leaves a specific artifact: a backup job report, a recovery point, a test failover report. Those are what a supervisor examines.
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.
