Hanad KubatVisit Website →
← Back to blog

5 Vendor Questions Engineers Need to Verify EU Data Residency

August 31, 2026
5 Vendor Questions Engineers Need to Verify EU Data Residency

GDPR does not require personal data to physically stay inside the EU or EEA. What it requires is a lawful transfer mechanism whenever that data leaves the bloc, documented under Chapter V of the regulation. In practice, that means mapping your data flows, picking a mechanism (adequacy decision, Standard Contractual Clauses, or binding corporate rules), and running a Transfer Impact Assessment for any destination without an adequacy decision. Residency becomes a hard requirement only in specific cases: certain health data in France, financial services under DORA, or a procurement clause that demands it.

TL;DR:

  • Data transfers outside the EU require a recognized mechanism, such as adequacy decisions, SCCs, BCRs, or explicit derogations, with a documented Transfer Impact Assessment.
  • The EU-US Data Privacy Framework offers a self-certification path for US vendors, but most companies still rely on SCCs and assessments due to legal uncertainties surrounding the Framework's longevity.
  • US law enforcement's CLOUD Act can compel vendors to hand over data even if stored within the EU, making physical hosting insufficient protection without additional safeguards.
  • Building residency-aware architecture and encrypting sensitive data with customer-managed keys from the start significantly reduces transfer risks and compliance burdens.
  • A comprehensive data flow map, current subprocessor register, signed transfer documents, and recent Transfer Impact Assessments are essential artifacts for demonstrating GDPR compliance.

Table of Contents

GDPR Scope and Chapter V: The Rules That Actually Govern Transfers

GDPR applies to any organization that processes personal data of people in the EU, regardless of where that organization is based. If you're a controller or processor established outside the EEA but you offer goods or services to EU residents, or you monitor their behavior, Article 3's extraterritorial scope pulls you in. This trips up a lot of US-based SaaS founders who assume GDPR is "someone else's problem" because their servers sit in Virginia.

Chapter V (Articles 44 through 50) is where transfer rules live. The core principle is simple: personal data can only leave the EEA if the destination offers an equivalent level of protection, verified through one of a small number of recognized mechanisms. The European Commission's guidance on international data transfers lays out the full toolkit, and it comes down to four real options:

  • Adequacy decisions. The European Commission has decided that certain countries, including the UK, Japan, and South Korea, offer protection equivalent to the EU's. Data can flow there without extra paperwork.
  • Standard Contractual Clauses (SCCs). Pre-approved contract templates that bind the receiving party to EU-level protections. This is the default mechanism most companies use because it doesn't require government-level negotiation.
  • Binding Corporate Rules (BCRs). Internal, regulator-approved policies for transfers within a single corporate group. These take months to approve and only make sense for large multinationals moving data between their own subsidiaries.
  • Derogations under Article 49. Narrow exceptions for one-off situations, explicit consent, or contract necessity. The EDPB's guidelines on Article 49 derogations are explicit that these are meant for exceptional, occasional transfers, not a standing basis for routine data flows.

Non-personal data operates under a different, looser regime. EU policy encourages the free movement of non-personal data within the EU, and member states can only restrict its movement for narrow public-security reasons. If your dataset is genuinely anonymized business analytics with no personal identifiers, you're playing a different game than if it contains customer names and emails.

Schrems II, the Data Privacy Framework, and Why Transfer Risk Keeps Rising

The 2020 Schrems II ruling changed the calculus for every company relying on SCCs to send data to the United States. The Court of Justice of the EU decided that a contract alone can't override a destination country's surveillance laws. If US law lets intelligence agencies access data held by US companies with fewer protections than the GDPR requires, an SCC doesn't magically fix that. Transfer legality now depends on what actually happens once the data lands, not just what the paperwork says.

The EU-US Data Privacy Framework (DPF), which took effect in 2023, gives US companies a path to self-certify and rely on an adequacy-like status. It's a real mechanism, and if your vendor has self-certified, that's meaningful. But most US SaaS vendors haven't self-certified, according to practitioner analysis of EU/US residency requirements, which means SCCs plus a documented Transfer Impact Assessment remain the fallback most companies actually use. The DPF also faces ongoing legal challenges in EU courts, following the same pattern that took down its two predecessors, Safe Harbor and Privacy Shield. Betting your entire compliance posture on the DPF surviving indefinitely is not a safe bet.

