Data Subject Rights, Retention and Erasure: The Engineering

Rights are features, not favours

The UK GDPR gives individuals a set of rights over their personal data, and the mistake most systems make is treating them as ad-hoc requests handled by whoever is free. Under the regulation, each right carries a statutory response deadline, usually one month, and “our developer will run a query when they get a chance” is not a control that survives scrutiny.

The rights that software has to support are:

• Access. A copy of the individual’s personal data and information about how it is processed.
• Rectification. Correction of inaccurate data.
• Erasure. Deletion of personal data, the right to be forgotten, where a lawful ground applies.
• Restriction. Limiting processing while a dispute is resolved.
• Portability. The data in a portable, machine-readable format.
• Objection. Stopping processing based on legitimate interests or direct marketing.

Each of these maps to a feature. Treating them as features, built and tested, is what makes the statutory deadlines achievable instead of stressful. The rest of this guide is how to build the ones that carry real engineering weight.

Access and portability: the export that assembles a person

Access and portability are the same underlying capability seen from two angles. Both need the system to assemble everything it holds about one individual, across every table and file, into a coherent, portable package on demand.

The features that make this reliable are:

• Permission-gated. Assembling a full personal-data export is a privileged action, so it sits behind a specific permission and is itself audited. An export capability is a powerful thing, and it should be treated as one.
• Portable format. The output is a structured, machine-readable format the individual can take elsewhere, which is what portability requires beyond mere access.
• On demand, within the deadline. The export runs when a verified request comes in, reliably enough to hit a one-month deadline without heroics.
• Complete. It reaches every place the person’s data lives, which is only tractable if the system knows where personal data is, which is what data classification provides.

The reason classification matters here is concrete. An export that assembles data by hand, table by table, will miss a column someone added last year. An export driven by classification reaches every field marked as personal, because the labels are the map.

Rectification: correcting with a record

Rectification is the least glamorous right and the easiest to get subtly wrong. The requirement is not just that data can be corrected, but that the correction is authorised and recorded.

That means editing personal data is a permissioned action, and every change is captured in the audit trail with who made it and when. Correcting a date of birth should leave evidence that it was corrected, by whom, and when, so a later question about the record can be answered from data. Rectification without an audit trail is just overwriting, and overwriting is how disputes become unwinnable.

Objection and restriction: consent and suppression

Objection and restriction are served by the consent and suppression controls that a data-protection-by-design system already has. Objecting to direct marketing is honoured by the suppression list, a durable no-contact record that blocks outbound contact regardless of other flags. Restriction is honoured by flags that stop specific processing while a matter is resolved.

The key property is that suppression must be durable enough to survive retention purges. A request never to be contacted has to keep being honoured after the rest of a record is gone, so the suppression entry persists as an explicit exemption when everything around it is erased. Consent and suppression are also the source of truth checked before any data is shared with a downstream processor.

Erasure without losing accountability

Erasure is where data protection engineering gets genuinely hard, because two obligations pull in opposite directions. The right to erasure says remove the personal data. The accountability principle says keep a record of what the system did. A naive deletion satisfies the first and violates the second.

The resolution is to stop treating “remove the data” as one operation. There are three distinct states, and knowing which one a situation needs is most of the skill.

Soft delete is not erasure

Soft delete marks a record as deleted and excludes it from normal reads, keeping the data for audit and recovery. It is an operational convenience, and it is emphatically not a privacy control, because the personal data is still present. Systems that answer an erasure request by setting a deleted flag have not erased anything. Soft delete has its place for accountability, but never confuse it with fulfilling the right to be forgotten.

Anonymisation keeps the reporting, drops the person

For operational tables, anonymisation is often the right tool. It overwrites every classified personal field with non-personal values, a name becomes a placeholder, medical notes become null, while keeping non-personal columns such as an enrolment or payment history that the business needs for reporting and reconciliation. The individual can no longer be identified, so the erasure obligation is met, but the aggregate record survives. Crucially, anonymisation has to reach soft-deleted rows too, because erasure must not be defeated by a record having been hidden earlier.

