How Long Should You Keep User Data?

Keeping everything is a decision, not a default

Storage is cheap, so the instinct is to keep everything. That reasoning ignores the actual costs.

A breach exposes what you hold. Data deleted three years ago cannot leak. Every additional year of retained records increases what an incident costs you.

Requests get harder. A subject access request covers everything you hold about that person. More history means more to find, across more systems.

It has to be secured and justified. Data with no current purpose still needs protection, and under most privacy regimes needs a lawful reason to exist.

It gets in the way. Old records slow queries, complicate migrations, and confuse people who cannot tell current data from archived.

So retention is a decision with real trade-offs, and the default of keeping everything is usually the wrong side of them.

Setting a period per type

Different data has different justification, so a single site-wide period does not work.

Start from the purpose. How long do you actually need this to do the thing you collected it for? A contact form enquiry is useful until the conversation concludes plus a reasonable window — not seven years.

Then check legal obligations. Invoices and financial records usually have a statutory minimum, often several years. Employment records have their own rules. These override your preference in the other direction.

Then consider genuine business need, honestly. "We might want to analyse it" is not a retention basis if nobody has analysed anything in three years.

Write down the period and the reason for each type. The reason matters, because it is what lets someone re-evaluate later rather than treating the number as arbitrary.

Typical shapes

Without being prescriptive, the common pattern looks something like:

Marketing and enquiry data — a defined period after last contact, often a couple of years, with re-engagement or deletion.

Account data — for the life of the account plus a short grace period after closure, so someone changing their mind is not punished.

Transaction records — the statutory period, which is usually the longest thing you keep.

Logs and analytics — short, often weeks to months. These accumulate fastest and are needed least, which makes them the highest-value thing to shorten.

Support conversations — long enough to give context on a returning customer, not indefinitely.

Backups — a defined cycle, deleted on schedule.

Deletion and backups

This is the part that produces the most confusion, so decide it explicitly.

If someone requests deletion, their data is removed from live systems. It typically remains in backups until those backups expire.

The usual position is to document that backups are held on a defined cycle, are not used selectively to restore individual records, and that data will be removed when the backup expires — and if a restore does happen, the deletion is reapplied.

What matters is having decided and written it down. Selective deletion from backups is impractical for most teams, and pretending otherwise creates a promise you cannot keep.

Anonymise rather than delete, where it helps

Some data has value in aggregate and none individually.

If you want to keep knowing how many orders were placed each month, you do not need the customer's name. Stripping identifiers converts personal data into statistics, which takes it outside most privacy obligations.

Do it properly. Removing a name while keeping an email address, a full IP, or a combination of fields that uniquely identifies someone is not anonymisation. If the record can be linked back to a person, it is still personal data.

Implement it, or it will not happen

A retention policy nobody executes is worse than no policy, because it documents a standard you are visibly failing.

Automate the deletion. A scheduled job that removes expired records, running regularly, logged so you can show it ran.

Make it idempotent and safe — the same discipline as any background job, since it will run repeatedly and must not delete more than intended.

Start with a dry run. Report what would be deleted before deleting anything, and check the number is what you expected. A retention job with an off-by-one in its date logic is a genuinely bad day.

Cover every system, not just the main database. Analytics, error tracking, email platform, support tool, exports sitting in cloud storage, and the spreadsheet someone made.

Handle cascades deliberately. Deleting a user affects related records, and a foreign key cascade discovered in production is not a plan — decide what happens to their orders, their comments, their audit trail.

Preserve what you genuinely need

Deletion should not destroy things you have a legitimate reason to keep.

Financial records generally must survive account deletion. An audit log recording that an action occurred may need to persist even when the actor's personal data is removed — usually by replacing the identifier rather than deleting the entry.

Design for this rather than discovering it when a deletion breaks your accounts.

A workable starting point

List your data types. Set a period and a reason for each. Write it into the privacy notice. Automate the deletion with a dry run first. Cover every system. Review annually.

That is a day of work and it removes a recurring liability — and it usually shortens log and analytics retention dramatically, which is the cheapest risk reduction available.

General information rather than legal advice; for regulated data, take advice on the specific periods.

If you are not sure what you are currently holding or for how long, book a call.

Common questions