Most organisations that spent this year on data protection can now tell you where their production systems live. Almost none can tell you where the copies live, which means backup residency compliance is the gap left behind by an otherwise diligent year of work. The asymmetry is not carelessness. Production location is a decision somebody made, minuted and paid for. Secondary copies are a by-product of settings, defaults, contracts and habits accumulated over a decade, and the people who configured them were solving for recovery rather than for jurisdiction.
Seven copies, and you probably inventoried one
A typical mid-sized estate holds personal data in considerably more places than its system list suggests. Backups, on disk, in an appliance, or in object storage, with a retention chain running weekly, monthly and yearly. Replicas and disaster recovery copies, continuously updated, frequently in a different country because distance is the point of having them. Snapshots, taken by the virtualisation or cloud platform, retained on a schedule nobody reviews, containing whole systems as they were on a given morning. Archives, including email journals, records kept for statutory periods and data moved off the primary platform to reduce licence cost. Logs and telemetry, which contain more personal data than anybody expects: usernames, addresses, identifiers, query parameters and sometimes payloads. These are often shipped to a monitoring service in another jurisdiction by default. Non-production refreshes, where a copy of production sits in test with weaker controls and a wider audience. Third party service backups, including the increasingly common practice of backing up a cloud collaboration or CRM platform into an independent provider, which creates a second copy under a second contract in a third country. Each of these is a processing activity, each has a location, and each should appear in the record of processing activities that was built this year. In most organisations the record covers the first item, describes it as offsite, and stops.
| Copy category | What to trace |
|---|---|
| Backups | Storage location and retention chain |
| Replicas and disaster recovery | Secondary destination and recovery use |
| Snapshots | Platform schedule and retained system state |
| Archives | Record owner, retention and retrieval |
| Logs and telemetry | Destination and identifying payloads |
| Non-production refreshes | Test access and production-data handling |
| Third-party service backups | Provider storage, access and contract |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Where the surprises actually are
The cloud storage default is the most common finding. Geographically redundant storage tiers replicate data to a paired location for durability, and in several cases that pairing crosses a national border. An organisation that carefully chose a European or regional primary region can find its backup tier replicating somewhere it never selected, because the redundancy option was chosen on price and resilience and the pairing is set by the provider. The second is monitoring and telemetry. Application logs routed to a hosted observability platform, crash reports, performance traces and error aggregation are usually configured by engineers with no transfer analysis attached, and they often contain identifiers that make the data personal. The third is the archive that was never decommissioned. Old mail archives, a retired system's database kept in case finance needs it, a decade of scanned documents on a share. These are the copies with the longest retention, the weakest access control and the least clarity about who owns them. The fourth is the backup taken by somebody else on your behalf, where the copy sits in the service provider's own storage rather than yours, under their retention policy, with their staff able to read it.
Two obligations pulling in opposite directions
The new European regime makes this genuinely awkward rather than merely untidy. On one side, security of processing is explicitly framed to include the ability to restore availability and access to personal data in a timely manner, and regular testing of the effectiveness of measures. That is a legal requirement to have working, tested backups, which is a rare instance of a regulation mandating something operations teams already wanted. On the other side, erasure rights, storage limitation and transfer rules all apply to copies. An individual asks for deletion, the record is removed from the live system, and it remains in eleven weekly backups, twelve monthly ones and a yearly set going back seven years. The workable position, and the one most practitioners have landed on this year, is not to purge backups. It is to define and document a bounded backup retention period, to record the fact that erased records persist in backups until they age out, to ensure that a restore does not silently resurrect deleted data by re-applying deletions after recovery, and to restrict backup access so that the copies are not used as a convenient search index. What matters is that this is a written, defensible position rather than an unexamined one. Authoritative guidance on the point is thin, which is precisely why the reasoning needs to be on paper before anyone asks. The recent hospitality disclosure is worth holding in mind here. The data that caused the damage lived in a legacy environment that was scheduled to be switched off. Secondary and end-of-life copies are not a lesser category of risk; they are frequently the whole of it.
Practical Guidance for a Backup Residency Audit
- Inventory copies, not systems. For each production system holding personal data, list every secondary copy, where it physically sits, who can read it, how long it is kept and under whose contract.
- Check the redundancy setting on every storage tier. Geographically redundant options may replicate across a border. This is a five-minute check per account that produces the most frequent finding in this exercise.
- Follow the logs. Monitoring, crash reporting, performance tracing and error aggregation destinations, and whether the payloads contain identifiers. Treat this as a transfer question, because it is one.
- Bound your retention and say so. An explicit backup retention period, applied consistently, is the foundation of every defensible answer about erasure and copies. Indefinite retention is a decision nobody made.
- Write down the erasure position. How deletion requests interact with backups, how restores avoid resurrecting deleted records, and why the approach is proportionate. One page, approved, kept current.
- Establish who holds the keys for backup encryption. Encryption at rest in a backup is only a control if the key custody is yours or contractually constrained, and a provider-managed key does not help with jurisdiction.
- Segregate by entity where entity rules differ. Groups with free-zone, mainland and offshore entities under different regimes frequently back all of them into one repository, which imports the strictest rule into everything or breaches it for one.
- Test a restore and time it. Then keep the evidence. It is the cheapest available demonstration that your security measures actually work, and the single most common thing organisations claim without having tried.
The Regional Angle
The secondary copy is often the only cross-border transfer in an otherwise local estate, and in this region it is usually unavoidable. There is still no live hyperscale cloud region in the GCC. Microsoft has announced UAE data centres and Amazon has announced Bahrain, and neither is open, so organisations wanting a genuine geographic separation between primary and recovery sites today are choosing between a second local facility a short distance away, which does not protect against a regional event, and a site in Europe, India or Singapore, which does and which moves the data out of the country. Most have chosen the second and documented it as an infrastructure decision rather than a transfer. Entity structure makes this materially worse here than elsewhere. A single group commonly runs mainland companies, free-zone companies and a financial free-zone entity in the DIFC or ADGM, with different data protection regimes applying to each, and then backs the whole estate into one repository at the group data centre or with its integrator. The regulated entity's data is now in a repository whose location and access controls were never assessed against its rules. Per-entity segregation at the backup layer is rare, cheap to design at the outset, and expensive to introduce afterwards. Sector regulators add a second layer that the residency conversation usually misses. Banks, insurers and healthcare providers here operate under outsourcing and hosting conditions that require notification or approval for material arrangements. A backup or recovery service hosted abroad is material outsourcing by any sensible reading, and it is one of the arrangements least likely to have been notified, because it was procured as infrastructure by a technical team rather than as an outsourcing by a compliance function. This is also the first year in which the archive question has a concrete local answer. Value added tax arrived in the UAE and Saudi Arabia in January with defined record retention requirements, so organisations now have statutory periods to meet and, more importantly, an obligation to produce records on demand. An archive nobody can search is not compliant with a production requirement even if the data is technically retained, and a good number of regional finance teams are about to discover the difference between keeping something and being able to find it. Finally, physical media still matters more here than the cloud-first discussion assumes. Tape rotation to a vaulting service, disk shipments between group sites and couriered media during migrations are all real, and each is a transfer with a custody chain, an encryption question and a plausible loss scenario that would meet the definition of a notifiable breach.
The objection worth taking seriously
The objection is proportionality. Nobody has been penalised over the location of a backup. Auditors ask whether backups exist and whether restores have been tested, not which country the replica sits in. Re-architecting disaster recovery to satisfy a residency reading that no regulator has yet enforced costs real money and delivers nothing a customer can see. The harder version is a resilience argument, and it is the strongest point in this whole discussion. The single most effective thing you can do to protect data is keep a copy a long way away, ideally under different failure conditions and different administrative control. Residency purism attacks exactly that. A rule requiring all copies to remain in one country increases correlated failure risk, concentrates the estate in the same power, network and political conditions, and in a region with limited independent facilities may mean the primary and the recovery copy share more than anyone admits. Trading availability for jurisdiction is a real trade, and it is not obviously the right way round. That argument should be made, in writing, to whoever is imposing the constraint. What it does not support is the status quo, because the status quo is not a considered trade-off. It is a set of defaults. The recommendation here is not to repatriate the copies; it is to know where they are, to have chosen it, to have encrypted them with keys you control, and to have a written justification ready. An organisation that can say "our recovery copy is in Frankfurt, encrypted with keys held in Dubai, here is the assessment and here is the restore test from last quarter" is in a strong position. An organisation that has to go and look is not, regardless of where the copy turns out to be.
Common Questions
Do we have to delete data from backups when someone requests erasure?
The prevailing practitioner view is no, provided backup retention is bounded and documented, restores do not reintroduce erased records, and backups are not used as a general search or reporting source. Guidance is still thin, so the defensibility comes from having reasoned and recorded the position rather than from a settled rule.
Is an encrypted offsite backup still a cross-border transfer?
Yes. Encryption is a security measure, not an exemption, and the data is still being sent and stored elsewhere. It does substantially change the risk picture, and where you hold the keys it strengthens the case considerably, but the transfer still needs to appear in your records with a basis.
What about backups of cloud services we do not run?
They are yours to account for. Independent backup of a collaboration platform or CRM creates a second copy under a second contract, usually in a different location from the primary service, and it is one of the fastest growing blind spots in this area because it is bought as insurance rather than as processing.
What should we expect over the next twelve months?
Expect the first substantive regulatory guidance on how erasure interacts with backups, because supervisory authorities are receiving the question repeatedly and organisations cannot resolve it alone. Expect regional hyperscale capacity to open during the year, which will for the first time allow in-region recovery sites and will remove the least comfortable transfer in many regional estates. Expect backup vendors to compete on residency controls and immutable storage, the latter driven by ransomware that now deletes backups before encrypting anything. And expect the question "where are your secondary copies" to start appearing in customer security schedules, which is how most organisations will find out that they do not know.
Backup Residency Audit — we inventory every secondary copy rather than every system, find the replication settings and log destinations nobody chose, and leave you with a written position on erasure and copies before a customer asks for one.