Data Sovereignty for Mid-Market Data Teams

If a customer’s legal team asked which government could compel access to your company’s data, would you have an answer, or would you point at your hosting region and hope that covers it? Most mid-market teams would do the second, because data sovereignty and data residency get treated as the same question, and the gap between them is starting to show up in EU procurement. This guide is for mid-market data teams in or selling into the EU who receive enterprise-grade security questionnaires and can’t fund a sovereignty program to answer them. It covers the distinction between sovereignty, residency, and compliance, what has changed in EU regulation, a five-question exposure assessment you can run without a lawyer, and what can be fixed at the analytics layer instead of through a migration nobody will fund.

At a Glance

• Understand why data residency and data sovereignty are different, and why an EU hosting region alone doesn’t settle the question.
• Know which EU rules affect you today and which are still proposals, so you can answer customers without overpromising.
• Find out in an afternoon which of your systems put your data within reach of non-EU law, using five questions and no lawyer.
• Reduce most of that risk by fixing one layer, the warehouse and BI platform where copies of all your data end up, instead of migrating every piece of software you use.

Who This Is For:

Sovereignty, Residency, and Compliance Are Three Different Things

Most content on data sovereignty vs data residency uses the terms interchangeably, which is how a team ends up with a residency clause in a vendor contract and a false sense of having handled EU data compliance.

1. Residency Is About Location

Residency is the easy one: the physical location of the servers holding your data. It’s contractual, verifiable, and almost any serious vendor will put it in writing. Some regulations make it a hard rule, which is what data localization means.

2. Sovereignty Is About Jurisdiction

Sovereignty asks which legal system governs the data and who could compel access to it, which turns on who owns and controls the provider, not on where the racks are. The CLOUD Act of 2018 lets US authorities compel providers under US jurisdiction to produce data wherever it’s stored, so a US-owned provider’s Frankfurt data center is still within US reach. This stopped being theoretical on June 10, 2025, when Microsoft France’s director of public and legal affairs told a French Senate inquiry, under oath, that he could not guarantee French citizens’ data held in Microsoft’s EU data centers would never be handed to US authorities without French consent. To his knowledge, no such demand had ever been made for a European customer.

3. Compliance Is About Rules, Not Control

GDPR governs how personal data is handled, including the Chapter V rules on transfers outside the EEA. It doesn’t require EU hosting, and it says nothing about data jurisdiction over non-personal data, which for most companies is the bulk of what sits in a warehouse. Inventory levels and product telemetry aren’t personal data, and GDPR leaves the sovereignty question over them untouched.

A team that has ticked the residency box and filed the GDPR paperwork still hasn’t addressed sovereignty, and the gap stays invisible until someone on the other side of a procurement process asks the right question.

Two EU Regulations That Now Affect Private Companies

Sovereignty used to be a concern for ministries and defense contractors. Two EU regulations have changed that, and if you sell software or services in Europe, both of them reach you.

• EU Data Act (in force since September 12, 2025). Cloud and SaaS providers must make it easy to switch to another provider, and switching fees are banned from January 12, 2027. Under Article 28, providers must also publish which jurisdiction their infrastructure falls under and how they protect data from foreign government access. That page is a useful starting point for the assessment below.
• Cloud and AI Development Act (proposed June 3, 2026, not yet law). It would grade cloud providers on four levels of sovereignty assurance. Anyone selling cloud services to the public sector would need at least the first level, and higher levels add stricter rules on ownership, supply chain, and who operates the service. The One Europe, One Market roadmap, signed April 24, 2026, aims for agreement by the end of 2027, so nothing in the proposal binds anyone today.

If You Serve the Public Sector, the Questions Arrive First

