GDPR and Data Architecture: Building Compliant Systems
The UK General Data Protection Regulation (UK GDPR) imposes specific requirements on how personal data is collected, stored, processed, and deleted. These requirements have direct implications for data architecture — compliance must be designed in, not bolted on.
Data Minimisation in Architecture
Systems should only collect and retain personal data that is strictly necessary. This means: not logging personal data in application logs, not storing personal data in analytics systems where aggregated data would suffice, and designing data models that separate personal identifiers from behavioural/transactional data.
Right to Erasure (Right to Be Forgotten)
When a user requests erasure of their personal data, you must delete it from: primary databases, backup databases, data warehouses, caches, audit logs (where legally possible), and third-party processors. This requires:
- A complete data map — knowing every system where personal data is stored
- Automated deletion workflows that can be triggered from a single request
- Pseudonymisation strategies for data in systems where deletion is technically difficult (e.g. audit logs — replace personal identifiers with pseudonyms)
Data Subject Access Requests (DSAR)
Individuals have the right to receive a copy of all personal data held about them. This requires: the ability to query all systems for data related to a specific individual, data in a portable format, and a process to respond within the statutory 30-day window.
Our Approach
We design systems with a personal data map, automated retention enforcement, pseudonymisation of analytics data, and DSAR response capabilities from the outset of every project involving personal data.