The data you keep becomes work you owe.

Picture a cardboard archive box on the bottom shelf of a records room. Someone has written on its side in marker: FORMER STUDENTS, KEEP JUST IN CASE. Nobody remembers who wrote it, or when, or what the case was supposed to be. The box costs almost nothing to keep. It takes up one shelf, and the room is paid for anyway. Its digital twin is cheaper still: a table in a database, a few gigabytes on a cloud bill, with a column called owner that was left blank on the day it was created. The box and the table are invented, but most organizations that have been around for a decade will recognize both.

The label on the box describes a possible future use. What the box actually demands is a present stewardship obligation: someone has to decide who may open it, know why it is still there, answer when a person asks what it holds about them, and one day see that it, and every copy of it, is gone. My argument is that retention is an operating decision, not a storage decision. Each identifiable record an organization keeps creates work today, whether or not anyone has been assigned to do it, and the right response is retention tied to a stated purpose with a disposal path the organization can demonstrate.

That is not an argument for deleting everything on a timer. Some records must be kept, some are worth keeping, and an organization that purges by reflex can destroy evidence it was obliged to preserve or research it promised to reproduce. The claim is narrower. A hope that data might be useful someday is a reason to ask a question, not an answer to it, and it does not tell anyone who is responsible for the data in the meantime.

Cheap to store is not cheap to keep

The case for keeping data usually arrives with two attachments. One is a storage quote, and it is persuasive, because the price of holding a gigabyte has fallen for decades and keeps falling. The other is a use case: a model that might be trained, a trend that might be studied, a customer who might come back. Both are real. Neither answers the question that matters on the day the box is opened by the wrong person, which is who was supposed to be watching it.

The storage bill measures the shelf. It does not measure what comes with the contents. An identifiable record about a person has to be protected from people who should not see it, which means someone maintains the access rules and removes access when jobs change. It has to be findable, because a person may ask what is held about them, a regulator may ask how it is secured, and a court may ask for it. It has to have a purpose that someone can state, because without one there is no way to decide when the purpose has ended. And it has to be disposed of eventually, which is harder than it sounds, for reasons the next section explains. Each of these is a task with a cost, and the cost does not fall with the price of disks.

A possible future use is a legitimate thing to want. It becomes a problem when it is the only line filled in on the card, because then the obligations on the back are owned by nobody. They still exist. They are simply unfunded, and the people who bear the cost when an unfunded obligation fails are usually not the people who decided to keep the data. They are the people the data describes.

One record, four copies

Follow one invented record through an ordinary system. A student named in a district's roster becomes a row in a production table. Each night, the row is written to an export file that a partner picks up. Each week, an analytics job copies the table into a warehouse where analysts can query it without slowing the live system down. And every day, the whole database is backed up, and the backups are kept for a few weeks in case something has to be restored.

Now suppose the organization decides that this student's record should go. Deleting the row from the production table is one statement in one database, and it is the step most people picture when they hear the word. It is also the smallest part of the job. The export file from last night still holds the row. The warehouse holds it until the next rebuild, or indefinitely if the warehouse appends rather than replaces. The backups hold it for as long as they are kept, and backups are often designed so that individual records cannot be removed, which is what makes them trustworthy as backups.

None of this means deletion is impossible. It means deletion is a process with several steps, each with its own timing and its own proof. The export can be regenerated and the old file removed. The warehouse can be rebuilt without the row. The backup cannot be edited, but it can be allowed to expire on schedule, and in the meantime the organization can keep a list of disposed records so that any restore replays the deletions before the restored data goes back into service. That last rule is easy to miss and important: without it, a restore after an outage quietly brings back records the organization had already decided to dispose of. The sheet below traces one such plan. Drag across it, or tab to it and use the arrow keys.

Notice what the sheet asks for at the end of each blue line: evidence. A disposal plan that cannot show its own completion is a hope of a different kind. The proof can be modest, a job log, a list of removed files, a rebuilt table's row count, a backup expiry date. What matters is that someone can produce it when asked, for each copy, and not only for the one that was easiest to reach.

A case on the record

On June 5, 2026, the Federal Trade Commission gave final approval to an order against Illuminate Education, a company whose software schools use to hold student records.¹⁴ The order settles allegations the Commission first announced in December 2025. They are allegations, settled without a trial, not findings by a court. According to the FTC, a hacker used the credentials of a former employee, who had left the company three and a half years earlier, to break into Illuminate's databases on a third-party cloud provider in late December 2021, exposing data about 10.1 million students, including dates of birth, student records and health-related information.³ The Commission also alleged that the company had been warned of security weaknesses as early as January 2020, stored student data in plain text until at least January 2022, and waited nearly two years to notify some school districts.³

For this essay the interesting part is what the order requires. It does not stop at security. Illuminate must delete covered information it no longer needs, meaning information whose retention is neither reasonably necessary to provide its contracted services nor requested by its customers, and give the Commission a sworn statement that it has done so. It must stop collecting or keeping information that is not reasonably necessary. And it must publish, and follow, a retention schedule that states why each kind of information is collected, the specific business need for it, and a set timeframe for its deletion.² The order even defines what deletion means: the information is no longer kept in retrievable form and cannot be retrieved in the normal course of business.² Alongside those duties sits a comprehensive security program with an inventory of the covered data, encryption at rest, phishing-resistant multifactor authentication, and removal of access within 30 days of a change in need, all for the order's ten-year term.²

