A month ago Amazon announced a European sovereign cloud. Microsoft's European data boundary has been phasing in through the year. The Data Act reached political agreement in June with provisions on switching and lock-in, and the argument over whether the European cloud certification scheme should carry sovereignty criteria remains unresolved. The visible consequence for anyone selling software is smaller and more immediate than any of that. Sovereignty questions have left the enterprise request for proposal and arrived in the mid-market questionnaire, asked by procurement teams of forty-person companies, often in language copied from a document none of them wrote.
Your buyer is not asking where the data is. They are asking what to tell their auditor, and they are hoping you will write it for them
That reframing is worth more than any architecture decision, because it tells you what a winning answer looks like. The buyer has an obligation — from a regulator, a customer contract, an insurer or a board — and needs an artefact that discharges it. A vendor who supplies that artefact clearly, in writing, on the first request, moves to the front of the evaluation regardless of where the servers are.
Four different questions wearing the same words
When "where is our data held" arrives, establish which of these is actually being asked, because the wrong answer to the right question loses the deal. Contractual flow-down. The buyer has promised one of their customers something about data location and must pass it on. The answer needed is a contractual commitment, not a technical description. Audit and checklist compliance. Someone needs a line in a document. The answer needed is a short, quotable statement they can paste. Genuine concern about foreign government access. Rarer, more sophisticated, and the only one where architecture is really the subject. The answer needed is about who can technically access what, from where. Political or board-level optics. The chief executive read something. The answer needed is reassurance with a named region and a named certification. Most mid-market questions are the first two. Most vendors answer all four with a paragraph about their data centre, which satisfies none of them precisely.
Why this reached the mid-market now
Three mechanics, none of them regulatory in origin. Enterprise requirements flow down: your customer's regulator became your customer's obligation, and your customer's obligation became your clause. Procurement templates propagate: one law firm's questionnaire ends up in three hundred companies. And insurance and audit questionnaires standardised, which put the question in front of buyers who had never considered it. None of those mechanisms care whether the buyer understands the question. They only require an answer.
Separate the three things you might be claiming
The most common self-inflicted wound is answering "yes, we are sovereign" when what you mean is "we host in Frankfurt." That claim survives until a security review, and then it costs you the renewal rather than the deal. Publish three distinct statements instead. Residency: where the data is stored at rest, per service. Processing locality: where it is actually processed, which includes anything that leaves the region for a moment. Operational access: who can technically reach it, from which country, and under whose legal jurisdiction they sit. Those are three different commitments with three different costs. Conflating them is what generates the awkward conversation eleven months later.
| Claim | Scope to state explicitly |
|---|---|
| Residency | Storage region per service, including the agreed backup scope. |
| Processing locality | Locations and flows for processing and operational tooling. |
| Operational access | Who can access the service, from where, under which control model. |
| Contract position | Commitments offered, excluded paths and change obligations. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The document that ends most of these cycles
Two pages, written once, maintained quarterly, sent proactively with every proposal: service-by-service storage region; subprocessor list with locations; the support model and where support staff sit; encryption and key custody; how you handle government data requests; and — the part most vendors omit and buyers value most — an explicit statement of what you will commit to contractually and what you will not. A clear no is worth far more than a vague yes. Buyers can work with constraints. They cannot work with ambiguity, and their lawyers will keep asking until it resolves.
Do not build for the questionnaire
Segment the demand before spending capital. The large majority of mid-market buyers will accept a clear statement plus a contractual residency commitment. A smaller group needs genuine in-region deployment. A very small group needs customer-held keys or sovereign-cloud hosting, and that group is usually identifiable by sector. Build only the tier your pipeline justifies, price the higher tiers as options rather than absorbing them into the base product, and be willing to decline the deals that require an architecture your revenue cannot support. Sovereign deployment is a premium offering with real marginal cost. Treating it as a default is how a healthy gross margin quietly disappears.
Practical Guidance for Residency Positioning Review
- Diagnose which of the four questions is being asked before answering.
- Publish residency, processing and access as three separate claims.
- Write the two-page statement once and send it unprompted.
- List subprocessors with locations, and keep the list current.
- State plainly what you will not commit to.
- Price in-region deployment as a tier, not as a concession.
- Inventory the non-obvious data paths before making any claim.
- Track how many days these questions add to your sales cycle.
The Regional Angle
Three things change how this plays here, and the first is that the winning answer is social rather than technical. Regional buyers — particularly government, semi-government and the large family groups that supply them — typically arrive with requirements copied from a public tender document, and they are rarely equipped to evaluate an architectural argument about key custody. What moves them is a reference: which comparable organisation in this country already runs your product, in country, and will say so. A named local hosting arrangement, a named in-country region, and two referenceable regional customers will beat a technically superior answer delivered as a diagram every time. If you are selling into this market and your residency answer is a paragraph about European certifications, you are answering a question nobody asked. The second is that your standard answer is probably out of date. In-country hyperscaler regions in the Emirates and Saudi Arabia have expanded substantially, national cloud-first policies have pushed public sector workloads onto them, and local providers have matured. A vendor who told a prospect two years ago that in-country deployment was not feasible is now making a claim the buyer can disprove in a browser tab, and it reads as unwillingness rather than constraint. Re-check availability and pricing for the regions your pipeline actually asks about before the next proposal goes out, and update the statement. This is a half-day task that changes the tone of several conversations. The third is the mismatch between how the requirement is written and how systems actually work. Regional contracts frequently specify that data must reside in country, full stop, with no definition of scope — and systems are never that binary. Backups, disaster recovery replicas, log aggregation, application monitoring, email and messaging providers, content delivery, error reporting, analytics and the support tooling your engineers use all move data, and several of them almost certainly leave the country in your current deployment. Nobody notices at signature. It surfaces during a security review or an audit two years later, at which point you are in breach of a clause you thought you had satisfied. Inventory every one of those paths before you sign a residency clause, and negotiate the scope explicitly — production data in country, operational telemetry excluded and listed — because a defined exception is a negotiation and an undisclosed one is a finding.
The objection worth taking seriously
The strongest objection is that the whole category is theatre. A multinational provider's parent company remains subject to compulsion under its home jurisdiction's law regardless of where the bytes are stored, which means geography offers considerably less protection than the marketing suggests. The buyers asking these questions overwhelmingly cannot explain what they would do with the answer, rarely audit the commitment afterwards, and are frequently satisfied by a sentence. Building infrastructure, hiring in-region support and maintaining separate deployments to satisfy a checkbox is capital diverted from product, in service of a legal theory that does not survive contact with a subpoena. The legal point is correct, and anyone claiming otherwise is selling something. Storage location is a weak control against determined lawful compulsion; only key custody and genuine operational separation change that materially, and almost nobody buys those. But the conclusion does not follow, because you are not selling into a legal argument. You are selling into a procurement process where someone has an obligation they must discharge and a form they must complete. Whether their obligation rests on sound reasoning is irrelevant to whether it blocks your contract. What this article recommends costs almost nothing — a two-page document, an honest taxonomy, an inventory of your own data paths — and avoids both expensive failure modes: the vendor who builds a sovereign deployment for a market segment that would have accepted a PDF, and the vendor who claims a residency guarantee they cannot honour and discovers it during a renewal. Clarity is cheap. Infrastructure is not. Buy the cheap one first.
Common Questions
Do we need a sovereign cloud offering?
Almost certainly not yet. Establish how many deals in the last four quarters genuinely required one, as opposed to requiring a clear statement, before committing capital.
Can we just say the data stays in region?
Only if it does — including backups, logs, monitoring and support access. That claim is checked eventually, and it is checked by someone with authority over your renewal.
How should we handle support access from another country?
Disclose it, describe the controls around it, and offer an in-region support tier as a priced option. Concealment is the only version of this that ends badly.
What should we expect over the next twelve months?
Expect sovereign offerings from the major providers to move from announcement to availability over the next year or two, at a clear premium, which will give you a partner option rather than a build. Expect the European certification argument to remain unresolved and politically contested, so do not plan around it. Expect questionnaires to add a question about where AI processing happens within the next two quarters — have that answer ready before it is asked. And expect "sovereign" to settle into what it is becoming across the software industry: a paid tier with a defined feature list, rather than a property of the product.
Residency Positioning Review — we map every path your data actually takes, write the two-page statement that closes questionnaire cycles, and tell you which sovereignty tier your pipeline justifies building.