GDPR Hosting Requirements: A Buyer’s Checklist

Image

GDPR does not mandate where you host data. It mandates how you protect it, who processes it, and what happens when something goes wrong.

Two articles carry most of the weight when you’re making hosting decisions:

• Article 28 governs the contractual relationship between you (the controller) and your hosting provider (the processor).
• Article 32 sets the baseline for technical and organizational security measures. Together, they define what a compliant hosting arrangement looks like.

A data controller determines why and how personal data is processed. If you run a website that collects EU visitor data, you are the controller. A data processor processes data on the controller's behalf. Your hosting provider is a processor. The processor acts only on documented instructions from the controller.

This distinction is important when assessing providers because liability follows it. Controllers are accountable for choosing compliant processors. Processors are accountable for following instructions and securing infrastructure. Both can face fines independently.

Key GDPR hosting requirements overview

Five areas define the hosting relationship under GDPR. We’ll cover each in more detail across this article, but here’s the landscape at a glance:

• Data residency and transfers require a lawful basis for any transfer of personal data outside the EEA, even though GDPR does not mandate EU-based servers. If your provider is US-based, you must implement a valid transfer mechanism such as the EU-US Data Privacy Framework (DPF) or Standard Contractual Clauses (SCCs).
• Data processing agreements require a signed Data Processing Agreement (DPA) between controller and processor before any processing begins under Article 28. Generic terms of service do not meet GDPR contractual requirements.
• Technical and organizational measures (TOMs) require encryption, access controls, monitoring, governance policies, and regular testing appropriate to the risk level of the data processed under Article 32. Security controls must be documented and proportionate to the likelihood and severity of potential harm.
• Data breach notifications require processors to notify controllers without undue delay after becoming aware of a personal data breach. Controllers must notify the relevant supervisory authority within 72 hours unless the breach is unlikely to result in risk to individuals’ rights and freedoms.
• Data subject rights and support require hosting infrastructure that enables compliance with erasure, portability, rectification, and related rights. The controller fulfills these requests, and the processor must provide the technical capability to support that fulfillment.

These controls should also align with GDPR’s core principles of data minimization and purpose limitation under Article 5, ensuring systems collect and retain only the personal data necessary for the stated purpose.

What your DPA must include under Article 28

Article 28 requires a binding contract before any processing begins.

Under the shared responsibility model, the hosting provider (processor) secures the infrastructure while the customer (controller) secures the application, the data it collects and the lawful basis for collecting it.

In agency-led engagements, the structure may involve an additional layer. The controller may appoint an agency as processor, and the agency may appoint the hosting provider as a sub-processor. In that model, the controller contracts with the agency under Article 28, and the agency must flow down equivalent Article 28 obligations to the hosting provider. Each processor remains fully liable for its sub-processors.

Every DPA must specify the subject matter, duration, nature and purpose of processing. It must name the types of personal data involved and the categories of data subjects.

The processor commits to acting only on documented instructions, maintaining confidentiality, implementing Article 32 security measures and assisting with data subject requests and breach notifications. The controller retains audit rights. At contract end, the processor must return or delete all personal data.

Article 28(2) requires processors to notify controllers before appointing new sub-processors. While the regulation does not prescribe a specific timeline, a 30-day notice period might be considered reasonable. In managed hosting, however, a more practical standard would be 14 days’ advance notice. Controllers are given a right to object. If an objection cannot be resolved, the controller generally retains the right to terminate.

Processors bear full responsibility for sub-processor failures. The controller may seek damages from the processor for a vendor’s breach or non-compliance.

Processors must execute appropriate DPAs and, where required, SCCs with all sub-processors. They should maintain a documented vendor risk review process with periodic reassessment.

Adequate cyber insurance must cover vendor-related incidents and supply chain failures.

Pantheon publishes its DPA and sub-processors list.

Article 32 security requirements in practice

Article 32 requires "appropriate technical and organizational measures" to match the level of risk. The regulation names four specific capabilities:

• Pseudonymization and encryption of personal data.
• Ongoing confidentiality, integrity, availability, and resilience of processing systems.
• The ability to restore access after an incident.
• A process for regular testing of those measures.

When evaluating a hosting provider, verify controls across several domains:

