Data retention policy: what to keep, for how long, and a template

A data retention policy says how long an organization keeps each type of record and what happens to the record when that time runs out. This page gives a retention schedule with US periods checked against the regulations, explains what GDPR and the CCPA add, and ends with a policy template you can copy.

What a data retention policy is

A retention policy has two parts:

• The policy sets the rules: who owns retention, how periods are set, how records are deleted, how legal holds work and how exceptions are approved.
• The retention schedule is a table. Each row is a record type, with its retention period, the event that starts the clock, the system that holds it and what happens at the end.

The policy changes rarely. The schedule changes whenever you add a system or a law starts to apply to you, so keep it as a separate document that the policy refers to.

A retention policy covers deletion as well as keeping. A schedule that only sets minimum periods leaves records in place forever by default. Each row should end in an action: delete, anonymize, archive or review.

Retention depends on knowing what data you hold and where. The data classification policy guide covers how to sort data into levels, and the data mapping and discovery guide covers how to find it. The retention policy adds the time rules to that inventory.

Privacy laws set maximum periods

Privacy laws rarely give a number of years. They say you may keep personal data only as long as you need it, and that you must tell people how long that is.

The GDPR has three provisions that shape a retention policy:

• Article 5(1)(e), storage limitation. Personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary" for the purposes of processing. Longer storage is allowed for archiving in the public interest, scientific or historical research, or statistics, with appropriate safeguards.
• Article 13(2)(a), privacy notice. When you collect data, you must tell the person "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period".
• Article 30(1)(f), records of processing. The controller's record must include, "where possible, the envisaged time limits for erasure of the different categories of data". The record of processing activities (ROPA) guide shows where that field goes.

Article 5(1)(e) covers data kept in a form that permits identification. Anonymizing data at the end of its period, so that it no longer identifies anyone, is therefore an alternative to deleting it.

Under the CCPA, California Civil Code section 1798.100(a)(3) requires a business to disclose, when it collects personal information, "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". The same paragraph says a business may not keep personal information for a disclosed purpose "for longer than is reasonably necessary for that disclosed purpose."

Both laws accept criteria when you cannot give a fixed period. "For the length of the contract plus six years" is a criterion. "As long as needed" is not, because a reader cannot work out a date from it.

Record-keeping laws set minimum periods

Tax, employment, safety and securities rules require you to keep certain records for at least a set time. Most schedules exist because of these minimums. The periods below are taken from the regulations.

• Tax records (IRS). The IRS default is 3 years. The period is 6 years if you did not report income that is more than 25% of the gross income on your return, and 7 years if you claim a loss from worthless securities or a bad debt deduction. Keep records indefinitely if you did not file a return or filed a fraudulent one. Property records are kept until the limitations period expires for the year you dispose of the property.
• Employment tax records (IRS). At least 4 years after the tax is due or paid, whichever is later.
• Payroll records (FLSA). Under 29 CFR 516.5, payroll records are kept at least 3 years from the last date of entry. Under 29 CFR 516.6, time cards, wage rate tables and records of wage additions or deductions are kept at least 2 years.
• Personnel records (EEOC). 29 CFR 1602.14 requires 1 year from the date the record was made or the personnel action was taken, whichever is later. For an involuntary termination, the period is 1 year from the termination date. If a discrimination charge is filed, keep all relevant personnel records until final disposition.
• Form I-9. Under 8 CFR 274a.2(b)(2)(i)(A), keep the form for 3 years after the date of hire or 1 year after employment ends, whichever is later.
• Workplace safety (OSHA). Under 29 CFR 1910.1020, employee medical records are kept for the duration of employment plus 30 years, and exposure records for at least 30 years. Injury and illness records, such as the OSHA 300 Log, are kept 5 years after the end of the calendar year they cover (29 CFR 1904.33).
• HIPAA documentation. 45 CFR 164.316(b)(2)(i) requires covered entities and business associates to keep Security Rule documentation for 6 years from its creation or the date it was last in effect, whichever is later. That rule covers the written policies, procedures and records of required actions and assessments, not patient records in general.
• Broker-dealers (SEC). 17 CFR 240.17a-4 requires some records to be kept at least 6 years and others, including business communications, at least 3 years, with the first 2 years in an easily accessible place. Electronic records must be kept either with a complete audit trail of changes or in a non-rewriteable, non-erasable (WORM) format.
• Audit workpapers. 17 CFR 210.2-06 requires the accountant who audited or reviewed an issuer's financial statements to keep the workpapers for 7 years after the audit or review ends. Some retention pages list "SOX: 7 years" for financial records in general. This rule binds the auditor's workpapers, not every financial record the company holds.

