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

The policy states the rules: that a schedule exists, who owns it, which disposal methods are allowed, how legal holds work and how often it is reviewed. The schedule is the working list underneath it: each record type, where it lives, how long it is kept, what starts the clock and how it is destroyed. Policies change rarely; the schedule changes whenever you add a system or sign a contract with new terms.

Why are the retention periods left as [set by owner]?

Because the right period depends on your customer contracts, your industry and the countries whose employment, tax and privacy law applies to you, and a template cannot know any of those. Where the Policyseed Data Retention and Disposal Policy names a period, the template quotes it as an example. It is a starting point for the owner and counsel, not a legal minimum or maximum.

Does SOC 2 require a data retention schedule?

SOC 2 does not prescribe a document or any retention period. The confidentiality criteria (C1.1 and C1.2) expect you to keep confidential information only as long as needed and to dispose of it when that time is up, and CC6.5 covers disposal of data and devices. A schedule plus a disposal log is the usual way to show both. If Confidentiality is not in your scope, the auditor will still look at disposal under CC6.5.

How does a legal hold interact with the schedule?

A legal hold suspends every deletion the schedule would otherwise require for the records it covers, until it is released in writing. Automated deletion (log retention, backup expiry, deletion jobs) has to be paused for those records too. The disposal log has a column to confirm that no hold applied before anything was destroyed.

Do backups need their own row?

Yes. Deleting a customer's data from production does not remove it from backups and snapshots, so the schedule should say how long backups live and that deleted data is gone once the last backup holding it expires. Auditors and customers both ask this question.

Data retention schedule template

A free record retention schedule in Excel: 16 common SaaS record types, each with example systems, a classification, an owner, the event that starts the retention clock, a disposal method and the evidence that disposal happened, plus a disposal log. Retention periods are left for you to set, because they depend on your contracts and the jurisdictions you operate in.

Not legal advice. Nothing in this template states a legal retention requirement. Every period reads [set by owner] and every legal basis reads [confirm with counsel]. Where the Policyseed policy names a period, it appears only as an example. Confirm periods with counsel before you rely on them.

Retention schedule vs. data retention policy

The Data Retention and Disposal Policy is the rulebook: it says a schedule must exist, that data is kept no longer than its business purpose, contract or legal obligation requires, which disposal methods are acceptable, how legal holds suspend deletion, and that the schedule is audited each quarter. The schedule is the table the policy points to: one row per kind of record, with the period and the method filled in. A data retention policy template without a schedule leaves the auditor asking “how long, exactly?”; a schedule without a policy has no owner or review process behind it.

The workbook has three sheets:

Instructions. How to fill it in, the four classification levels, and the legal hold rule.
Schedule. The 16 starter rows below plus ten blank rows, with filters on every column.
Disposal log. One row per disposal of Confidential or Restricted data or of a device: date, record type (from the schedule), what was disposed of, classification, disposal method, performed by, verified by, legal hold checked (yes / no), evidence location.

How to fill it in

Sit down with the people who hold each kind of record: engineering for production data, backups and logs, people operations for employee and candidate records, finance for billing and contracts.
Delete the starter rows that do not apply, and add rows for anything you hold that is missing.
Classify each row using the four levels in the Data Classification and Handling Policy: Public, Internal, Confidential, Restricted.
Replace each owner role with a named person.
Have the owner set the period, and have counsel confirm the basis: the customer contract clause, the employment or tax rule, or the business reason.
Check that each disposal method actually runs: a lifecycle rule, a time-to-live, a deletion job, an MDM erase. Write down where the evidence lives.
Date the row, and update the policy if any period you set differs from the one it states.

The columns

Every column on the Schedule sheet, in order:

Column	What goes in it
Record type / data category	One category of records per row, named the way the people who hold it would recognise it. Split a category when parts of it are kept for different periods.
Example systems	Where the records live: the system of record first, then the copies (backups, exports, vendor systems). Disposal has to reach all of them.
Classification	Public, Internal, Confidential or Restricted, as defined in the Data Classification and Handling Policy. It decides how carefully disposal is done and whether it is logged.
Owner	The person accountable for the period and for disposal actually happening. Replace the role with a name.
Retention period	How long the records are kept after the trigger. Left as [set by owner]: the owner sets it from business need, customer contracts and the law that applies to you. Where the Policyseed policy names a period it is shown as an example, not a requirement.
Trigger	The event the period counts from, such as end of contract, end of employment or ticket closure. A period with no trigger cannot be applied.
Legal / contractual basis	Why the period is what it is: the contract clause, statute or business reason. Always [confirm with counsel] in the template; only someone who knows your contracts and jurisdictions can fill it in.
Disposal method	How the records are destroyed when the period ends, using a method the policy allows: automated deletion or expiry, cryptographic erasure, overwriting, NIST SP 800-88 purge for media, cross-cut shredding for paper.
Evidence of disposal	What proves the disposal happened: a lifecycle rule and its run history, a deletion ticket, a disposal log entry, a certificate of destruction.
Review date	When this row was last reviewed. The policy reviews the schedule at each policy review and samples it in the quarterly retention audit.

