Data Residency & Sovereignty

## The two duties are not one duty **Data residency** is a claim about *place*. It says that the records — and, read strictly, every copy of them — are stored and usually processed on hardware standing inside a named geography: a country, a bloc of countries, occasionally one named site. It is settled by a placement decision, and it is audited by walking an inventory and asking of each copy: which jurisdiction is that machine in? **Data sovereignty** is a claim about *law and reach*. It says the data is subject to the law of that jurisdiction and is **not** reachable under another one. Placement alone does not settle it, because the company operating the hardware may be incorporated elsewhere, may employ administrators elsewhere, and may hold a key that decrypts what it stores. A record can sit on a disk inside the jurisdiction and still be reachable by a lawful order served on a parent company abroad, or readable by a support engineer on another continent. | | Data residency | Data sovereignty | |---|---|---| | **Question it answers** | where do the bytes sit | whose law and whose staff can reach them | | **Settled by** | the placement of every copy | placement, plus control of access and of the key | | **Broken by** | one copy landing outside | a foreign order, or an operator abroad who can read it | | **Evidence produced** | an inventory of copies and locations | that inventory, plus key custody and access records | ## What "every copy" includes The common failure is not choosing the wrong region. It is choosing the right region and then forgetting what the platform copies on your behalf. A residency inventory has more rows than teams expect: - the primary store itself; - a **standby replica**, which may sit in another zone of the same region or in a different region entirely, depending on what you enabled; - **backup copies**, including every generation still inside its retention, and wherever that retention keeps them; - **exported telemetry** — log lines, traces and metric labels sent to one aggregation point, which is frequently a single global one; - **support material**: a diagnostic bundle attached to a case, or a session in which someone elsewhere can see the data on screen; - what the **management plane** holds about the resource: its name, its tags, its configuration and size, which travel even when the stored records do not. Each of those rows is a residency question in its own right, and each of them is answerable. A row you cannot map to a jurisdiction is the finding. ## Why sovereignty does not follow from residency Three reaches survive a correct placement, and they are the reason the second word exists: 1. **Corporate control.** The entity operating the region is usually part of a group incorporated somewhere. An order served on the group may compel production of data held by a subsidiary, regardless of which country the disk is in. 2. **Operator access.** Managed tiers exist because someone else operates the service. That operating is done by people, and those people are not necessarily inside the jurisdiction. Remote administrative access is a border crossing that leaves no copy behind. 3. **Key custody.** Encryption at rest is applied by default on most platforms, but the interesting question is who can *use* the key. If the operator can decrypt on request, the cipher does not change who can be compelled. That is why sovereignty arguments always land on keys and on people, and why a contract that says only "hosted in country X" is usually not a sovereignty commitment at all. ## Where providers genuinely differ Designs vary, and it is fair to say so without assuming one shape. Some providers operate an in-jurisdiction footprint through a locally incorporated entity with locally resident staff and contractual limits on who may access customer environments; others operate every region from one global operations organisation. Some replicate a backup outward by default and let you turn it off; others keep it inside one region unless you ask. Some let you hold a key the platform cannot use without a live call you can revoke; others hold the key for you. The mechanism is the same everywhere; the defaults and the contractual posture are not, so the honest answer in an interview is "it depends on the platform's default, and here is what I would check". ## What a reviewer actually asks for Not a statement that the correct region was selected. Three artefacts: the **inventory** of copies with a jurisdiction against each row; the **key custody** answer, meaning who can cause a decryption and under whose law; and the **access record**, meaning who outside the jurisdiction has looked at this data and under what approval. Residency is the first of those. Sovereignty is the other two.