Data Retention Policy Requirements: What Retention Policies and a Records Retention Schedule Must Disclose

A data retention policy is the written statement of how long you keep each category of personal data and why. Since January 1, 2023 it has been a disclosure obligation in California, not just an internal document: Civil Code 1798.100(a)(3) requires a business to tell consumers, at or before collection, "the length of time the business intends to retain each category of personal information, including sensitive personal information, or if that is not possible, the criteria used to determine that period". Minnesota now requires a description of your retention policies in the privacy notice too. No US state tells you a number. They tell you that whatever number you publish becomes the standard you are held to.

That is the shift most retention guidance has not caught up with. The classic advice is a records retention schedule copied from a template, filed somewhere, and reviewed never. What the current laws ask for is different and harder: a period you are willing to publish, applied to data you can actually locate, with a defensible reason when you keep something a consumer asked you to delete.

Is a data retention policy required by law?

Not as a standalone document, and no US state privacy law says "you must have a data retention policy" in those words. What they require adds up to one anyway. Three duties stack: a limit on how long you may keep data, a disclosure about how long you intend to keep it, and a duty to delete on request unless a stated exception applies. You cannot satisfy the middle one without having written the schedule down.

The requirements differ more than most summaries admit, so here is what each regime actually asks for.

Read the California row again, because the drafting is doing something specific. It does not merely say keep data no longer than necessary. It says the period is per category, per disclosed purpose, and that if you cannot state a length you must publish the criteria instead. "As long as necessary for our business purposes" is not criteria. It is a refusal to answer, dressed as one.

How long should a company keep customer data?

As long as the purpose you collected it for is still live, plus any period a specific law makes you keep it, and no longer. That is genuinely the whole rule under privacy law, and it is why no statute hands you a number. The numbers that do exist come from elsewhere: tax, employment, securities and health regulators, each with its own minimum for its own record types. Those minimums are floors on specific records, not permission to keep everything for the longest one.

These are the federal minimums most US businesses run into. Confirm any of them against the current rule before you build a schedule on it, and check your state and industry rules on top, since several are longer.

Notice what is missing from that table: the customer. Nothing in it tells you how long to keep a marketing profile, a support ticket history, a shipping address, an abandoned cart, a chat transcript or a device identifier. Those are the categories a consumer actually asks about, and for those there is no federal minimum at all, which means the answer is entirely your purpose analysis and entirely your exposure if you get it wrong.

Payment and invoice records sit awkwardly across both halves. The invoice itself is a tax record with a four-year floor, but the collections correspondence attached to it, which for many companies now runs through an automated workflow that chases every open invoice by email and text, is a stack of messages to a named person and squarely personal data. The invoice has a retention floor. The dunning history does not, and it is the part that shows up in an access request.

What is the difference between a data retention policy and a records retention schedule?

The terms get used interchangeably and they are not the same artifact, which matters once someone asks you to produce one.

• A records retention schedule is the operational table: record class, retention period, disposition, legal citation. Invoices, four years. Employment applications, one year. It is organized by type of record and it usually predates anyone's privacy program by a decade.
• A document retention policy is the governance wrapper around that schedule: who owns it, how destruction is authorized and logged, what happens when litigation is anticipated. In many companies it is a document retention and destruction policy, and the destruction half is the part auditors read.
• A data retention policy under a privacy law is a different cut of the same reality. It is organized by category of personal data and by purpose, because that is how the statutes are written and how the disclosure has to be published.

Most organizations have the first two and publish the third without reconciling them. That is where the trouble starts.

The half of retention that no schedule covers

A records retention schedule answers a question about a class of documents. A privacy request asks a question about a person. Those are not the same question, and the gap between them is where retention programs quietly fail.

Work through it concretely. Your schedule says customer transaction records are kept for seven years. A deletion request arrives naming one individual. To act on it you need to know which of your systems hold data about that person, which of those records fall inside the seven-year transaction class, and which do not. The schedule cannot tell you any of that. It describes categories of record, and it is silent about where those records live, how many copies exist and whether the person's data is also sitting in six places the schedule never contemplated: the analytics warehouse, a shared drive, an email archive, a CRM note, a support tool, a backup.

Three consequences follow, and they are the ones that turn up in enforcement rather than in templates.

A published period you cannot enforce is worse than no period. Once you state that support tickets are kept for 24 months, that becomes a representation to consumers and to regulators. If tickets are also replicated into a data warehouse that nobody put on a deletion cycle, the representation is inaccurate, and the inaccuracy is documented in your own privacy notice. The disclosure requirement in 1798.100(a)(3) has this effect: it converts an internal aspiration into an external commitment, and it is far easier to enforce against a specific published claim than against a vague duty of proportionality.