If your customers include public bodies, or companies that supply them, you’ll feel these rules before they formally apply to you. Public sector buyers that must choose assured cloud providers will ask the same questions of their own suppliers, usually through security questionnaires about where your data sits and whose laws govern it. The Cloud and AI Development Act already points this way. It would let certain private companies run the same checks on their own cloud providers, starting with those the EU treats as essential services under its cybersecurity rules, such as energy, transport, banking, and healthcare. It would also let the European Commission make those checks mandatory later. Residency questions are already standard in these questionnaires, and jurisdiction questions are next, so if you haven’t prepared your answers yet, now is the time to start.

Check Which Laws Can Reach Your Data in an Afternoon

Here’s how to spot your sovereignty and compliance risks before a customer or auditor catches you off guard. None of it needs a lawyer: just a spreadsheet, a list of your systems, and an honest hour per question.

1. Where Does Each System Physically Store Its Data?
   “Where is my SaaS data stored?” is the question every team asks first, and for most SaaS tools the answer is in the data processing agreement or the trust center. The disclosure the Data Act requires covers jurisdiction, not storage location. Write “unknown” where it’s unknown, because unknown is itself a finding.
2. Who Owns Each Vendor, and Under Which Jurisdiction?
   Residency documentation doesn’t answer this one. Note the ultimate parent company and where it’s incorporated, then go one layer down to whoever runs the infrastructure underneath the vendor.
3. Which Systems Hold Data You Could Not Explain Losing Access To?
   Sovereignty risk concentrates in the handful of systems holding customer contracts, financials, product data, or anything a customer would consider theirs, and those deserve more attention than a marketing tool full of campaign metrics.
4. Where Does Your Data Get Copied To?
   It’s the question teams skip, and it’s where most exposure sits. Analytics platforms pull copies of everything into wherever the BI vendor hosts, backups land in a region someone chose in 2019, and integration platforms cache payloads in transit. Every one of those is a copy under a jurisdiction, and the data pipelines feeding them rarely have it written down.
5. Could You Answer All of This in a Security Questionnaire Tomorrow?
   If not, that is the finding, and it’s worth writing down before a customer writes it down for you. Rank the list by how much sensitive data each system holds and how confident you are in the jurisdiction answer:

System	Where It Rests	Vendor Owner and Jurisdiction	Infrastructure Underneath	Copies Out	Exposure
CRM	EU region	US parent, US law	US hyperscaler	BI, backups	High
BI and warehouse	Vendor’s choice	Unknown	Unknown	Exports, AI features	Highest until answered
Payroll	In-country	EU-owned	EU provider	Accountant	Low

The two “Unknown” cells in the BI row are the point of the exercise: analytics is the system most teams can describe least, and it holds a copy of everything above it.

What You Can Fix Without Migrating Everything

The advice most teams receive at this point assumes consolidation into a single sovereign environment, a program nobody at mid-market scale will fund. Hybrid data architecture is the durable state, and a plan that starts with “first, move everything” never starts.

Fix the Consolidation Layer First

Your CRM, ERP, and email aren’t moving this year, and they don’t need to. The layer carrying the most exposure is the one holding a copy of all of them, the warehouse and BI layer, and it’s also the cheapest to move, because it doesn’t run your business, it reports on it. Sovereign BI, in practice, means deciding where that copy lives and under which vendor. The data foundation article covers how to structure that layer; this one is about where it sits.

Document What You Cannot Change

A known, documented exposure is a defensible position, and an undocumented one is a finding waiting to happen. For the systems you aren’t going to move, write down where they rest, who owns the vendor, and what the contract says about third-country access. A procurement reviewer who sees a complete map with two honest gaps reacts very differently from one who sees a blank, because “we know, and here is why we accepted it” is an answer and silence is not.

Three Caveats That Should Ease the Pressure

Sovereignty sells, and some of the claims deserve a closer look. These three should lower the temperature.

Sovereignty Is Not a Security Guarantee

Jurisdiction and security are separate questions. An EU-owned provider with weak access controls, no audit logging, and a support team that can see everything is a worse place for your data than a US hyperscaler region with tight controls. Run both assessments.

