A GDPR-compliant cloud architecture applies data protection by design to every layer of an application: personal data is minimised and classified, hosted in approved UK or EU regions or transferred only under a valid safeguard, encrypted with controlled keys, accessible only to authorised identities, logged without exposing personal data, kept no longer than necessary, and supported by workflows for data subject rights and breach notification. The cloud provider secures the platform, but the organisation remains responsible for how its application processes personal data. This reference design shows the controls, where they sit and how they map to GDPR and UK GDPR obligations. It is technical guidance, not legal advice; confirm requirements with your data protection officer.
Key takeaways
- GDPR does not mandate a specific technology, but Article 25 requires data protection by design and Article 32 requires appropriate security.
- Decide data residency up front: which regions host data, backups, logs and support access.
- Minimise and classify personal data so controls can be applied precisely.
- Design data subject rights, such as access and erasure, into the data model and APIs from the start.
- Keep evidence: records of processing, DPIAs, processor contracts and audit logs.
GDPR obligations that shape cloud architecture
The GDPR applies in the EU, and the UK applies an equivalent regime through the UK GDPR and the Data Protection Act 2018, with guidance from the Information Commissioner’s Office. These articles have the most direct architectural impact:
| Obligation | Article | Architecture response |
|---|---|---|
| Data minimisation, storage limitation, integrity and confidentiality | 5 | Collect only needed fields, retention policies, encryption and access control |
| Data protection by design and by default | 25 | Privacy-protective defaults, pseudonymisation, controls built in from the start |
| Processor obligations | 28 | Data processing agreements with cloud and SaaS providers; sub-processor review |
| Records of processing | 30 | Maintained data inventory and data flow documentation |
| Security of processing | 32 | Encryption, resilience, backup, regular testing of controls |
| Breach notification | 33 – 34 | Detection, alerting and an incident process able to notify within 72 hours |
| Data protection impact assessment | 35 | DPIA for high-risk processing, such as large-scale profiling or new technology |
| International transfers | 44 – 49 | Region selection, adequacy decisions or standard contractual clauses for transfers |
A GDPR-compliant cloud reference architecture
Identity and access
Use a central identity provider with multi-factor authentication, role-based access, least privilege and just-in-time elevation for administrators. Separate production access from development, and review access regularly.
Network
Keep data stores on private endpoints, not the public internet. Use a web application firewall and segment workloads that process special category data.
Application
Collect only the fields the purpose needs, record consent or the lawful basis where relevant, and expose internal APIs for data subject requests. Avoid writing personal data into URLs, error messages or analytics events.
Data
Classify data, encrypt it at rest and in transit, and use customer-managed keys where policy requires control over key access. Pseudonymise data used for analytics and testing, and never copy raw production personal data into lower environments.
Logging and monitoring
Log security events and access to personal data, but mask or exclude personal data from application logs. Set retention periods for logs as you would for any other personal data.
Backup and recovery
Keep backups in approved regions, encrypted, with tested restores. Document how erasure requests are handled for data held in backups, typically by ensuring restored data is re-processed against erasure records.
Data residency and international transfers
Choosing UK or EU regions for primary data is the simplest way to reduce transfer risk, but it is not the whole picture. Check where backups, disaster recovery copies, logs, support personnel and AI model processing are located. Major providers publish commitments, such as the Microsoft EU Data Boundary. Where data must leave the UK or EU, use a valid transfer mechanism, such as an adequacy decision or standard contractual clauses, as described by the European Data Protection Board.
If your delivery partner works from outside the UK or EU, design access so that their engineers do not need routine access to production personal data, for example by using pseudonymised test data and controlled, logged support access.
Designing for data subject rights
Individuals have rights to access, rectify, erase, restrict and port their data, and to object to certain processing. These requests must normally be answered within one month. Architecture makes this feasible:
- Use a consistent person identifier across services so all records for one individual can be found.
- Maintain a data map that lists every store holding personal data, including search indexes, caches and analytics.
- Build internal APIs for export and erasure in each service, orchestrated by one workflow.
- Log each request and its completion as evidence.
GDPR and AI features
Adding AI to an application brings additional considerations: whether personal data is sent to a model provider and where it is processed, whether prompts and outputs are retained, how data used for retrieval respects access rights, and whether automated decisions with significant effects require human involvement under Article 22. A DPIA is usually appropriate. Our guide to AI-ready data covers classification and permissions, and LLM guardrails covers filtering personal data in prompts and responses.
GDPR cloud architecture checklist
| Area | Check |
|---|---|
| Inventory | Every store of personal data is mapped, including logs, caches and backups |
| Residency | Regions for data, backups, logs and support access are documented |
| Transfers | Any transfer outside the UK or EU has a valid mechanism |
| Access | MFA, least privilege, access reviews and privileged access logging |
| Encryption | At rest and in transit; key management documented |
| Minimisation | Only necessary fields collected; pseudonymised data outside production |
| Retention | Retention periods enforced automatically, including logs |
| Rights | Export and erasure workflows tested end to end |
| Incidents | Detection and a tested process to notify within 72 hours |
| Evidence | Records of processing, DPIAs and processor agreements current |
Serving clients across the region? See how we work with teams in the UK, Europe, Ireland and the Netherlands.
Common questions
Is a cloud application GDPR compliant if it is hosted in an EU region?
Not automatically. Region choice helps with transfers, but compliance also depends on lawful basis, minimisation, security, retention, rights handling, processor agreements and records.
Who is responsible for GDPR in the cloud, the provider or us?
Both have duties. The provider, usually as a processor, secures its platform under a data processing agreement. Your organisation, as controller, remains responsible for how the application processes personal data.
Is UK GDPR different from EU GDPR?
They are closely aligned but separate regimes, with different regulators and transfer rules. Applications serving both should be designed to meet both.
Do we need a DPIA for a new cloud application?
A DPIA is required when processing is likely to result in high risk, for example large-scale processing of special category data or new technologies such as some AI uses. Your data protection officer can confirm.
How do we handle erasure for data in backups?
A common approach is to keep backups encrypted and time-limited, record erasure requests, and re-apply them to any data restored from backup.
Build a cloud application that is private by design
Share your application’s data flows and target markets. Our cloud and DevOps and software development teams will design the controls with your data protection officer and build them into the platform from day one.