Vendor copies expire on someone else's schedule. Your processors hold copies of the same data, and whether they must return or delete it at the end of the service depends on which state you are reading. Virginia, Colorado, Texas and Iowa all require a delete-or-return clause in the contract. Utah does not. California addresses it differently, giving the business a right to require documentation that the vendor no longer retains the data. The state-by-state differences in data processing agreement requirements decide whether your retention period actually ends at your vendors or only at your own database.

Deletion has to propagate, and propagation is a discovery problem. A retention period expiring is a deletion event, exactly like a consumer request, and it has the same requirement: you have to know every location first. Teams that have already mapped where personal data lives across their systems can run a retention cycle as a routine job. Teams that have not are choosing between deleting the copies they know about, which leaves the policy inaccurate, and not deleting at all.

Can you refuse a deletion request because of a retention policy?

Only if a law makes you keep the specific data, and the retention policy itself is never the reason. Under the CCPA you may keep data that falls within one of the eight statutory exceptions in Section 1798.105(d), and complying with a legal obligation is one of them. So a payroll record inside its three-year FLSA window can stay while the marketing profile about the same person is deleted. What you cannot do is point at your own schedule and treat it as authority. Your policy is your decision. An exception is the law's.

Two things follow. First, apply the exception to the specific data, not to the request as a whole, which is the normal shape of a compliant response and is covered in more depth in the guide to the CCPA right to delete and its eight exceptions. Second, the retained slice is still on a clock. An exception lets you keep a record for the duration of the obligation that justifies it, and once the four-year tax window closes, the reason closes with it. Data retained under an exception and then never revisited becomes ordinary over-retention with a paper trail showing you knew about it.

Legal hold is the one thing that outranks both. When litigation is reasonably anticipated, a hold suspends destruction for the data in scope, including data a consumer has asked you to delete and data whose retention period has expired. Preservation wins. The practical failure here is not legal, it is operational: holds get issued to custodians by email and never wired into the systems that run automated deletion, so a retention job quietly destroys held data while everyone believes the hold is in force. If you automate deletion, the hold has to be a flag in the system, not a memo.

What should a data retention policy include?

Six elements, and the third is the one most policies skip.

• Categories of personal data, in the language of your privacy notice. Not record classes. The disclosure obligation is per category of personal information, so the internal document and the public one need to use the same vocabulary or you will not be able to publish from it.
• The purpose each category is retained for, stated specifically. Purpose is what makes a period defensible. A period without a purpose is arbitrary, and arbitrary is exactly what a regulator asks about.
• The systems each category lives in. Almost no template includes this and it is the field that makes the policy executable. Minnesota effectively requires it already by mandating a data inventory. Without it you have a policy about data you cannot find.
• The retention period, or the criteria, per category. Criteria are legitimate when a fixed number genuinely is not possible, for example "for the duration of the account plus 90 days". Criteria that resolve to "indefinitely" are not criteria.
• The disposition method, and how it is logged. Deletion, anonymization or archival. Note that anonymized data leaves the scope of these laws only if it genuinely cannot be reidentified, which is a higher bar than removing a name column.
• The legal hold procedure and the exceptions register. Who can issue a hold, how it reaches automated jobs, and where you record data kept under a statutory exception so someone reviews it when the exception lapses. The interaction between a litigation hold and a deletion request is the sharpest version of this, because there the exception has to be applied and explained inside a statutory deadline.

How long does GDPR allow you to keep data?

For no longer than is necessary for the purposes it was processed for. Article 5(1)(e) sets storage limitation as a principle rather than a period, and Articles 13 and 14 require you to tell the data subject either the retention period or the criteria used to determine it at the point you collect. The structure is the same as California's, which is not a coincidence, and it means a single well-built retention statement can serve both. Data kept purely for archiving in the public interest, scientific or historical research, or statistical purposes can be held longer, with safeguards under Article 89(1). That exception is narrower than it sounds and is not a route for keeping customer records because analytics might want them later.

Where retention and access requests meet

Retention is usually written as a deletion problem, and it is equally an access problem. When someone exercises a right of access, the scope of your answer is whatever you still hold, which means your retention practice determines the size of every request you will ever answer. Companies that retain everything forever have made each future access request larger, slower and more expensive, and they have done it to themselves. Companies with real retention discipline answer smaller questions.

The connection runs the other way too. Building a retention schedule that names the systems each category lives in produces exactly the map you need to answer a request, and it answers which state privacy laws apply to your business along the way, because both start with knowing what you hold and about whom. The difference between a retention policy that works and one that sits in a folder is whether anyone can execute it against live systems on a given Tuesday, which is the same test a deletion request applies to a data subject access request.

None of this is legal advice, and the retention periods that apply to your industry belong to your counsel. What can be built in advance is the part underneath: an accurate picture of which systems hold which categories of personal data about whom, so that a published period is something you can actually keep, and a deletion request can be answered completely rather than approximately.