Most Companies Are Not at Risk of Compelled Access

The Microsoft testimony had a second part worth holding onto: to his knowledge, no such demand had ever been made for a European customer. Compelled access under the CLOUD Act is an instrument used in criminal investigations, and for a mid-market company the odds of being on the receiving end are close to zero. The realistic exposure is commercial and procedural: failing a questionnaire, or losing a deal to a competitor who could answer.

European Does Not Automatically Mean Sovereign

Ownership, hosting infrastructure, subprocessors, and support access are separate attributes, and a provider can be European on one and not the others. Any vendor should answer these five vendor questions in writing, and the next section answers them for ClicData:

1. Who is the ultimate owner of the company, and where is it incorporated?
2. Which infrastructure provider runs the service, and who owns that provider?
3. Can we choose the region, and can we choose to host the data layer ourselves?
4. Which subprocessors touch the data, and from where?
5. Can support staff access our data, from which countries, and can we switch that off?

A vendor who can’t answer all five hasn’t earned the word.

How ClicData Fits

The five vendor questions, answered against ClicData’s own terms of service, privacy policy, and platform pages.

1. Who owns it, and where is it incorporated? ClicData SAS, a French company based in Lille, with a US affiliate, ClicData Inc, in Delaware. For customers outside the US, the contract falls under French law and disputes are settled in France. If you use ClicData to store and process personal data, you also sign a data processing agreement, and that one is with ClicData SAS too. That makes it a French contract, which is not the same as immunity from the CLOUD Act, for the reason in the next answer.
2. Which infrastructure runs it? Microsoft Azure. That puts the hosting layer with a US-owned provider, the same question the assessment asks of every other vendor. What ClicData controls on top of it is which region your data lives in and who can reach it. Azure’s own staff have no access to your content unless a system issue requires it, and even then ClicData supervises that access. For teams that need to remove the question entirely, the self-hosted option in the next answer does exactly that.
3. Can you choose the region, or host it yourself? Both. Shared plans host in Ireland or US East, and dedicated plans add France, Germany, the Netherlands, the UK, Canada, Singapore, and Australia. Your data stays in the region you pick, backups included. If you need the data layer on your own terms, ClicData connects to a warehouse you host yourself on SQL Server 2022 Enterprise, Azure SQL Database, or Synapse. That is the consolidation-layer fix from earlier.
4. Who else touches the data? Azure for hosting, Braintree for payments, and an email delivery provider. ClicData works from an agreed subprocessor list, available on request, and gives a month’s notice before changing it. The AI features are the one copy out worth knowing about: ClicData writes the query itself and sends only your question and the query structure to OpenAI or Anthropic. Your raw data never leaves and isn’t used for training.
5. Can support see your data? Only if you let them. You grant support access explicitly, can revoke it in account settings, and can see every visit in the audit logs. Engineers can step in without permission only to fix a critical platform problem. The support team may work from the US or Canada, including for EU customers. Role-based access at the data layer, activity logs, and transformation logic kept in Data Flow, where it can be inspected, cover the rest.

Stated plainly, the limitation is this: sovereignty at the analytics layer doesn’t fix exposure in your source systems. If your CRM, email, and file storage run on US-owned platforms, choosing a European BI vendor hasn’t solved sovereignty. It closes one gap, the one holding a copy of everything, which is worth doing and is not the whole picture.

If the consolidation layer is near the top of your list, book a session and bring the list.

Conclusion: Know the Answer Before You Are Asked

Sovereignty exposure is a question your team can either answer or not, rather than a compliance status you hold. Building the map is an afternoon; moving the consolidated copy is a small project by comparison.

The next step is concrete: list your top five systems by how much data they hold, and for each one write down where it rests and who owns the company. The gaps in that list are your roadmap, and if one of the five is your analytics layer, that’s the one to fix first. Book a session with the team when you’re ready to compare options.

FAQs