Where Do Your Backups Live? The Question Nobody Asked

On 18 October 2007, a junior official at HM Revenue and Customs in Tyne and Wear posted two CDs to the National Audit Office in London through an internal courier service. The discs held child benefit records for around 7.25 million families — roughly 25 million individuals, including names, addresses, dates of birth, National Insurance numbers and bank details. They were password-protected and not encrypted. They never arrived. The loss was reported internally on 8 November and disclosed to Parliament by the Chancellor on 20 November. The discs were never found. What made the incident instructive was not the courier failure. It was that nobody in the organization could readily answer a simpler question: where else does this data exist, and who is accountable for each copy? Two decades later, most organizations still cannot answer that question about their backups.

The Copy Everyone Forgets

Organizations govern their production systems reasonably well. Access is controlled, the hosting location is documented, the vendor is contracted, and someone senior owns the risk. Then there are the copies:

• Nightly backups, held for thirty days, ninety days, or "we think forever."
• Disaster recovery replicas in a second data centre, frequently in a different country.
• Database snapshots taken before an upgrade and never deleted.
• Log and monitoring data aggregated into a platform with its own regional storage.
• Test environments refreshed from production, complete with real customer records.
• SaaS vendor backups, held under the vendor's policy in the vendor's chosen regions.
• A former administrator's export, sitting in personal cloud storage. Every one of these is a full-fidelity copy of personal data. Each sits somewhere, under some jurisdiction, accessible to some set of people. Almost none appear in the records of processing activities that the same organization presents to regulators and enterprise customers.

Why Backup Jurisdiction Is a Real Legal Question

The residency rules that apply to your live data apply to every copy of it. Regulators have shown no interest in the distinction between a primary database and a replica. That creates four specific exposures. Cross-border transfer. A disaster recovery site in another country is a transfer, requiring the same legal basis, assessment and documentation as any other. Companies that carefully restricted production to an in-country region have repeatedly discovered that replication was configured to a default region on another continent. Foreign disclosure orders. Data stored by a provider subject to another country's compulsory disclosure laws can be reachable by that country's authorities regardless of where your headquarters sits. Whether that provider holds usable keys determines whether the order produces readable data. Localisation mandates. Several GCC, Asian and Latin American regimes require specific categories of data — health, financial, government-related — to remain physically in-country. Backups are rarely carved out of those requirements, and are frequently the first thing to violate them. Deletion obligations. This is the one that catches careful organizations. You honour an erasure request in production; the record persists in thirty days of backups, in a DR replica, and in a snapshot from last quarter. Most supervisory authorities accept that immediate deletion from backup media is impractical, provided you can show a documented, time-bound cycle after which the data genuinely disappears and a control preventing restoration of erased records. "It will age out eventually" is not that documentation.

The Recovery Test Nobody Runs Properly

The operational failure sits beside the legal one. Backups exist to be restored, and restoration is tested far less often than it is assumed. The questions that separate a working DR position from a documented one:

• When did you last restore a full production system — not a file, the system — and how long did it take?
• Does your measured recovery time meet the recovery time objective in your policy? By how much does it miss?
• If your primary cloud region became unavailable, could you restore in another region, and is your data already there?
• Are your backups immutable, or could ransomware encrypt them along with production? This is now the single most consequential backup design decision.
• Who holds the encryption keys for your backups, and where are those keys stored?
• If your SaaS vendor lost your data tomorrow, what is your independent copy, and have you tested it? That last question catches more mid-sized organizations than any other. Many assume the shared responsibility model gives them vendor-managed backup with customer-grade recovery rights. Often it gives them platform resilience — protection against the vendor's infrastructure failing — and little protection against a bulk deletion performed with valid credentials.

What a Backup Residency Position Looks Like

• Inventory every copy. Production, DR, backup, archive, logs, analytics, test environments, and every vendor holding data on your behalf.
• Record the country for each — actual storage location, not the vendor's headquarters or your contracting entity.
• Map each location to a legal basis, and note which government could compel access.
• Hold your own keys wherever the sensitivity justifies it, and store them under separate control from the data.
• Document the deletion cycle for backups, with a stated maximum period and a restoration control that re-applies erasures.
• Make backups immutable and hold at least one copy isolated from production credentials.
• Test restoration on a schedule and record the actual elapsed time, not the theoretical one.
• Review after every migration. Region defaults change, vendors add sub-processors, and replication settings get adjusted during incidents and never reverted. HMRC's discs were lost because a routine process moved a complete copy of sensitive data without anyone senior knowing it was happening. Backups do exactly the same thing, automatically, every night. The difference is that nobody notices, because nothing goes missing.

Common Questions

Do data residency rules apply to backups?

Yes. Backups, replicas and archives are copies of the same personal data and attract the same transfer, localisation and security obligations as production systems.

How do you handle an erasure request when data is in backups?

Delete from production immediately, document a defined backup retention cycle after which the data expires, and implement a control that prevents erased records from being reinstated if a restore occurs. Be able to evidence all three.

Is disaster recovery in another country a cross-border transfer?

In most regimes, yes. A DR site abroad requires the same legal basis and assessment as any other international transfer, and is one of the most commonly undocumented flows in an organization.

What is the most common backup mistake?

Assuming backups work. The second most common is leaving them reachable with production credentials, which is why ransomware operators target them first.

---

Backup Residency Review — Outpace inventories every copy of your data across backups, replicas, archives and vendor environments, documents the jurisdiction and legal basis for each, and tests whether your recovery position matches what your policy claims.