• Data encryption at rest (AES-256 or equivalent) and in transit (TLS 1.3), with keys managed separately.
• Access control should include role-based permissions with multi-factor authentication on administrative accounts.
• Network security should cover firewalls, intrusion detection, DDoS mitigation, and segmentation between customer environments.
• Backup and recovery should include automated backups with tested restoration procedures.
• Monitoring should provide centralized logging, real-time alerting and audit trails.

Article 25 (Data Protection by Design) should be considered during system and infrastructure design reviews, including how servers and logging are configured:

• IP addresses are personal data under GDPR, and default web server configurations often log them indefinitely.
• Customer-accessible web and application logs should be rotated or deleted after 30–60 days unless a longer retention period is justified.
• Truncate or anonymize addresses where full precision is unnecessary, and disable logging modules that capture identifiers beyond your stated purpose.

This doesn’t eliminate the need for longer retention of internal security and audit logs. Providers may retain infrastructure and security telemetry for extended periods, often up to 12 months, to support threat detection, incident response and forensic investigation.

Controllers should distinguish between operational application logs and internal security logs when documenting retention practices.

Pantheon’s security includes managed HTTPS with TLS 1.2 and 1.3 through automated Let's Encrypt. Container isolation and immutable production code are documented. Encrypted secrets management protects credentials. Google Cloud infrastructure handles physical security and resilience.

Transferring data outside the EEA

GDPR does not require EU data residency. It requires a lawful mechanism for any transfer outside the European Economic Area.

The current hierarchy starts with adequacy decisions. The EU-US DPF, adopted in July 2023, restored adequacy for certified US organizations. Where adequacy does not apply, SCCs using the 2021 EU Commission templates are required.

Some organizations also choose to maintain SCCs alongside DPF certification as an additional safeguard, given the evolving legal landscape around transatlantic data transfers.

When relying on SCCs, you must complete a Transfer Impact Assessment (TIA) to evaluate whether the destination country's legal framework undermines the protections in the clauses. It also helps you determine what supplementary technical, contractual, or organizational measures are required to mitigate identified risks.

Two related concepts – data residency and sovereignty – are often confused. Data residency refers to the physical location of servers. Data sovereignty refers to legal jurisdiction. A US-headquartered company hosting data in Belgium is still subject to US law, including FISA 702 and the CLOUD Act. Physical residency alone does not resolve jurisdictional exposure. That is what DPF certification, SCCs and TIAs address.

One question worth asking directly is does the provider route support tickets, monitoring data, or telemetry through US infrastructure even when primary data sits in the EU? The answer determines whether you need SCCs for operational data flows, not just storage.

Breach notification responsibilities

GDPR creates a two-stage notification obligation split between the processor and controller.

The hosting provider (processor) must notify the controller without undue delay after becoming aware of a breach. While GDPR does not prescribe a fixed processor deadline, many controllers contractually require notification within 24 hours to preserve their ability to assess risk, seek legal relief, and meet supervisory authority deadlines.

The processor must supply enough detail for the controller to act: nature of the breach, approximate number of data subjects affected, likely consequences and measures taken.

The controller must then notify the relevant supervisory authority within 72 hours of becoming aware. If the risk to individuals is high, the controller must also notify the affected data subjects directly. Under EDPB guidance, the controller is often considered "aware" as soon as the processor becomes aware. Therefore, any delay by the provider in notifying you consumes your 72-hour window.

Your hosting provider's response capability directly determines your ability to meet this window. To verify this capability:

• Evaluate whether the provider runs continuous monitoring with automated alerting.
• Check that logs are retained long enough for forensic investigation (90 days minimum is a reasonable baseline).
• Confirm the provider has a documented incident response runbook with defined escalation timelines, and a dedicated security contact separate from general support.

If the provider’s contractual notification SLA is 24 hours, you effectively have 48 hours remaining within the 72-hour supervisory authority window.

Pantheon runs more than a million health checks daily. Centralized security logs are retained for a year. The company maintains a practiced incident response program with documented procedures.

How hosting enables data subject rights

The obligation to respond to data subject requests belongs to the controller. The processor must assist, but the hosting provider's role is to supply the infrastructure that makes fulfillment possible.

