What is data retention: data retention explained for teams that hold evidence
Data retention is how an organisation decides, documents and enforces the length of time each category of personal data is kept before it is deleted or anonymised, and how it justifies that period against the purpose the data was collected for in the first place.
What does data retention mean under GDPR?
It means the storage limitation principle, Article 5(1)(e), which requires personal data to be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed".
There is no universal number in the regulation, and that is deliberate. Recital 39 puts the obligation on you instead: "time limits should be established by the controller for erasure or for a periodic review". Breaches of Article 5 sit in the higher enforcement tier under Article 83(5), which reaches "up to 20 000 000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover", whichever is higher.
How is a retention period decided?
Not by picking a round number. You work from the outside in, per category of data, and the schedule is usually the longest of the following, capped by the shortest thing you can actually defend:
- The purpose. Once the claim is settled and the appeal window closed, what is the data still for?
- Statutory obligations. Insurance, tax and accounting rules that set their own minimums, which vary by jurisdiction and override your preference.
- The limitation period for legal claims arising from the matter, which is the number most evidence teams are really thinking about.
- The regulatory or ombudsman window, which is often longer than people assume and is the reason short retention bites.
- Complaint patterns. Your own data on when files actually get reopened beats a guess.
Write it as a schedule by data category, not by system. "Everything in the capture platform: three years" is not a retention schedule. It is a storage setting with a policy label on it.
Data retention example: the claim closed in March
A motor claim is settled in March and retention is set at twelve months across the board, because storage costs were the thing being reviewed that quarter. Two years later the policyholder complains to the ombudsman about the repair scope. The video the decision rested on is gone, and the insurer defends the case without its own evidence.
Run it the other way and the picture is no better. Keeping every submission for ten years by default means holding faces, home interiors, number plates and precise locations belonging to people whose claim was paid and closed in a fortnight. Both versions are a failure. They just fail different audits.
Where dispute readiness and data minimisation pull in opposite directions
This is the tension nobody selling software will name for you, so name it yourself.
Evidence practice says keep everything, in original form, for as long as anyone might reopen the file. Data minimisation and storage limitation say keep the least you can justify, for the shortest period you can justify. Both are correct inside their own logic, and no configuration screen reconciles them.
What does help is refusing to treat it as one decision:
- Tier by outcome. A disputed file and a paid-in-full file do not need the same retention.
- Reduce what is kept, not only how long. The integrity record, the hashes, the session timeline, the seal and the audit trail, is small and far less intrusive than the media it describes. It can often outlive the video and still prove what you received.
- Use legal hold. A named process that suspends deletion on a specific case, with a named person who can lift it, lets you run a short default without losing contested files.
- Review dates, not just deletion dates, where the horizon genuinely is not knowable at intake.
- Remember erasure is not absolute. Article 17(3) disapplies the right to erasure where processing is necessary "for the establishment, exercise or defence of legal claims". That is a real exemption, and it is narrower than "we might need it".
Retention is a policy decision, not a software setting
Software enforces a number. Somebody still has to choose the number and be able to stand behind it when asked. Who owns the schedule. Who signs it off. How often it is reviewed. Who authorises a legal hold and who is allowed to release one. Turning on auto-purge before that conversation happens just automates a choice nobody can defend.
Common data retention mistakes
- One blanket period applied across every category of data, which is over-retention for most of it and under-retention for the rest.
- A period configured in the tool but never written down, so the justification exists only in the head of whoever set it.
- Copies outside the schedule. The export in a shared drive, the email attachment, the record pushed into the claims system. Deleting the original changes nothing if four copies survive.
- No legal hold, so the only way to preserve a contested file is to suspend deletion for everybody.
- No evidence of deletion. You will occasionally need to show that erasure happened, not just that it was scheduled.
Set the window against your real dispute horizon and your real obligations, then hold it. The related discipline sits in the evidence integrity design and in what your chain of custody has to reconstruct, and the wider legal frame is in our note on the GDPR.
Venta Capture, a product of VentaVid, offers configurable retention with auto-purge, so an agreed schedule can be enforced per capture flow rather than by hand. Choosing and defending that schedule stays with you.