A compliance lead is asked to sign off on a tool, and nobody in the room can say where the data would sit. That gap is not a formality. It is a decision the tool has already made on your behalf, and it is easier to correct before the contract than after.
Residency Is a Decision, Not a Setting
Data residency is the answer to where each record lives, who can read it, and what leaves your control. Settle it before a tool is chosen, not after.
Teams can name their tools more easily than they can name the regions those tools use. The answer to a simple question about location can arrive by accident: a default chosen during setup, a hosting choice made by the vendor, or a call from someone who has since left the team. Nobody wrote it down because nobody was asked.
The question turns urgent at a specific moment. A customer sends a due diligence form and wants to know which records left the country. The team needs to explain where a piece of evidence was stored last quarter. A new jurisdiction applies to a piece of work, and the tool cannot say where the copy went. At that point a team is rebuilding a decision it did not make on purpose.
Treat residency as one decision with three parts. Where the durable record rests. Who can read it, including any party that operates the service. What leaves your control when someone works on it. A tool can be strong on the first part and silent on the third, which is why a single yes or no is a poor answer.
Separate the Record From the Processing
Storage and processing are different questions with different answers. A record can sit in one place while content drawn from it is processed somewhere else.
The storage question is about the copy that persists. Backups, exports, and the primary store all count. The processing question is about what happens while the work is live: what a person reads, what a tool assembles, and what a model is given.
A team that answers only storage feels finished and is not. The durable copy can sit exactly where the policy says, and the same record's content can still be sent to a model that runs in another region, under a different contract, with a different retention rule. Both facts can be true at the same time.
Ask both questions of the same record, and write both answers down. A placement note that covers storage alone will read as complete and leave the harder half unexamined.
| Layer | What It Covers | A Question Worth Asking |
|---|---|---|
| Storage | The durable copy, backups, and exports | Where does this record rest when nobody is working on it |
| Access | Who can open or copy it | Which parties, inside or outside the team, can read it |
| Processing | What happens while work is done | What content leaves, and where it is sent |
| Retention | How long each copy survives | What is removed at contract end, and what is kept |
The Questions That Decide Placement
Placement follows a short set of questions asked per record type: what the record is, who needs to read it, which rules touch it, and what work is done on it.
Ask them for each type of record rather than once for the whole tool. The answers will differ, and that difference is the part worth planning around. A blanket answer that covers everything can be wrong in several places at once.
The rules that touch a record matter as much as the record itself. Different privacy, sector, or customer expectations about the same item can lead to different handling, and one blanket placement answers neither.
| Question | Why It Decides Placement | What a Weak Answer Costs |
|---|---|---|
| What the record is | A policy draft, an approval, and a model prompt carry different weight | A sensitive record lands beside a routine one |
| Who needs to read it | Readers may sit in a different region from the record | Access turns into movement nobody planned |
| Which rules touch it | Rules attach to content and to people | One answer is wrong in several places |
| What work is done on it | Processing can move content across a boundary | Storage looks clean while processing does not |
| How long it is kept | Retention sets how long the exposure lasts | Copies outlive the reason they were made |
| What happens at the end | Contract end decides whether leaving is practical | Removal is undefined when it matters some |
When the Answer Is Different per Record Type
A policy document, a piece of evidence, and a model prompt sometimes does not need the same home. Deciding per record type is what keeps one blanket answer from being wrong everywhere.
Record types differ in who produced them, who reads them, and what the record needs to show later. Sorting the records first, then placing each group, produces a decision you can defend. Sorting the records after the fact produces a scramble.
| Record Type | What Drives Its Placement | A Common Mistake |
|---|---|---|
| Evidence artifacts | Where the work that produced them happened | Storing the artifact apart from its context |
| Decision records | Who approved what, and when | Keeping the approval but not the reasoning |
| Model prompts and outputs | Where inference runs | Assuming storage rules cover processing |
| Contracts and vendor files | The counterparty and the term | Treating a vendor's copy as your own record |
| Incident and ticket history | Who needed to see it during the event | Losing the thread once the ticket closes |
| Training and attestation records | Which people the record covers | Keeping names without a clear retention reason |
Model Traffic Is Its Own Residency Question
Model traffic is the content sent to a model while work is done. Where that model runs decides where your data is processed, which is a separate answer from where it is stored.
Teams may pick a model for output quality first and location second, or not at all. That order is easy to understand and expensive to hold. A model that writes excellent drafts but runs in a region your records cannot reach has answered a different question from the one your reviewer is asking.
This is where a bring-your-own-model arrangement changes the picture, because the processing path becomes a choice rather than a vendor default. Choosing the model your work runs on covers those trade-offs, and a local-first split draws the line in a different place: what stays local and what does not.
Ask three things about any model in the path. What it is given, what it keeps, and whether the request leaves your environment. If those answers are not documented, the processing half of the residency decision is still open.
What Changes When a Record Crosses a Border
A record that crosses a border sits under a different set of rules, even when its content does not change. The decision is which records can move and which stay put.
Movement can happen accidentally. A support engineer in another region opens a ticket. A backup replicates to a second site. A model request routes through a gateway that logs the prompt. None of those is a breach, and each one moves data somewhere the placement note did not account for.
Cross-border compliance work turns placement decisions into a planning exercise rather than a surprise. Map the records, map the routes, and record where each route ends. When a sub-processor sits on the path, tracking the parties downstream is the same question asked one step further out.
Put the Residency Decision in Writing
A residency decision that is not written down is a habit, not a decision. Record the placement you chose, the reason, and the date, so the next person can find it.
The note does not need to be long. It needs to name the record type, the chosen home, the reasoning, and who agreed. A short entry beats a long policy that nobody opens. When the next review arrives, that entry answers the question without a search.
Keep the note beside the work it describes. A decision filed in a separate folder, disconnected from the evidence it governs, gets lost the moment the person who wrote it changes role. Proximity is what makes the reasoning useful rather than merely present.
FAQ
What is the difference between residency and sovereignty?
Residency is about where a record physically sits. Sovereignty adds the question of whose rules apply to it. The second sometimes follows from the first, but a record can sit in one country while its handling is governed by a contract from another.
Does local storage settle the question on its own?
No. Where a record rests is one part of the answer. If work on that record sends its content to a model or a service elsewhere, the processing question stays open even though storage looks settled.
Who should own the residency decision?
The person accountable for the record, with input from whoever runs the tool and whoever answers the reviewer. If no single name owns it, the answer defaults to whatever the tool was configured to do.
How sometimes should the decision be revisited?
When the tool changes, when a record type is added, or when the contracting party changes. A fixed calendar date sometimes does not matches the moment the answer actually shifts.
What should be asked of a vendor in writing?
Where records rest, which parties can read them, what leaves during processing, and what happens at contract end. An answer that stays verbal is the one that becomes a dispute later.
Where the Residency Decision Should Live
A placement choice that survives only in a setup screen and someone's memory is hard to defend when the question returns. Keep the placement you chose, the reason, and the date beside the records it governs. CASK by Truvara keeps that kind of decision record together with the evidence it explains, so the reasoning stays findable when the question comes back. What it does not do is choose the placement or sign off on it; that judgement stays with your team and your reviewers.