For data protection officers and country leadership
Four separate questions get answered as one, and the two that are usually silently false are where the copies live and who can reach the records from which country. This page answers each of the four separately, names the regions available today rather than planned, and says what we would have to decline.
A localisation obligation is unusual among compliance requirements because it is geographic rather than procedural. It cannot be satisfied by a policy, a training module or a well-drafted clause. Either the bytes are inside a border or they are not, and the authority asking will eventually ask in a form that requires a specific answer about specific infrastructure.
The awkward part is that the obligation attaches to copies as firmly as to originals, and copies are where architectures leak. Backups written to a consolidated location. A disaster recovery replica in a neighbouring territory chosen for latency. An analytics pipeline that ships events somewhere central. A crash reporter forwarding payloads to a service headquartered elsewhere. None of those appear on a datasheet and every one of them is the same obligation.
Human access is the question that most often turns out badly, and it is rarely asked directly. A support engineer in another territory opening a record to investigate a fault is a transfer, regardless of where the storage sits. So is a screen share showing a record. So is an exported log containing an identifier. A residency answer that only describes storage has not touched the part a supervisory authority tends to examine first.
Then there is the vocabulary problem. A vendor says data is stored in your region, meaning the primary datastore. You hear that records concerning your residents do not leave. Neither party is lying and the two statements are different, and the difference surfaces during an audit rather than during procurement, at which point renegotiating is not really available.
And the commercial pressure runs one way. Naming an available territory wins deals, and the cost of naming one that is not yet real arrives much later and lands on somebody else. Which is why the useful residency page is the one that lists what exists today and says what it would have to decline.
A single "in region" answer conflates primary storage, backup copies, operational telemetry and human access — and a residency commitment is only as strong as the weakest of those four, which is almost never the one the vendor described.
Primary storage is the easy one and it is answered first: records for a customer are held in the region agreed at the start of the arrangement, and moving them later is a deliberate migration rather than an operational convenience. That is the promise most vendors make and it is the smallest of the four.
Backups and recovery copies are held in the same region as the primary. This is the promise that costs something, because the cheap arrangement is a consolidated backup location and the resilient arrangement is a second location in a different territory. Choosing the same region for copies means accepting a narrower recovery position, and that trade belongs in your decision explicitly rather than being made for you quietly.
Operational telemetry is where an honest answer has to be specific. Records themselves are not shipped for analytics. What does travel is operational measurement — counts, timings, error classes — and the standing rule for it is that it carries structure rather than content: how many, how long, which class of failure, never the record. That distinction is the one to press on, because a vendor who cannot describe what their telemetry contains has not looked.
Human access is answered by restricting it rather than by promising discipline. Support access to customer records is a granted, time-bounded action rather than a standing capability, it is exercised against your identity provider rather than an internal account, and the event lands in your log stream. Where an arrangement requires that access originate only from inside a territory, that is a real constraint we can accept in writing — and where it requires a staffed presence inside a territory, we do not have one, and that is the sentence that closes some opportunities.
On regions: what is operated today is a footprint in the United States, and a customer-run deployment inside infrastructure the customer already owns — which is the arrangement that satisfies most territorial obligations, because the territory is then yours to choose. There is no European, United Kingdom, Canadian, Australian or Indian estate of ours today. Where an obligation requires one, the honest answer is the customer-run deployment or nothing, and saying so during procurement costs less than being found out during an audit.
Where primary records are held — measured by a written region commitment naming the territory, agreed before provisioning.
Where backup and recovery copies are held — measured by a written statement that copies share the primary region, and the recovery trade that accepts.
What operational telemetry contains — measured by a written description of the fields emitted, checkable against what your monitoring receives.
Whether human access ever crosses a border — measured by the access record in your own log stream, showing each grant, its window and its origin.
Which territories are genuinely available — measured by a written statement of the operated footprint, with the ones we would decline named.
Whether an obligation can be met at all — measured by a written yes or no during procurement rather than a qualified answer during an audit.
no European, United Kingdom, Canadian, Australian or Indian estate of ours exists today, and no adequacy determination, certification or approved transfer mechanism is claimed on our own account. No staffed support presence inside a specific territory is offered. Where an obligation requires any of those, the available answer is a deployment inside infrastructure you already run, or a decline. An independent SOC 2 Type II attestation is in progress and no report exists yet.
When the software runs inside infrastructure your organisation already operates, the territorial question stops being ours to answer. The region is the one you chose, the backups are yours, the retention is yours, and the transfer question reduces to whether anybody of ours can reach it — which is answered by a credential you issue and can withdraw without telling us.
That arrangement carries a real cost and it is not the cheap option. Your team carries the operating burden, the patching cadence and the monitoring. For an organisation whose obligation is genuinely territorial, that cost is frequently smaller than the alternative, and for one whose obligation is procedural rather than geographic it is usually not worth paying.
Where the arrangement is ours to operate, the region is fixed at the start and stated in the contract rather than being an operational detail we could change. A vendor who can relocate your records as a capacity decision has not made a residency commitment; they have described a current configuration.
The operated footprint today is in the United States. That is stated first because a residency page that buries it has inverted its own purpose, and because a buyer with a European or Indian localisation obligation should be able to reach a decision on this page rather than in a fourth call.
What remains available to such a buyer is a deployment inside infrastructure they already run, in a region they choose. That is a genuine answer rather than a consolation, because it moves the territorial question entirely onto their side of the boundary — but it is a different operating model with a different cost, and presenting it as equivalent would be misleading.
No adequacy determination, transfer certification or approved mechanism is held or claimed on our own account. Where a lawful transfer basis is required, it is established in the contract by the parties rather than supplied by a status we possess, and any vendor implying they carry one for you has described something that does not work that way.
On independent assurance: a SOC 2 Type II attestation is in progress and no report exists yet, so nobody can be handed one, and it is an attestation with a scope and a period rather than a certification. We hold neither a FedRAMP authorization nor a FedRAMP certification and claim no equivalency, which is relevant here because federal territorial requirements often arrive alongside that question.
Put the region in the contract rather than in an onboarding note. A residency commitment that lives in configuration is one a capacity decision can undo, and the difference only becomes visible at the moment it matters most.
Ask the backup question separately and in writing. It is the single most reliable way to find out whether a residency answer was written by somebody who checked. A vendor whose backups leave the territory while their primary stays is not being dishonest; they answered a narrower question than you asked.
Ask what the telemetry contains, field by field. Not whether it is anonymised — what fields it carries. A vendor who can produce that list has looked; a vendor who describes it in the abstract has not.
And test the access record before signing rather than after. Ask for a support grant to be exercised in a trial environment and confirm the event appears in your own log stream with its origin. An access story that cannot be demonstrated is a story.
A written answer to your specific territorial obligation — including backups, telemetry and human access — issued before any evaluation of features begins.
This is a subject where the correct first outcome is frequently a decline, and a decline delivered in week one is worth considerably more to both parties than a qualified answer delivered in month four. If the obligation requires an estate we do not operate, that should be established here.
Where the answer is a deployment you run, the next artefact is the description of that arrangement and its cost to your team, because that is the decision rather than the feature set.
Only after the territorial question is closed does an evaluation make sense. Running it the other way round produces a team that likes the product and cannot lawfully use it, which is the most expensive possible ordering.
No. The operated footprint today is in the United States, and there is no European, United Kingdom, Canadian, Australian or Indian estate of ours. That closes any arrangement where records concerning residents must sit inside an estate we operate in that territory, and we would rather say it on this page than in a fourth call. What remains available is a deployment inside infrastructure your organisation already runs, in a region you choose — which moves the territorial question entirely onto your side, at a real cost in operating burden to your team.
The same region as the primary. That is the answer that costs something, because the cheaper and more resilient arrangement is a consolidated backup location in a different territory, and keeping copies in region means accepting a narrower recovery position. That trade belongs in your decision rather than being made quietly on your behalf. It is also the single question most likely to reveal whether a residency answer was written by somebody who checked — ask every vendor separately and in writing.
Only through a support grant you make, for a bounded window, exercised against your identity provider, with the event landing in your log stream including its origin. There is no standing capability for support staff to open customer records. Where your obligation requires that access originate only inside a territory, that constraint can be accepted in writing. What we do not have is a staffed presence inside a specific territory, so an obligation requiring one is a decline rather than a negotiation.
They do, which is why the standing rule is that operational measurement carries structure rather than content — how many, how long, which class of failure — and never the record itself. Ask for the field list rather than an assurance that it is anonymised; the list is the thing that distinguishes a vendor who looked from one who assumed. What your own review should then do is compare that list against what your network actually observes leaving, because a description and a behaviour are two different artefacts.
Yes, and you should insist on it with every vendor rather than accepting it as a configuration note. A residency commitment that lives in a settings page is one an operational decision can reverse, and the reversal becomes visible at exactly the moment it is most expensive. Named in the contract, moving records becomes a deliberate migration requiring your agreement rather than a capacity choice somebody makes on a Tuesday.