Español
Updates

EU Businesses: 4 Vendor Questions Before You Store Data in the EEA

Checklist for EU businesses: keep personal data in the EEA when possible, use adequacy or SCCs for transfers, and document a Transfer Impact Assessment.

EU Businesses: 4 Vendor Questions Before You Store Data in the EEA

GDPR does not force you to store personal data inside the EU or EEA, but moving that data outside the EEA triggers Chapter V transfer rules that most businesses underestimate. Your practical next step is simple: keep data within the EEA when you can, or confirm a lawful transfer mechanism, such as an adequacy decision or Standard Contractual Clauses, and document a Transfer Impact Assessment. Guidance from the European Commission, the EDPB, and Spain’s AEPD all point the same way: location matters less than the safeguards you put around it.

TL;DR:

  • Keeping personal data inside the EEA reduces transfer risks, but remote access outside the region still activates Chapter V transfer rules under GDPR.
  • Countries on the adequacy list allow data transfers without extra safeguards, but most businesses rely on SCCs and must implement operational follow-through.
  • Conducting a Transfer Impact Assessment is essential for higher-risk destinations, especially when laws in that country could undermine GDPR protections.
  • Inside EU-based data centers, essential security measures include encryption, role-based access, and logical data separation, which mitigate compliance risks even without cross-border transfers.
  • Member state-specific rules and sectoral regulations may impose stricter data localization or processing requirements beyond GDPR, impacting storage and transfer decisions.

Table of Contents

Storage Location Versus International Transfers Under GDPR

Businesses often assume GDPR is a residency law. It isn’t. GDPR applies based on where you process personal data and whose data it is, not on which country’s server racks hold it. The regulation covers the European Economic Area (EEA), which includes all EU member states plus Iceland, Liechtenstein, and Norway. Inside that zone, the rules apply uniformly regardless of which member state hosts the data.

Two roles matter here. The controller decides why and how data gets processed; the processor handles it on the controller’s behalf. When data moves to a country outside the EEA, the sender becomes an “exporter” and the receiving party becomes an “importer,” and that movement is what activates Chapter V of GDPR, not the physical act of storage itself.

This distinction trips up a lot of businesses. You can store data entirely within the EEA and still have a transfer problem if a subprocessor or support team outside the EEA can remotely access it. Access counts as a transfer under EU guidance, even without a single byte physically leaving the continent.

The Court of Justice of the European Union’s Schrems II ruling reinforced a principle regulators now apply strictly: protection has to “follow the data.” If you send data to a country whose surveillance laws could undermine the safeguards you rely on, contractual promises alone will not satisfy a regulator. You may need supplementary measures, such as stronger encryption or restricted access, layered on top of whatever transfer mechanism you choose. We’ll walk through what that looks like in practice later in this guide.

Adequacy Decisions, SCCs, BCRs, and When Exceptions Apply

Once you know a transfer is happening, you need a lawful basis for it. The European Commission maintains a list of countries it considers “adequate,” meaning their data protection framework is essentially equivalent to the EEA’s. If your destination country is on that list, you can transfer data there without adding extra contractual tools. It’s the simplest route, but it only works for a limited set of countries, so check the current list before assuming your vendor qualifies.

When adequacy isn’t available, most businesses turn to Standard Contractual Clauses (SCCs). The European Commission publishes these as an appropriate safeguard, but signing them is only step one. SCCs require real operational follow-through: you have to implement the commitments they describe, not just file the signed document. The Commission’s SCC framework includes different modules depending on whether you’re acting as controller-to-controller, controller-to-processor, processor-to-processor, or processor-to-controller, so pick the module that actually matches your relationship with the vendor.

Binding Corporate Rules (BCRs) suit large organizations transferring data within their own corporate group, and approved codes of conduct or certifications can work for specific sectors, but both require more setup than most small or mid-sized businesses need. Article 49 derogations, covering cases like explicit consent or contract necessity, exist for occasional, non-repetitive transfers. They are deliberately narrow: regulators do not treat them as a substitute for a proper transfer mechanism on recurring data flows, so lean on adequacy or SCCs for anything routine.

Adequacy Decisions, SCCs, BCRs, and When Exceptions Apply — overview diagram

