Data Retention Policy: What to Keep & How Long (2026 Guide)

A data retention policy is the documented set of rules that decides what data your organization keeps, where it lives, how long it stays, and how it is destroyed when that time ends. It applies to customer records, employee files, marketing data, contracts, logs, and, whether you planned it or not, to whatever your website collects and sends to third parties.

For most data a modern business holds, no law gives you a single number. Some laws set minimums: keep payroll records for three years and tax records for at least as long as the IRS can audit them.

Privacy laws pull the other way, setting a maximum: keep personal data only as long as necessary and be able to prove what “necessary” was. A retention policy reconciles the two category by category. Anyone who hands you a single number for everything is selling you a liability.

Get this wrong in either direction, and the damage is practical. Keep data too long, and you expand breach exposure, audit scope, and regulatory risk under frameworks such as GDPR and CCPA. Delete it too early, and you create legal, evidentiary, and operational problems.

What is a data retention policy?

A data retention policy is a formal, written document that answers four questions for each category of data your organization holds: what you keep, where it is stored, how long it is kept, and what happens to it at the end.

It usually takes the form of a short policy statement plus a working table, the retention schedule, that assigns each data category a period, a legal or business justification, and a deletion trigger.

The term gets confused with three neighbors, and the confusion causes real compliance failures:

A backup is not a retention policy: backups copy data, while the policy decides how long anything, including those backups, should live. An archive is not a retention strategy. It is where data goes, not when it dies. And a legal hold overrides the schedule entirely, which is why a policy that doesn’t mention holds is incomplete.

Is there a law that tells you exactly how long to keep data?

No single law does, because two different kinds of law pull in opposite directions, and your policy exists to reconcile them.

The first kind sets floors. Records and sectoral laws require you to keep specific records for specific minimum periods: payroll records for three years, employment tax records for four, HIPAA compliance documentation for six, audit workpapers for seven. Delete earlier, and you’re exposed to the IRS, the Department of Labor, or a court that assumes the missing records would have hurt you. 

The second kind sets a ceiling. Privacy laws (the GDPR in Europe, California’s Consumer Privacy Act (CCPA) as amended by the Privacy Rights Act (CPRA), and the wave of US state privacy laws that followed) prohibit keeping personal data longer than necessary for the purpose it was collected and require you to disclose your retention periods or the criteria behind them. Keep everything forever “just in case,” and you’re violating the ceiling even if nothing is ever breached.

So the honest answer to “how long should we keep this?” is always: which data, collected for what purpose, under which laws? The sections below give you both halves: the real numbers where laws provide them, then the rules where they deliberately don’t.

Who asks to see this document?

Regulators, increasingly: California’s law requires retention disclosures as part of your consumer-facing notices. Also, enterprise clients’ security and due diligence questionnaires and auditors. “Send us your data retention policy” is a standard line in vendor reviews, and “we don’t really have one” is a worse answer than most people realize. The upside of getting this right is concrete: data you have properly deleted cannot be breached, subpoenaed, does not inflate your storage bill, or widen the scope of your next audit.

Data retention periods: the laws that set real numbers

When laws do give numbers, they give minimums for specific record types, mostly tax, employment, financial, and compliance records. The following are the federal floors:

Two laws cut the other way, with explicit maximums: Utah’s Employment Selection Procedures Act requires employers to dispose of job-applicant selection data within two years if the applicant wasn’t hired (Utah Code § 34-46-203), and the federal Video Privacy Protection Act requires destruction of video-rental records within one year of their no longer being needed (18 U.S.C. § 2710(e)). Maximums are still rare in US law, but privacy legislation is steadily adding them, and the CPRA’s “no longer than reasonably necessary” rule is a maximum in everything but the numbers.

A few categories genuinely never expire: formation documents, bylaws, board minutes, property deeds, and court orders are all considered permanent records.

