O1.02.3Storage limitationdesignresearch

Retention duration is part of data minimization

Aliases: retention schedule · retention minimization · data lifecycle

What it is

Storage limitation treats time as a dimension of data minimization: even information legitimately collected should remain only as long as its defined purpose requires. Retention is not one arbitrary number for an entire database. Each data class and purpose needs a start event, duration, deletion method, and bounded exceptions. Moving unused records into an indefinite archive is still retention.

Why it happens

The present utility of records often declines while their accumulated exposure persists. Old data enlarge breaches, preserve stale identities and errors, and allow later uses to reconstruct longitudinal lives. Automatic expiry turns deletion from an event dependent on human memory into a lifecycle property. A policy-only duration fails when storage, replication, and backup systems continue multiplying copies.

Studying it

Retention audits can sample creation time, latest justified use, expiry rule, actual deletion, and backup residue by data class, using distributions rather than averages to expose a long tail. Utility studies can estimate the marginal contribution of successively older windows to a function or model. Read frequency is not necessity: rarely accessed audit evidence may be mandatory, while frequently queried historical profiling may lack a legitimate purpose.

Where it stops holding

Contracts, tax records, disputes, and security investigations may require longer storage or a legal hold, but exceptions should identify records, authority, and end conditions. Properly de-identified aggregates may outlive source records; pseudonymous records remain linkable and are not automatically anonymous. Delayed removal from backups can be reasonable only if restored data immediately re-enter expiry enforcement and are unavailable for routine use.

Applying it

  • Define when the clock starts, duration, extension events, deletion method, and exception authority for each data class.
  • Attach expiry metadata at write time and automate enforcement across primary stores, caches, indexes, warehouses, and processors.
  • Aggregate early and remove identifiable detail when only population-level trends retain long-term value.
  • Periodically restore a backup in isolation, run lifecycle enforcement, and inspect oldest records, deletion logs, and holds; clear any overdue record without auditable justification.

Related

  • Same group: O1.02.1 Collect only the data necessary to deliver the function · O1.02.2 Every data field needs a stated purpose
  • Adjacent: O1.07 Right to erasure and data deletion · O2.04 Privacy dashboard
  • Search terms: storage limitation · retention schedule · data lifecycle

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O1.02.3