I have read a lot of data retention policies as part of audit work, and most of them share the same problem. They were written by someone trying to satisfy a lawyer or an auditor, in language nobody on the engineering team would ever use in conversation, and then filed away. Nobody deletes anything on schedule because nobody who can actually run the deletion job has read the document.
A retention policy that works has to answer one question clearly for every category of data you hold: why are we keeping this, and for how long. If you cannot answer that in a sentence, that is usually a sign you are keeping the data out of habit rather than need.
Start with categories, not a single blanket rule
The biggest mistake we see is a single retention period applied to everything, usually because it is easier to write down. In practice, different kinds of data have different reasons to exist and different natural lifespans. A reasonable starting set of categories for a typical small company looks like this:
| Category | Typical reason kept | Reasonable default |
|---|---|---|
| Active customer account data | Ongoing service delivery | Duration of active relationship, plus a grace period |
| Transaction and invoice records | Tax and accounting law | Set by local law, often 5 to 10 years |
| Support tickets and chat logs | Quality review, dispute resolution | 12 to 24 months after closure |
| Marketing contact list | Sending newsletters or promotions | Until unsubscribe, or after a defined period of no engagement |
| Server and access logs | Security investigation | 30 to 90 days |
Your categories and periods will differ based on your industry and jurisdiction, and the numbers above are starting points, not the law. The point of the table is the shape of the thinking: reason first, period second.
Write it for the person who has to run the delete job
Once you know your categories, write the policy for the engineer or operations person who will actually implement deletion, not for an auditor. That means naming the actual system and table or object where the data lives, not just a category name. "Marketing contact list" means something different if it lives in three different tools than if it lives in one.
Build in the exceptions before someone asks about them
Two exceptions come up in almost every retention policy we help write:
- Legal holds. If a customer's data is relevant to an active legal dispute or investigation, deletion needs to pause regardless of the normal schedule. Name who has authority to place and lift a hold.
- Backups. Deleting a record from the live database does not delete it from last week's backup. Decide up front whether backups are exempt from the retention clock for a defined period, and say so explicitly rather than leaving it ambiguous.
A short template
For each data category, we suggest writing exactly five lines. It reads more like a checklist than a legal document, and that is deliberate:
- What is this data, in plain terms
- Where does it live, named specifically
- Why do we keep it
- How long do we keep it, and what triggers the clock
- Who is responsible for deleting it, and how often does deletion actually run
We have used this five-line format with clients ranging from a nine-person marketing agency to a 150-person logistics company, and it scales surprisingly well in both directions. The agency's whole policy fit on one page. The logistics company needed 14 categories, but each one still followed the same five lines.
The point of a retention policy is not to look thorough. It is to make deletion a routine event instead of a crisis that happens once, right before an audit, when someone finally asks where all the old data went.
- How long should a company keep customer data?
- It depends on the purpose the data serves and any legal obligations that apply, such as tax or accounting rules. A common approach is to set a default retention period for each category of data, tied to why it was collected, rather than keeping everything indefinitely by default.
- Who should own a data retention policy inside a company?
- Ownership works best when it sits with someone who can actually enforce deletion in the systems involved, often an engineering or operations lead, with legal or compliance reviewing the periods rather than writing the whole document alone.