How should an enterprise software startup design data retention and deletion settings?
Security and legal reviewers ask how long an enterprise product keeps their data, whether they can change it and whether they can freeze it. A good design offers per-type periods, shows real deletion stages, supports legal holds and confirms policy changes before they delete anything.
Illustrative situation: a startup sells inspection-report software to field teams, and a regional insurer’s legal counsel reviews it before signing. Her questions are short. How long do you keep our data? Can we change that? If we are sued, can we freeze it? The startup’s settings page has one “Delete project” button and nothing else. Nobody can say whether a deleted project is gone, hidden or sitting in a backup, and the only written answer is “we keep everything until you delete it.” The scene is invented. It shows the gap this guide covers: customers must govern the data they put in your product, and the product gives them no controls.
Humbleteam, a digital product design agency, publishes this guide. It covers who opens these settings, retention per data type, what deleting really does, legal holds, export and contract end, policy changes and the security review, with a worksheet and an invented worked example. Product behavior is described as of November 6, 2026 and can change. This is not legal or compliance advice: your counsel and your customers’ counsel decide what a policy must say.
Who opens these settings, and what is each person deciding?
Four people open them. This list is our reading, not research.
- The IT admin sets workspace defaults and wants one place to do it.
- The legal or compliance lead decides how long records must exist and when they must be frozen.
- The data protection officer asks whether personal data is kept longer than needed and how erasure requests are handled.
- Your own support staff get “please restore my project” requests and need to know what can still be recovered.
One area of settings can serve all four if it separates the policy (how long), the process (what deletion does) and the exceptions (holds). Our guide to roles and permissions covers who may edit it. For end-user chat history, see our guide to AI memory and chat history controls.
What should an admin be able to set for each data type?
Retention is rarely one number. Slack keeps message and file retention as separate settings. On paid plans it keeps data for the lifetime of the workspace by default, and an owner can choose a custom timeline instead. Data deleted by a retention setting is permanent, and Slack says so on the page.
Google Vault shows a second design choice. Each service gets one default rule, and custom rules win over it. For Drive items the retention clock can start at creation, at last modification or when the item is moved to trash, and that choice changes what gets deleted.
Our suggestions: list five data types (content, files, messages and comments, activity logs, backups) and give each its own row. Offer “Keep until deleted” and “Custom period” as named choices, and print the start rule in the label, such as “counted from last edited.” Keep backups out of the customer’s control and state their fixed period instead. The activity log has its own period, covered in our audit log guide.
The law gives the reason to offer a limit. GDPR Article 5(1)(e) says personal data should be kept identifiable no longer than necessary for its purposes. The customer decides those purposes. Your job is to let them set a limit.
What does “delete” actually do?
Deletion is a sequence, and admins want to see where an item sits in it. Notion’s Enterprise settings show three stages. Deleted pages sit in trash, 30 days by default and up to 10 years. They then enter a retention period, again 30 days by default and up to 10 years. After that they are purged and nobody can restore them. Anyone with access can restore from trash. Owners can also restore from the retained stage, to their own private pages if the matter is sensitive.
Backups add a lag. Google Cloud’s deletion documentation describes marking data for deletion, an optional recovery period of up to 30 days, deletion from active systems that generally takes about two months, and expiry from backups on a fixed cycle. It commits to delete customer data within about six months. Google Vault says data can stay available to Vault administrators for about 30 more days after retention expires.
Our suggestions: name the states in the product (Deleted, Pending purge, Purged). On every delete, print the date after which the item cannot be restored. Tell admins the truth about backups in one line: “Copies in backups expire within N days after purge.” N must be your own number. If you do not know it, find out before the security review. Do not borrow another company’s figure.
How should a legal hold work against retention?
A hold freezes data whatever the retention rule says. Vault states that holds take precedence over retention rules, and that when a hold is deleted the data is immediately subject to the retention rules again. A release can therefore purge a backlog at once. Microsoft Purview settles the same conflict inside retention: by default, retention takes precedence over permanent deletion, and the longest retention period wins.
Slack’s legal holds show the edges. They are an Enterprise feature run by a Legal Holds Admin role, with up to 1,000 custodians per hold. Held messages and files are kept regardless of retention settings, edits or deletes. The date range and included conversations cannot be edited after creation. If a held channel is deleted, its data is not saved, and Slack Connect conversations are not covered.
Our suggestions: give holds their own role, so an IT admin cannot release one. Mark held items and workspaces with a visible tag. Block deleting a whole container, such as a project or workspace, while anything inside is held, because deleting a container is where Slack’s hold stops protecting data. On release, preview what the retention rules will purge and let legal pick a start date. GDPR Article 17(3)(e) lists legal claims among the exceptions to erasure, so an erasure request can meet a hold. Decide in advance who tells the requester, and have counsel approve the wording.
What should happen at export and contract end?
Contract end is a deletion too, and the largest one a customer runs. Slack lets only the Primary Owner delete a workspace, says it is permanent and recommends exporting first. GitHub says deleting an organization is irreversible and keeps the name unavailable for 90 days. For a vendor that acts as a processor, GDPR Article 28(3)(g) says that at the controller’s choice it deletes or returns all personal data after the services end, and deletes existing copies unless law requires storage.
Our suggestions: offer export before delete, in the same flow. Limit deletion to the account owner and ask them to type the workspace name. Add a waiting period before purge, with the date shown. Then send a written confirmation that lists the deletion date, what remains in backups and until when, and anything kept under a hold or legal duty. A reviewer can file it as evidence.
How should a policy change be confirmed?
Shortening a retention period deletes data, so it needs more care than any other control here. Slack asks admins to review the changes and save a second time, and says deletions run once a day, so data can go soon after a change. An org-level policy waits for the Primary Org Owner’s approval. Vault warns that a wrong rule might let services purge data immediately and irreversibly, and advises testing on a small group first. Microsoft’s Preservation Lock goes furthest: once applied, no one, including a global admin, can turn off or shorten the policy. It is available only through PowerShell, so it cannot be set by accident.
Our suggestions: make shortening a period heavier than lengthening it. Show a preview with counts and a first-deletion date, for example “Shortening to 90 days deletes 41,200 items from November 8.” Start after a delay the admin can cancel. Offer an optional second approver. Treat an irreversible lock as a separate, clearly labeled choice for regulated customers. Record old value, new value, actor and approver in the audit log.
How do you present this in a security review?
Print one table: data type, default, who can change it, deletion lag, backup lag and what a hold changes. Make the product match your data processing agreement (DPA). If the agreement says 30 days, the product should purge at 30 days. Put the table on your trust center too. We did not research what SOC 2 or ISO 27001 require for retention, so this guide makes no claim about either. Ask your auditor.
Which fields does each part of the settings need?
| Element | Main reader | Decision it supports | Default we suggest | Print beside it | Admin control |
|---|---|---|---|---|---|
| Retention by data type | IT admin, legal | How long do we keep each kind? | Keep until deleted; custom period offered | Start rule; what happens at expiry | Who may edit |
| Deleted items view | Admin, support | Can this still be restored? | Trash window you can state | Restore-until date | Window length |
| Legal hold | Legal | Is this frozen? | Hold role separate from IT admin | Held tag; who placed it; since when | Place, release |
| Policy change | Admin, second approver | What will this delete? | Preview and a cancelable delay | Item count; first deletion date | Second approver on or off |
| Export and workspace deletion | Account owner | Is our data out before it goes? | Export first; typed confirmation | Waiting period; purge date | Owner-only |
| Backup statement | Security reviewer | When do copies expire? | One sentence with your real number | N days after purge | None; fixed |
| Policy audit entries | Compliance | Who changed retention? | Log old and new value | Actor; approver; time | Export, stream |
Illustrative worked example: an inspection startup and an insurer
Everything here is invented. Fennick is a fictional inspection-report startup. Harlow Mutual is a fictional insurer. Lena Marchetti is Harlow’s counsel, and Dev Oyelaran is its IT admin.
Lena asks her three questions. Dev opens Retention in Fennick. Reports are set to “Keep until deleted,” counted from the date a report is closed, and he changes that to 7 years. He sets draft comments to 2 years. Fennick shows “Shortening to 2 years deletes 31,000 comments from November 12, 02:00 UTC. You can cancel until then,” and Lena approves as the second approver.
Months later a claim arrives, and Lena places 14 projects on hold. A field user deletes one of them. The user sees a normal deletion. Admins see “Deleted, preserved under legal hold.” At contract end, Dev exports, types the workspace name and waits out a 30-day window. Fennick’s confirmation says backups expire within 35 days after purge and lists the 14 held projects as kept. The example shows the type table, the preview, the hold and the confirmation doing the work.
Where do these defaults stop working?
The sources are vendor documentation, one cloud provider’s security documentation and the text of the GDPR. None of them measures whether better controls shorten a security review. Features depend on plan: Slack’s legal holds need Enterprise, and Notion’s custom retention is for Enterprise workspace owners. We read the GDPR text, not national law or regulator guidance, and retention duties vary by country and sector. Some pages carry no update date. Atlassian’s retention documentation was not clear enough to cite, and we did not research Zoom or Linear. A startup can begin with a per-type retention table, a deleted-items window and a written contract-end confirmation. Involve counsel before you promise any of this.
What can you produce now?
Five things, before the next security review:
- A retention table by data type: default, options and the rule for when the clock starts.
- A deletion lifecycle with named states, a restore-until date and a backup sentence with your real number.
- A legal hold specification: who places and releases, what it blocks and the preview on release.
- A policy change flow: preview, cancelable delay and an optional second approver.
- A contract-end checklist: export, waiting period and a written confirmation.
If you want a design partner for these screens, our comparison of agencies that publish B2B SaaS platform cases shows what each one publishes.
