Data Retention and Disposal: How Long to Keep Data (and How to Destroy It)

Keeping data forever is a liability, not an asset. This is how to decide how long to keep each kind of data, how a retention schedule differs from a legal hold, and how to destroy data securely when its time is up.

Why retention is a control, not an afterthought

Most organizations default to keeping everything indefinitely because deleting feels risky and storage feels cheap. But under modern privacy and security regimes, holding data you no longer need is its own liability — every extra record is more to secure, more to disclose, and more to lose in a breach. Retention is the deliberate decision about how long each kind of data lives and how it is destroyed afterward, and regulators increasingly expect that decision to be written down and followed.

The clearest legal driver is the GDPR's storage-limitation principle in Article 5(1)(e), which requires that personal data be kept in a form that identifies people for no longer than is necessary for the purposes it was collected for. There is no fixed number attached — "necessary" depends on your purpose and legal basis — and the regulation allows longer storage where data is held purely for archiving in the public interest, scientific or historical research, or statistics, subject to safeguards. The practical upshot is that if you cannot articulate a current reason to keep a personal record, the GDPR's default is that you should not.

Pulling the other way are obligations to retain. HIPAA requires covered entities and business associates to retain the documentation the Security and Privacy Rules require — policies and procedures, risk analyses, training records, and similar — for six years from the date of creation or the date it was last in effect, whichever is later, under 45 CFR 164.316(b)(2). (Note this six-year rule is about HIPAA documentation; how long you keep the underlying medical record is set mainly by state law.) Layered on top are tax record rules, employment and contract obligations, and sector-specific mandates. Retention is the discipline of resolving these competing pulls into one defensible answer per data category.

How to set a retention period for each data category

You do not set one retention period for "our data" — you set one for each category of data, because the right answer differs by what the data is and why you hold it. Start by inventorying what you actually keep: customer records, employee files, financial and tax records, marketing contacts, application logs, backups, support tickets, and so on. The GDPR record of processing activities (Article 30) is a natural home for this if you process personal data, but every organization benefits from the same map.

For each category, work through three lenses. First, the legal and regulatory floor: is there a law that requires you to keep this for a minimum time — tax records, HIPAA documentation, employment records, industry rules? That sets the minimum. Second, the legal basis and purpose: for personal data especially, why are you holding it, and does that purpose still exist? When the purpose ends and no retention law applies, the GDPR pushes toward deletion. Third, genuine business need: a defensible window for handling disputes, warranty claims, or recurring-customer history — justified, not open-ended.

The output is a specific, bounded period per category — "keep for the active relationship plus N years, then dispose" — with the reason recorded next to it. Vague rules like "retain as long as useful" fail in an audit and fail in a data subject access request. Where minimums and maximums conflict (a law says keep, a principle says delete), the retention obligation generally wins for that record, but only the data and only the time the obligation actually covers — not everything, forever, by default.

Retention schedule vs legal hold — two different things

A retention schedule and a legal hold are easy to confuse, and treating them as the same thing causes real problems. A retention schedule is your standing policy: the routine, repeatable rules that say each data category is kept for a defined period and then disposed of automatically. It runs in the background, the same way every cycle, and its whole purpose is predictable, defensible deletion.

A legal hold (sometimes called a litigation hold) is the opposite motion — a targeted instruction to stop deleting specific data because it may be relevant to actual or reasonably anticipated litigation, a regulatory investigation, or an audit. When a hold is in place, it overrides the retention schedule for the data it covers: records that would otherwise be destroyed on schedule must be preserved until the hold is lifted. Destroying data that is under a hold, even by following your normal schedule, can amount to spoliation of evidence and carries serious legal consequences.

The practical implication is that your disposal process must be pausable and selective. Before any scheduled destruction runs, you need a way to confirm none of the targeted records are subject to a hold, and you need a documented process for issuing, tracking, and releasing holds. A well-run program treats the schedule as the default and the hold as a deliberate, recorded exception — never an informal "let's just keep it in case."

The risk of keeping data too long

Over-retention is the quiet risk that most teams underrate. The first cost is breach exposure: data you deleted years ago cannot be stolen. Every record you keep past its useful life enlarges your attack surface and your breach-notification scope, so a single incident touches more people and more sensitive history than it needed to. Data minimization is not just a privacy principle — it is one of the cheapest security controls available, because the safest record is the one you no longer hold.

The second cost shows up in disclosure obligations. Under the GDPR, individuals can make a data subject access request (DSAR) and ask what personal data you hold about them; the more you have kept, the more you must find, review, and produce, often within a tight statutory window. Stale data also feeds erasure requests, e-discovery, and regulator inquiries — all of which get slower and more expensive in direct proportion to how much you hoarded.

There is a compliance cost too. Holding personal data with no current purpose and no retention justification is itself a likely breach of the storage-limitation principle, independent of whether anything ever leaks. Regulators have penalized organizations for keeping data long after the reason to hold it expired. "We never got around to deleting it" is not a defense — it is the finding. Disciplined deletion is one of the few controls that simultaneously reduces breach impact, lowers DSAR burden, and improves your regulatory posture.

Secure disposal: how to actually destroy data

Reaching the end of a retention period only matters if disposal is real. Dragging a file to the recycle bin or reformatting a drive does not reliably remove the underlying data, and "we deleted it" is not credible to an auditor without a method behind it. The reference framework here is NIST Special Publication 800-88, Guidelines for Media Sanitization, which defines three escalating levels based on how hard you want to make recovery.

