The GDPR does not require private cloud. But private cloud eliminates entire categories of compliance risk that public cloud providers — particularly those subject to US jurisdiction — cannot resolve through contracts alone.
GDPR mandates accountability. You cannot be accountable for data you do not control.
GDPR is not primarily a data residency regulation — it is an accountability framework. Article 5(2) requires the controller to demonstrate compliance with every data protection principle. Article 24 mandates "appropriate technical and organisational measures." Article 25 requires data protection by design and by default.
These obligations are difficult to discharge when your data sits on infrastructure operated by a third party, in a jurisdiction that claims extraterritorial access rights, managed by personnel you have never vetted, under terms of service that change unilaterally.
Public cloud providers operate a shared-responsibility model: they secure the infrastructure, you secure your data. In theory this works. In practice, the controller remains fully liable under GDPR regardless of what the processor's contract says.
When a supervisory authority investigates a breach, they do not accept "our cloud provider handles that" as an answer. They ask: what measures did you implement? Can you demonstrate them? With private infrastructure, you can. With a hyperscaler, you are relying on their attestations — and hoping the supervisory authority accepts them.
The CJEU did not just invalidate Privacy Shield. It made clear that US surveillance law is incompatible with EU fundamental rights.
FISA Section 702 and Executive Order 12333 grant US intelligence agencies access to data held by US companies — regardless of where the data is physically stored. An "EU region" does not change the legal jurisdiction of the provider.
In July 2020, the Court of Justice of the European Union (Case C-311/18) invalidated the EU-US Privacy Shield. The court found that US surveillance programmes — particularly FISA 702 — are not limited to what is strictly necessary and lack effective judicial redress for EU data subjects.
The ruling did not merely remove one transfer mechanism. It established that any data transfer to the US requires a case-by-case assessment of whether "supplementary measures" can provide "essentially equivalent" protection.
The European Commission adopted an adequacy decision for the EU-US Data Privacy Framework (DPF) in July 2023, based on Executive Order 14086. This is the successor to Privacy Shield. It introduces a Data Protection Review Court and proportionality requirements for US intelligence access.
However, the DPF faces the same structural vulnerability as its predecessors: it relies on executive action, not legislative change. FISA 702 was reauthorised in April 2024. Privacy advocates have signalled a "Schrems III" challenge. Organisations building long-term compliance strategies should not treat the DPF as settled law.
If you process personal data using a US-headquartered cloud provider, you must either rely on the DPF (which may be invalidated) or conduct a Transfer Impact Assessment and implement supplementary measures under Standard Contractual Clauses.
With EU-jurisdiction private cloud infrastructure, this entire compliance layer disappears. No international transfers. No Transfer Impact Assessments. No dependency on political agreements between Washington and Brussels. The data stays under EU law, full stop.
Article 28 GDPR governs the controller-processor relationship. When you use a cloud provider, that provider is a processor (or sub-processor) of personal data. Article 28 requires a binding contract that specifies:
Article 28(3)(h) requires that the processor "makes available to the controller all information necessary to demonstrate compliance" and "allows for and contributes to audits, including inspections."
In practice, hyperscalers do not permit on-site audits of their data centres. They offer SOC 2 reports and ISO 27001 certificates as substitutes. Some supervisory authorities accept this; others do not. The EDPB has stated that reliance on certifications alone may not satisfy Article 28 audit obligations in all circumstances.
With private infrastructure, you are the operator. There is no controller-processor relationship for the infrastructure layer itself. You can audit every component, inspect every configuration, and demonstrate compliance directly — without relying on a third party's willingness to open their doors.
| GDPR Requirement | Public Cloud Challenge | Private Cloud Approach |
|---|---|---|
| Data Residency Articles 44-49 |
Data may traverse non-EU jurisdictions for processing, backup, or support. Provider metadata and telemetry often flows to US headquarters. "EU region" does not guarantee no data leaves the EU. | Data resides on hardware you own or lease, in a jurisdiction you choose. No cross-border transfers unless you explicitly configure them. |
| Right to Erasure Article 17 |
You can delete data from your application layer. But can you verify it was erased from all backup tiers, logs, caches, and CDN edge nodes? The provider's retention policies may conflict with your erasure obligations. | You control every storage tier. You can cryptographically verify deletion across all layers — block storage, object storage, backups, and logs. |
| Data Protection by Design Article 25 |
You design your application for privacy. But the infrastructure beneath it was designed for multi-tenancy and telemetry collection. The provider's design priorities are not your design priorities. | You design the entire stack — from network topology to storage encryption to access controls — with data protection as a foundational requirement. |
| Breach Notification Articles 33-34 |
You must notify the supervisory authority within 72 hours. But if the breach occurs at the infrastructure layer, you depend on the provider to detect and inform you in time. Their SLA may not guarantee this. | You operate the infrastructure. You detect incidents directly. Your monitoring, your alerting, your timeline — no dependency on a third party's incident response process. |
| Data Processing Agreements Article 28 |
Hyperscaler DPAs are non-negotiable. They cover thousands of sub-processors. The list changes regularly. You accept their terms or you do not use the service. | You select each sub-processor individually. DPAs are negotiated bilaterally. The sub-processor chain is short, transparent, and under your control. |
| Records of Processing Article 30 |
You maintain records for your application. But the provider processes data for their own purposes — telemetry, billing, support — and you may not have full visibility into those activities. | Every processing activity on your infrastructure is logged and auditable. There are no hidden processing activities because there is no third party with independent access. |
Article 28(2) requires prior specific or general written authorisation before a processor engages a sub-processor. Major cloud providers maintain lists of hundreds of sub-processors — support teams, infrastructure partners, security vendors, analytics providers — that change frequently.
Under general authorisation, the processor must inform you of changes and give you the opportunity to object. In practice, objecting means leaving the platform. This is not meaningful oversight; it is a notification with no practical recourse.
With private infrastructure, the sub-processor chain is minimal and fully under your control. You choose the hardware vendor, the data centre operator, the support provider. Each relationship is governed by a DPA you negotiated. If a sub-processor is unsatisfactory, you replace them — without rebuilding your entire infrastructure.
Article 35 requires a Data Protection Impact Assessment when processing is "likely to result in a high risk." Infrastructure choices directly affect your DPIA outcomes.
Large-scale processing of special categories of data (health, biometric, genetic), systematic monitoring of public areas, and automated decision-making all trigger DPIA requirements. If your infrastructure processes any of these data types, the choice of cloud platform is a material factor in the assessment.
A DPIA must assess the necessity and proportionality of processing, risks to data subjects, and measures to mitigate those risks. Using a US-jurisdiction processor for sensitive EU personal data introduces transfer risk, surveillance risk, and sub-processor risk that must all be documented and mitigated.
When infrastructure is EU-based, EU-operated, and under your direct control, the DPIA for the infrastructure layer is straightforward: no international transfers, no third-party surveillance risk, auditable access controls, and a minimal sub-processor chain. The risk profile is fundamentally different.
Understand where your current cloud infrastructure creates GDPR compliance exposure and what EU-jurisdiction alternatives exist.