Consent Records You Cannot Delete on Request Are a Liability, Not an Asset

Every consent platform sales pitch leans on the same comfort: we keep your proof forever. It sounds like safety. Then a data subject exercises an erasure right, or a regulator asks about your storage limitation practices, and forever turns out to be a policy nobody chose, applied to records nobody inventoried.

Consent records are personal data. They identify a person, or a device close enough, and describe their choices. They sit squarely inside the same rules as the data they authorise: purpose limitation, storage limitation, and erasure rights with a compliance shaped exception. Handling them well is a balancing act that has to be designed, not inherited from a vendor default.

Why you keep records at all

The record exists to demonstrate that processing had a valid basis: who consented, when, to what version of purposes and vendors, with what choices. Accountability under GDPR expects you to show this, and the showing usually concerns the past. Delete too early and you cannot defend processing you actually did. That is the real risk on one side of the balance.

On the other side, a record kept a decade after the relationship ended, for a purpose that no longer exists, fails storage limitation and becomes its own violation. The answer is a retention schedule tied to the processing the consent covered and the limitation periods that apply where you operate, reviewed like any other schedule in the records programme.

Erasure requests and the compliance exception

When a person asks for erasure, consent records are not automatically exempt and not automatically deletable. The working pattern most programmes land on: delete or anonymise what is not needed, retain the minimal record necessary to demonstrate compliance and to honour the erasure itself, such as a suppression entry so the person is not re added, and document the reasoning. The record shrinks to a tombstone rather than vanishing or surviving whole.

Whatever your pattern, it must be written before the request arrives, applied consistently, and explainable to the requester in plain language. Improvised answers differ by handler, and inconsistent erasure handling is its own finding waiting for a complainant to notice.

Anonymisation that actually anonymises

Vendors love to offer anonymised retention: keep the statistics, drop the identity. Check what that means in the export, not the brochure. Hashed identifiers that stay stable across records are pseudonymous, not anonymous, and remain personal data. True anonymisation breaks the link to the individual irreversibly, keeping only aggregates like counts and dates at coarse grain.

Test it the way an auditor would. Take an anonymised record set and try to single someone out using timestamps, choices and any surviving identifiers. If a motivated analyst with your other logs can reattach a name, you have pseudonymisation with good marketing, and your retention clock is still running.

Put the schedule in the consent platform contract

Retention is set in configuration and contract, not in intentions. Confirm the platform's defaults, set your schedule in the tool, verify deletion actually propagates to backups and exports on the vendor's stated cycle, and diarise the review. Consent vendors change hands and change defaults. The schedule you negotiated should survive both, on paper.

Run one deletion drill a year. Pick expired records, watch them leave, and document the evidence. When a regulator or a customer asks how retention works, a dated drill record beats a policy paragraph every time.

Related reading

These earlier guides go deeper on connected questions: Consent Renewal: Asking Again Is a Timing Problem Before It Is a Design Problem, The Consent Log Is the Product: What to Keep When a Choice Is Challenged, and Reject Button Parity: The Second Layer Is Where Consent Goes to Die.

Frequently asked questions

How long should consent records be kept?

Long enough to demonstrate compliance for the processing they authorised: generally while the processing continues plus the limitation period that applies to claims or regulatory action in your jurisdictions. After that, delete or genuinely anonymise them on a documented schedule. Forever by default fails storage limitation principles and creates avoidable exposure.

Must consent records be deleted on an erasure request?

Not always in full, but they cannot simply be ignored either. Most programmes retain a minimal tombstone, enough to prove the consent history and to ensure the person is not reprocessed, while deleting the rest, under the compliance exception. The key is a pre written, consistently applied policy you can explain to the requester.

Are hashed consent records anonymous?

Usually not. A stable hash of an email or identifier is pseudonymous: it can still single out a person and be re linked with other data. Pseudonymous records remain personal data with retention duties attached. True anonymisation irreversibly breaks individual linkage and typically keeps only aggregated statistics.

Who owns the retention decision, legal or the consent vendor?

The organisation does. The vendor supplies defaults and tooling; accountability for the schedule sits with the controller. Set retention deliberately in the platform configuration and contract, verify deletion behaviour including backups, and review it on a cycle. A vendor default you never examined is still your decision in a regulator's eyes.