The starter rows

These are the record types most small SaaS companies hold. The classifications and disposal methods follow the Policyseed policies; the periods are placeholders, with the policy’s own period quoted as an example where it gives one (see section 5 of the policy). Every row’s legal basis is [confirm with counsel].

Record type	Classification	Owner	Retention period	Trigger	Disposal method
Customer account data (data customers put in the product) Production databases and object storage; non-production copies if any exist	Restricted	Engineering lead	[set by owner] (example from the Policyseed policy: agreement term plus 30 days)	End of the customer agreement, or a verified deletion request	Application deletion job and provider API; remaining copies purged when the last backup containing them expires
Deleted-customer data (residual copies after offboarding) Backups, snapshots, exports, subprocessors holding the customer's data	Restricted	Engineering lead	[set by owner]	Customer offboarding completed or deletion request executed	Backup expiry on schedule; deletion triggered in each subprocessor; exports deleted
Production backups and snapshots Database backups, volume snapshots, object storage versioning	Restricted	Engineering lead	[set by owner] (example from the Policyseed policy: 35 days rolling)	Creation of each backup	Automatic expiry through lifecycle or retention settings in the backup tool
Application logs (debug and request logs) Logging platform, application servers, CI logs	Confidential	Engineering lead	[set by owner] (example from the Policyseed policy: application debug logs: 30 days)	Log entry written	Retention or time-to-live setting in the logging platform
Security and audit logs Cloud audit trail, identity provider sign-in logs, database access logs, SIEM	Confidential	Security Owner	[set by owner] (example from the Policyseed policy: Security and audit logs: 12 months)	Log entry written	Retention setting in the log store; suspended while a legal hold or investigation applies
Support tickets and customer correspondence Help desk, shared support inbox, chat with customers	Confidential	Support lead	[set by owner] (example from the Policyseed policy: Support tickets: 3 years after closure)	Ticket closed	Scheduled deletion or bulk delete in the help desk tool
Billing records and invoices Billing platform, accounting system, payment processor dashboard	Confidential	Finance lead	[set by owner] (example from the Policyseed policy: Financial, tax and payroll records: 7 years)	End of the financial year the record relates to	Deletion in the accounting and billing systems; paper cross-cut shredded
Employee records (contracts, payroll, performance) HR information system, payroll provider, shared HR drive	Confidential	People Operations lead	[set by owner] (example from the Policyseed policy: Employment records: 7 years after employment ends)	End of employment	Deletion in the HR system and payroll provider; paper cross-cut shredded
Candidate applications (unsuccessful candidates) Applicant tracking system, hiring manager email	Confidential	People Operations lead	[set by owner] (example from the Policyseed policy: Unsuccessful candidate records: 12 months)	Hiring decision for the role	Automatic deletion rule in the applicant tracking system
Access review records Access review workbook, user list exports, approval tickets	Confidential	Security Owner	[set by owner] (example from the Policyseed policy: access reviews, policy approvals and audit evidence: 7 years)	Review completed	Deletion from the evidence store
Security incident records Incident tickets, post-incident reviews, incident chat channels	Restricted	Security Owner	[set by owner] (example from the Policyseed policy: Incident records, risk assessments, access reviews, policy approvals and audit evidence: 7 years)	Incident closed	Deletion from the ticketing system and evidence store, unless a legal hold applies
Vendor contracts and vendor review records Contract repository, vendor inventory, vendor SOC 2 reports	Confidential	Finance lead	[set by owner] (example from the Policyseed policy: Contracts and vendor records: term plus 7 years)	End of the contract	Deletion from the contract repository; vendor reports deleted under their own terms
Policy versions and personnel acknowledgments Policy repository, HR system or training platform	Internal	Security Owner	[set by owner] (example from the Policyseed policy: policy approvals and audit evidence: 7 years)	Version superseded, or acknowledgment recorded	Deletion from the policy repository
Marketing contacts and product analytics CRM, email marketing tool, product analytics	Confidential	Marketing lead	[set by owner] (example from the Policyseed policy: Product analytics and marketing data: 24 months)	Last engagement, or an unsubscribe or deletion request	Deletion or anonymisation in the CRM and analytics tools
Source code and build artifacts Source control, CI/CD pipeline, artifact and container registries	Confidential	Engineering lead	[set by owner] (example from the Policyseed policy: Source code: indefinitely; build artifacts and CI logs: 90 days)	Code: repository archived. Artifacts: build created	Artifact expiry settings in CI and registries; archived repositories deleted when no longer needed
Laptops, devices and removable media Company laptops and phones, approved removable media	Restricted	People Operations lead	[set by owner]	Device returned, reassigned or retired	Remote erase or destruction of the full-disk encryption key; media leaving the company purged or destroyed per NIST SP 800-88

