In short
Set a retention period for each category of information rather than for individual files, based on how long you actually need it and what any legal obligation requires. Then automate the deletion or attach it to a trigger, because retention rules applied by hand are retention rules that do not happen. Keeping everything is not the safe default: old personal data is a liability in a breach, makes finding current information harder, and in many jurisdictions is not permitted once the purpose has passed.
Key takeaways
- Keeping everything forever is a choice with costs, not a neutral default.
- Set periods by category, not by file. Nobody makes per-file decisions reliably.
- Legal minimums are floors, not targets. Beyond them, keeping is a choice you should be able to justify.
- Attach deletion to a trigger. Calendar-based clean-ups do not happen.
- Backups have their own retention, and deleting from live systems does not delete from them.
Keeping everything is not neutral
The default in most small businesses is to keep everything, forever, on the reasoning that storage is cheap and you never know. Storage is indeed cheap. The other costs are not, and they are not visible until something goes wrong.
- Breach exposure. If your systems are compromised, everything you hold is exposed. Data deleted three years ago cannot be. This is the only security control that works retroactively.
- Findability. Every superseded copy competes with the current one for attention and for search results, which is the mechanism described in where things live. Volume is the main reason people cannot find things.
- Obligation. In the UK, the EU and a growing number of jurisdictions, personal data may not be kept indefinitely once the purpose it was collected for has passed. Keeping it is not caution; it is a position you would have to defend.
- Answering requests. When someone asks what you hold about them, you have to search everything you hold. The less you keep, the shorter that exercise is.
Data you no longer need is not an asset sitting quietly. It is a liability you are paying to store, index, back up and defend.
This is not legal advice, and retention minimums vary by country and by type of record. What follows is the operational half: how to make retention a rule rather than a matter of individual judgement.
Set periods by category
The reason most retention policies fail is that they require someone to decide, file by file, whether something should be kept. Nobody does this reliably, so nothing is ever deleted.
Rules have to attach to categories instead. Most small businesses have six or seven that cover almost everything.
| Category | Typical driver |
|---|---|
| Financial and tax records | Statutory minimum, which is the longest constraint for most businesses |
| Contracts and agreements | Limitation periods for claims, usually several years past expiry |
| Employment records | Statutory minimums, varying by record type |
| Client project files and deliverables | Your own operational need, plus any contractual commitment |
| Marketing contacts and enquiries | Consent and purpose. Usually the shortest period and the most frequently ignored |
| Internal working files, drafts, message history | Almost entirely your own choice, and usually kept far longer than anyone needs |
Write one line per category: how long, and why. Half a page in total. The why matters, because it is what lets a successor understand whether a period is a legal floor or a preference, and those should be changed by different processes.
How long is actually needed
Two questions per category, in order.
What is the legal minimum? This varies by jurisdiction and record type, and it is worth ten minutes with your accountant and your local regulator's guidance rather than an assumption. Treat the answer as a floor.
What do we actually use? This is the question nobody asks. Look at how far back anyone has genuinely needed to reach in the last two years. For most operational categories the honest answer is far shorter than the retention period people would defend in the abstract, and the gap between the two is pure liability.
Is usually longer than anyone has actually needed to reach back into internal working files, drafts and message history. The instinct to keep them for a decade is not based on any recalled instance of needing them.
Between those two numbers, choose deliberately. Longer than the legal minimum is a legitimate choice for records that carry ongoing value; it should just be a choice rather than a failure to decide.
- Data minimisation
- The principle of holding only the information needed for a stated purpose, for as long as that purpose lasts. It is a legal requirement for personal data in several jurisdictions and an operational benefit everywhere, because less stored information means less to search, secure and eventually explain.
Making deletion happen
A retention policy that depends on a quarterly clean-up is a policy that ran twice and then stopped. Deletion has to be automatic or attached to something that already happens.
- Automate where the tool allows it. Many systems support retention rules natively: message history, ticket archives, file storage. Configure once, and the policy runs whether or not anyone remembers it.
- Attach to a trigger where it does not. Engagement closes, employee leaves, financial year ends. Triggers happen; quiet months do not, which is the same reason trigger-based archiving works and calendar-based tidying does not.
- Archive first, delete later. A two-stage rule — out of the working area at closure, deleted at the retention date — is easier to accept and removes the findability cost immediately.
- Record that deletion happened. A short log of what was deleted and when. It is the only evidence you will have that the policy is real.
Build the triggers into processes you already run. Client offboarding is the natural place to set the retention clock on an engagement's files, and employee offboarding is where personal records start theirs.
Backups and the copies you forget
The commonest gap in an otherwise sensible retention policy: deleting from the live system does not delete from the backup.
If backups are retained indefinitely, then your real retention period is indefinite, regardless of what the policy says. That is worth knowing rather than discovering during a request or an incident.
- Set a defined backup retention period, and know what it is. It should be long enough to recover from a problem noticed late, and no longer.
- Know which systems are backed up at all. Cloud tools are widely assumed to be and frequently are not, beyond a short deletion window.
- Account for the other copies. Exports on personal machines, email attachments, a spreadsheet someone downloaded in 2024. These are the hardest to reach and the most likely to be forgotten.
That last category is also a single source of truth problem in a different costume. Uncontrolled copies cause wrong decisions while they are current and retention problems once they are not, which is another reason to reduce their number rather than manage them.
When someone asks what you hold
At some point a client, an employee, or a former employee will ask what personal information you hold about them, and in many jurisdictions you are obliged to answer within a defined period.
The exercise is straightforward if you know where things live and how long you keep them, and close to impossible if you do not. What makes it manageable:
| What you need | Why |
|---|---|
| A list of systems that hold personal data | You cannot search what you have not listed. This is the inventory from access management |
| Consistent naming and structure | Search only works if things are named findably |
| Retention rules already applied | Everything already deleted is not in scope, which is the strongest argument for deleting on schedule |
| One named owner for the response | Statutory deadlines are short, and unowned deadlines are missed |
Doing this once for practice, on a hypothetical request, tends to be more informative than any amount of policy writing. Most businesses discover that they cannot confidently list every system holding personal data, which is the actual finding and the thing worth fixing first.
The Mayim Ops assessment examines documentation and systems together, because the ability to answer what do we hold, where is it, and who can reach it is a single operational capability that happens to be assessed by regulators as three separate questions.
Frequently asked questions
How long should a small business keep records?
It depends on the category and the jurisdiction: financial and tax records typically have a statutory minimum of several years, employment records have their own, and personal data collected for a specific purpose should generally be deleted once that purpose has passed. Check your local requirements, treat them as floors, and set your own period per category rather than per file.
What is a data retention policy?
A written statement of how long each category of information is kept, why, and how it is deleted afterwards. Its practical value is that it converts thousands of individual keep-or-delete judgements into a handful of rules that can be applied consistently or automated.
Is it safer to keep everything?
No. Data you hold is data you are responsible for: it can be exposed in a breach, requested by a person whose information it is, and it makes current information harder to find. In several jurisdictions, retaining personal data beyond the purpose it was collected for is itself a breach.
How do you actually delete data on a schedule?
Automate it where the tool supports it, and attach it to an existing trigger where it does not — engagement closes, employee leaves, financial year ends. Retention that relies on someone remembering to run a quarterly clean-up does not survive contact with a busy quarter.
Do backups need their own retention rules?
Yes. Deleting from a live system does not remove data from backups, so a backup retained indefinitely quietly retains everything you thought you had deleted. Set a defined backup retention period and know what it is, because it becomes the real answer to how long you keep things.