As for the schedule you’re going to draw up, it should be noted that the IRS, the DOL, and the majority of agencies accept electronic storage, on the condition that the records remain legible, complete, and retrievable for the whole period; a scanned archive is just as acceptable to them as a physical one.

Customer marketing data, website analytics, support conversations, and product usage logs are not covered in the table above. For the categories a digital business drowns in, no statute gives a number. That is by design, and it’s where the other kind of law takes over.

What the privacy laws require: GDPR and CCPA data retention rules

Privacy laws don’t tell you how long to keep data. They give you a principle, a disclosure duty, and a demand for proof.

The GDPR, the EU’s General Data Protection Regulation, is the source of most of these concepts. It applies to organizations anywhere that offer goods or services to people in the EU or monitor their behavior.

The principle: storage limitation

Article 5(1)(e) of the GDPR requires personal data to be “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed.” Note the test: necessary for the purpose, not potentially useful someday. Retaining a customer’s history because they might buy again is not, by itself, a lawful basis.

California adopted the same approach. The CCPA, as amended by the CPRA, bans the retention of a consumer’s personal information “for each purpose for which the personal information was collected if such retention extends beyond what is reasonably necessary for that purpose.” It also mandates that any collection, use, retention, and sharing must be “reasonably necessary and proportionate” to the purpose (Cal. Civ. Code § 1798.100). The majority of the more recent US state privacy laws adhere to this same model.

The disclosure duty

This is the part businesses miss. GDPR Article 13(2)(a) requires you to tell people, at collection, “the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period.” California’s § 1798.100(a)(3) requires the same disclosure, per category of personal information, in your privacy notice. “We retain data as long as necessary for business purposes” does not satisfy either one; regulators have said so in enforcement decisions.

The proof

GDPR Article 30(1)(f) expects your record of processing activities to include “the envisaged time limits for erasure of the different categories of data.” Under both regimes, an undocumented retention decision is treated as no decision at all.

One point that confuses people is that the disclosure applies on a category and context basis, not on a per-data-element basis. A customer’s email address can legally have three different retention periods at the same time: one for order fulfillment means keeping it for the entire duration of the account, one for the newsletter means retaining it until the customer unsubscribes, and another one, in the context of a tax record, means keeping it for four years. The schedule links each purpose to its respective retention period, and the notice lists these.

How to decide what to keep and for how long

For each type of data, five questions produce a defensible retention period. The output is one line in your schedule for each category.

1. What was the reason for its collection, and is that purpose still in effect? If that purpose had ended, the legal basis for retaining the data would usually have ended as well.
2. Is there a minimum requirement set for this kind of record? Refer to the floors table listed above. A statutory floor takes precedence over a ceiling set by privacy law: it is a legal requirement to keep tax records for four years, not an example of over-retention.
3. Will a privacy law set a limit on it? With personal data having no minimum limit, the rule regarding a maximum applies: it should not extend beyond what is necessary for the purpose.
4. Which period are you able to document and defend? Select a period between the floor and the ceiling that you can justify in writing, stating the purpose, the legal minimum, and the judgment call, and record it.
5. When does the clock start, and what ends it? A period without a start event can’t be enforced. Define the trigger: collection date, account closure, end of the tax year, consent withdrawal, plus the action that fires when it hits.

Here is the method producing real periods for the categories every website operator holds:

Run every category through the same five questions, and you have the spine of a retention schedule.

What a data retention schedule looks like

A retention schedule is a working table: one row per data category, one column per decision, and one of the core data retention best practices for setting defensible periods. Eight columns cover everything an auditor, a client questionnaire, or your future self will ask:

1. Category: what the data is
2. Purpose: why you have it, and whether the business still needs it for that original purpose
3. Period or criteria: how long, or exactly how the period is determined
4. Legal basis: the floor, the purpose, or the documented judgment behind the period
5. Clock start / deletion trigger: the event that starts and ends the count
6. System: where the data actually lives, including relevant data storage details, applicable storage locations, and, per category, who else holds a copy
7. Owner: the person accountable for that row
8. Disposal method: deletion, anonymization, or archival, and how it’s verified, which also clarifies how the organization stores records over time