Crypto-shredding for what you cannot delete

Some data genuinely cannot be physically deleted on request. Immutable audit records and immutable backups are the classic cases: you keep them precisely because they must not be mutable, which is the opposite of “delete this row”.

Crypto-shredding resolves this. Store the sensitive content encrypted under a key unique to the subject, with that key wrapped by a key in a managed key vault. To erase the subject irreversibly, destroy their key. The ciphertext remains, satisfying the immutability requirement, but its personal content is permanently unreadable, satisfying erasure. This is the design that reconciles an immutable audit trail with the right to be forgotten, and it is worth planning for even if you phase it in, because it is very hard to add to data that was written in cleartext.

Fail safe, not sorry

One discipline underpins all of this: when erasure cannot be completed fully, it should refuse rather than partially erase. If a record has associated files and the file-deletion path is not yet built, the safe behaviour is to block the erasure and surface the gap, not to delete the database row and orphan the files. A half-finished erasure that leaves personal data in storage is worse than a clear failure, because it looks done and is not.

Retention: storage limitation as an engine

Erasure on request handles the individual case. Retention handles the rule: personal data kept no longer than necessary, enforced automatically rather than by memory. This is the storage limitation principle, and it is the one most systems quietly ignore because keeping everything is the path of least resistance.

A retention engine that works has a recognisable shape.

• Rules are data, keyed per data class and jurisdiction. Each rule names a period and an action, anonymise or delete. There is deliberately no fallback row, so a data class with no rule is a visible, logged gap rather than an accidental keep-forever. Nothing is erased without a rule someone knowingly configured.
• A scheduled job evaluates and acts. It runs on a schedule, finds records past their period, and applies the action. In non-production it defaults to a dry run, so you can see what would be purged before anything is.
• Every evaluation is logged, even when nothing is purged. The engine records that it assessed a data class against its rule and what it found, so the audit log proves the rule was considered, not merely that something was deleted. Absence of deletion is evidence too.
• Legal holds override the schedule. Data under investigation or litigation must not be purged. A legal hold marks a subject as exempt until the hold is lifted, and the exemption lives in the orchestrator so no data class can forget to check it.
• Coverage is enforced by a test. A build-time test asserts that every table holding classified personal data is either covered by a retention rule or listed as an explicit exemption with a documented reason. New personal data cannot silently escape retention, because adding it without a rule or an exemption breaks the build.

Keeping the cut-off calculation in code, from an injected clock rather than a database timestamp, keeps the behaviour testable and consistent. And because retention drives destructive actions, it is exactly the kind of engine that benefits from the fail-safe discipline above.

Children’s data and stricter defaults

Where a system holds children’s data, the rights and retention model tightens. Rights are generally exercised by a parent or a person with parental responsibility, though a child of sufficient age and understanding may exercise their own, consistent with the controller’s practice. Retention for children’s, special-category, and safeguarding data should be the strictest in the schedule, and safeguarding retention in particular is often set by policy or law rather than convenience. Designing the retention engine to key rules per data class makes these stricter defaults a configuration, not a special case in code.

Where to start

If you are building or retrofitting subject rights and retention, sequence it like this:

1. Classify first. Access, erasure, and retention all depend on knowing where personal data is. Do the classification before the rights tooling.
2. Build the export. Access and portability from one permission-gated, classification-driven export.
3. Make the audit trail immutable. It is what erasure has to preserve, and what rectification records into.
4. Separate the three removal states. Decide per table whether erasure means anonymise, hard delete, or crypto-shred.
5. Build retention as an engine. Rules per class and jurisdiction, scheduled, logged, with legal holds and a coverage test.
6. Fail safe. Where erasure cannot complete, block and surface it rather than partially delete.

Subject rights and retention are where data protection stops being a policy and becomes a system that can be asked hard questions and answer them from data. Build them as features, and the statutory deadlines become routine. If you want them designed into a build from the start, book a consultation or read how we approach data protection by design.