Clear applies standard read/write commands to overwrite data so it cannot be retrieved with ordinary tools or software recovery — suitable when media will be reused inside your control. Purge uses stronger, often hardware-level techniques (such as cryptographic erase, secure-erase commands, or degaussing magnetic media) to make recovery infeasible even with laboratory methods, appropriate when media leaves your control. Destroy physically renders the media unusable — shredding, disintegrating, pulverizing, or incinerating — so it can never be reused; this is the highest assurance and the right choice for the most sensitive data or end-of-life devices. The correct level depends on the sensitivity of the data and whether the media is being reused or retired.

Two techniques deserve a specific mention. Cryptographic erasure (crypto-shredding) works by securely destroying the encryption keys for data that was encrypted at rest — if the key is gone and the data was strongly encrypted, the ciphertext is effectively unrecoverable, which is especially useful in cloud and multi-tenant environments where you cannot physically shred a disk. For physical records, cross-cut shredding (and secure destruction of backup tapes and decommissioned drives) is the paper-world equivalent of Destroy. Whatever the method, record what was destroyed, when, how, and by whom — a certificate of destruction or a disposal log is the evidence that the deletion actually happened.

Building and operating a retention schedule — and where templates fit

A retention schedule is a living document, not a one-time spreadsheet. Build it by listing every data category you hold, assigning each a defined retention period with the legal, contractual, or business reason recorded beside it, naming an owner, and specifying the disposal method and assurance level (Clear, Purge, or Destroy) for each. Then operationalize it: schedule periodic reviews, check the legal-hold register before any deletion runs, automate disposal where your systems support it, and log every destruction event. Review the whole schedule at least annually, and whenever a law, a system, or a processing purpose changes.

This is where a written Data Retention and Disposal policy earns its place, because it turns scattered intentions into a repeatable control your team and an auditor can both follow. ComplianceDocs toolkits include exactly this layer: the GDPR Compliance Pack for Small Business ships a Data Retention and Deletion Policy alongside its records-of-processing workbook, and the ISO 27001 Complete Toolkit includes a Data Retention and Secure Disposal Policy as part of its ISMS document set. These are editable starting points — current list prices are $79 for the GDPR pack and $99 for the ISO 27001 Complete Toolkit, and a launch discount code may apply at checkout (illustrative of list pricing, not a quote; confirm at checkout).

Be clear about what that documentation does and does not do. A policy template gives you a structured, defensible schedule and disposal standard to tailor to your data, which is genuinely most of the drafting work. It does not, on its own, make you GDPR-compliant or ISO 27001-certified: GDPR compliance comes from actually operating the controls, and ISO 27001 certification comes only from an accredited certification body after it audits a working information security management system. The template is the documentation layer; the compliance comes from running the schedule, honoring legal holds, and destroying data securely, week after week.

Frequently asked questions

Does the GDPR say exactly how long I can keep personal data?

No. The GDPR's storage-limitation principle in Article 5(1)(e) does not set fixed numbers; it requires that personal data not be kept in identifiable form for longer than is necessary for the purposes it was collected for. You determine the period yourself, based on the purpose, your legal basis, and any retention laws that apply, and you should be able to justify it. The regulation does allow longer storage where data is held purely for archiving in the public interest, scientific or historical research, or statistical purposes, subject to appropriate safeguards. When the purpose ends and no law requires retention, the default expectation is deletion.

What does HIPAA's six-year retention rule actually cover?

Under 45 CFR 164.316(b)(2), covered entities and business associates must retain the documentation that the HIPAA Security and Privacy Rules require — such as policies and procedures, risk analyses, and certain records — for six years from the date of creation or the date it was last in effect, whichever is later. This rule is about HIPAA documentation, not the medical record itself. How long you must keep the underlying patient or medical record is generally governed by state law, which varies and is often longer, so you need to check both.

What is the difference between a retention schedule and a legal hold?

A retention schedule is your standing, routine policy: each data category is kept for a defined period and then disposed of automatically. A legal hold is a targeted instruction to stop deleting specific data because it may be relevant to litigation, an investigation, or an audit. When a hold is in place, it overrides the schedule for the data it covers, and that data must be preserved until the hold is released. Deleting data under a legal hold — even by following your normal schedule — can be treated as spoliation of evidence, so your disposal process must check the hold register before anything is destroyed.

Is deleting a file or reformatting a drive enough to securely dispose of data?

Usually not. Ordinary deletion and quick reformatting often leave the underlying data recoverable with widely available tools. NIST SP 800-88 defines three levels of media sanitization: Clear (overwriting so data can't be retrieved with standard tools, for media you'll reuse internally), Purge (stronger methods like cryptographic erase or degaussing that defeat even lab recovery, for media leaving your control), and Destroy (physically shredding, pulverizing, or incinerating the media). Choose the level based on data sensitivity and whether the media will be reused or retired, and keep a destruction log as evidence.

Will a retention policy template make my organization compliant?

No. A Data Retention and Disposal policy template gives you a structured, defensible schedule and disposal standard to tailor to your data, which removes most of the drafting work — but a document on its own does not make you compliant or certified. GDPR compliance comes from actually operating your controls, including running the schedule, honoring legal holds, and securely destroying data on time. ISO 27001 certification comes only from an accredited certification body after it audits a working management system. The template is the documentation layer; compliance comes from consistently doing what the policy says.

Related guides: GDPR · ISO/IEC 27001

Toolkits that help

← All articles