A Compliance Checklist for Vendor Contracts and Audits

Before you sign with any vendor, or renew an existing contract, walk through this checklist to confirm you know exactly where your data goes and who can touch it.

Questions to ask every vendor:

  1. Which regions host the primary data center, and is that commitment written into the contract?
  2. Do subprocessors operate outside the EEA, and if so, under what transfer mechanism?
  3. Can remote support or admin staff access data from outside the EEA, even temporarily?
  4. Does the vendor publish a current subprocessor list you can review and object to?

Contract clauses to verify:

  • SCCs are included, with the correct module selected for your controller or processor relationship.
  • Audit rights let you verify compliance rather than just take the vendor’s word for it.
  • Breach notification timelines are specific, not vague.
  • Liability allocation is clear if a transfer safeguard fails.

Running a basic Transfer Impact Assessment doesn’t require outside counsel for every vendor. Document the destination country, the legal mechanism you’re relying on, any surveillance laws that could interfere with protections, and the supplementary measures you’ve added. Save that documentation. If a regulator ever asks, a dated decision record carries far more weight than a verbal assurance.

Finally, require baseline operational controls regardless of location: encryption at rest and in transit, role-based access limits, defined retention schedules, and activity logging you can produce on request.

Retention Limits and Baseline Security for Stored Data

Storage location is only half the compliance picture. GDPR’s storage limitation principle requires you to keep personal data only as long as your purpose and legal basis justify, then delete or properly archive it. A booking record kept for tax purposes has a different retention clock than a marketing opt-in, so tie each retention period to the specific reason you collected the data in the first place.

Minimization matters just as much as deletion. Collect only what the purpose requires, and where you can achieve the same goal with pseudonymized or aggregated data, use that instead of raw personal identifiers.

Baseline technical and organizational measures regulators expect:

  • Encryption applied both at rest and in transit, not just one or the other.
  • Role-based access control so staff see only the data their job requires.
  • Regular patching and vulnerability management on systems holding personal data.
  • Backup routines that respect the same geographic and access rules as primary storage.
  • A documented incident response plan, tested rather than theoretical.

Recordkeeping ties it together. Maintain a written retention policy, keep your data processing records current, and involve a Data Protection Officer where one applies to your organization. A specific practical guide for tourist accommodation operators covers how these retention and documentation duties apply in that sector.

Pro Tip: Set calendar reminders tied to each retention period rather than relying on manual review. Missed deletions are one of the most common findings in GDPR audits.

How to Run a Transfer Impact Assessment and Judge Destination Risk

A Transfer Impact Assessment, or TIA, is the documentation that proves you actually evaluated the risk of a transfer rather than assuming SCCs alone were enough. The EDPB’s guidance on international data transfers recommends exporters perform this assessment and add supplementary measures where a destination country’s laws could interfere with the protections SCCs are supposed to guarantee. That recommendation followed directly from Schrems II, which found that contractual promises cannot override a government’s legal power to access data within its own borders.

What a defensible TIA should document:

  • The specific country or countries data will reach, including any subprocessors.
  • The legal mechanism relied on, whether adequacy, SCCs, or another tool.
  • Any surveillance or disclosure laws in that country relevant to the data type involved.
  • Supplementary measures added, such as encryption where only you hold the key, or contractual limits on government access requests.
  • The date of the assessment and who approved it.

One finding worth building into your process: the EDPB’s own recommendations describe a risk-tiered approach to assessments, where low-risk transfers, such as those to an adequate country or within a group covered by BCRs, warrant lighter documentation than transfers to higher-risk destinations. That means you do not need to over-engineer every assessment; match the depth of your review to the actual risk.

Spain adds a layer worth knowing about: national rules under the LOPDGDD can require prior authorization for certain international transfer types, so if you operate there, check whether your specific transfer falls into a category that needs that extra step before you rely on SCCs alone.

Technical Safeguards Inside EU-Based Data Centers

Choosing a data center physically located in the EU solves the geography question but not the security one. Regulators expect the same baseline technical and organizational measures inside an EU facility that they’d expect anywhere else, just without the added transfer-mechanism burden.

