- 512-551-0338
- [email protected]
- 512-551-0338
- [email protected]
Short answer: a good data retention policy makes three promises and backs each one with proof. You say how long you keep customer data and delete it automatically, you stop anyone from casually reading it, and you give the customer a way to verify both. Then you do the one thing most vendors skip: you publish it. Anthropic’s data retention and review white paper is the modern example, but here is the fun part, none of this is new. Cisco Duo published the same playbook back in 2021, and it still works.
I represent lots, literally 100s and 100s, of SaaS companies, and the same fight comes up over and over. You keep customer data for a legitimate reason (fraud detection, abuse prevention, safety, debugging), and then an enterprise buyer’s security team asks you to justify it. Here are the three takeaways I lift from Anthropic’s paper, plus an old trick from Cisco Duo that ties them together.
Anthropic’s first commitment is simple. Retained data is deleted at 30 days, automatically and permanently, unless it is under an active safety investigation or the law requires holding it longer.
That is the move most vendors get wrong. “We delete data when it is no longer needed” is not a retention period, it is a shrug. A defensible policy names a number, ties the delete to a system that runs on its own, and writes down the narrow exceptions (legal hold, open investigation). Regulators are pushing the same way, since data minimization and storage limitation sit at the center of both the CCPA and recent FTC enforcement. If you keep data for a safety or abuse purpose, say so, cap the clock, and make the deletion happen without a human remembering to click anything.
The second commitment is that retained data is not human readable by default. A person only sees content through a controlled path, triggered by something specific (a classifier hit), with two person approval for regulated data categories, and every read is logged.
This is the piece your enterprise buyers actually worry about. It is one thing to store data, it is another to have your staff casually browsing it. The design idea worth stealing is purpose bound access enforced at access time, not just in a policy PDF. In plain terms: access is automated only unless a real trigger fires, and non safety access requires the customer to pre approve it. (Two other commitments round it out, and both belong in your privacy documentation too: retained enterprise data is not used to train the model, and it is not shared with other customers.)
The third takeaway is the one that separates a real program from marketing. Every human read emits a tamper proof log entry that the customer can pull themselves through a compliance API (Anthropic calls it Access Transparency). And the system fails closed: if the audit path is down, access is denied rather than allowed.
The promise only counts if the customer can verify it themselves. Anyone can write “we protect your data” into a policy. Giving the customer a log they can pull on their own, plus a fail closed design and customer managed encryption keys (CMEK) with a narrow, published carve out for severe harm cases, is what turns the promise into something a security team will sign off on. It is the difference between “trust us” and “check for yourself.”
Here is the part I love. None of this is a 2026 invention. Cisco Duo published a Privacy Data Sheet back in 2021 that laid the whole thing out in plain tables: what data they collect, where it lives on AWS, how long they keep it, who their subprocessors are, and, my favorite, exactly who can access customer data and why. They kept it simple. The customer’s administrator sets the policies and controls access, and Duo’s own access is limited to supporting the service through a logged, access controlled process. You set up the controls, they support them. That was five years ago. What changed is that buyers now expect every vendor to show this. You can read the full Cisco Duo Privacy Data Sheet yourself, it is worth ten minutes.
Duo also published its retention in a table: most personal data held one year after account deletion (or sooner if the customer deletes it), backups for three years, and up to 30 days to fully purge. Whether or not those exact numbers fit your business, the move is the same. Pick the number, write it down, and show your work.
The single most useful thing to copy from Duo is the access control table. It answers the question every security reviewer actually asks: who can touch my data, and why? Here is Duo’s actual table, straight from the 2021 data sheet. Notice the shape. The data category sits on the left, and each one splits into two rows on the right, the customer’s own access and Duo’s support access, each with its own reason.
| Personal data category | Who has access | Purpose of the access |
|---|---|---|
| End-user registration and authentication information | Customer administrator | Modify and control access to the services and other administrator information |
| Duo | Support the services in line with its data access and security controls process | |
| Administrator registration information | Duo | Deliver, support, upgrade, and improve the services |
| End-user device metadata | Customer administrator | Set policies for the customer network, monitor it, and limit or approve access to users and applications |
| Duo | Deliver, support, upgrade, and improve the services | |
| Events and usage data | Customer administrator | Set policies, monitor the network, and limit or approve access |
| Duo | Deliver, support, upgrade, and improve the services | |
| Authentication and activity logs | Customer administrator | Set policies, monitor the network, and limit or approve access |
| Duo | Deliver, support, upgrade, and improve the services |
Copy the structure, not the labels. Put each data category on the left, split it into who controls access and who supports it, and give each a one line reason. Splitting customer controlled access from your own support access is what makes it credible, because it shows you designed for least privilege instead of just claiming it. That is the chart to put on your trust page.
Call it a privacy data sheet, a trust page, or a data security statement. The name does not matter. What matters is that a prospect can find, in plain English, what you collect, how long you keep it, who can access it, and who your subprocessors are, without emailing your sales rep. That page closes deals, because it answers the security questionnaire before it arrives. This is exactly the kind of work we handle as a data privacy lawyer for SaaS vendors. For what else belongs on that page, see our post on SaaS trust sites.
You do not need to be an AI company for any of this to matter. If your SaaS product retains customer data for a safety, abuse, fraud, or operational purpose, the same three moves translate straight into your data retention policy, your DPA, and your security documentation: a stated retention period with automated deletion, an access model that is purpose bound and logged, and a way for the customer to verify what happened. Back it with the certifications buyers expect, SOC 2 Type II, ISO 27001, and for AI systems the newer ISO/IEC 42001, plus a HIPAA BAA or CSA STAR listing where they fit your market. Do that, publish it, and you have answered the security questionnaire before it arrives.
If you want to see how a large vendor frames all of this publicly, Anthropic’s privacy center for commercial customers is a good modern reference, and Cisco Duo’s Privacy Data Sheet is the older one. Borrow the structure, then write your own in plain English (if Google can do it, so can you) for your own data flows.
What is a data retention policy? It is the rule that says what data you keep, why you keep it, how long you hold it, and when and how you delete it. For a SaaS vendor it usually lives in your privacy policy and your DPA, and it should match what your systems actually do.
How long should a SaaS company keep customer data? Only as long as the stated purpose needs, then delete it. Pick a defined retention period for each data type (Anthropic uses 30 days for retained enterprise prompts, Cisco Duo used one year after account deletion), automate the deletion, and write down the narrow exceptions like legal holds.
Should we publish our data retention policy? Yes. Enterprise buyers increasingly expect a public trust page or privacy data sheet, and Cisco Duo has published one since 2021. Showing what you collect, how long you keep it, and who can access it answers diligence before it starts.
What should a data retention policy include? Four things: the categories of data you hold, the purpose for each, the retention period and deletion method, and the access controls plus audit trail that prove only the right people can read it. Skip the generic template language and describe your real data flows.
I hope this helps. Trust me on this one, the vendors who can prove and publish their retention practices win the enterprise deals faster than the ones who just assert them.
Last updated: July 4, 2026.
Resources:
This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
Subscribe to get the latest posts sent to your email.
Get started with a free initial consultation—fill out the form below to connect with our experts today!