EU Data Residency Compliance Tool: A 7-Surface Evaluation Rubric

An EU data residency compliance tool does two jobs, and vendor pages usually advertise only the first: it keeps a defined set of your data on infrastructure located in the EU, and it produces evidence of where that data sits so someone else can check. Storage location is a configuration setting. Evidence is a product feature. A tool that gives you the first without the second still leaves you writing residency answers by hand the night before a procurement deadline.

That gap is what this rubric is for. Below is a seven-surface map of where data actually goes, a 14-point scoring scheme for grading a vendor's residency statement, the failure modes that surface after signature rather than before, and a small effort model you can run on your own numbers before you buy anything.

Residency, sovereignty and localisation are three separate arguments

Residency is a location fact: which region or country the data rests in and is processed in. It is verifiable from documents and configuration.

Sovereignty is a jurisdictional question — whose authorities and whose law can reach the data. It is not answerable from a settings page, and it is not answerable by a vendor's marketing copy either.

Localisation is a rule that data stays inside one specific country. It usually arrives from a sector body or a customer contract rather than from general data protection law.

A practical routing rule: if the requirement reached you inside a customer's security questionnaire, treat it as residency and answer it with locations and documents. If it reached you from your own legal team, a regulator or a sector body, treat it as sovereignty or localisation and confirm the scope with counsel before you start comparing tools. Shopping for software to satisfy a requirement nobody has read carefully is the most expensive way to fail an assessment.

The seven surfaces a residency claim has to cover

"Data stays in the EU" is a statement about one surface. Real systems have at least seven, and each one can be configured, or forgotten, independently.

Surfaces 1 and 2 are the ones vendors document. Surfaces 3, 5 and 6 are the ones that come back as follow-up questions from a reviewer who has done this before.

Score it: a 14-point residency evidence rubric

Grade each of the seven surfaces on the same three-point scale, using only what the vendor has put in writing:

• 0 points — not addressed anywhere you can cite.
• 1 point — addressed in prose, but with no named region, country or subprocessor.
• 2 points — names the region or country and the subprocessor, in a document you can reference: the data processing agreement, the subprocessor list, or a dated trust page.

Fourteen points is the ceiling. Use these thresholds:

• 11–14: answer customer questions directly from the vendor's own documents and cite them by name and date.
• 6–10: write a scoped answer covering the surfaces you can evidence, and open one vendor question per surface scoring 0 or 1.
• 0–5: do not put a residency assertion into a customer questionnaire on that vendor's behalf. Describe what you know, name what you have asked, and give a date for the follow-up.

One override matters more than the total: any single surface scoring 0 caps the vendor at "scoped answer", whatever the sum says. A 12/14 with an unanswered telemetry question is not a 12 — it is a blind spot with good marks around it. Averages hide exactly the surface a reviewer will ask about.

If you want the answer-writing side of this in more depth, the mechanics of tying each claim to a citable document are covered in Evidence-Based Compliance Answers: A Practical Framework.

Where residency claims break first

The claim is rarely wrong on the day it is written. It decays.

Subprocessor lists are versioned; the answer you wrote six months ago is not. A vendor can add a US-hosted transcription service in March and publish it correctly, and your questionnaire library will happily keep exporting the February answer until someone re-reads the list. Put a recheck date on every residency answer, not just an owner.

Telemetry is the second break point. An application can store every customer record in Frankfurt while its error tracker receives stack traces containing identifiers and forwards them to a region nobody reviewed. This is usually not a policy failure — it is an integration that was added by an engineer solving a reliability problem, in a quarter when nobody asked them where the data went.

Human access is the third, and it is the one most often answered too confidently. Storage residency and access geography are separate questions, and reviewers increasingly ask them as separate questions. A support engineer outside the EEA viewing a record through a screen-share is a different fact from a support engineer exporting that record, and both are different from where the record lives.

The early warning sign is linguistic. If your draft answer needs the word "primarily", the answer is not ready.

Four shapes the residency question takes in a questionnaire

Residency questions look varied and are not. Nearly all of them are one of four shapes, and each has a matching answer pattern.

1. Location. "In which countries is customer data stored?" Answer with region and country, and name which of the seven surfaces the statement covers. An unscoped location answer invites a follow-up.
2. Access. "Can personnel outside the EEA access customer data?" Answer yes or no, then state the conditions and the control that enforces them — approval workflow, session logging, time limits. A "no" you cannot evidence is the one that returns during an audit.
3. Subprocessors. "List all subprocessors and their locations." Point to the versioned list and cite its date rather than retyping it into a spreadsheet cell that will be stale by the next questionnaire.
4. Change control. "How are we notified of subprocessor changes?" Answer with the notification mechanism and notice period from your own data processing agreement.

