DORA Article 12 on Azure: Backup, Restoration, and Recovery Evidence

Nobody has ever asked me whether a client had backups.

They ask for the restore test report. Every time.

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 toolbox is short: Azure Backup for data, Azure Site Recovery for workload failover, geo-redundant storage for regional resilience, and a quarterly test failover that produces the paperwork.

Here is the position I will defend for the rest of this piece. An untested Azure backup satisfies zero of Article 12. Not most of it. Not the technical half of it.

Zero.

A backup you have never restored is a hypothesis wearing a green checkmark. Article 12 is where DORA stops accepting policy and starts wanting proof.

Three obligations, not one

Institutions keep collapsing Article 12 into a single word. Backup. It is three words, and they fail in three different places.

Backup is copying data so it survives loss. Restoration is bringing that data back into a usable state. Recovery is returning the business function to operation. A successful backup proves nothing about restoration. A successful restoration proves nothing about recovery, because the workload around the data also has to come back, in the right order, with its dependencies. Article 12(4) mandates testing precisely because those three break independently of each other.

The specifics. Article 12(1) covers the policy: scope and frequency of backups, plus the 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. If your backups share a region, a subscription and a fate with production, you have a second copy, not a separation. Geo-redundant storage and a vault sitting outside the production blast radius are how you answer 12(2).

Go and check where your Recovery Services vault actually lives. I’ll wait.

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, and pretending they do means one of them is over-engineered and the other is lying. 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 and no more than thirty seconds of data loss. Or the exact 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

Those bands are illustrative. They are the shape of the artifact, not your numbers. If the table you produce looks exactly like mine, one of us has skipped the criticality assessment, and it isn’t me.

The mechanisms are real enough. 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 what Article 12(1) is asking for.

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 through 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 you are holding 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 the failover. Its evidence is the replication health status, which shows whether the RPO is being met, and the test failover report. You can run a test failover into an isolated network without touching production. That test produces a report.

The report is the proof.

Geo-redundant storage (GRS or 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 12(2). Its 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. The dashboard still reads green, because it only counts what the policy already knows about. That silent gap is exactly what a supervisor finds. See Azure configuration drift for why deployed state and documented state pull apart over time.

Restores do not fail on the data

Here is the part that surprises people, and it is the same every time.

The restore works. The data comes back. And the workload still will not serve traffic.

Because between the environment as it was documented and the environment as it was actually running, there is a set of small changes somebody made to make it work. A connection string pointed somewhere else. A firewall rule widened during an incident. A permission granted to get a deployment through on a Friday. Each one correct at the time, each one load-bearing, none of them written down.

A restore faithfully reproduces the documented thing. The gap is everything that was never documented.

So the failure is not “we lost the data.” It is four hours of engineers rediscovering, under pressure, which undocumented change the workload needs before it will come up. And it is always the connections, the databases and the storage, in roughly that order, because those are the components that carry environment-specific configuration.

Which means your stated RTO is not a property of Azure Backup. It is a property of how far your documentation has drifted from your deployment. Nobody has ever put that in a recovery policy, and it is the number that decides whether you meet the objective.

That is also why the test is the only thing that tells you the truth. Nobody assumes their backups are broken. They assume the restore lands somewhere production-ready, and that assumption is untested right up until the morning it matters.

How often, and what the regulation actually says

“But our backup dashboard is green across the board. We’re fine, right?”

You are fine on one of the three obligations, and it’s the easy one. Green means copies were made. It says nothing about whether anything ever came back.

Now the frequency question, carefully, because there is a lot of confident nonsense about it.

Article 12(4) requires periodic testing and names no frequency at all. What DORA does write down is elsewhere: Article 11(6) requires ICT business continuity and response-and-recovery plans to be tested at least yearly, and on any substantive change to systems supporting critical or important functions. Article 24(6) requires appropriate testing at least yearly of all ICT systems and applications supporting critical or important functions. Annual is the floor the text gives you.

Quarterly is my recommendation, not a regulatory requirement and not a supervisory expectation I can point you at. The argument for it is drift: if the gap between documented and deployed is what breaks your restore, then the interval between tests is the interval in which that gap grows unobserved. Twelve months is a long time for a connection string to move.

Pick your cadence deliberately, write the reasoning into the backup policy, and make it proportionate to criticality. A documented, argued quarterly beats an undocumented quarterly, and both beat an annual test nobody justified.

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 does its job, you tear it down. Azure Site Recovery records the test, its duration (your measured RTO against your stated target) and the outcome. That record is the evidence that recovery worked.

Not that it should have. 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, and the records are the point.

A supervisor examining Article 12 asks for three things, in this order. The per-workload RTO/RPO table. The backup job reports showing the policy actually runs. The most recent test failover report showing recovery was tested and hit its target. Produce all three inside an hour and you have Article 12 evidence. Produce backups and no test report and you have a hypothesis with good graphic design.

I have been the person in that room asking for the dated report while everyone else admires the dashboard. It is not a personality that gets invited back for drinks. For the risk framework these recovery controls sit inside, see DORA Article 11 and Azure architecture.

The finding that made me build a tool

The same gap kept turning up. Not missing backups, which are easy to spot and easy to fix, but critical workloads sitting silently outside the backup policy while the coverage number read 100% for everything the policy already knew about. Counting your own known-knowns is not coverage. So I built Platform Architecture Authority to read the estate directly and tell me which workloads have Azure Backup, which have Site Recovery replication, which storage accounts are geo-redundant, and which critical resources have none of the above. It is read-only. It will not run your test failover for you, and it has no opinion about your recovery sequencing, which remains a platform lead’s job.

Frequently asked questions

Does DORA Article 12 specify how often we must test recovery? No. Article 12(4) requires periodic testing and names no frequency. The nearest written floors sit elsewhere in DORA: Article 11(6) requires ICT business continuity and response-and-recovery plans to be tested at least yearly and on substantive change, and Article 24(6) requires appropriate testing at least yearly of all ICT systems supporting critical or important functions. Quarterly is a common practice choice above that floor rather than a regulatory or supervisory requirement. What matters is that the frequency is proportionate to criticality and that the reasoning is written into the backup policy.

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 the 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.
• Article 12(4) sets no frequency. DORA’s written floor is annual, in Articles 11(6) and 24(6). Quarterly is a defensible choice above it, and the choice belongs in the policy with its reasoning.
• Restores rarely fail on the data. They fail on the undocumented changes between the environment as designed and the environment as deployed, and that gap is what your real RTO measures.
• 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, and it is indifferent to the one that merely configures. The backup is the easy part. You already have that part.

The dated, successful restore report is the part that survives examination.