Unified Backup Strategy: Why Immutability Is the Cheap Part

Across the postmortems I have collected over the years, one pattern shows up again and again: the backups existed, the dashboards were green, and the data we pulled back was already encrypted. The same shape, different companies. Snapshots present, retention honored, restore "successful," and the restored bytes carrying the attacker's payload because the breach predated the recovery point we trusted. I logged enough of these to stop treating "the backup ran" as a signal of anything. The Motability Operations rebuild on AWS is interesting to me precisely because it answers the question every one of those postmortems exposed: can you prove the copy you restore is clean before you mount it.

Motability Operations runs the UK's Motability Scheme for roughly 900,000 disabled customers. As their AWS footprint grew across multiple accounts and multiple AWS Organizations, they could not guarantee recovery from a verified, untampered state during a cyberattack. Their existing setup had no way to isolate recovery points from production, no consistent policy across managed and customer-managed accounts, and no clean answer for Financial Conduct Authority auditors.

So they rebuilt the whole thing on AWS Backup. The interesting part of their story is not that they chose immutability. It is the order they did things in, and that order is the argument I want to make here.

The reflex when people read "ransomware-resilient backup" is to fixate on the lock: Vault Lock, compliance mode, write-once-read-many, done. I think that reflex is backwards. Immutability is the cheapest, most mechanical step in a unified backup strategy. The expensive, load-bearing work is isolation and proof of recovery. Get those wrong and a locked vault just guarantees you keep a pristine copy of data you can never trust.

A Locked Vault Without Isolation Is a Locked Box of Maybe

Compliance mode on an AWS Backup vault does exactly one thing well: it stops deletion. Once the grace period closes, no one, including root, including AWS itself, can shorten retention or remove a recovery point inside its window. That is real and worth having. But deletion resistance answers only half the threat. The other half is whether the bytes inside the vault are clean, and a lock says nothing about that.

This is why Motability's two-tiered design matters more than the lock that sits on top of it. Tier 1 lives in each workload account: AWS-managed keys, governance mode, fast operational restores that the team can manage with normal IAM privileges. Tier 2 lives in a separate central backup account as a logically air-gapped vault, locked in compliance mode, with customer-managed keys at one CMK per platform. Workload backups are copied up into Tier 2; a breach in a workload account cannot reach across to alter or delete the central copy because the account boundary plus the lock removes the path. The separation, not the cryptography, is what survives a full account compromise.

The blast-radius math is what sells it. In a flat design, one stolen admin credential reaches every recovery point. In this design, the same credential reaches Tier 1 and stops at the account wall. That is the difference between a bad week and an unrecoverable quarter.

There is a real cost to this rigidity, and I would rather name it than pretend it away. Compliance mode means you cannot shorten retention to save money once the lock takes effect, and you cannot quietly delete a misconfigured plan. If you seal a Tier 2 vault with the wrong retention or a botched key policy, you live with it for the full window. That is the deliberate trade: you give up operational flexibility in Tier 2 precisely so an attacker gives up theirs too.

Five Accounts Exist So a Breach Cannot Travel

Motability's architecture splits the work across five account types. The split is a containment design, and reading it as bureaucratic tidiness misses the point entirely.

The delegated management account defines backup policy centrally and hosts the dashboard that shows job health across the estate. Workload accounts hold Tier 1 vaults for quick restores. The central backup account holds the air-gapped Tier 2 vaults. A separate forensic account verifies integrity, with the Tier 2 vault shared to it over AWS Resource Access Manager. And a recovery account is stood up on demand during an incident, where the last clean backup is restored within the team's recovery-time objectives.

The point of five boundaries is least privilege with no overlap. Workload teams reach only their own workload and recovery accounts. Backup administrators alone touch the central account. The forensic account reads copies but cannot write production. So a credential stolen anywhere in this topology unlocks one room and gets stuck at the door. I built the flat version of this once, where the backup role had reach into everything "for convenience," and convenience is exactly the word an attacker uses too.

One operational edge worth flagging from the broader AWS Backup behavior: backups run one concurrent job per resource, and additional requests queue. During a mass-recovery event that queuing is real friction, and it argues for testing failover under load rather than assuming the architecture diagram scales linearly.

Verified Recovery Is the Metric, Not Recovery Time

Here is where I will plant my flag against a lot of the disaster-recovery orthodoxy I grew up on. For most of my career the headline number was RTO: how fast can you bring it back. Speed still matters, but speed restoring the wrong data is worse than slowness, because it reinfects the environment you just rebuilt. The metric that actually protects you is whether you can prove a given recovery point is clean before you mount it.

Motability wires this in as an event-driven loop. When a backup copy lands in the central account, EventBridge triggers AWS Backup restore testing into the forensic account, and Elastio, an APN partner, analyzes the restored data for tampering and ransomware artifacts. CloudWatch carries the monitoring and retry logging. The output is not "the file exists." It is "this recovery point restored and passed inspection," which is the only assurance worth carrying into an incident.

This reflects a genuine 2026 shift in how the field talks about recovery: from raw speed toward verified outcomes, where a successful restore test counts for more than a low RTO on a slide. I would push it further. A recovery point you have not test-restored is an untested assumption, and untested assumptions are where 100-day recovery cycles come from. The work to validate is not free, computationally or operationally, but the alternative is discovering your assumption was wrong during the incident itself.

If you want a way to interrogate your own backup story, run it through this table. Each row is something to check, what a passing answer looks like, and why a wrong answer changes the call.

Tag-Based Policy Has One Failure Mode You Must Engineer Around

The piece that makes a unified strategy scale is tag-based enforcement: the delegated account pushes backup plans across the organization, and any resource carrying the mandatory tags inherits protection automatically. No per-account hand-configuration, no drift between teams. This is the right pattern, and Motability credits it with cutting the manual effort of onboarding new workloads.

But automation by tag has a quiet hole, and pretending otherwise is how teams get burned. An untagged resource is an unprotected resource. It sits outside the policy and outside the audit scope until something notices it, which during fast deployment can be never. The fix is to treat the tag as a hard deployment gate rather than post-provisioning cleanup. Enforce it where infrastructure is defined, reject untagged resources at creation through service control policies, and make "no backup tag" fail the build the same way a missing required field would. The compliance dashboard is then telling you the truth, because there is nothing silently outside it.