Data retention policy template for SaaS companies

What a SaaS retention policy has to cover#

A SaaS retention policy has to cover two different kinds of records: customer data you hold and process under contract, and records your company creates while running its business. The first is governed largely by your agreements with customers; the second by your own decisions within the law.

Many templates blur the two. A policy that applies one schedule to everything either keeps customer data longer than contracts allow or deletes company history with lasting value, such as support conversations about your product and the engineering record behind each release.

Scope the policy by system, not by department. Records live in Zendesk, Jira, GitHub, Salesforce, Slack and the production database, and each tool has its own retention settings that must match what the policy says.

Sections every policy template should include#

Every retention policy template should include the same core sections, written so a system owner can apply them without asking legal about each decision.

• 1Purpose and scope: which entities, systems and record types the policy covers.
• 2Roles: a policy owner, a named owner for each system, and who approves exceptions.
• 3Record categories: customer data, company operational records, financial records, personnel records and logs.
• 4Retention schedule: the table of systems, record types, periods and end-of-period actions.
• 5Legal holds: how a hold is issued, who applies it and how it overrides deletion.
• 6Review before delete: the step that checks company-owned history before disposal.
• 7Deletion and archival methods: how records are destroyed or moved, and how that is logged.
• 8Vendors: how settings in SaaS tools and subprocessors are kept in line with the policy.
• 9Review cycle: when the policy and schedule are revisited, and by whom.

Retention schedule by system and record type#

The retention schedule is the working heart of the policy: one row per system and record type, each with an owner, a basis for its period and a defined action when the period ends. The periods themselves are set with counsel based on contracts, tax rules, employment law and privacy obligations, then entered in the policy beside each row.

Customer data and company records follow different rules#

Customer data and company records follow different rules because you usually hold customer data on the customer's behalf. Customer agreements and data processing addenda commonly require deletion or return at the end of the contract and limit use to providing the service, so the policy should point to those terms rather than set its own period.

Company records are yours to govern. A support ticket in which your agent explains a product fault, a Jira bug with the pull request that fixed it, or a deal history in your CRM are business records your company created. Privacy laws still apply to the personal information inside them, but how long to keep the record itself is your decision.

Some records sit on the line. A support ticket can carry a file the customer uploaded from its own systems, which may be customer data even though the ticket is yours. Note these mixed cases in the schedule so owners know what to strip before archiving.

The review-before-delete rule#

The review-before-delete rule says that company-owned history reaching the end of its period is checked by its system owner before disposal, and the decision is recorded. It is a short step per record category, and it prevents the most common loss in a growing company: an auto-delete setting quietly erasing years of useful history.

• 1Is a legal hold or open dispute in place? If yes, keep the records.
• 2Does a contract or law require deletion? If yes, delete them.
• 3Do the records contain personal information that is no longer needed? If yes, delete that information or de-identify the records.
• 4Do the records still serve a documented purpose, such as product analysis, staff training or possible licensing? If yes, archive them under access control.
• 5None of the above? Delete and log the deletion.

How deletion decisions shape what you can license later#

Deletion decisions shape what you can license later because a record that is gone cannot be prepared, reviewed or offered, and a record kept without a lawful basis may not be usable either. Retention and any future licensing are therefore decided together, not one after the other.

Keeping personal information because it might be useful someday is hard to justify under privacy laws that expect retention to match a purpose. Keeping de-identified business history for a named purpose is much easier to defend. Write the purpose down at the review step, and confirm with counsel that it is a legitimate one for each record type.

The archives AI developers ask about are usually long, connected company histories: support conversations linked to engineering fixes, deal histories with stage changes, code reviews with the issues behind them. A policy that preserves those links while removing personal details on schedule keeps both options open.

Illustrative: a property management software company tightens its schedule#

Illustrative: a fictional property management software company has grown from a founder-led team into a mature product with enterprise customers. Its COO finds that Slack is set to delete messages after a fixed period, old Zendesk tickets are kept forever with tenant details inside, and nobody can say what happens to customer databases after cancellation.

Using the template, the company names an owner for each system and sets periods with counsel. Customer data is deleted at contract end, as the data processing addendum requires. Before the next Slack purge, engineering and incident channels are exported and archived. Old Zendesk tickets are de-identified, keeping product issues and resolutions while removing tenant names and addresses.

The tool settings now match the written schedule, and each deletion or archive is logged with the owner's decision. When a prospective enterprise customer later asks for the retention policy during a security review, the COO can send it the same day.

How SourceX looks at retained archives#

SourceX looks at retention early because accessible history decides what a company could offer. The fit check asks which systems hold records, how far back they go and which retention or deletion rules apply, using metadata only.

If a package proceeds, the Rights and Preparation steps of the SourceX five-step transaction check deletion obligations and remove personal and confidential details, and the SourceX Evidence Packet records provenance, permitted use and the privacy record for what is released.