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. That month can now be paused in defined circumstances, which the next section covers, but a pause you have to justify is not the same as breathing room.

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.

What the Data (Use and Access) Act 2025 changed

The Data (Use and Access) Act 2025 (DUAA) amended the UK GDPR and the Data Protection Act 2018. Most of its data protection provisions came into force on 5 February 2026, and the complaints provisions followed on 19 June 2026. It did not rewrite the rights above, but it changed four things that land directly in code.

The clock can be paused, on conditions

Section 76 puts the practice of stopping the clock on a statutory footing. Where you reasonably require clarification in order to respond to a subject access request, the one-month period pauses until the individual provides it. You cannot ask for clarification routinely, and you have to be able to show why it was reasonably required.

In software terms, the request record needs a paused state carrying a reason and a timestamp. A single received date with a deadline calculated from it cannot represent the position you are actually in, and it will not evidence the pause if the ICO asks.

Searches must be reasonable and proportionate

Section 78 amends Article 15 so that an individual is entitled to the data you can provide from a reasonable and proportionate search. This codifies a standard already found in ICO guidance and case law. What counts as reasonable depends on the nature of your business, the request, and the resources available to you.

For a well-classified system this changes little, because a classification-driven export is proportionate by construction. It does mean you should record the scope of each export, since the ICO expects a controller to be able to show why a search was not taken further.

Automated decision-making is narrower than it was

The prohibition on solely automated decisions with legal or similarly significant effects now applies mainly where the processing involves special category data. Other significant automated decisions have broader lawful bases available, subject to safeguards.

If you built a hard block around every automated decision, the letter of the law no longer demands it. We would keep the human review path and the decision logging regardless. Clients and regulators ask how a decision was reached, and a system that cannot answer that is a problem whichever way the statute reads.

A complaints procedure is now a feature

Section 164A of the Data Protection Act 2018 gives individuals the right to complain to the controller directly. You have to accept complaints through an accessible channel including an electronic form, acknowledge within 30 days, investigate without undue delay, and communicate the outcome. Individuals can still go to the ICO at any point.

That is a form, a case record, a clock, and a notification path. In our experience this is the change most often missing from systems designed before 2026, because teams read it as a privacy notice update. Treat it the way you treat the export: a feature with an owner, a test, and an audit trail.

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.
7. Build the complaints path. An electronic form, a logged case, a 30-day acknowledgement, and a recorded outcome, as required since June 2026.

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.