For erasure requests, the controller must remove data from all systems, including the hosting environment. Application-layer deletion is straightforward. Backups are more complicated.

Most providers retain automated backups on a rolling schedule of 7 to 30 days. Data persists in those backups until the retention window expires. Confirm the schedule, whether the provider supports selective purging, and document a reasonable timeframe for full deletion. Account for backup expiry when responding to the data subject.

For portability requests, data subjects can request their data in a structured, machine-readable format. This is an application-level function, but hosting infrastructure affects whether you can execute it reliably through database export tools, API access, or sufficient compute for large export jobs.

For rectification, data subjects can request correction of inaccurate records. The hosting requirement is that your environment provides the access and tooling to locate and update data.

Your DPA should explicitly state the processor's obligation to assist with these requests, including cooperation timelines.

Documentation and audit checklist

Compliance is documentation. If you can’t demonstrate it, regulators will not assume it.

Maintain a signed DPA with your hosting provider meeting all Article 28 requirements. If data transfers outside the EEA occur, keep SCCs on file (2021 EU Commission templates) alongside a Transfer Impact Assessment.

You need a current sub-processor list from your provider with roles and locations for each entity. Security certifications should be on file, along with documentation of encryption standards, access control policies, patch management SLAs and network architecture.

Backup retention periods and the process for honoring erasure requests should be documented separately. This includes retention schedules and a policy prohibiting the restoration of data that has been deleted in response to an erasure request.

On certifications, independent third-party audits demonstrate control effectiveness but do not replace contractual GDPR obligations.

SOC 2 Type II provides an auditor attestation that security controls are designed and operating effectively over a defined review period. The report is confidential and shared under NDA.

Some providers also pursue ISO 27001 certification, which requires implementation and external audit of a formal information security management system.

Certifications support, but do not guarantee, GDPR compliance. The focus should remain on documented technical and organizational measures under Article 32 and the contractual safeguards required by Article 28.

Choosing a managed hosting approach

Three models serve GDPR compliance, each with different trade-offs.

A US-based provider with DPF/SCCs and EU region options offers mature platforms, global scale and established DPA templates. The trade-off is US jurisdiction. You need to validate DPF certification, execute SCCs and potentially complete a TIA. Operational data may still flow through US infrastructure.

A common architecture uses an EU-facing domain or CDN edge location while routing all application processing and data storage to US data centers. Domain location does not determine processing location. If personal data is transmitted to or accessed from the US, the transfer rules apply regardless of where the domain is registered or where DNS resolves.

A multi-region EU provider removes the need for cross-border transfer mechanisms and avoids US jurisdictional exposure. The compliance posture is simpler. The trade-off is potentially a smaller scale and fewer integrations with US-based SaaS tools. Article 32 verification requirements still apply.

An EU-only "Sovereign Cloud" provider guarantees all processing, storage, and administration occur exclusively within the EU. This is the strongest position for highly regulated industries. The trade-off is limited provider options, higher cost and potential restrictions on global CDNs or support teams in other time zones.

Pantheon fits the first category. It’s a US-headquartered, DPF-certified managed hosting provider running on Google Cloud Platform infrastructure. An EU data residency option is available under Global Regions. This provides EU hosting where all site components and backups remain in-region.

Making your decision

Think about your data. What personal data do you collect, where are your data subjects located and what is the risk level if that data is exposed?

Your DPA must be signed and specific. Generic terms of service don’t satisfy Article 28. Verify it covers sub-processor notification and objection rights.

Your transfer mechanism must match your architecture. If data leaves the EEA for any reason, whether for support, monitoring or analytics, you need SCCs and a TIA at minimum. DPF adequacy applies if the destination is a certified US organization.

Your provider's security controls must be documented and verifiable. Request certifications. Confirm log retention and backup deletion schedules.

Your incident response plan must account for your provider's timeline. The 72-hour clock does not pause while you wait for information.

Your infrastructure must support data subject rights. Backups eventually expire. Make sure you know when, and that the timeline is defensible.

GDPR compliance is not a product feature you can purchase. It is the result of how you architect your systems, what contracts you sign and how you operate day to day.

Pantheon's GDPR compliance documentation is available right now for your consideration. If you’re convinced, start building on Pantheon today!