· Yair Knijn
The EU data residency claim your subprocessor quietly broke
The DPO signs the residency attestation because the primary data store is in eu-central-1. That is the wrong unit of analysis. Residency is a property of every place the data is touched, not just where the rows sit at rest, and the rows at rest are the one part nobody was ever going to get wrong.
The claim you put in front of a regulated prospect is estate-wide: all customer data stays in the EU. The reality is that one tool in the estate has a support tier staffed out of a US team, a backup target in another region, and a telemetry pipeline that ships logs to a vendor's home country. Storing data in Frankfurt or Azure North Europe does not, on its own, stop a transfer. A support engineer in Austin opening a session against that EU tenant is the transfer, and post-Schrems II that means SCCs plus a documented transfer impact assessment, or you do not have a legal basis at all.
Where residency leaks: support access, backups, logs, telemetry
The primary store is the part of the chain everyone scrutinizes, so it is the part that is almost always correct. The leaks are in the boring operational paths nobody put in the architecture diagram.
- Support access: a follow-the-sun support model means an offshore engineer can read production data during a ticket. That session is an access transfer even if no bytes are copied to disk.
- Backups and DR: the snapshot target or the failover region sits outside the EU "for resilience," and now your recovery copy lives somewhere your DPA never named.
- Logs and telemetry: error traces, APM payloads, and session replays routinely carry personal data, and the observability vendor's ingest endpoint is wherever that vendor decided.
- Sub-processors of sub-processors: the tool you vetted relies on a CDN, an email relay, and an AI feature whose inference runs on someone else's GPUs in a third country.
Why per-tool DPAs and SCCs do not add up to an estate-wide claim
Each product hands you a DPA, an SCC module, and a sub-processor list. Those documents are real and individually fine. They do not compose into the sentence you actually wrote down. Under the modernized SCCs, Module 3 requires every sub-processor to appear in Annex III with its own clauses, and Schrems II requires a transfer impact assessment per transfer. Ten tools means ten lists, ten Annex III sets, and a transfer surface that no single document describes.
When the customer asks "does all our data stay in the EU," they are asking one question about the whole chain. Ten compliant DPAs answer ten narrower questions. The gap between those is exactly where the claim breaks, and it breaks silently, because nothing in a per-tool document is wrong on its own terms.
The due-diligence questionnaire that exposes the gap
This surfaces at the worst possible moment: the prospect's security team sends the questionnaire. The questions are not "where is the database." They are "list every party who can access this data and the country they operate from," "name every sub-processor and its transfer mechanism," and "describe your support access model including out-of-region staff." You answer per tool, by hand, and the support-access row contradicts the residency row you certified three slides earlier. The deal does not die on a missing control. It dies on an inconsistency a careful reviewer catches in five minutes.
One operating record that keeps residency provable across every product
The fix is not a fourth policy PDF. It is one operating record per customer tenant that every product hangs its processing facts off: who accessed what, from where, which sub-processors touched it, where backups and telemetry landed. When residency is a queryable property of that record instead of a sentence in a slide deck, the questionnaire becomes one export, and the contradiction shows up to you before it shows up to the prospect.
In Spot Suite, the Customer Environment is that record, so support access, transfer paths, and sub-processor flows are attributes of the tenant rather than facts scattered across ten vendor portals. You can read how we hold residency together across products on our security page.