Filled in, using the framework above:

Effective data retention policies also enhance operational efficiency, and regularly purging unneeded data can reduce storage and maintenance costs.

That last row is where most schedules quietly fail. The columns you can’t fill in (system, owner, disposal) are not an oversight.

The retention your policy can’t see: your own website

Most retention guides tell you to inventory your CRM, email, HR system, your cloud drives, and your backups. Yet almost none of them ask what data your website gathers and sends from the visitor’s browser. For a business that operates online, this is where the retention policy has its biggest hole.

Two things are happening on your website right now that your schedule probably doesn’t cover, and missing them can leave you keeping too much data.

First, your site may collect information in the browser that never makes it into the systems you usually review, even though it still creates privacy, compliance, and operational risk.

Second, data captured on the site may be copied into archives or backups under a separate backup retention policy, which affects how long those copies are kept for recovery, legal, or archival purposes.

Cookies set their own retention periods

The expiry date attached to each cookie your site sends out is usually set at a length of months or years for analytics and advertising cookies. A two-year analytics cookie represents a retention decision, since personal identifiers are kept on the visitor’s device for two years due to a default setting that no one has chosen or reviewed. If your policy states that you retain analytics data for 14 months but your tag manager is set up to place cookies that last longer than this, then your policy is fictitious.

Pixel transfers create copies your schedule will never reach

When an advertising or analytics pixel fires, data leaves the visitor’s browser and ends up on a third party’s platform: the ad network, the analytics provider, or the tag ecosystem. At that point, a copy of the data is held according to their retention policy, not yours. Even if your schedule states “delete after 12 months”, this instruction will be carried out faithfully in all cases except those where the data had actually been sent.

This isn’t only an operations problem. It’s a disclosure problem. The per-category disclosure duty lands directly here: “identifiers” and “internet or other electronic network activity” are categories your website collects continuously, and most companies are unable to give an honest timeframe for this data because they have never mapped what their site collects, which endpoints receive it, and what the recipients keep. So the wrong disclosure isn’t buried in a log file somewhere. It goes live in the privacy notice on day one, and nobody knows.

Here is the surface you are governing:

The boundary to be honest about: this is the browser layer, what the page itself sends. Server-to-server flows (for example, conversion APIs that transmit events directly from your server to a platform) don’t pass through the browser and aren’t visible there. They need their own inventory. But the browser layer is where the unmapped sprawl lives, and it is the layer almost no retention policy covers.

The two control points follow logically. 

• Upstream: minimize what you send, because you cannot over-retain data a pixel never transmitted. 
• Downstream: make vendor contracts carry deletion obligations, because contract terms are the only reach your schedule has inside someone else’s platform (the vendor-contract mechanics are covered in our CCPA compliance guide). 

And the client-side mechanics of how this data moves are mapped in our guide to data leakage

When retention ends: deletion, anonymization, backups, and legal holds

A retention period that ends without a working deletion process is just a date on a page. Four mechanics decide whether your schedule is real.

1. Delete, or genuinely anonymize

When the period expires, the data must be deleted, or anonymized to a standard that removes identifiability. Pseudonymized data (a name replaced by a customer ID you can still link) is still personal data under the GDPR. Denmark’s Datatilsynet made the point expensively in 2019: taxi company Taxa 4×35 deleted customer names at its own two-year deadline but kept phone numbers, and the authority held that nearly nine million rides were still identifiable personal data, recommending a fine of 1.2 million kroner and reporting the company to the police. Partial deletion is not deletion.

2. Deletion means all copies, including the backups.

Live databases, exports, spreadsheets, logs, and backups all hold the data, and when the retention period expires, it must be securely deleted or genuinely anonymized. Where immediate deletion from backups isn’t technically possible, the accepted approach is to restrict processing of the backed-up data and let it age out with backup rotation under a documented backup retention policy written into the policy, not improvised per request.

