GDPR Articles 15 through 22 grant data subjects eight distinct rights. Most organisations satisfy them with a support ticket queue and a shared inbox labelled "privacy requests." That approach works until it doesn't — until request volume increases, until a regulator audits response times, until a data subject escalates to their national supervisory authority. The ICO can issue reprimands and fines for systematic failure to respond within the 30-day deadline. The architecture that makes data subject rights reliable is not a support workflow. It is a system API.
The Rights as System Capabilities
Each GDPR right maps to a system operation that must be automated to be reliable. The right of access (Article 15) requires the system to compile all personal data held about an individual across every data store — including backups, analytics warehouses, and third-party processors. The right to erasure (Article 17) requires deletion or anonymisation in every data store, with logged confirmation. The right to rectification (Article 16) requires an audit trail of the change. The right to data portability (Article 20) requires export in a machine-readable format, which means a defined data schema, not an ad hoc CSV export.
Implementing these as manual processes means a compliance team member manually queries each database, manually contacts each third-party processor, and manually compiles a response package. This does not scale. For an organisation handling 500 subject access requests per month, the manual process requires dedicated headcount and still produces inconsistent results.
The right to erasure in an event-sourced system is architecturally non-trivial. You cannot delete an event from an append-only event log without corrupting the log. The correct architecture uses cryptographic erasure: encrypt the personal data with a key that is held separately, and when an erasure request arrives, destroy the key. The data remains in the log but is unreadable — satisfying erasure without compromising log integrity.
The Rights Management API Architecture
The rights management API is a separate service with three core responsibilities: request intake and identity verification, orchestration of data retrieval or deletion across all registered data stores, and evidence generation for each completed request. The intake layer handles identity verification — an access request submitted by someone other than the data subject must be rejected. The orchestration layer must have a registry of every data store in the organisation that processes personal data: primary databases, analytics warehouses, data lakes, ML feature stores, backup archives, and third-party processors accessed via API. The evidence layer generates a tamper-evident record of what was found, what was returned or deleted, and when each step completed.
The data store registry is the hardest component to maintain. Every time a new database, data warehouse, or analytics tool is deployed, it must be registered with the rights management system. This registration should be part of the infrastructure provisioning process — enforced by infrastructure-as-code templates that require registration as a pre-condition for deployment in environments that process personal data.
Retention Automation
The right to erasure under Article 17 overlaps with the data minimisation principle under Article 5(1)(e): personal data shall be kept no longer than necessary. Most organisations define retention periods in a data retention policy document. Fewer actually implement automated deletion when retention periods expire. The gap between the documented retention period and the actual retention — where data persists in databases because nobody ran the deletion job — is a systematic GDPR violation that data protection authorities have penalised.
Retention automation requires a retention metadata layer: every personal data record is tagged with a retention category and a calculated deletion date. A scheduled job evaluates records against their deletion dates and triggers deletion or anonymisation. The job generates evidence of execution. Exceptions — records held under a legal hold or a legitimate interests override — are flagged separately and reviewed by the DPO on a defined schedule.
Third-Party Processor Orchestration
The access request response must include personal data held by processors acting on the controller's behalf. If the CRM, the marketing automation platform, the analytics vendor, and the customer support tool all hold personal data, all four must be included in the response. The rights management API must be able to send erasure or access requests to each processor's API and aggregate the responses. This requires processor APIs to exist and to be documented — a procurement requirement that must be enforced at the vendor selection stage, not discovered when the first SAR arrives.
- Build a data store registry as a prerequisite: every system that holds personal data must be registered before it can receive data
- Implement cryptographic erasure for append-only and event-sourced systems — key destruction is deletion
- Automate retention enforcement: tag every personal data record with a retention category and deletion date at creation
- Require processor API support for SAR and erasure as a procurement condition — evaluate this before contracting
- Generate tamper-evident evidence for every rights request: what was found, what action was taken, completion timestamp
- Build identity verification into the intake layer — an unverified SAR must not trigger data disclosure
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.