Here's the detail that catches founders off guard: the US CLOUD Act lets US law enforcement compel US-headquartered companies to hand over data they control, even when that data sits on servers physically located in Frankfurt or Dublin. Hosting in an EU region doesn't neutralize this if your vendor's parent company is American. This is the exact reason "our data is stored in the EU" is not the same claim as "our data is protected from foreign legal reach."

What this means for your SCC strategy: signing an SCC template and filing it away is not compliance. Post-Schrems II, the EDPB's guidance sets a clear expectation that SCCs need to be paired with:

  • A documented Transfer Impact Assessment evaluating the destination country's actual surveillance and access laws
  • Supplementary measures where the assessment finds a gap: strong encryption, pseudonymization, or contractual commitments that go beyond the standard template
  • A record of when the assessment was performed and by whom, available for inspection

Regulators expect this documentation, and the European Commission's own transfer guidance treats undocumented, ad-hoc vendor assurances as weak evidence in an audit. A vendor telling your sales rep "we're GDPR compliant" is not a Transfer Impact Assessment. It's marketing.

How to Run a Transfer Impact Assessment Without Drowning in Paperwork

Most compliance programs fail at the mapping stage, not the legal analysis stage. Here's the sequence that actually works for a small team.

  1. Classify your data first. Separate ordinary personal data (names, emails, IP addresses) from special categories under Article 9 (health, biometric, political opinion, sexual orientation) and from genuinely non-personal data. Special categories carry a much higher bar and deserve remediation priority.
  2. Map every flow, not just the obvious ones. List every collection point: signup forms, support tickets, payment processors, analytics tools, and any AI feature that sends prompts or context to a third-party model API. Then trace where each flow lands: your primary cloud provider, your email tool, your customer support platform, your backup destination, and every subprocessor those vendors use.
  3. Score the risk for each cross-border flow. For each destination outside the EEA without an adequacy decision, run a Transfer Impact Assessment: what does that country's law actually permit in terms of government access to data, and does your vendor have any track record or transparency report addressing it?
  4. Identify supplementary measures where the assessment flags a gap. This might be encrypting sensitive fields before they leave your infrastructure, or negotiating additional contractual commitments with a vendor that won't budge on its default terms.
  5. Prioritize remediation by sensitivity and retention, not by alphabetical vendor list. A payment processor handling card data under long retention deserves attention before a marketing tool that stores email addresses for 90 days.

Pro Tip: Keep your data-flow map in a plain spreadsheet, not a diagram tool nobody updates. One column per flow: source, destination, legal basis, mechanism, last review date. A messy spreadsheet that's current beats a beautiful diagram that's eight months stale.

Regulators and auditors generally expect four artifacts at minimum: a data-flow map, a subprocessor register, signed SCC documentation for each non-adequate destination, and a dated Transfer Impact Assessment for the highest-risk flows. If you can produce those four documents in an afternoon, you're in far better shape than most companies your size. For teams building AI features specifically, this documentation set overlaps heavily with what you'd need for EU AI Act compliance as well, since both frameworks care about where prompts, embeddings, and model outputs travel.

Architecture Patterns That Actually Reduce Transfer Exposure

Engineering controls won't make Chapter V disappear, but they shrink the surface area you have to defend. A few patterns matter more than the rest.

Region-aware deployment means separating EU/EEA customer data at the database and storage layer, not just picking "EU-West" as your default region and calling it done. If your architecture treats tenant location as a first-class field from day one, splitting data by residency later doesn't require a rewrite. Retrofitting this after 50,000 rows exist is a different kind of project entirely, and I've seen founders discover that the hard way when a due-diligence review asks for tenant-level data isolation proof.

Encryption model matters more than most teams realize. Provider-managed keys are the default and they're fine for low-sensitivity data, but for anything in a special category under Article 9, customer-managed keys (or envelope encryption where you hold the wrapping key) give you a real answer when a vendor's parent company gets a legal request you can't see. If you can't produce the key, the data on the other end is functionally useless to whoever's asking. That's the actual value of the model, not a compliance checkbox.

  • Separate EU customer data at the storage layer from day one, even if your team is three people
  • Use customer-managed or envelope encryption for special-category data specifically, not everything uniformly
  • Include backups and disaster-recovery replicas in your residency plan, because a backup vendor in a different jurisdiction is still a transfer
  • Audit every subprocessor your primary vendors use, since their subprocessor list is effectively part of your transfer chain
  • Prefer EU-headquartered vendors over EU regions of global providers when the data is genuinely sensitive, since headquarters jurisdiction, not server location, determines CLOUD Act exposure