Proper removal also means addressing partial deletion as both data deletion and data disposal, not just record cleanup.

3. Record the destruction

What was deleted, when, and by what method. Under the accountability principle, the record of deletion is itself part of compliance: it is what separates “we have a policy” from “we can prove we follow it.”

4. Two overrides can legally stop deletion

First, the legal hold: the moment litigation, a regulatory investigation, or an audit is reasonably anticipated, scheduled destruction of anything potentially relevant must stop until the hold lifts. Deleting on schedule is compliance. Deleting after a hold should have applied is spoliation. 

Second, an erasure request meets a retention duty: when someone exercises a “right to be forgotten” against data you’re legally required to keep, the retention duty wins, narrowly. GDPR Article 17(3)(b) and CCPA § 1798.105(d) both carve out legal obligations (plus needs like completing the requested transaction and detecting security incidents), but the carve-out applies to the minimum data, for the required duration, for the specific purpose, and the decision must be documented. 

The process of handling access and deletion requests end-to-end is in itself a separate discipline. (Our guide to data subject access requests (DSARs) covers it.)

How to create a data retention policy, step by step

A comprehensive data retention policy should be clear and actionable. You can build a defensible first version in a working week, in this order:

1. Inventory your data. Every category, every system. Include the website layer from the section above, or the inventory is incomplete on arrival.
2. Map the laws per category. Floors from the verified table, ceiling rules for anything personal, and a note of which regimes reach you (GDPR for EU data subjects, CCPA/CPRA if you meet California thresholds, sectoral laws).
3. Set periods with the five questions. Purpose, floor, ceiling, defensible period, clock start and trigger: one schedule row per category.
4. Write the policy. Scope, the schedule itself, disposal procedures, the legal-hold process, exceptions, and roles. Include storage and access rules for retained data: a period means nothing if everyone can still reach everything.
5. Assign one accountable owner. Not a committee. One person who owns the schedule, the reviews, and the answers. No DPO required, but no owner, no policy.
6. Implement deletion technically. Automation wherever possible: lifecycle rules, scheduled purges, platform-native retention settings. Manual deletion is where retention policies go to die. The CNIL’s cases are full of companies whose systems “couldn’t” delete, an excuse regulators reject outright.
7. Train the people who touch data. The policy fails in inboxes and shared drives, not in the document.
8. Review on a cadence, and on triggers. At least annually, and immediately when a law changes, a new tool is added, or a new data category appears. 

Where a category touches regulated records or likely litigation, set the period with your counsel. This guide is the map, not legal advice.

What happens if you get retention wrong in either direction

The regulations in this case impose requirements on both sides: failing to keep the data for too long is a breach that regulators actively seek to enforce, and removing it too early can end up being worse in court than the lawsuit itself.

In the US, the California Privacy Protection Agency has made retention a key part of its enforcement approach. In its first enforcement advisory, published on April 2, 2024, the agency described data minimization as “a foundational principle of the CCPA” and instructed businesses to apply it “to each and every purpose for which they collect, use, retain and share consumers’ personal information”, specifically mentioning retention.

Fines for breaches of the CCPA are administrative and amount to $2,663 for each violation or $7,988 (both inflation-adjusted) if the violation is intentional, and “we kept the data longer than we had disclosed” represents an exposure on a per-consumer, per-category basis. This is why a retention program is not just about regulatory compliance; it is also a direct way to reduce compliance risk tied to over-retention.

Data that has been kept beyond what is necessary can be used as evidence in the event of a breach: any information that has been retained past its intended purpose can be stolen by an attacker and obtained by a plaintiff through a subpoena. The same unnecessary data also expands the impact of data breaches and drives up storage costs without adding business value.

In Europe, where retention enforcement is most active, the decisions are dated and specific:

Deutsche Wohnen (Berlin, 2019–2026)