One thing not to do in any of the four: answer with a legal conclusion about whether a transfer arrangement is lawful. Describe the arrangement, cite the contractual document, and leave the conclusion to counsel who can own it.

An effort model to run before you buy

Before comparing any EU data residency compliance tool, work out what the manual version costs you:

Annual residency-answer effort = Q × R × M

• Q = security questionnaires received per year
• R = residency, hosting and subprocessor questions per questionnaire
• M = minutes to answer one from scratch, including chasing the person who knows

A fictional worked example: a 40-person SaaS vendor receives Q = 18 questionnaires a year, each containing R = 9 residency-adjacent questions, at M = 12 minutes each. That is 1,944 minutes, roughly 32 hours a year, before any re-review when a subprocessor list changes.

The model does not prove that any tool will move M. It tells you how much M is worth moving. A decision rule that follows from it: if Q × R × M lands under about five hours a year, tooling is solving the wrong problem — fix the source document instead, publish a dated residency page, and answer from it. Below that threshold the integration and review overhead of a new tool tends to exceed the work it absorbs.

Eight questions to ask a vendor before you sign

• Which regions can be pinned, and can the region be pinned per workspace rather than per account?
• Show the subprocessor list with a version date: how are changes announced, and how much notice is given?
• Which of the seven surfaces above does the residency setting actually cover, and which are outside it?
• Where does support access originate, and is any data copied out of the platform during a support session?
• If AI features are enabled, which provider processes the text, in which region, and is input retained after the request?
• What happens to data location during regional failover, and where is that documented?
• Which of these statements sit in a contractual document, and which sit only on a marketing page?
• Can we export everything and receive deletion confirmation with a date?

The broader evaluation criteria — file fidelity, review controls, workflow fit, operating cost — are set out in Compliance Questionnaire Software: A 14-Point Buying Framework.

Where Compliance Concierge fits, and where it does not

Compliance Concierge is a security-questionnaire drafting tool hosted in Frankfurt. You upload your own policies and the questionnaire; answers are drafted with citations pointing back into your documents, and nothing leaves the tool without passing a mandatory human review gate. That touches residency in two narrow ways: the workflow itself runs on EU infrastructure, so your policies and drafts stay there, and the residency answers you keep rewriting can be drafted from your own data processing agreement and subprocessor list rather than from a model's recollection.

What it does not do is worth stating plainly. It does not control where your production systems store customer data — that is an infrastructure decision in your own stack. It does not determine whether an arrangement satisfies a legal requirement. And a citation shows where a sentence came from, not whether the control behind it is still operating; that is precisely why the review gate exists and why a named human still signs off. For location, transfer and notification questions, the sources of truth remain your DPA, your subprocessor list and your counsel.

Teams weighing this against a bundled platform with a trust-center product will find the trade-offs laid out in Compliance Concierge Alternative to Conveyor: A Decision Framework.

Questions reviewers actually ask

What is EU data residency?

EU data residency describes data being stored and processed on infrastructure physically located in the European Union. It is a statement about location, not a statement about legal status, and it applies per surface — a system can have EU residency for its primary database and a different answer for its logs.

Is data residency the same as data sovereignty?

No. Residency is where the bytes are. Sovereignty concerns which jurisdiction's law and authorities can reach them, including through a provider's corporate structure. A tool can give you a defensible answer on the first; the second is a question for legal advice, and any vendor answering it for you in a sales deck is answering out of scope.

Does EU hosting answer a residency question on its own?

Rarely in full. "Hosted in the EU" typically addresses surfaces 1 and 2 of the seven above. A reviewer who asks a second question is usually asking about telemetry, support access or model inference, so answer the location question and state the scope in the same breath.

The case this rubric does not cover

Single-country requirements. When a customer or a sector body asks for data to stay in one member state rather than anywhere in the EU, an EU-wide residency setting does not answer the question, and a scorecard of 14/14 against the seven surfaces will not either. Ask the vendor directly whether country-level pinning exists, get the answer into a contractual document before signature rather than after, and have counsel confirm where the single-country requirement came from — sector rules and customer contract terms behave differently, and only one of them is negotiable.