A sovereignty review typically establishes where the primary system sits, which staff can reach it, and under whose law the operator falls. It then stops. The same data exists in backup copies, secondary copies, an archive tier, a replica at a recovery site and a catalog that may be hosted by the backup vendor, and each of those has its own physical location and its own controlling entity.
The asymmetry is easy to explain. The primary system was designed, and the design was reviewed. The copies accumulated, one policy at a time, each addressing a durability or cost problem that had nothing to do with jurisdiction. A cloud tier was added because capacity was cheaper there. A second copy was sent offsite because an auditor asked for offsite. A vendor-hosted console arrived with a software upgrade.
The result is a data estate whose sovereignty posture is set by its weakest copy, not by its primary. An organization that can describe its production boundary precisely and cannot say which legal entity holds its oldest archive copy does not have a sovereignty position, it has a sovereignty position for one system.
Backup architectures grow by accretion. A daily copy lands on a local target. A weekly copy is written to a second target for isolation. A monthly copy is pushed to an object tier for retention economics. A replica is maintained at a recovery site. Long-retention data is moved to an archive class when it stops being restored frequently. Each step is justified on its own terms and none of them were framed as a location decision.
Tiering is the most common source of surprise, because it is automatic. A lifecycle or tiering rule moves data from a target the organization chose deliberately to a class whose underlying region was set by a default, and the movement is continuous rather than a single event that someone approved. The rule was written to control cost and quietly became a placement policy.
Seeding and migration leave residue as well. Data shipped on physical media to bootstrap a cloud repository passes through a logistics chain and an import facility. Test restores write real data into staging environments that are rarely inventoried. Neither is a permanent copy in intent, but both create plaintext in places the copy inventory does not mention.
The backup catalog is the first. It holds file names, paths, object keys, host names, user identifiers, retention state and the map of what exists where. It is not the data, but it is a precise description of the data, and in several regulatory readings that is itself regulated content. Where the catalog lives matters more when the backup product offers a hosted control plane, since the catalog then sits with the vendor by default. Protecting the catalog is usually discussed as a recovery problem, and it is equally a residency problem.
The second is the immutability or object lock ledger, along with any key material protecting the copies. A copy stored inside a national border but encrypted with a key held by a foreign key service is only as local as that key, which is why who holds and can be compelled to produce the keys should be answered per copy rather than once for the estate.
The third is the disaster recovery replica, which is often placed by availability logic. Recovery sites are selected for distance from the primary, correlated failure being the concern, and distance frequently means a different jurisdiction. A recovery site that avoids shared failure can still introduce a boundary crossing nobody recorded.
| Copy | Who usually controls its location | What to check per copy |
|---|---|---|
| Primary backup target | The customer, explicitly | Facility, operator and whether any tiering rule can move data off it |
| Cloud or archive tier | A lifecycle rule plus a provider default region | Resolved region, storage class and the replication policy of that class |
| Backup catalog or metadata | The backup software vendor, if the control plane is hosted | Hosting location, retention and whether an on-premises option exists |
| Disaster recovery replica | An availability decision made on distance | Jurisdiction of the recovery site and who operates it |
| Test and staging restores | Nobody, in practice | Whether real data is written and how long it persists |
Every copy reduces to two questions. Where is it physically, expressed as a facility or a named region rather than a service name. Which legal entity can be compelled to produce or disclose it, expressed as a company and a jurisdiction rather than a product brand. A service marketed as regional answers the first and leaves the second open if the operator's parent is incorporated elsewhere.
The second question is the one that most often has an uncomfortable answer, because it follows the corporate structure rather than the network diagram. Support subsidiaries, subcontracted operations staff and parent-company obligations all bear on it. Resolving it requires reading the contract rather than the console.
A useful discipline is to record the answers as a pair for every copy, and to treat an unanswered second question as a finding rather than an outstanding administrative task. A copy whose controlling entity is unknown should be assumed to fall outside the boundary until shown otherwise.
ARTESCA is object storage software used as a backup target, sized from roughly 50 TB to 8.5 PB, deployed on infrastructure the customer runs. For a copy inventory that means the location entry is a facility the organization can name and the controlling entity is the organization itself, rather than a region identifier resolved by a provider and an operator whose corporate structure has to be traced.
Immutability is provided through S3 Object Lock, so retention on a copy is enforced by the storage layer inside that same boundary rather than by a policy engine operated elsewhere. ARTESCA is commonly deployed as a target for Veeam and other backup software, which leaves the catalog and the copy under the same operator when the backup software is also run locally, and makes the hosted-control-plane question an explicit choice rather than a default.
Larger estates that need the same property at exabyte scale, across multiple sites under operator-defined placement, are the case RING addresses. The sovereignty reasoning for a copy is identical in both.
Start from the backup software rather than from the storage. Enumerate every job, every repository, every tier target and every replication relationship, then resolve each repository to a physical location and a legal entity. Include the catalog, the reporting or monitoring service, and any long-term retention target that is no longer written to but still holds data. The inventory is finished when every row has a facility, an operator, a jurisdiction, a key holder and a retention end date.
Re-derive the inventory quarterly and after any change to a lifecycle or tiering rule, since those rules alter placement without producing a change record anyone reviews. Treat the addition of a new repository as a configuration change requiring the same approval as a firewall rule. The same reasoning applies whenever replication crosses a border, since replication and backup differ in mechanism but not in what they imply about where data ends up.
Finally, test the inventory by restoring from the oldest copy that exists. It is the copy most likely to sit somewhere nobody chose.