Pro Tip: Ask any vendor one direct question: "If a foreign government compelled your parent company to hand over this data, could you comply without notifying me?" The answer tells you more than their compliance page ever will.

None of this requires enterprise budget. A two-person engineering team can build region-aware separation and customer-managed keys into a system from the start for roughly the same effort as bolting it on generically. Planning this early is exactly what a solid SaaS architecture plan should account for, before the first paying customer asks about it in a security questionnaire.

When Residency Stops Being Optional: Sector and Member-State Rules

GDPR's general flexibility on location doesn't apply once you're in a regulated sector or dealing with a customer who has its own rules. A handful of situations turn "residency is a choice" into "residency is a requirement."

  • French health data. Hosting certain health data for French patients generally requires certification under the Hébergeur de Données de Santé (HDS) framework, which in practice means EU hosting with specific security certifications, not a general adequacy argument.
  • German procurement practice. Public-sector and enterprise buyers in Germany often lean on BSI guidance and procurement norms that push vendors toward EU hosting even where GDPR itself wouldn't strictly demand it. This is a market expectation as much as a legal one.
  • Financial services under DORA. The Digital Operational Resilience Act adds operational resilience and third-party risk requirements for EU financial entities that function as de facto residency and oversight pressure on their technology vendors.
  • Contractual mandates. A growing number of enterprise customers write EU-residency clauses directly into their vendor contracts, regardless of what GDPR technically requires. If your biggest customer's legal team demands it, it's now a requirement for your business, whatever the regulation says.

These sector rules don't replace GDPR analysis, they sit on top of it. A field guide to data residency makes the point well: treat sector and contract-driven residency as a separate checklist item from your general Chapter V analysis, and reconcile the two only after you know which one is stricter for a given data class. Operating across multiple member states means you plan for the strictest applicable rule, not the average one.

The Vendor Questions That Separate Real Compliance From a Marketing Page

A vendor's compliance page will tell you what you want to hear. A short, specific set of questions tells you what's actually true. Keep this list on file and re-run it whenever a vendor changes ownership or subprocessor lineup.

  1. Where does data go at every stage? Ask for the full pipeline: primary storage, processing, backups, any AI features that send data to a model provider, analytics, and who on the support team can access raw customer data.
  2. Where is the parent company incorporated, and who are the subprocessors? A vendor with EU servers but a US parent company carries CLOUD Act exposure regardless of region. Request the current subprocessor list and ask how often it changes.
  3. Who holds the encryption keys, and can you audit that claim? Ask for evidence, not an assertion: SOC 2 reports, ISO 27001 certification, or a specific answer about key custody for sensitive fields.
  4. What transfer mechanism applies, and is there paperwork? Request the signed SCCs, DPF self-certification status, or BCR approval, not a vague "we're compliant" line in the terms of service.
  5. What does the DPA actually say about notification and audit rights? Your Data Processing Agreement should specify breach notification timelines, name the SCC module in use, and grant you inspection or audit rights, not just a promise of "reasonable cooperation."

Pro Tip: If a vendor can't produce a current subprocessor list within a week of asking, treat that as a signal about their internal documentation discipline generally, not just their subprocessor tracking.

This checklist doubles as due-diligence material. A buyer evaluating an acquisition or a large customer running security review will ask nearly identical questions, and having answers on file before they ask saves weeks. For a deeper look at what technical validation buyers actually expect, this guide to technical validation for EU compliance covers the evidentiary bar in more depth. Cloud buyers weighing providers on contractual protections and egress terms will also find the HIPAA compliant cloud providers buyer's guide useful, even outside a healthcare context, since the contractual logic around switching and lock-in is nearly identical.

Keeping the Program Inspectable: Owners, Templates, and Minimal Automation

A compliance program that lives only in someone's head fails the moment that person leaves or a regulator asks a specific question. Assign a named owner for each data class (who owns the customer database, who owns the analytics pipeline) and a named owner for transfer controls generally, even if that's one person wearing two hats on a five-person team.

