Security, Abuse & Privacy

Data Retention

Definition

Data retention is the deliberate answer to the question of how long each kind of record lives. The GDPR calls the underlying principle storage limitation: personal data should be kept in a form that identifies people no longer than is necessary for the purpose it was collected for. In practice that becomes a retention schedule, a short table naming each store, its purpose, its period and what happens at the end of it. Periods vary enormously by purpose — server logs commonly run 30 to 90 days, marketing lists are often reviewed at twelve or twenty-four months, while invoices and tax records are usually required to be kept for six years or more. The end state is either deletion or true anonymisation, and the difference matters: aggregate counts with no identifiers can be kept indefinitely, whereas the rows they were built from should not be.

Why It Matters

Every record you still hold is a record you must protect, find on request and explain after a breach. A form store four years old contains people who have forgotten the download, changed employer and would be surprised to hear from you, and it adds nothing to the business while adding weight to every incident. The other direction has teeth too: deleting something you were obliged to keep, such as a financial record, is its own problem, which is why a schedule beats a reflex either way. Retention is also where version history quietly accumulates, since a file replaced twenty times may have twenty stored predecessors, some containing details the newest one no longer shows. As general information rather than legal advice: pick a period per store, write it down, and make the deletion actually run.

How It Works

Retention is enforced in whatever system holds the data, so each store needs its own mechanism. Object storage offers lifecycle rules that delete or downgrade objects after a set number of days since creation. Log pipelines drop indices past their window. A form or CRM needs either a built-in policy or a scheduled job that runs the deletion and records that it ran. Two things routinely survive the cull: backups, which hold their own copy until the backup itself expires, and exports someone made to a spreadsheet, which live on a laptop outside every policy you have written. A workable approach is to keep the identifying rows briefly, roll them up into counts that identify nobody, and let the aggregate carry the long-term value — the shape of the traffic survives, the list of people does not.

Real-World Example

An agency runs a campaign with a gated proposal at brandpack-2026.99helpers.site and collects 340 registrations over six weeks. The schedule says the raw list goes to the mailing tool within a week and is cleared from the form store after ninety days; the aggregate — how many, from where, through which referrer — is kept for good, because it identifies nobody. Version history on the proposal itself is pruned once the campaign closes, since four superseded drafts on 99helpers carry pricing the agency would rather not leave reachable. Six months later there is a report to learn from and no pile of stale addresses to worry about.

Common Mistakes

  • Writing a policy and never scheduling the job — an unenforced retention period is worse than none, because it is now a promise you are breaking
  • Forgetting the copies: backups, exports, the spreadsheet on someone's laptop and the attachment in a support ticket all outlive the main store
  • Deleting records required by tax or contract law to prove tidiness — retention runs both ways, and some data must be kept

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →