How long can you keep user data? Write down the period, then make something enforce it.

Your privacy policy says you delete account data thirty days after someone cancels. A prospect's security questionnaire asks you to confirm it, so you open the code to check.

The accounts table has a deleted_at column and nothing that ever removes the row. Your error monitor is holding serialised user objects on whatever schedule that vendor defaults to. The warehouse copy has no clock on it at all. Nobody wrote that sentence dishonestly: it was true of the delete endpoint on the day it shipped, and the other six places the data goes were never in anyone's scope.

That gap stays invisible until someone who can make you answer comes asking. In January the French regulator fined Free Mobile 27 million euros after a breach, and one of its three findings was not about the attack at all: on the day the CNIL inspected, the company was still holding millions of records on former subscribers with no justification for keeping them 4. The inspection happened because more than 2,500 people complained.

Every product has former users, and most keep more of them than their privacy policy admits. When I scanned Product Hunt launches across July and August, three quarters of the 397 readable privacy policies named a retention period. Publishing that sentence is easy. Keeping it true is engineering work, and it happens in the codebase rather than in the document.

What exactly do you have to publish about retention?

A number, or the rule you use to arrive at one. Article 13(2)(a) of the GDPR asks for "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period" 1, and Article 14(2)(a) repeats it for data about a person that reached you some way other than from them 1.

This duty is yours where you are the controller. Where you are a processor, holding data on behalf of a business customer, the period comes from their DPA and their instructions, and your privacy policy is the wrong place to describe it. Both kinds sit in the same tables and the same logs, so the sorting has to happen deliberately.

That second option, publishing the criteria, is narrower than it sounds. The transparency guidelines endorsed by the European Data Protection Board, the body that coordinates the national privacy regulators, say the criteria can come from statute or industry practice, but have to be written so a reader can work out what the period will be for their own data. Then they shut the obvious door: "It is not sufficient for the data controller to generically state that personal data will be kept as long as necessary for the legitimate purposes of the processing" 2. The same guidance asks for different periods to be stated for different categories of data where that is relevant, so one sentence covering the entire product is usually too coarse.

Underneath the disclosure sits the principle it reports on. Article 5(1)(e) 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" 1. Your published sentence is a description of that. The regulator checks the description against your systems, and in the Free Mobile case the systems were where the failure sat: the CNIL's finding is about records that were still present on the day it inspected.

There is a third place the same number belongs. Article 30 requires a record of processing activities: an internal register of what you process and why, never published, produced when a regulator asks. Article 30(1)(f) says it should state, where possible, "the envisaged time limits for erasure of the different categories of data" 1. Small teams often assume Article 30 does not apply to them because they employ fewer than 250 people, but that exemption falls away where the processing "is not occasional" 1, and a product with live users processes continuously. Assume you owe the register.

What did 32 regulators find when they went looking?

Periods nobody could defend. One controller "was unable to distinguish the appropriate retention periods for different processing operations and instead applied the longest period applicable to one processing activity to all of them" 3. Another applied a period meant for one protected category of data by default, without checking whether it suited anything else. Defining and implementing retention periods came back as one of seven recurring problems.

Those findings come from a coordinated action the EDPB published on 10 February 2026, in which 32 supervisory authorities questioned 764 controllers, mostly public-sector bodies and large enterprises, about how they handle requests to delete personal data 3. The authorities that raised this one reported it for smaller organisations in particular 3.

Where does user data survive after you delete the user?

In more places than the delete button reaches. Assume one person's data is spread across every one of these before you write any period down:

• Primary tables. The row you delete, if you delete it. A deleted_at column is a hidden row, not an erased one.
• Rows that point at the user. Audit trails, comments, events, invoices, webhook payloads. Foreign keys survive their parent more often than anyone intends.
• Application and access logs. Request logs carry user IDs, IP addresses and sometimes bodies. Their lifetime is set by whoever configured the log drain, which is rarely the person who wrote the privacy policy.
• Error monitoring. A stack trace with a serialised user object attached, kept on the vendor's schedule.
• Product analytics and the warehouse. Copies made for reporting, each with its own clock.
• Third-party processors. Your email provider, your billing provider, your model API. Every one of them keeps a copy and deletes it on terms you agreed to once.
• Backups.

Backups are where most teams have no answer, and the regulators found the same. Half of the responding authorities raised concerns about deletion in backups, and many controllers had no specific procedure for it, relying instead on the backup being overwritten in the normal cycle 3. Separately, one authority looked at controllers deleting in increments spanning long periods and found the practice "creates difficulties to conclude" whether deletion prompted by an erasure request happens "without undue delay", as Article 17(1) requires 3. Vagueness here is not a small-company habit either: a 2019 review of major privacy policies found Instagram promising to keep data for a "reasonable" amount of time in backups after a user asks for deletion.

You can hold a defensible position here without claiming instant deletion. State how long a backup lives before it is overwritten, keep restores from resurrecting people who asked to leave, and re-apply outstanding deletions after any restore. Teams skip that last step, because a restore is already a bad day and nobody wants a second checklist during it, so write the checklist now and keep it with the runbook.

What would I write down, and what would I build?

I would open the schema before opening the privacy policy. List the categories of personal data the product holds: account records, billing records, support conversations, logs, analytics events. For each, write a period and the criterion that sets it, and name where the criterion comes from, because accounting and tax rules will decide several of them and saying so is more useful to a reader than a round number. Article 13(2)(a) lets you publish either one 1. The EDPB report asks for both, and recommends keeping a table with one row per kind of data, showing its legal basis and how long you keep it 3.

Then make one of those periods real in code before you publish any of them. A scheduled job that deletes expired rows, with a test that proves it, is worth more than a well-drafted paragraph. Retention is the claim I would least like to publish ahead of implementing, because it is the easiest one for an outsider to falsify. It sits among the twelve facts a privacy policy needs before launch, and it is the only one a prospect can test against your product rather than against your prose.

The reason I would build the job first is that the sentence ages badly. Retention windows move during ordinary product work: somebody raises log retention from thirty days to a year to chase a bug, a new analytics vendor arrives in a pull request, a table gets added that nobody classifies. None of that looks like a legal event on the day it merges, and each one can quietly make a published period wrong.

Lawcel is a tool that keeps a company's legal documents matching the product it actually ships. It watches where product change shows up, mostly GitHub pull requests and issue trackers, and tells you when a change has made one of your published documents wrong. It keeps a record of the deadlines you have promised people, deletion timelines among them, so a pull request that moves a retention window gets checked against the period you published instead of waiting for a review nobody schedules.

If you have published a retention period, you need something in the product that enforces it, or the first person to test the claim will be an attacker, a regulator or a customer's security questionnaire, and the answer they get will be whatever your database happens to hold that day. Open the schema, write the period and its reason next to each category of data, and pick the one you would least like to explain. Write that deletion job this week, and if you would rather not be the one tracking the sentence afterwards, point Lawcel at the repository and let it watch.