GDPR compliant infrastructure: what it actually requires.

This page is an engineering perspective on GDPR. It is not legal advice. Consult your DPO or legal counsel for regulatory interpretation specific to your situation.

The four architectural questions

Every GDPR conversation eventually reduces to four questions about the infrastructure. If you cannot answer all four with specifics, the paperwork does not matter.

1. Where is personal data physically stored? Not "in the cloud" — which data centre, in which country, under which jurisdiction.
2. Who can technically access it? Including subprocessors, cloud provider engineers, backup services, CDN providers, analytics vendors.
3. Who holds the encryption keys? If the cloud provider holds both the data and the keys, the data is effectively readable by them, regardless of any legal agreement.
4. How would you prove, on a regulator request, that the above has held for the last 12 months? Audit logs, change history, access records.

Data residency: the Schrems II reality

After the Schrems II ruling (July 2020), transfer of EU personal data to the US became legally risky by default. Standard Contractual Clauses (SCCs) alone are insufficient; they require "supplementary measures" — typically encryption with keys held outside the reach of US authorities — to bridge the gap. For most businesses, the simplest architectural answer is to not make the transfer in the first place.

What this means in practice for your infrastructure:

• Primary compute, storage and databases hosted within the EU. Not "region=EU" in an account run by a US-headquartered provider with US-subpoenable data access — actually on EU-operated infrastructure.
• CDN POPs: EU-only, or use a provider that can contractually and technically guarantee no US edge for your traffic.
• Email delivery (transactional and marketing): EU-based ESPs. Many of the popular ones are US-owned and process in the US.
• Analytics: server-side, EU-hosted, or a privacy-preserving alternative to Google Analytics.
• Error tracking: self-hosted or EU-region-only (Sentry, for example, offers an EU region).

The subprocessor chain nobody maps

When we audit an existing environment for GDPR fitness, the single most common finding is an unmapped subprocessor chain. The main app is on EU infrastructure — good. But the image-optimisation API it calls is US-hosted. The email deliverability platform is US-owned with US data flow. The error tracker is US-default. The analytics pipeline goes through a US tag manager. Each of those is a separate data flow that needs to be documented, and — under Schrems II — each needs a legal basis for any US transfer.

Our Article 28 DPA lists every subprocessor by name, jurisdiction and role. We require the same discipline from subprocessors we use on client environments.

Encryption key custody: BYOK vs. HYOK vs. provider-managed

Encryption at rest is necessary but not sufficient. The question is who holds the keys.

• Provider-managed keys — The cloud provider encrypts your data with keys they generate and hold. Operationally simplest. Offers no protection against the cloud provider itself being compelled to decrypt.
• Bring Your Own Key (BYOK) — You generate the key and upload it to the provider's key management service. The provider still holds a working copy at runtime. Better than provider-managed for compliance narratives, marginally so in technical reality.
• Hold Your Own Key (HYOK) — You run the key management service yourself (often in a different cloud or on-premises). Every decryption is a network call from the cloud provider to your HSM. Operationally harder; genuinely different trust model.

For most mid-market businesses, BYOK with a European key management provider is the pragmatic sweet spot. HYOK is for healthcare, finance and public-sector workloads where the threat model includes the cloud provider itself.

Audit-ready from day one

When a supervisory authority or a large B2B prospect asks for proof of compliance, you have weeks to produce it, not months. That means the evidence needs to exist continuously, not be assembled on demand.

What we set up on every GDPR-sensitive environment:

• Write-once audit logs for every administrative action, stored separately from the primary environment so they cannot be altered by someone who gained access.
• Access records: every SSH session, every admin login, every database query run outside of the application path.
• Change management with signed-off change windows. Every production change leaves a documented trail.
• Backup verification reports — audits often ask not just "do you have backups" but "have you proven they work, and when".
• Continuous infrastructure-as-code state so the exact configuration of the environment on any given past date is reproducible from git history.

Where Binadit fits in your DPO's map

As your managed infrastructure partner we are a Data Processor under Article 28 GDPR. Our DPA is available at binadit.com/dpa. We operate from the Netherlands, which falls under the EU GDPR and the Dutch UAVG. Our subprocessors for infrastructure services are documented and EU-based. Our Article 28 obligations — security, subprocessor transparency, breach notification, audit cooperation, data return on termination — are built into the engagement model, not stapled on afterwards.

Related engineering content