Encryption remains the starting point: data at rest should be encrypted with keys you control or can audit, and data in transit between your systems and the provider’s should run over secure protocols rather than open connections. Access controls need to be role-based and logged, so you can show exactly who touched a given record and when, which matters as much for internal regulatory readiness as for stopping unauthorized access.

Data segregation is the piece businesses overlook most often. In a shared or multi-tenant EU data center, your organization’s data needs logical separation from other customers’ data, whether through separate database instances, strict access boundaries, or both. Ask any EU-based provider how they achieve that separation rather than assuming “EU region” automatically means your data is isolated.

Physical security, redundant backups stored within the same EEA boundary, and documented patching schedules round out what a regulator will expect to see if they ever ask how you protect data that never left EU soil. None of this replaces the legal transfer analysis, but it does remove one variable: when data stays inside the EEA with no subprocessor access from outside it, you skip Chapter V entirely.

Member State Rules That Go Beyond GDPR’s Baseline

GDPR sets a floor, not a ceiling, and EU member states have added their own layers on top of it. That matters because storing data “in the EU” does not automatically mean every member state treats your data the same way once it lands there.

Some countries impose sector-specific data localization rules for health records, financial data, or public sector information that go further than GDPR requires. Others maintain their own supervisory authority practices around prior authorization for certain transfers or processing activities, as Spain’s LOPDGDD illustrates with transfer authorization requirements that sit alongside GDPR rather than replacing it.

National security and law enforcement access frameworks also differ by member state, which matters if you’re evaluating where within the EU to locate infrastructure for data sovereignty reasons, not just GDPR compliance. A data center in one member state might sit under different government access rules than one in another, even though both satisfy GDPR’s EEA residency preference equally well.

Procurement rules for public sector contracts sometimes layer additional data sovereignty requirements on top of GDPR too, particularly where a member state wants assurance that data tied to public contracts stays under its own jurisdiction rather than a neighboring one.

The practical takeaway: if your business operates across multiple EU markets, don’t assume uniform rules just because you’re inside the EEA. Check whether your specific sector or the member state where your provider is based adds requirements GDPR itself doesn’t mention.

Cloud Providers Versus On-Premises Storage Inside the EU

The choice between a cloud provider and on-premises infrastructure inside the EU changes where compliance risk concentrates, even when both options keep data within the EEA.

Cloud and on-premises EU storage comparison

On-premises storage gives you direct physical and administrative control. You know exactly where the hardware sits, who has keys to the server room, and who can access the data, because you manage all of it yourself. The tradeoff is that you also carry the full weight of maintaining encryption, patching, backups, and physical security without a vendor sharing that responsibility.

Cloud providers introduce convenience but also introduce subprocessors, which is where many businesses lose track of their own compliance picture. An EU region selection in a major cloud platform is not, by itself, a guarantee that your data never leaves the EEA. Support staff, backup replication, or disaster recovery procedures can involve access from outside the region you selected unless the provider contractually commits otherwise. National guidance from data protection authorities has flagged this exact gap: cloud setups often involve subprocessors and remote administrative access that count as transfers and need contractual scrutiny, not just a settings toggle.

Whichever model you choose, the controller remains responsible for compliance. That means requiring a current subprocessor list, audit rights, and explicit data residency commitments from any cloud vendor, and applying the same discipline to access logging and patching if you run infrastructure yourself.

What Schrems II Changed for Transfers and EU-Based Storage

The Schrems II ruling is often framed as a US-EU transfer case, and it was, but its logic reaches further into how businesses think about storage inside the EU too. The court found that SCCs remain valid as a transfer tool, but only if the exporter actually verifies that the destination country’s laws won’t undermine the protections those clauses promise. A signed contract is not enough on its own.

For storage decisions made entirely within the EEA, Schrems II’s direct relevance drops, since intra-EEA data flows aren’t subject to Chapter V transfer rules in the first place. Where it still bites is at the edges: subprocessors, support teams, or backup systems that reach outside the EEA even briefly, including from an EU-based primary data center, can trigger the same scrutiny the ruling demands for any other cross-border transfer.