This schedule is free and is not part of the paid product. The $39 Audit Kit tailors all 22 policies, including the retention policy, to your stack and adds the risk register, vendor inventory and access review pre-filled from your answers.

How auditors use it

The auditor reads the policy, asks for the schedule, then samples. They pick a record type and check that the oldest records are within the period, pick disposal log entries and ask for the evidence, and check that a deleted customer’s data is really gone, including from backups. What each criterion needs from the schedule:

Criterion	What the schedule and log have to show
C1.1 Identifying and protecting confidential information	That confidential information is identified and kept only as long as needed. The schedule's classification and retention period columns are where this shows, together with the data inventory.
C1.2 Disposing of confidential information	That confidential information is disposed of when its retention period ends. The auditor samples disposal log entries and checks them against the schedule's methods and periods.
CC6.5 Disposal of physical assets	That data and devices are made unrecoverable before disposal or reuse. The device and media row, MDM erase records and certificates of destruction are the evidence.
CC6.7 Data in transit and on removable media	That removable media and data leaving the company are controlled. The schedule's disposal method for media, and the log entries for it, support this.

C1.1 and C1.2 apply when Confidentiality is in the scope of your SOC 2 report; CC6.5 applies to every report. For everything else the auditor will ask for, see the SOC 2 evidence checklist.

Common mistakes

Periods copied as if they were law. A number from a template, a blog post or another company’s schedule is not your obligation. Write down the basis, and have counsel confirm it.
Forgetting the copies. Backups, logs, analytics, support tickets, exports on laptops and vendor systems all hold the same customer data. A deletion that only reaches the main database is incomplete.
A period with no trigger. “Seven years” from when? End of contract, end of employment and ticket closure give very different answers.
No evidence that deletion ran. A lifecycle rule nobody checks may have been switched off months ago. The quarterly retention audit in the policy exists to catch this.
Keeping everything “just in case”. Data with no purpose is breach exposure with no benefit, and it contradicts a policy that says data is disposed of promptly.
Ignoring legal holds. Automated deletion that keeps running during a hold destroys records you were obliged to keep.

Related templates: the risk register and the user access review, whose records appear as rows in this schedule.

Frequently asked questions

What is the difference between a data retention policy and a retention schedule?: The policy states the rules: that a schedule exists, who owns it, which disposal methods are allowed, how legal holds work and how often it is reviewed. The schedule is the working list underneath it: each record type, where it lives, how long it is kept, what starts the clock and how it is destroyed. Policies change rarely; the schedule changes whenever you add a system or sign a contract with new terms.
Why are the retention periods left as [set by owner]?: Because the right period depends on your customer contracts, your industry and the countries whose employment, tax and privacy law applies to you, and a template cannot know any of those. Where the Policyseed Data Retention and Disposal Policy names a period, the template quotes it as an example. It is a starting point for the owner and counsel, not a legal minimum or maximum.
Does SOC 2 require a data retention schedule?: SOC 2 does not prescribe a document or any retention period. The confidentiality criteria (C1.1 and C1.2) expect you to keep confidential information only as long as needed and to dispose of it when that time is up, and CC6.5 covers disposal of data and devices. A schedule plus a disposal log is the usual way to show both. If Confidentiality is not in your scope, the auditor will still look at disposal under CC6.5.
How does a legal hold interact with the schedule?: A legal hold suspends every deletion the schedule would otherwise require for the records it covers, until it is released in writing. Automated deletion (log retention, backup expiry, deletion jobs) has to be paused for those records too. The disposal log has a column to confirm that no hold applied before anything was destroyed.
Do backups need their own row?: Yes. Deleting a customer's data from production does not remove it from backups and snapshots, so the schedule should say how long backups live and that deleted data is gone once the last backup holding it expires. Auditors and customers both ask this question.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.