Some popular retention pages say "tax records: 7 years (IRS)". The IRS default is 3 years. Seven years applies only to bad debt and worthless securities claims. Many companies still choose 7 years for all tax records because it covers every case except the indefinite ones, and that is a reasonable business choice as long as the schedule says it is one.

Sample retention schedule

This schedule uses the periods above. Rows with "Business-set" as the source cover data that no law sets a period for. Change those periods to fit your purposes and record the reason.

A period needs a start date. Most legal periods run from an event such as a termination, a last entry or the end of an audit, so each row names the event that starts the clock. Your systems need to record that event date, or the deletion job cannot calculate the end date.

How to set a period when no law gives one

Most personal data falls in this group: customer accounts, support tickets, marketing lists, analytics, logs. For each record type, answer four questions and write the answers in the schedule:

1. What is the purpose? Name the reason you collected the data. A period has to be tied to a purpose under both GDPR and the CCPA.
2. When does the purpose end? The account closes, the contract ends, the candidate is rejected, the ticket is resolved.
3. What do you still need after that? Common reasons are a minimum period from the list above, a contract term, or the time in which a claim could be brought against you. Write down the reason along with the number.
4. What happens at the end? Delete, anonymize, or aggregate into statistics that no longer identify anyone.

If two rules apply to the same record, the longer minimum wins. Once that minimum ends, the privacy limit applies again, so delete the record unless another named reason still applies.

Legal holds override the schedule

A legal hold stops deletion for records that relate to a lawsuit, investigation or audit that is under way or expected. The schedule says when records are due for deletion. The hold says which of them must not be deleted yet.

Deleting records after a duty to preserve them arises can lead to court sanctions or criminal charges:

• Under Federal Rule of Civil Procedure 37(e), if electronically stored information is lost and cannot be restored or replaced, a court can order measures to cure the prejudice. If the party acted with intent to deprive the other side of the information, the court can presume the information was unfavorable, tell the jury to presume so, or dismiss the action or enter a default judgment.
• 18 U.S.C. 1519 makes it a crime to destroy or alter records with intent to impede a federal investigation or bankruptcy case, including in anticipation of one. The maximum sentence is 20 years.
• The EEOC rule above also works as a hold: once a charge is filed, relevant personnel records are kept until final disposition.

A hold needs an owner (usually legal), a written notice to the people who hold the records, a flag in every system that runs deletion jobs, and a release step when the matter ends. The deletion job should check the flag before it deletes anything.

Where retention fails in practice

Most schedules cover the main database and miss the copies. Check these places when you set up deletion:

• Backups. Deleting a record from production does not remove it from last month's backup. Set a backup retention period in the schedule, so deleted records age out when old backups expire, and make sure a restore does not bring deleted records back into production.
• Logs and analytics. Application logs, event streams and warehouse tables often copy personal data with no expiry. Give each one its own row and a time-to-live.
• LLM prompts and traces. Observability tools store full prompts and responses, and some keep dataset copies after the trace is deleted. The article "Deleting personal data from LLM logs" covers retention settings and deletion in common trace stores. Redacting personal data before it reaches the trace store, covered in "PII redaction for LLM prompts and traces", shortens the list of things to delete.
• Vendors. Processors hold copies of your data. Your data processing agreement should say what they do with it at the end of the contract. The guide to LLM vendor DPAs and subprocessors lists the terms to check.
• Email and file shares. People save exports and attachments outside the systems the schedule covers. The policy should say that copies follow the schedule of the original record.
• Broker-dealer records. Records under SEC Rule 17a-4 need the audit-trail or WORM storage described above, so a plain delete-and-overwrite design does not meet the rule for them.

Deletion should also leave evidence. Log what was deleted, under which schedule row and when, without logging the deleted content itself. That log answers an auditor's question and a person's deletion request.

Data retention policy template

Copy the text, replace the parts in square brackets and delete what does not apply. Keep the schedule as a separate document, using the table above as a starting point.

[Organization name] Data Retention Policy

