Most companies have a retention policy. Far fewer have a retention schedule. The policy says data is kept "no longer than necessary". The schedule says which data, in which system, for how long, counted from what event, and who deletes it. Only the second one can be followed, tested or audited.
GDPR Article 5(1)(e) sets the principle of storage limitation: personal data must be kept in a form that permits identification for no longer than necessary for the purposes of processing. Articles 13 and 14 require you to tell people the retention period, or the criteria used to set it. Article 30 asks for the envisaged time limits for erasure in your record of processing, where possible. The CCPA, as amended by the CPRA, similarly requires businesses to disclose how long they intend to keep each category of personal information, or the criteria used.
All of these assume a schedule exists. This article covers how to build one that engineers can implement and an auditor can test.
What an entry in the schedule contains
A retention schedule is a table. Each row is one category of data in one place. The fields that make a row usable are:
| Field | What it records | Example (hypothetical) |
|---|---|---|
| Data category | What the records are | Customer support tickets |
| System | Where they live, including copies | Helpdesk tool, data warehouse export |
| Owner | The person accountable for the rule | Head of Support |
| Purpose | Why the data is kept | Resolving and reviewing support issues |
| Retention period | How long | 24 months |
| Trigger event | When the clock starts | Ticket closed |
| Basis for the period | Why that length | Internal need; no statutory minimum identified |
| Disposal method | What happens at the end | Automated deletion job |
| Exceptions | What can suspend disposal | Legal hold |
The two fields teams most often leave out are the trigger and the basis. Without a trigger, "24 months" is ambiguous: from creation, from last activity, or from contract end. Without a basis, nobody can tell later whether the period was a legal requirement or a guess, so nobody dares shorten it.
How to build the schedule
Work from what you hold, not from a template list of record types.
Start from your data inventory. Take each system that holds personal data from your record of processing. If you do not have one yet, building an Article 30 record of processing comes first, because a schedule built without it will miss systems.
Group records into categories. Categories should be coarse enough to manage and fine enough that one rule fits. "Customer data" is too coarse. "Billing records", "product usage logs" and "support tickets" usually work.
Find the legal minimums. Tax, accounting, employment and sector rules often require records to be kept for a minimum period. These vary by country and sometimes by state. Ask finance, HR and your legal team for the rules that apply to you, and record the source in the basis field.
Set operational periods for everything else. Where no law sets a minimum, the period is a judgment about purpose. Write down the reasoning. A short reason ("support needs recent history to spot repeat issues") is better than none.
Pick a trigger for each row. Common triggers are account closure, contract termination, end of employment, last login and record creation.
Decide the disposal method. Deletion, anonymization, or aggregation into statistics. Anonymization only counts if the result can no longer identify anyone.
Assign an owner and get sign-off. The owner is the person who answers when the rule is questioned. Legal or privacy reviews the whole schedule before it is published.
Retention periods that rest on legal interpretation, such as how long you may keep records to defend potential claims, are worth confirming with counsel.
Choosing retention periods you can defend
The hard part of a schedule is the number in each row. A few principles keep the numbers defensible.
A legal minimum is not a reason to keep everything. If tax rules require invoice records, that covers the invoice data. It does not cover the full account history or product usage logs attached to the same customer.
"Legal claims" needs a boundary. Keeping data to defend potential disputes is a common and legitimate reason. It is also the most common way schedules quietly become "forever". Tie it to a defined limitation period that your legal team has identified, not to the possibility of litigation in general.
Shorter is easier to implement than you expect. Teams often choose long periods to avoid hard conversations. Every extra month is more data to secure, search during access requests, and disclose in a breach.
Different copies can have different periods. Production data, analytics exports and logs serve different purposes. A schedule that gives every copy the longest period of any copy has missed the point.
For records your compliance program itself produces, such as audit evidence and policy versions, see how long to keep audit evidence. Those rules come from your frameworks and auditors rather than from privacy law.
Backups, legal holds and the copies people forget
Backups
Backups are where most schedules become untrue. Deleting a record in production does not delete it from last month's snapshot. Rewriting backups to remove individual records is rarely practical.
The common approach is to document the backup retention cycle as its own row, make sure it is no longer than needed, and ensure deleted data is not restored to live use. If you restore a backup, reapply deletions that happened after the backup was taken. Check how your supervisory authority treats backups in its erasure guidance, and say in your privacy notice that backups expire on their own cycle.
Legal holds
A legal hold suspends disposal for specific records because of litigation, an investigation or a regulatory request. The schedule needs a defined process for placing a hold, recording its scope, and lifting it. Holds that are never lifted are a common source of indefinite retention.
Shadow copies
The rows nobody writes are for spreadsheets exported from the CRM, files in shared drives, attachments in email and chat, and data pulled into local notebooks. You cannot schedule what you do not know about. A periodic sweep of shared storage, and a rule that exports carry the retention of their source, covers most of it.
Making deletion actually happen
A schedule nobody enforces is worse than none, because it is a written promise you are breaking. Enforcement comes in three forms, in descending order of reliability:
Automated deletion. Time-to-live settings, lifecycle rules on storage buckets, and scheduled jobs that delete or anonymize records past their trigger. This is the only approach that scales.
Configured retention in vendor tools. Many SaaS tools let you set retention on tickets, messages and logs. The setting is evidence in itself.
Manual review. A recurring task for an owner to delete records in systems that cannot automate it. This works for a few small systems and fails for large ones.
Retention also interacts with individual rights. When someone asks for erasure under Article 17, the schedule tells you where their data lives. When someone asks for access, a shorter schedule means less to search. The guide to handling data subject access requests on time covers that process.
Evidence an auditor or customer will ask for
Customers ask about retention in security questionnaires, and auditors test it under ISO 27701 and the privacy criteria in SOC 2. The evidence that holds up:
- Not done:
The current schedule, with a version history and an approval record
- Not done:
Configuration exports showing retention settings in each system
- Not done:
Logs or job output showing deletion runs, with dates and record counts
- Not done:
A sample of records past their trigger, showing they are gone
- Not done:
Legal hold records, with dates placed and lifted
- Not done:
A review date, with evidence the schedule was revisited
The fifth and sixth items are the ones teams cannot produce. A schedule last reviewed three years ago will not match the systems you run now. Review it at least annually and whenever you add a system that holds personal data. The GDPR framework page lists the related controls.
How TrustLynce helps
TrustLynce keeps your record of processing, including retention periods, in its data privacy workflows, so the schedule and the inventory stay in one place. Retention policies are versioned with acceptance tracked through policy management, and retention settings can be collected as timestamped evidence through evidence collection.