Most organisations treat GDPR compliance as a legal and process problem: privacy policies, consent banners, DPA agreements with vendors. These are necessary — but they're not sufficient. The real compliance risk is architectural: data that flows through systems without control, personal data stored in places nobody planned, retention that was never enforced.
Privacy by Design means building data protection into your architecture from the start. Not as a constraint you work around, but as a design principle that shapes your technical decisions.
The Seven Privacy by Design Principles
Privacy by Design was originally formulated by Dr. Ann Cavoukian, former Privacy Commissioner of Ontario, and is now enshrined in GDPR's Article 25. The seven principles are:
- Proactive, not reactive — Anticipate and prevent privacy-invasive events before they occur, rather than remediating them after
- Privacy as the default — Systems should automatically protect personal data without requiring users to take action to enable privacy
- Privacy embedded into design — Privacy is not bolted on as an add-on; it's integral to the architecture
- Full functionality — positive sum — Privacy and functionality are not in conflict; both can coexist without trade-offs
- End-to-end security — Full lifecycle protection of personal data from collection to deletion
- Visibility and transparency — Systems and data practices are open to independent verification
- Respect for user privacy — Keep user interests at the centre of all decisions
These are principles, not checklists. The question is: how do they translate into concrete architecture decisions?
Principle 1: Data Minimisation Architecture
GDPR's data minimisation principle (Article 5(1)(c)) requires that you collect only the data that is necessary for your specified purpose. This is primarily a design decision.
At the API layer: Define exactly which fields you collect for each use case. Review every POST and PUT endpoint — does it accept data you don't need? Remove unnecessary fields from your schemas. Every field you don't collect is data you can't leak, breach, or misuse.
At the database layer: Resist the "collect everything, analyse later" pattern. Every column containing personal data should have a documented purpose. Implement a data inventory (Record of Processing Activities — ROPA) that maps data fields to processing purposes.
For analytics: Use aggregated and anonymised metrics where possible. Differential privacy techniques allow you to derive statistical insights from datasets without exposing individual records. For product analytics, evaluate whether you need raw user events or whether aggregate metrics would serve the same purpose.
The ROPA as a living document
GDPR requires a Record of Processing Activities (ROPA). Rather than treating it as a compliance document produced once and forgotten, treat it as a technical artefact maintained alongside your data models. When you add a new database table or field, update the ROPA. This keeps your legal records aligned with your actual system.
Principle 2: Purpose Limitation in Architecture
Purpose limitation (Article 5(1)(b)) requires that data collected for one purpose is not reused for another. This is harder than it sounds in practice, because data tends to accumulate and get repurposed informally.
Logical data separation: Store data collected for different purposes in separate tables or databases, with explicit access controls. Marketing data should not be accessible to the customer support system without an explicit justification and access grant.
Event-sourced audit trail: For systems that process personal data, maintain an immutable audit log of every access and processing event. This provides evidence of purpose-limited processing and enables you to reconstruct data lineage for compliance audits.
Data access controls by purpose: Implement attribute-based access control (ABAC) that encodes purpose into the access model. A data analyst should be able to query for marketing analytics purposes but not access raw customer support transcripts.
Principle 3: Data Residency and Sovereignty on Azure
GDPR restricts international transfers of personal data (Chapter V). Transfers to countries without an adequacy decision require additional safeguards. For cloud architecture, this means knowing where your data is processed and stored at all times.
Azure data residency controls:
- Region selection: Specify the Azure region at resource provisioning. EU personal data should be stored in EU regions (e.g., West Europe / Netherlands, North Europe / Ireland, Germany West Central, France Central).
- Paired regions: Azure's cross-region replication uses paired regions. Ensure your pair is within the same geographic boundary — EU-to-EU replication for EU personal data.
- Service-level controls: Some Azure services (e.g., Microsoft Entra ID, Azure Cognitive Services) may process metadata outside your selected region. Review the data residency documentation for every service you use.
- Disable cross-geo replication: For storage accounts and databases, explicitly disable geo-replication or configure it to a compliant paired region.
Third-party services and data transfers
Every third-party SaaS tool that processes EU personal data — analytics platforms, support tools, CRM systems, email providers — is a data processor under GDPR. You need a Data Processing Agreement (DPA) with each one, and you need to verify they have appropriate safeguards for cross-border transfers (e.g., Standard Contractual Clauses for transfers to the US).
Principle 4: Encryption Architecture
GDPR doesn't mandate encryption explicitly, but Article 32 requires "appropriate technical measures" — and encryption is consistently identified in guidance as one of those measures. More practically, a documented breach of encrypted data with customer-managed keys, where the keys were not compromised, is much less likely to trigger notification obligations.
Encryption architecture decisions:
Encryption in transit: TLS 1.2 minimum, TLS 1.3 preferred, for all data in transit. Enforce this at the load balancer/API gateway level. Never allow plain HTTP for any endpoint that handles personal data.
Encryption at rest: Enable Azure Storage Service Encryption (SSE) for all storage accounts (enabled by default). For databases, enable Transparent Data Encryption (TDE). These encrypt the physical storage but the encryption is managed by Microsoft.
Customer-Managed Keys (CMK): For highly sensitive data or regulatory requirements that mandate customer control, use Azure Key Vault-managed keys. CMK gives you control over the encryption key — including the ability to revoke access instantly by deleting the key. This is the architecture that makes "crypto-shredding" possible (see below).
Field-level encryption: For the most sensitive personal data (financial details, health data, biometrics), consider application-level field encryption — data is encrypted before it enters the database, using a key managed by the application. This means database administrators cannot read the sensitive fields in plaintext.
Principle 5: Retention and Right to Erasure
GDPR's storage limitation principle (Article 5(1)(e)) and the right to erasure (Article 17) create a technical obligation most architectures handle poorly: you must delete personal data when it's no longer needed or when a user requests it.
The deletion problem: Personal data doesn't live in one place. It's in your relational database, your search index, your analytics warehouse, your backup files, your email system, your support tickets, your audit logs, your CDN cache. A deletion request that removes data from the primary database but leaves it in 15 other systems is not compliance.
Data deletion architecture:
- Data inventory first: You can't delete what you don't know you have. Maintain a complete record of every system that holds personal data and the retention period for each.
- Soft delete with scheduled hard delete: Implement soft deletion (mark as deleted, hide from application) with automated hard deletion after a configurable retention period.
- Cascading deletion events: Publish a
user.deletedevent to an event bus. Every system that holds user data subscribes to this event and deletes accordingly. - Crypto-shredding: For data in backup files and data warehouses (where deletion is operationally difficult), encrypt the data with a customer-managed key. Deleting the key is effectively deleting the data — "crypto-shredding". This is the only practical approach for immutable audit logs and backup archives.
- Search index management: Elasticsearch, Azure Cognitive Search, and similar systems require explicit deletion calls — data doesn't cascade from the database. Include search index deletion in your deletion workflows.
Document your retention decisions
Every personal data category should have a documented retention period with a legal basis. "30 days after account closure" should trace to a specific legal justification — legal obligation, legitimate interest with justification, or contractual necessity. This documentation is your evidence in a regulatory audit.
Principle 6: Privacy Impact Assessments in the Development Process
GDPR requires a Data Protection Impact Assessment (DPIA) for processing that is "likely to result in a high risk to the rights and freedoms of individuals" (Article 35). DPIAs are required for:
- Systematic profiling
- Large-scale processing of special category data (health, biometric, financial, religious, political)
- Systematic monitoring of a publicly accessible area
- New technologies with unclear implications
Embedding DPIAs in the development process: Rather than treating DPIAs as a legal exercise triggered reactively, build a lightweight privacy screening into your product development process:
- Privacy pre-screening: For every new feature involving personal data, answer five questions: (1) What data is collected? (2) Who processes it? (3) Is it special category data? (4) Is profiling or automated decision-making involved? (5) Is large-scale processing involved?
- DPIA trigger: If the pre-screening flags any high-risk indicators, conduct a full DPIA before the feature is developed.
- Privacy review as part of code review: Senior engineers with privacy training should review database schema changes and new data flows as part of the standard code review process.
Practical Compliance Stack on Azure
| Requirement | Azure Service / Approach |
|---|---|
| Data residency | Region selection + geo-replication policy |
| Encryption at rest | SSE + TDE (default) or CMK for sensitive data |
| Encryption in transit | TLS 1.3 enforced at API Management / Front Door |
| Access control | Entra ID + RBAC + Azure Policy |
| Audit logging | Azure Monitor + Log Analytics + Immutable Storage |
| Secrets management | Azure Key Vault |
| Data discovery | Microsoft Purview (data classification + lineage) |
| Deletion evidence | Soft delete + event-driven cascading + crypto-shredding |
| DPA tracking | Documented vendor list with contractual links |
Privacy by Design requires a shift in how technical teams think about data: not as an asset to collect maximally, but as a liability to manage carefully. The teams that build this thinking into their culture and architecture spend far less time in reactive compliance mode — and far less time explaining themselves to regulators.
Cybersecurity and data protection architecture are core to my practice. If you need a privacy-by-design review of your architecture or help preparing for a compliance audit, let's talk.