Version: [1.0]
Owner: [Privacy lead / Records manager / General counsel]
Approved by: [name of role or committee]
Effective date: [date]
Next review: [date, no later than 12 months after approval]

1. Purpose
This policy sets how long [Organization] keeps records,
including personal data, and how records are deleted or
anonymized at the end of their retention period.

2. Scope
This policy covers all records created or received by
[Organization] in any format, in any system, including
backups, logs, email, file shares and data held for us
by vendors. It applies to all employees, contractors
and vendors who handle [Organization] records.

3. Retention schedule
Records are kept for the periods in the Retention
Schedule [link]. Each schedule entry names the record
type, the system of record, the retention period, the
event that starts the period, the legal or business
reason, and the action at the end of the period.
Copies of a record follow the schedule entry of the
original.

4. Setting retention periods
Where a law or contract sets a minimum period, the
record is kept for at least that period. Where no law
sets a period, the record owner proposes a period tied
to the purpose of collection, with the reason, and
[policy owner] approves it. Personal data is not kept
longer than needed for the purpose it was collected
for, unless a legal minimum requires it.

5. End of retention
At the end of the period, records are deleted,
anonymized or archived as the schedule states.
Deletion is done by automated jobs where possible.
[Confidential and Restricted] records are securely
deleted. Each deletion run is logged with the
schedule entry, date and number of records, without
the deleted content.

6. Backups
Backups are kept for [period]. Deleted records are
removed when the backups that hold them expire.
Records restored from backup are checked against the
schedule and deletion log before use.

7. Legal holds
[Legal contact] issues a legal hold when litigation,
an investigation or an audit is under way or expected.
Records under a hold are not deleted, whatever the
schedule says. Holds are recorded, communicated in
writing to record owners, applied in every system that
deletes records, and released in writing when the
matter ends.

8. Roles
[Policy owner]: maintains this policy and the schedule.
Record owners: keep schedule entries for their systems
current and confirm deletion runs.
IT and engineering: build and run deletion jobs,
backup expiry and deletion logs.
Legal: approves periods with a legal basis and manages
legal holds.
All staff: do not keep personal copies of records
outside approved systems.

9. Privacy notices
Retention periods, or the criteria used to set them,
are stated in [Organization]'s privacy notices for
each category of personal data.

10. Exceptions
Requests to keep records longer than the schedule
allows go to [policy owner] in writing, with the
reason and an end date. Approved exceptions are
recorded and reviewed at expiry.

11. Enforcement
Violations are handled under [disciplinary policy].

12. Review
[Policy owner] reviews this policy and the schedule at
least every 12 months and when laws, systems or
business purposes change.

Related documents: [data classification policy],
[record of processing activities], [privacy notice],
[information security policy], [incident response
plan].

Rolling the policy out

1. List your systems and the record types in each. A ROPA or data map already has most of this.
2. Draft the schedule with legal and HR. Fill the legal minimums first, then propose business periods for the rest.
3. Make sure each system stores the event that starts the clock, such as the account closure or termination date.
4. Build the legal hold flag before the deletion jobs. A deletion job that cannot see holds should not run.
5. Turn on deletion one system at a time, starting with systems that hold a lot of personal data and have few legal minimums, such as logs and marketing lists.
6. Update the privacy notice to state each period or the criteria, as GDPR Article 13 and the CCPA require.
7. Review the schedule every year against new systems, new vendors and new laws.

Frequently asked questions

Sources

• GDPR: Regulation (EU) 2016/679, Articles 5(1)(e), 13(2)(a) and 30(1)(f)
• CCPA: California Civil Code 1798.100(a)(3) (California Privacy Protection Agency)
• IRS: How long should I keep records?
• FLSA: 29 CFR 516.5 and 29 CFR 516.6
• EEOC: 29 CFR 1602.14
• Form I-9: 8 CFR 274a.2
• OSHA: 29 CFR 1910.1020 and 29 CFR 1904.33
• HIPAA: 45 CFR 164.316
• SEC: 17 CFR 240.17a-4 and 17 CFR 210.2-06
• Legal holds: Federal Rule of Civil Procedure 37(e); 18 U.S.C. 1519

Need this built?

We build data inventories, retention schedules wired to deletion jobs, legal hold flags and deletion logs as part of our Python and Node development and data science work. Tell us about your project, and we will reply with questions or a rough plan.