Four templates cover most of what you need: a Transfer Impact Assessment template you reuse for every new vendor, a subprocessor register updated on a fixed schedule, a folder of signed SCC insertions per vendor, and a review calendar that forces a re-check every time a vendor changes ownership or a new adequacy decision gets published.

  • Set a quarterly review cadence for your subprocessor register, not an "as needed" one that quietly never happens
  • Log encryption key access and rotation events somewhere durable, even a simple audit log beats no record
  • Flag any new vendor integration for a transfer check before it ships, not after a customer asks about it
  • Keep DPA and SCC documents in one indexed folder, not scattered across email threads

Pro Tip: A founder-led engineering team can absolutely produce the data-flow map, the subprocessor register, and the technical controls. What it usually can't produce credibly is the legal interpretation of a borderline transfer or a genuinely novel derogation. Bring in counsel for the interpretation, not the documentation legwork.

Good engineering practice and good compliance practice overlap more than people expect. A codebase built for maintainability and auditability from the start makes every one of these templates easier to fill in honestly, because the data flows are traceable in the code, not reconstructed from memory during an audit.

Author's Practical Notes: Building Residency-Aware MVPs Alone

When I build a first version of a product, I separate EU and non-EU customer data at the schema level from the first migration, tagging tenant records by region rather than retrofitting it later. Region-aware deployment on Cloudflare Workers or a comparable edge platform makes this tractable without a dedicated infrastructure team.

For key management, I favor envelope encryption with customer-managed keys for anything touching special categories, and provider-managed keys for everything else. That split keeps the audit footprint small enough for a single engineer to maintain honestly.

What I hand over at the end of a build: a data-flow map, a signed SCC template ready for the client's vendors, a subprocessor list, and a basic disaster-recovery plan. What founders should expect: building region-aware separation from day one costs a bit more time up front than ignoring it, but it costs far less than retrofitting it after your first enterprise customer's security review flags the gap.

— Hanad Kubat

Thirty to Ninety Days: What to Actually Do About This

In the next 30 days, do three things: map every EU personal-data flow in your system, gather SCC or DPF evidence from your top five vendors, and run a Transfer Impact Assessment on your two riskiest transfers, usually your primary cloud provider and any AI API you call.

Insist on EU residency specifically when you handle special-category data, operate in a regulated sector like health or finance, or a major customer's contract demands it. Otherwise, documented SCCs plus a real Transfer Impact Assessment satisfy Chapter V. Legal, procurement, and engineering all need the same underlying map: without it, nobody in the room can tell you where the actual risk sits.

Where Engineering Judgment Meets Compliance Reality

I work as a single senior engineer delivering fixed-scope builds, not a law firm. I can build the region-aware architecture, the encryption model, and the documentation artifacts a Transfer Impact Assessment needs. I cannot give you a legal opinion on a borderline derogation or represent you in a regulatory inquiry: that's counsel's job, and I'll tell a client directly when a question has crossed that line.

What I can do is build the first real version of your product with these controls baked in from the first commit, not bolted on after a customer asks about it. If your prototype from Bolt, Lovable, or a similar tool has stalled around 70%, usually right at the parts that have to be right, that's exactly the rescue work I do. Every line is written by me, no juniors, fixed price, fixed scope, and you own the code from day one. Details on how I work are at Hanad Kubat's engineering services.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

FAQ

What are the requirements for data residency in the EU?

GDPR doesn't require data to physically stay in the EU. It requires a lawful transfer mechanism, adequacy decision, SCCs, BCRs, or a narrow derogation, whenever personal data moves outside the EEA, along with documented risk assessment for non-adequate destinations.

What are the 7 GDPR requirements?

GDPR's core principles cover lawfulness and transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality (security), and accountability, with international transfer rules under Chapter V sitting alongside them as a distinct compliance track.

Can EU data be stored in the US?

Yes, if a valid transfer mechanism applies: the vendor has self-certified under the EU-US Data Privacy Framework, or you've signed SCCs and documented a Transfer Impact Assessment covering supplementary measures where needed.

Does GDPR apply to US citizens?

GDPR applies based on location and context, not citizenship: it protects the personal data of anyone in the EU when a company targets or monitors them, regardless of that person's nationality, and it applies to US companies that offer services to people in the EU.