Retention Period

Nobody gets credit for deleting data. Ship a feature and users notice and revenue moves; delete the records of a member who left three years ago and not a single number changes. As storage got cheap, the last practical reason to clean up went away with it.

So a company's database tends to grow older than the company. The member table at a business three years into operating holds the people using it now, the people who signed up once and never came back, and the people who pressed the delete-my-account button two years ago, all in the same place. The consequence only becomes visible when that table leaks.

A company with 30,000 active users files a breach notification, counts who has to be told, and arrives at 210,000 people. The other 180,000 left long ago, and they are victims because the company still held their data. Data nobody was using had been accumulating with nothing but risk attached to it.

A retention period puts an end date on that accumulation. Deciding how long something will be kept happens at the same time as deciding to collect it, and when the clock runs out the data goes. The shift underneath the rule is treating data past its purpose as a liability rather than an asset.

Three principles govern this area and each one bites at a different moment. Data minimization applies at collection, purpose limitation applies at use, and a retention period applies at deletion.

Set a separate period for each item, derive that period from either a law or the purpose, and make the deletion run automatically rather than by hand.

There are only two sources for the number.

1. A statutory period — the company cannot shorten these. Commerce rules commonly require contract and payment records to be kept for five years and consumer complaint and dispute records for three, and data protection rules often require access logs for systems holding personal data to be kept for at least a year. This is why a departed member's payment history cannot simply be erased on the day they leave.
2. The end of the purpose — where no law sets a figure, the company does, and the question is when the reason for collecting the data runs out. An address collected to ship an order stops being needed once the order arrives and the return window closes. "We might want it later" is not a basis for extending the clock.

Once the numbers exist, three things follow.

1. Put it in a table. Four columns: the data item, its purpose, the period, and where the period comes from. Not "member information" as one row, but email, payment records, access logs and support tickets each on their own line.
2. Automate the deletion. A period with no job behind it is a number that lives only in a document. Whether a nightly task exists that selects expired rows and removes them is the entire difference between a policy and a claim.
3. Decide what deletion means. Either the record goes entirely, or the identifying parts come out and the rest stays. When monthly signup counts have to survive, names and email addresses get stripped and only the fields the aggregate needs remain.

Data can also be set aside before its period ends. Moving accounts that have not logged in for a year into a separate, locked store is a common pattern, and it pulls that data out of everyday access paths so a breach reaches less of it.

The places where the clock is hard to honor are predictable.

1. Account deletion — one button triggers a different period for every item. Email and name go immediately, payment records move to separate storage for five years, support tickets expire after three.
2. Logs and the analytics pipeline — deleting the row in the member table leaves a user identifier sitting in every event already sent to an analytics tool. Each destination needs its own period and deletion method, and with external services the company often cannot delete anything directly.
3. Backups — yesterday's backup still contains what was deleted today. The usual answer is keeping backups on a short rotation rather than trying to edit them, since surgically rewriting a restored snapshot costs more than letting the snapshot expire.
4. Recruiting — a rejected candidate's resume has served its purpose once the hiring round closes. Keeping it to reach out again later requires consent collected for that purpose.

Managing these periods as a table is not only a privacy task; it overlaps with what data governance covers, because a company can only honor a clock on data it knows it has.

"What's the retention period on this table? The doc says one year and there are rows from two years ago."

The documented period and the actual data have drifted apart.

"We don't delete everything at account closure — payment records move to separate storage for five years."

Splitting statutory retention from everything else.

"How do we delete the events we already sent to the analytics tool? Those carry a user ID too."

Raising the fact that deletion reaches past the company's own database.

Pagedeck only built this table after its first deletion request. A user asked for everything about them to be removed, and it took Theo one minute to delete the row in the member table. Finding what was left took two days.

The same person's data was spread across support tickets, records held by the payment processor, events sent to the analytics tool, and a backup from two days earlier. Grace had an item-by-item period table written that week and moved deletion onto a nightly job. Eleven items went on the table, and four of them had never had a period set at all.

Many teams assume keeping data longer is the safe choice, on the theory that records help if a dispute comes up later. For items a law requires, that is true. For everything else, data kept past its purpose sits unused while enlarging the blast radius of an incident. Breach scale is counted by the number of people in the database, not the number of people using the product. Deleting expired data is one of the few levers that shrinks the damage of an incident before it happens.

The other common misreading is that deleting the row in the member table finishes the job, because deletion is imagined as a single command. In reality the same person appears in payment records, support tickets, the analytics tool, backups and log files. Delete only the member row and the person looks gone while remaining identifiable everywhere else. That state is worse than doing nothing, because the company believes it is done and nobody goes looking for the rest.