One blanket retention period is two compliance failures at once
By Dylan Wolpe
The short version
- Retention obligations are set per category by different statutes, but most organisations apply one period to everything, which over-retains some data and under-retains the rest simultaneously.
- An erasure request is rarely 'delete everything', it is 'delete what you are not legally required to keep', which requires knowing per record which rule applies.
- Without a category-level map, every erasure response is a judgement call made under time pressure by whoever picked up the ticket.
- The map is unglamorous, non-technical work, and it is the prerequisite for any tooling to help, including ours.
Ask what your retention period is and you will usually get one number. Seven years, say. Applied to customer records, transaction logs, support tickets, marketing consent and CCTV alike, because at some point somebody took the longest obligation anyone could name and applied it to everything, which felt safe.
It is not safe. It is two breaches wearing one policy.
Failing in both directions
Over-retention. Data whose obligation is two years is being kept for seven. Every framework in this space requires that personal data not be kept longer than necessary, so the five extra years are not caution, they are a breach with a paper trail you wrote yourself.
Under-retention. Something in the estate has a ten-year requirement nobody catalogued, and it is being deleted at seven. This one only surfaces when it is asked for.
The blanket period survives because it looks conservative. It is simultaneously too long for most of your data and too short for some of it.
What an erasure request actually demands
Requests are rarely “delete everything you hold”. Properly understood the request is: delete what you are not legally required to keep.
Answering that requires knowing, for each element of a person’s record, which rule governs it. Consider one customer:
| Data | Governed by | Response |
|---|---|---|
| Identity documents | Financial-crime statute | Retain, required |
| Transaction records | Tax and sector rules | Retain, required |
| Marketing preferences | Consent | Erase |
| Support call recordings | Business need only | Erase |
| Website behaviour | Legitimate interest | Erase |
Without a category map, that determination is made by whoever picked up the ticket, under a deadline, from memory. It will be inconsistent between requests, which is itself the finding an inspection reports, inconsistency is evidence of no controlling process.
Building the map
This is a table, not a system, and it is the prerequisite for everything else. Per category:
- What the data is, in words a non-specialist recognises.
- Which statute or business need requires keeping it, cite it.
- For how long, and when the clock starts (collection? account closure? last transaction?).
- Where it physically lives, including warehouses, extracts and backups.
- What happens at expiry, and whether anything actually enforces that.
Point five is where most maps become fiction. A schedule saying data is deleted after five years, with nothing deleting anything, is worse than no schedule, you have documented an obligation you are demonstrably not meeting.
Where technology helps, once the map exists
Given a map, per-subject and per-category keying makes the granular response routine: erase the categories the request reaches, keep the ones the law requires, without editing the archive or restoring anything. The mechanism is in the erasure piece.
Without the map, the same mechanism just executes a policy you cannot defend, faster and more consistently. Which is worth being clear about, since we sell the mechanism: the boring fortnight is the part that determines whether any of it helps.
- South African framing: POPIA retention and erasure
- Where backups fit: the backup problem
Questions people ask about this
Can a retention requirement override a deletion request?
For the specific data the law requires you to keep, generally yes, data protection frameworks recognise legal obligation as a basis for continued processing. What it does not do is justify retaining everything else in the same record. The obligation attaches to particular categories, not to the whole file the categories happen to live in.
What does a retention map actually contain?
For each category of personal data: what it is, which statute or business need requires keeping it, for how long, when the clock starts, where it physically lives, and what happens at expiry. It is a table, not a system, and most organisations do not have one at this granularity.
Why is one blanket retention period a problem?
Because it is chosen by taking the longest obligation and applying it everywhere. Data with a shorter obligation is then kept beyond necessity, which breaches minimisation, while anything with a longer requirement is missed. It fails in both directions at once, which is why it survives, it looks conservative.