What GDPR expects from the platform, and what it does not
GDPR is Regulation (EU) 2016/679. Most of it is about organisations, not infrastructure: lawful basis, transparency, rights, records and accountability. But a handful of requirements land squarely on your cloud platform. Article 32 asks for appropriate technical and organisational measures to secure processing. Article 28 governs the relationship with processors. Chapter V governs transfers of personal data to third countries.
Our job on a GDPR and EU data residency engagement is narrow and practical: make the technical measures real, enforced and provable inside your AWS, Azure or Kubernetes environment. We are a DevOps and cloud consultancy, not a law firm or an auditor. We hold no company-level certification, and nothing we build makes you compliant on its own. Compliance is owned by you and your advisers. If you want the wider picture across frameworks, see the compliance hub.
Processor role and DPAs in practice
Your cloud provider is a processor for the personal data you place on it. Any consultancy with access to your accounts, including us, can also be a processor or subprocessor. Article 28 expects a written contract covering instructions, confidentiality, security, subprocessors and deletion or return of data.
In practice the technical side of a DPA is an access question:
- Who can reach personal data, through which role, from which network?
- Is access time-limited and logged?
- Does any data leave your accounts for a vendor’s systems?
We usually work inside your cloud accounts with scoped roles, and we sign a data processing agreement where we may process personal data. We do not copy production data to our own systems. Our standards are summarised in the Trust Center. Whether a given arrangement makes someone a processor, joint controller or something else is a legal call, so confirm it with your adviser.
Choosing and enforcing EU regions
Choosing a region is a business decision. Enforcing it is an engineering one. A wiki page saying “use eu-central-1” fails the first time someone runs a quick experiment from a laptop. You want preventive guardrails at the organisation level.
Region restriction policies as code
On AWS, a service control policy attached to the organisation or an OU can deny requests outside approved regions. A simplified example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideApprovedEURegions",
"Effect": "Deny",
"NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*", "support:*", "sts:*"],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
}
}
}
]
}
The NotAction list exists because some AWS services are global and are served from a single endpoint. The exact list depends on what you use, so we test it in a sandbox OU before it touches production.
On Azure, the built-in Allowed locations policy, assigned at a management group, blocks deployments to other regions. In Google Cloud, the constraints/gcp.resourceLocations Organisation Policy does the same:
constraint: constraints/gcp.resourceLocations
listPolicy:
allowedValues:
- in:eu-locations
Two caveats we always raise. First, these policies control where resources are created. They do not control what an application sends to a SaaS tool or a third-party API. Second, some managed services replicate or process data in ways that are documented per service, so we read the provider documentation rather than assume.
We manage all of this in Terraform so changes go through pull requests, and we scan modules with Checkov in CI to catch resources defined with disallowed regions before they reach an apply. See our Terraform infrastructure as code service for the delivery model, and the AWS, Azure and Google Cloud pages for platform specifics.
Encryption and key management
Article 32 names encryption as an example of an appropriate measure. For the platform that means:
- Encryption at rest on every data store, with customer managed keys (AWS KMS, Azure Key Vault, Google Cloud KMS) where you want control over rotation and revocation.
- Keys in the same residency boundary as the data, with key policies that separate who administers keys from who uses them.
- TLS in transit, including between services inside the cluster where the data sensitivity justifies it.
- Secrets kept out of Git and out of container images, using HashiCorp Vault or the cloud’s native secret store.
Customer managed keys add operational cost and a real risk: delete or lose a key and the data is gone. We document recovery and deletion protection for every key we create.
Access and logging
Auditors and regulators ask who accessed what, and whether you would know. The baseline we implement:
- Least privilege roles, single sign-on, no long-lived human credentials, and Kubernetes RBAC mapped to those identities.
- Organisation-wide audit trails (CloudTrail, Azure Activity Log, Cloud Audit Logs) delivered to a locked-down log account in an EU region.
- Retention periods you set, because logs themselves can contain personal data such as IP addresses and user identifiers. Keeping them forever is not a safe default.
- Alerts on risky actions: disabling logging, changing a region policy, broad data exports.
Our logging service covers application logs. The practical rule is to keep personal data out of logs where you can, and to treat logs as a data store with its own retention.
Data subject request readiness at the platform level
Rights requests, such as access and erasure, are handled by your organisation. The platform determines how hard they are. We help with the engineering prerequisites:
- A data inventory: which databases, buckets, queues, caches and analytics stores hold personal data, tagged consistently.
- A way to find one person’s records across those stores using a stable identifier.
- A tested deletion path, including search indexes and derived datasets.
- A documented position on backups, since erased records may persist there until the backup expires.
Backups and retention
Backups are personal data stores too. We configure backup vaults and replication to stay within approved EU regions, apply retention you choose, and test restores. Where erasure matters, the usual approach is short enough backup retention plus a procedure to re-apply deletions after a restore. Our backup and disaster recovery service covers the mechanics.
International transfers and subprocessors
Transfers outside the EU are governed by Chapter V, and which mechanism applies is a legal question we leave to your adviser. Technically, we make transfers visible: egress restrictions, a register of the SaaS and cloud services that touch personal data, and an inventory of the support and administrative access paths that providers and consultancies use. A subprocessor list is only as good as the engineering inventory behind it, and that inventory is what we help you build.
Evidence
The point of continuous controls is that evidence is a by-product. A typical mapping:
| Requirement area | Technical control we implement | Evidence it produces |
|---|---|---|
| Residency | SCP, Azure Policy or Organisation Policy for allowed regions | Policy definitions in Git, deny events in audit logs, policy compliance reports |
| Security of processing | Encryption at rest and in transit, key policies | Configuration snapshots, key inventory and rotation settings |
| Access control | SSO, least privilege roles, Kubernetes RBAC | Access review exports, role definitions in Git |
| Logging | Central audit trails with defined retention | Log retention configuration, sample queries |
| Backup and erasure | EU-only backups, restore tests, deletion runbook | Restore test records, retention settings |
| Change management | Pull requests, CI policy checks | PR history, pipeline results |
What we do not do
- We do not give legal advice or interpret GDPR for your situation.
- We do not act as your DPO, run data protection impact assessments or notify regulators.
- We do not write your privacy notices, records of processing or organisational policies.
- We do not certify, audit or issue an opinion on compliance.
Common misunderstandings
- “EU region means GDPR done.” Residency is one control among many.
- “Encrypted means safe.” If every engineer can decrypt everything, encryption helps little.
- “We deleted it, so it is gone.” Backups, logs and replicas may still hold it.
- “Policy as code is the same as legal approval.” Code enforces a decision. Someone still has to make it.
If your main need is legal interpretation, a data protection impact assessment, or advice on transfer mechanisms, hire a privacy lawyer or specialist consultancy first, then bring us in to implement. Related frameworks include NIS2 technical controls, DORA ICT third party risk and SOC 2 and ISO 27001 readiness. To scope work, start with the Cloud DevOps Health Check or the landing zone sprint, or contact us.