In October 2019, Berlin’s data protection authority imposed a fine of €14.5 million on the real-estate company for storing tenants’ personal data in a system that had no means of deletion. The fine was, however, set aside in 2021 as a result of Germany’s corporate-liability procedure. The Court of Justice of the EU dismissed that argument in December 2023 (Case C-807/21), and in June 2026 the Berlin Regional Court confirmed the breach while reducing the fine to €900,000 (LG Berlin I, June 2026). The amount has changed, but the principle has not. An archive from which you can’t delete data is a violation by design.

Taxa 4×35 (Denmark, 2019)

Datatilsynet’s first GDPR fine recommendation, 1.2 million kroner, for keeping phone numbers three years past the company’s own schedule. The authority’s line belongs in every policy: you cannot set a deletion deadline three years longer than necessary “simply because the company’s system makes it difficult to comply.”

Kaspr (France, 2024–2026)

The CNIL fined Kaspr €240,000 on December 5, 2024, partly for a retention period that automatically renewed itself every time a scraped LinkedIn profile was updated: a five-year clock that could never run out. The CNIL ordered the mechanism removed. Kaspr deleted its database and stopped the collection, and the order closed in March 2026. A retention period that extends itself is not a period.

The other direction has no fines attached, which is why people underrate it. Delete records before their floor, and the IRS can assess on assumption. A regulator’s request goes unanswered, and once litigation is reasonably anticipated, destroying relevant evidence invites spoliation sanctions and adverse-inference instructions, in which the court tells the jury it may assume the deleted records would have hurt you. The retention policy’s job is to keep you off both edges: never past the ceiling, never below the floor, and never deleting after a hold should have applied.

Data retention mistakes and myths

The mistakes that actually get companies in trouble:

• One period for everything. A blanket “seven years” over-retains marketing data (ceiling violation) and under-retains OSHA exposure records (floor violation) at the same time.
• A schedule that exists on paper only. If the policy says two years and the database holds eight, you have proven you knew the standard and missed it, which is worse than no policy.
• Forgetting secondary systems and the website layer. Production gets cleaned, while exports, logs, backups, and the tag manager keep full copies.
• Vague disclosure language. “As long as necessary for business purposes” fails the GDPR and CCPA transparency requirements.
• No destruction records. If you can’t show what was deleted when, you can’t prove the policy works.

The myths, corrected:

• “HIPAA requires medical records to be kept seven years.” No. HIPAA’s six-year rule covers compliance documentation (45 CFR § 164.530(j), in the table above); medical-record periods come from state law, and the “seven years” figure traces to Medicare rules, not HIPAA.
• “The IRS requires seven years.” The IRS base assessment window is three years, or six for substantial underreporting. A seven-year window exists, but only for worthless securities and bad-debt claims. As a blanket rule, “seven” is practitioner folklore, not the statute.
• “GDPR requires deleting data within 30 days of account closure.” No such rule exists. The GDPR sets no fixed periods at all: it sets the necessity test.
• “Keeping everything is the safe option.” It is the enforced-against option: the CPPA’s minimization principle and the GDPR’s storage limitation both treat indefinite retention as a violation, and every case above started with data someone thought was harmless to keep.

How MELURNA helps

You can’t set, disclose, or defend a retention period for data flows you’ve never mapped. The least-mapped flows at most companies are the ones their own website creates.

MELURNA keeps an eye on the browser layer by showing which third-party endpoints receive data from which pages and which cookies your system sets, along with their expiry durations, which makes data retention easy to document and review. This information fills the section of the schedule that most policies leave blank (website-collected identifiers and behavioral data) with real systems, real recipients, and real periods, rather than defaults nobody chose.

MELURNA also helps teams apply category-based review instead of relying on blanket schedules, and it is the evidence behind the at-collection retention disclosure California expects: you can state a period for a category if you know exactly what data you are collecting and where it is sent. Retaining too much data across secondary systems and the website layer multiplies both risk and review burden.

See what your website actually sends, and start your schedule’s hardest row with facts, not guesses.

FAQs

DISCLAIMER: This guide is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information, and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.