Does GDPR require EU data residency? No, but it regulates transfers
The GDPR has no general rule that personal data must be stored inside the EU. The obligation that matters is Chapter V, which applies when an organization bound by the GDPR discloses personal data to, or makes it accessible to, a separate controller or processor in a third country. If a customer, contract or regulator asks for EU residency, treat it first as a contract term or risk requirement, not a statutory one, and then check whether keeping the data and its administration inside the EEA removes transfer work from your own environment. Ask the requester to state in writing whether the demand is a legal citation or a commercial condition, because the answer determines what you must prove and to whom.
The answer changes with three facts: where the data is stored, who administers the systems, and who can reach the data from abroad. The EDPB's Guidelines 05/2021 treat storage in a cloud outside the EEA offered by a provider, and remote support or viewing by a provider in a third country, as transfers. By contrast, data kept in the EEA and administered only by your own employees is not transferred, even when an employee logs in while traveling abroad. Map each of these three facts for every system that holds personal data, including backups, logs, monitoring and support tooling, because a single provider administrator in another country can bring an otherwise EU-hosted system into Chapter V. Confirm the current wording of the guidelines before relying on any example in your own assessment.
DeployOpen can help you prepare the systems, access model and evidence that show where data sits and who can reach it, and it can document that position for your assessment team. The decision on residency, the transfer tool you rely on, and the conclusion that a transfer is or is not occurring remain with your organization. Only an independent auditor, a certification body or a supervisory authority reaches a finding on compliance. Where the answer depends on a provider's foreign-law exposure, the controller must assess that exposure before engaging the provider, and a supervisory authority can order a data flow suspended if the transfer rules are breached.
What counts as a transfer under the EDPB's guidance
The EDPB's guidance tests whether data leaves the GDPR's reach by a disclosure or by making data available to someone outside the EEA. The four situations below show where that line falls, and each card names the check that decides which side a given arrangement sits on.
Disclosure to a third-country recipient
Your organization, as an exporter subject to the GDPR, discloses personal data to a separate controller or processor located outside the EEA. This is a transfer in the plain sense, and it triggers Chapter V whether or not the recipient is a vendor you chose on purpose. Check who receives the data, where that recipient is established, and whether the recipient is a separate legal party. A subsidiary or affiliate abroad that is a separate entity usually counts.
Storage in a non-EEA cloud
A service provider offers cloud storage in a data center outside the EEA, and personal data is hosted there. The EDPB treats this as a transfer even when the provider is an EU company. Confirm the physical regions for primary data, replicas, backups and logs, and whether any sub-processor stores copies outside the EEA. Hosting choices are the first thing to verify, because they determine whether the transfer question even arises.
Remote viewing or support access
A vendor engineer in a third country logs into a system holding EEA personal data to view records, troubleshoot or administer it. The EDPB's Example 11 treats this remote support access by a provider in a third country as a transfer, even when no copy is made. Check who can connect, from which countries, under what approval, and whether sessions are logged. Remote access is often overlooked because no data leaves the system.
Employee access while traveling
An employee of the organization holds EEA-hosted personal data in the organization's own systems and opens them while on a trip abroad. Under the EDPB's three criteria this is not a transfer, as illustrated by Example 8, because the data stays in the EEA and is administered only by the exporter's own staff. The check is that the access is by your own employee, under your control, and that no third-country party gains access. Contractors or vendor staff abroad change the answer.
Which hosting and administration model fits your data flows
This table compares three ways of hosting and administering personal data and shows whether each one creates a transfer under the EDPB criteria, what transfer work it adds, and when it fits. Read each row against your own answers on who can reach the data and from where. The main takeaway is that keeping both storage and administration inside the EEA, with only your own staff in the loop, removes most transfer work.
| Model | Transfer under EDPB criteria? | Added work and when it fits |
|---|---|---|
| EEA hosting, administration only by your own employees | No. Staff accessing systems while abroad is not a transfer (Example 8). | Little transfer work beyond keeping the EEA-only design documented. Fits when your own team operates the platform and no outside party can see the data. |
| EEA hosting, third-country provider access for support | Yes. Remote viewing or administration by a provider in a third country counts as a transfer (Example 11). | Needs a transfer tool, a transfer impact assessment and review of foreign authority request risk. Fits when vendor support is essential and the contract and access controls can be verified. |
| Hosting or access from a third country under an adequacy decision | Yes. Storage or access outside the EEA is a transfer, justified by an adequacy decision such as the EU-US Data Privacy Framework. | Requires confirming the recipient's current adequacy status and its scope. Fits when the provider is certified under the relevant decision and the data flow matches that scope. |
| Hosting or access from a third country under standard contractual clauses | Yes. The flow is a transfer and the clauses serve as the transfer tool. | Requires a completed transfer impact assessment, supplementary measures where needed and periodic re-evaluation. Fits when no adequacy decision covers the destination and the risk assessment supports the flow. |
When keeping data and administration in the EEA removes transfer work
Keeping data in the EEA and administering it only through your own employees often removes the transfer question altogether. Under the three criteria in the EDPB's Guidelines 05/2021 (the EDPB Guidelines 05/2021), a flow is a transfer only when a GDPR-bound exporter discloses data to, or makes it available to, a separate controller or processor in a third country. An employee who works from abroad and opens the organization's own systems, which sit in the EEA, is not that separate party. The guidelines treat this as Example 8, and it holds even when the employee is traveling. The practical test is who holds the administrative access and where the people using it are employed, not where the laptop happens to be.
The limit comes as soon as someone outside your employment touches the data or the systems. A provider with an establishment or staff in a third country, a support engineer who views data remotely from a third country, or an EU-hosted provider subject to third-country law can each create a transfer, even with no copy leaving the EEA. Example 12 of the same guidelines goes further for the last case: foreign authority requests to an EU provider can themselves amount to a transfer, and the controller should assess that risk before engaging the provider. Confirm with each vendor where its administrators sit, which entity holds the contract, and whether any sub-processor sits outside the EEA.
Residency is therefore a design choice that reduces transfer work, not a substitute for a transfer assessment. Where a provider has any access path into the environment, the decision is still whether the legal tools in Chapter V apply and whether supplementary measures are needed. Write down which roles hold administrative access, from which countries, and under which entity, and keep that record with the processing documentation. A quote or scope for self-hosted deployment should name who will administer the platform after handover, because that answer determines whether the transfer analysis can be skipped.
How to test whether your flows are transfers
This sequence turns the question of whether data leaves the EEA into a documented, owned decision for each flow. It moves from an inventory of systems to the transfer tool chosen for every flow that qualifies, and ends with a dated record that an assessor or regulator can follow.
Inventory every system holding personal data
List each application, database, file store, backup set, log pipeline and analytics tool that holds personal data, and record where it is physically hosted, including the region and any secondary or disaster recovery site. Name the team that owns each system. The step is complete when every system has a hosting location recorded against it and no system is left without an owner, so gaps can be checked before any analysis begins.
Map the personal data flows between systems
For each system, trace where personal data is copied, synced, exported or sent onward, including to partners, customers and third-party tools. Record the data categories and the purpose of each flow. The output is a data flow register that shows the origin, destination and hosting location of every flow. This register becomes the input for every later decision and should be reviewed whenever an integration changes.
List every party with access
For each system, list every party that can view, change or administer the data. Include your own staff, especially those working from outside the EEA, sub-processors, the software vendor's support engineers, managed service providers, and the providers of backup, logging and monitoring services. Note whether each party has standing access, just-in-time access or access only during a support session. The output is an access register that matches each party to each system.
Apply the EDPB criteria to each party
For each exporter and recipient pair, test whether the GDPR-bound exporter discloses data or makes it available to a separate controller or processor located in a third country. Then test whether remote viewing, support access or storage outside the EEA is involved, since the EDPB Guidelines 05/2021 treat those as transfers too. Record the result for each flow with a short reason. An employee of your organization accessing EEA-hosted systems while abroad is not a transfer under those guidelines, so record that case separately. Have a privacy lead or the DPO review the conclusions.
Select the transfer tool for each transfer
For each flow that is a transfer, check first whether the destination country or sector is covered by an adequacy decision under Article 45, including the EU-US Data Privacy Framework where the recipient is a certified participant. Where no adequacy decision applies, select appropriate safeguards such as standard contractual clauses or binding corporate rules under Articles 46 and 47. Use the Article 49 derogations only for specific situations, not as a routine basis. The output is a tool selection per flow, and where safeguards are used, a transfer impact assessment that supports the choice.
Obtain and file the signed transfer documents
Confirm that the contractual instrument for each selected tool is in place and signed by the right entities. For standard contractual clauses, check that the correct modules are used for each relationship and that the annexes describe the actual flows, including remote access. For adequacy relying on certification, confirm the recipient's current status with the supplier and keep a dated copy of the evidence. The output is a filed set of signed documents linked to the flows in your register.
Record each decision with its date and owner
Consolidate the results into a single transfer decision record that lists each flow, the party, the criteria applied, the tool chosen, the date of the decision and the named owner responsible for it. Record any flow you have decided is not a transfer, with the reasoning. The record is complete when every flow in the data flow register has a decision and an owner, and when the record is stored where the DPO and the assessor can retrieve it.
Confirm the record stays current
Set the trigger events that reopen the analysis: a new system or vendor, a change in hosting region, a change in who can access the data, a new sub-processor, or a change in the third country's law or the status of an adequacy decision. Confirm with the owner of each flow that the register and decision record are updated when a trigger occurs. The output is a documented review routine that keeps the earlier decisions accurate as the environment changes.
Who decides, who prepares evidence, and who decides on compliance
As controller, your organization carries the GDPR responsibility for where personal data is stored and who can reach it. Residency and transfer questions are legal and commercial decisions that sit with the people who hold the data and sign the contracts, even when technical staff do the analysis. Nothing in this split moves that accountability to a vendor or consultant.
- Residency decision: Choose where each dataset is hosted and whether administration stays inside the EEA, and record the reasons.
- Transfer tool choice: Decide whether an adequacy decision, standard contractual clauses or another Chapter V tool applies to each flow, and who signs it.
- Transfer records: Keep the record of processing, the flow inventory and the transfer impact assessment up to date.
- Contracts: Negotiate and hold processor terms, sub-processor lists and any support access clauses.
- Re-evaluation: Review these decisions when providers, support locations or third-country law change.
Before relying on any of this, confirm with your legal and privacy team which transfer tool and contract terms apply to each specific flow.
An implementation partner such as DeployOpen works inside the infrastructure the organization already controls. The partner can prepare hosting and access configurations that keep data and administration where the controller decides, and it can document how each administrative path works. It supplies the technical facts that the controller and its advisers need, but it does not make the legal call or sign transfer instruments for the organization.
- Hosting configuration: Deploy the platform in the agreed region and document where each component, backup and log store runs.
- Access paths: Map who can reach administrative interfaces, from where, and through which accounts and keys.
- Administrative documentation: Describe every remote support or maintenance path, including any path that would reach data from outside the EEA.
- Evidence packs: Assemble configuration exports, architecture diagrams and access logs for the controller to review.
- Scope limits: Confirm in the written scope that the partner will not sign transfer tools, issue legal opinions or represent the organization to regulators.
Ask for the written scope to name each configuration and document the partner will produce, and confirm who reviews them before they are relied on.
Independent assessment and enforcement belong to parties outside both the organization and its implementation partner. The GDPR requires no audit or certificate, so no single report confirms that a residency position is compliant. Where an assessor is engaged, it tests the position against the evidence and reports its own findings. Supervisory authorities enforce the GDPR and can act on transfers that fall short.
- Independent testing: An external auditor or assessor samples the flows, contracts and configurations and reaches its own conclusions.
- Findings and reports: Only the independent party issues any finding, report or certificate. DeployOpen does not issue audit reports, attestations or certifications.
- Supervisory enforcement: National supervisory authorities may investigate transfers and, under Article 58, order the suspension of data flows.
- Certification: Article 42 certification, where it exists for a service, is voluntary and does not transfer responsibility away from the controller.
- Fine exposure: Transfer infringements fall under the highest fine tier in Article 83, so the organization should understand that responsibility remains its own.
Before engaging any assessor, confirm its accreditation status and the exact scope of the opinion it will give.
Where residency projects go wrong
Most residency projects fail in the gaps between the data center map and the actual flow of data. Each pitfall below assumes the data is safely inside the EEA, and each shows where that assumption breaks. Every card gives a check and an owner so the question is closed before contracts are signed.
EU hosting does not end exposure
Storing data in an EU data center does not settle the transfer question when the provider is subject to third-country law. EDPB Guidelines 05/2021 (Example 12) note that an EU provider may still receive foreign authority requests, and complying with one would be a transfer. Check whether the provider has named the laws that could compel disclosure and has a documented process for challenging such requests. Owner: the DPO with legal counsel, before signature.
Do not treat DPF as permanent
The EU-US Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, is the basis many transfers to US providers rely on. An appeal in *Case C-703/25 P, Latombe v Commission* is pending, so its outcome could remove that basis. Confirm the provider's DPF status today, and keep SCCs and a transfer impact assessment ready as a fallback. Owner: legal counsel, with a review date in the transfer register.
Remote support, backups and logs
Residency projects often fix where the primary database sits and forget the other copies. A vendor engineer who views data for support from a third country creates a transfer even without copying anything, and EDPB Example 11 treats that access as a transfer. Backup replicas, log pipelines and monitoring exports can also leave the EEA. Check every copy, including backups, logs and tickets, along with its location and access path. Owner: platform engineering, reviewed by the DPO.
Missing sub-processors in the chain
Residency is only as strong as the weakest link in the processing chain. A hosting provider may use its own sub-processors for support, monitoring, email or ticketing, and any of them may sit outside the EEA. A decision made on the first contract can be undone by a sub-processor nobody reviewed. Request the full sub-processor list with locations and access types, and confirm that changes require advance notice. Owner: procurement with the DPO, refreshed at each renewal.
Questions buyers ask before deciding on residency
Does the GDPR forbid storing personal data outside the EU?
No. The GDPR does not require personal data to be stored inside the EU or the EEA. It regulates transfers, meaning disclosures of personal data to a separate controller or processor in a third country, and it regulates them under Chapter V. A flow is treated as a transfer when a GDPR-bound exporter discloses or makes data available to a recipient outside the EEA. Storage location matters because a cloud outside the EEA run by a service provider counts as a transfer, but the rule attaches to who can reach the data, not to the building it sits in. Confirm the scope of your own processing with your legal team before you design around it.
Can we use a US cloud provider under the GDPR?
Yes, in many cases, but the transfer must rest on a valid tool and be assessed. Under Article 45, a transfer can take place without specific authorisation where the Commission has adopted an adequacy decision. The United States is recognized for organizations that participate in the EU-US Data Privacy Framework, set out in Commission Implementing Decision (EU) 2023/1795. Where a provider is not certified, standard contractual clauses under Article 46 and a transfer impact assessment are the usual route. Check the provider's current certification status, its sub-processors and its exposure to foreign authority requests before signing.
What does the work require from our own organization?
The core decisions and records stay with your organization, because the controller owns its compliance. Expect to maintain an inventory of systems, providers and locations where personal data is hosted or accessed, and to review the contracts that govern each provider. You also need records of processing, a documented decision on the transfer tool for each third-country flow, and a written assessment of the laws that apply to each provider. A partner can help prepare these inventories and technical evidence, but it cannot make the legal determinations or sign off on them on your behalf.
Can our in-house team handle GDPR residency work alone?
Yes, if the team combines privacy law knowledge with hands-on control of the infrastructure. Lawyers or privacy staff need to read the Chapter V tools and the EDPB guidance, while engineers need to show exactly who can reach each system, from where and under which account. Many organizations keep the work in-house for the legal analysis and bring in an outside partner for the technical work, such as hosting in their own EEA infrastructure, restricting administrative access or producing logs. Outside help is optional, and the choice depends on the skills and capacity you already have.
What makes the residency effort larger or smaller?
The main drivers are the number of third parties with access, the location and type of support access, and the number of jurisdictions involved. Each provider that holds or can reach personal data adds a contract, a sub-processor review and possibly a transfer assessment. Remote support or administration from a third country counts as a transfer even when no data is copied, so access patterns matter as much as storage. Keeping hosting and administration inside the EEA, using employees rather than external administrators, reduces the number of flows you must justify. Ask any provider to list every location from which staff or sub-processors can access your data.
Does an certification prove GDPR compliance for our systems?
No. The GDPR does not require an audit, attestation or certificate, and no certificate removes your duty to comply. Certification under Article 42 is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce the responsibility of the controller or processor. Buyers should treat any certificate as one input and still review the transfer tool, the provider's access model and the records that support it. Only an independent auditor or certification body can issue a report or certificate, and a partner that prepares your evidence cannot issue one.
What happens if a transfer is found to be unlawful?
Transfer infringements sit in the highest fine tier. Article 83(5)(c) sets maximum fines of EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Supervisory authorities can also order the suspension of data flows under Article 58(2)(j), which may stop a service you depend on. For that reason, the most effective step is to confirm the transfer tool and the access model before go-live, not after a complaint. Ask your counsel to document the decision and the date it was taken.
How DeployOpen scopes EEA hosting and administration
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For the residency question, that means we help define where data sits and who can reach it, then prepare the systems and records that show the chosen setup matches the organization's transfer position.
How we scope
- Scope is agreed in writing before work starts, listing the systems, data stores and regions in question.
- The written scope names every party with administrative or support access, including vendors and their locations.
- Scope records which backups, logs and monitoring tools hold personal data and where each one is stored.
- Engagements are fixed-scope, with deliverables and timelines confirmed in the document before any build begins.
How we build
- Hosting is deployed in the client's chosen EEA regions within the client's own infrastructure accounts.
- Administrative access is limited to named client staff, with multi-factor authentication and logged sessions.
- Vendor or support access paths are designed so that any third-country access is either removed or documented.
- Encryption and key ownership are configured as agreed in scope, with the key holder recorded in the design.
How we hand over
- A data flow and access map shows each store, administrator, location and transfer mechanism in use.
- Configuration records, runbooks and access lists are delivered so the client's own team can operate the platform.
- Evidence for each agreed control is collected, labeled and handed over for the client's assessor or DPO to review.
- We state plainly which transfer assessments, contract terms and legal conclusions remain the client's responsibility.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-checking access paths when administrators, vendors or hosting regions change.
- Security testing of the deployed platform can be scoped separately to confirm access controls work as documented.
- Questions about legal interpretation should go to qualified counsel or the organization's data protection officer.