The EDPB’s response to Schrems II made the assessment obligation concrete, pushing exporters toward documented TIAs and supplementary measures rather than a one-time contractual checkbox. For businesses storing data in the EU, the practical lesson is to treat every path data could take out of the EEA, not just the primary storage location, as a potential transfer point worth documenting. A provider that keeps everything, including support and backups, inside the EEA removes that analysis entirely.

Contracting Well With EU-Based Processors and Storage Providers

Choosing an EU-based processor reduces your transfer analysis, but it doesn’t eliminate the need for a solid contract. Start by confirming the provider’s data processing agreement names its subprocessors and specifies their locations, since an EU-based primary provider can still rely on subprocessors elsewhere.

Ask for explicit data residency commitments in writing, not just marketing language about “EU servers.” A contractual guarantee that production data, backups, and support access all stay within the EEA is worth far more than a regional setting you can’t verify. Guidance on what to look for in data collection practices can help frame these questions if you’re assessing a vendor serving the hospitality sector specifically.

Build in audit rights so you can verify compliance rather than relying on annual self-certifications alone, and confirm breach notification timelines match or beat your own regulatory deadlines. Finally, check that the provider’s data processing agreement covers Article 28 obligations directly, since a well-drafted agreement can satisfy both your SCC-equivalent needs and your basic processor contract requirements in one document when the right module is used.

Our Take on Where Businesses Actually Get Stuck

Most businesses treat EU data storage as a single yes-or-no decision, when it’s really a chain of smaller decisions: where the primary database sits, where backups replicate, which subprocessors a vendor uses, and who can access data remotely. The chain breaks most often at the subprocessor and remote-access links, not at the primary storage location businesses spend the most time evaluating.

We think the bigger risk isn’t choosing the wrong country. It’s assuming a signed SCC or a regional dropdown setting closes the conversation, when regulators increasingly expect a documented, specific decision trail behind it.

— Sofía Herrera

EU-Based Storage and Automated Reporting for Accommodation Businesses

For property owners, managers, and hotels handling guest data daily, the compliance questions above translate into a concrete operational need: a system that keeps guest records inside the EU and handles legal reporting without manual work. That’s the specific gap we built EuroCheckin to close.

Eurocheckin

Our platform hosts guest data on infrastructure located within the European Union and can automatically send the required traveler data to SES Hospedajes, in line with Real Decreto 933/2021 and GDPR. Beyond reporting, we provide features like multilingual online check-in, digital contracts, and calendar synchronization across various booking platforms, helping to centralize guest data for easier management.

If reporting to SES Hospedajes is your main concern, our SES Hospedajes management page details how that automation works. Hotels and larger operators can check plan details built for professional volume on our hotel registration page.

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.

FAQ

Are data centers being built in Europe?

Yes, major cloud providers and regional operators continue to expand EU-based data center capacity, and many businesses now have a genuine EU-region option for the infrastructure they use. Availability varies by provider and region, so confirm the specific location and subprocessor arrangement before assuming a given service stores data where you expect.

Does GDPR require data to be stored in Europe?

No, GDPR does not require storage inside the EEA. It regulates transfers of personal data outside the EEA through Chapter V mechanisms like adequacy decisions and SCCs, so storing data outside the EEA is lawful as long as you have a valid transfer basis in place.

Is there a difference between GDPR and “EU GDPR”?

No, there is one GDPR regulation that applies across the European Union and the wider EEA. “EU GDPR” is simply an informal way some people refer to the regulation to distinguish it from other countries’ similarly named privacy laws, such as adapted versions used outside the EU.

What is the EU policy on data protection generally?

The EU’s core policy is GDPR, which sets rules for lawful processing, data minimization, retention limits, and security across all member states, backed by the EDPB’s guidance on cross-border enforcement and transfers. National authorities, like Spain’s AEPD, add their own guidance and enforcement on top of that shared framework.

How do I check if my current vendor’s data storage setup is compliant?

Ask for a current subprocessor list, written confirmation of which regions host your data and backups, and whether support staff can access data from outside the EEA. If any part of that chain reaches outside the EEA, confirm the vendor has a valid transfer mechanism, such as SCCs, and a documented Transfer Impact Assessment behind it.

Sources

Related articles