Two cautions keep the case in proportion. The order concerns one company and the facts the Commission alleged about it; it is not a statement of every organization's legal duties. And nothing in it proves that a particular retention schedule would have prevented the breach. What it does show is how a regulator, faced with a large store of sensitive records, translated the problem into operating terms: a stated purpose, a business need, a deadline, a definition of done, and a person who has to swear to it.

A register, not a purge

The practical alternative to the archive box is a retention register: one entry for each set of identifiable records, with five things written down. The purpose for which the data is kept. An accountable owner, by name or role, who can be asked about it. A review date on which someone checks whether the purpose still holds. A disposal rule that covers every copy, including the export files, the analytics copies and the backups. And a list of documented exceptions, each with its reason and its own review date. This register is my proposal, not a schema the FTC prescribed; the Illuminate order asks for a public retention schedule with purposes, needs and timeframes, and the register is one way to build the internal machinery that would let a schedule like that be true.

The National Institute of Standards and Technology's Privacy Framework, published in January 2020, gives the same idea a structure. It is voluntary guidance for managing privacy risk, not a certification, a law or a safe harbor.⁵ Its five functions run from understanding what data an organization processes and why (Identify-P), through policies and responsibilities (Govern-P), to managing data with enough granularity to control the risk, including retention and disposal (Control-P), and then communication and protection.⁵ Read with the archive box in mind, the framework's point is that disposal is not a separate cleanup project. It is the last stage of a lifecycle that starts with knowing what you hold and who is responsible for it.

The register makes one more thing visible: cost. When each entry has an owner, someone has to budget for the access reviews, the request handling and the disposal jobs. That is the right place for the argument about whether a dataset is worth keeping. A use case that cannot justify the cost of its own stewardship is telling you something about its value.

Good reasons to keep

The tradeoff is real, and pretending otherwise would make the register a deletion campaign with better paperwork. Auditors may need records for years. Laws impose recordkeeping duties of their own. A litigation hold suspends ordinary disposal, and destroying records under one is far worse than keeping them too long. Researchers who publish a result may have promised to keep the data that produced it, so that others can check the work. The Illuminate order itself carves out retention required by law, court order or other legal obligation, including the preservation of evidence in pending litigation, and retention requested by customers or government agencies.²

The answer to these is not a universal rule, such as deleting everything after a fixed number of days. It is a scoped exception: this dataset, for this reason, under these access controls, until this date or this event, reviewed by this person. An exception written that way is a stewardship obligation that has been accepted and funded. An exception that says "legal said to keep everything" is the archive box again, with a more authoritative label.

Objections, considered

Deleting data destroys future value. Sometimes it does. Data that seemed worthless has later answered questions nobody thought to ask, and a strict schedule will occasionally discard something that would have mattered. The response is not to keep everything but to make the future use specific: name it, set a review point, and compare keeping identifiable records with keeping aggregates or carefully assessed deidentified data, which can serve many analytical purposes with less risk to the people described. The Illuminate order, notably, excludes deidentified information from its deletion requirement.² A future use that cannot survive those questions was a hope, not a plan.

Retention is a legal department issue. Interpretation is. Lawyers decide what the organization must keep, what it may keep and what it must not. But execution is a systems problem: finding the copies, writing the jobs, rebuilding the warehouse, expiring the backups, replaying deletions after a restore. A policy that legal approves and nobody in technology is funded to carry out is a document, not a practice. The owner on the register has to be someone who can make the systems do what the policy says.

The order concerns one company. Exactly. It is a bounded case with its own alleged facts, settled by consent, and it should not be read as a statement of what every organization owes. Nor is the idea peculiar to it. In 2022 the Commission's proposed order against the alcohol delivery platform Drizly, after a breach it said exposed data on about 2.5 million consumers, likewise required the company to destroy personal data it did not need and to keep personal information only for specific purposes set out in a retention schedule.⁶ European law has stated the general principle since 2016: personal data should be kept in identifiable form no longer than its purposes require, with longer storage allowed for archiving, research and statistics under safeguards.⁷ The Illuminate order's usefulness is that it is concrete. It shows what a regulator asked for when it had to turn an abstract principle into duties a company could be held to, and those duties are a reasonable checklist for anyone holding other people's information.

Every retained record needs a reason to remain and someone responsible for its departure.

Before the next storage quote

• Which datasets have no current purpose? Not a possible one, a current one, written down with a name next to it.
• Who owns each copy? The export files, the analytics copies and the backups, not only the production table.
• Which exceptions have no review date? An exception without one is permanent by default.
• Can a restore bring back records already scheduled for disposal? If nobody knows, assume it can.
• What evidence would show a disposal was complete? For every copy, and who would produce it if asked.

Back to the box on the bottom shelf. Nothing about it has to change dramatically. Turn the card over and fill in the back: an owner whose name someone recognizes, a purpose that can be checked, a date when the box will be reviewed, and a date when it, and its copies, will leave. It may turn out that the box should stay. If so, it will stay for a reason, and someone will be responsible for it.