Most organizations are good at collecting data and poor at getting rid of it. Old exports sit in downloads folders, former customers stay in databases, and backups preserve everything indefinitely. Each forgotten record is a liability: it can be breached, subpoenaed, or mishandled, and it adds nothing to the business.
A retention schedule fixes this by answering a simple question for each kind of data: how long do we keep it, and why?
Keep Less, Risk Less
Data you do not hold cannot be stolen from you. In an incident, the volume of affected records often decides how serious the consequences are. Privacy principles in many jurisdictions also expect you to keep personal data no longer than needed for its purpose. The specifics differ by location and sector, so treat this guide as a framework and confirm legal requirements with qualified counsel.
There is a tension to respect. Some records must be kept for set periods under tax, employment, financial or industry rules. Others should be deleted promptly. The schedule exists to make both of those decisions deliberately.
Build the Schedule in Five Steps
1. List your data categories. Group by purpose, not by system. Examples: customer account records, billing and invoices, employee files, job applicant data, support tickets, marketing contacts, website logs, security logs, and backups.
2. Identify the reason to keep each. Is it a legal obligation, a contractual need, an operational need, or a legitimate business interest? “Might be useful someday” isn’t a reason.
3. Set a period and a trigger. Retention clocks usually start from an event such as account closure, the end of employment, or the date of a transaction, rather than from creation.
4. Assign an owner. Someone is accountable for each category, including approving deletion.
5. Define how deletion happens. Manual, scheduled, or automated, and how you will confirm it worked.
A Format That Works
| Data category | Reason to keep | Retention trigger | Disposal method | Owner |
|---|---|---|---|---|
| Customer account data | Service delivery, support | Account closure plus review period | Scheduled database deletion | Product lead |
| Invoices and payment records | Tax and accounting rules | End of financial period | Secure archive then delete | Finance |
| Job applicant files | Hiring decision, short follow-up | Close of hiring round | Delete from applicant system | HR |
| Support tickets | Quality and dispute handling | Ticket closed | Anonymize or delete | Support lead |
| Security and audit logs | Investigation, compliance | Log creation | Automated expiry | Security |
| Marketing contacts | Consent-based outreach | Withdrawal of consent or inactivity | Remove from lists and tools | Marketing |
Fill in the actual periods with your legal adviser, because they depend on jurisdiction and industry. I have deliberately left them blank here. Copying someone else’s numbers is how organizations end up either hoarding or deleting something they were obliged to keep.
A Hypothetical Example
A small online service has never deleted anything. When it reviews its database, it finds accounts for people who stopped using the product long ago, support tickets containing identity documents, and applicant resumes from several hiring rounds back.
The team does three things. They define “inactive” for accounts and set a notification-then-deletion process. They change the support workflow so identity documents are removed once verification completes. And they add a deletion step to the hiring checklist. Within a quarter, the database is meaningfully smaller and the next privacy review is far simpler.
The Parts That Trip People Up
Backups. Deleting a record from the live database leaves it in backups until they expire. Don’t rewrite old backups; instead, keep backup retention reasonably short and document that deleted data ages out with them. If you restore from a backup, re-apply deletions that occurred since.
Copies and exports. Data spreads: spreadsheets, email attachments, test environments, analytics tools. Deletion must cover derivative copies, which is another argument for data inventory.
Vendors. Processors that hold your data need to delete it too. Check contracts for deletion on termination, and ask for confirmation when you leave a service.
Legal holds. If litigation or an investigation is likely, normal deletion must pause for relevant records. Make sure someone has authority to impose a hold and a way to notify system owners.
Anonymization. Sometimes you want the statistics without the person. True anonymization is harder than removing names; if individuals can still be identified by combining fields, it isn’t anonymous. Get specialist advice before relying on it.
Making Deletion Actually Happen
- Automate where you can: time-based expiry in storage, scheduled jobs in databases, retention settings in mail and chat tools.
- Where it is manual, put it in a calendar with a named owner.
- Log deletions at a category level so you can show the process runs.
- Test with a small dataset before deleting broadly, and take a verified backup first.
- Review the schedule at least annually, and whenever you launch a product that collects new data.
Frequently Asked Questions
Is there a standard retention period we can adopt? No single standard applies to everyone. Legal rules differ by data type, sector and location, so base your periods on advice specific to your situation.
What if we’re not sure whether we need to keep something? Resolve the uncertainty by asking the relevant legal or compliance contact, then record the decision. Silence defaults to hoarding.
Do we have to delete data from backups? Practice varies, and regulators generally accept that backups expire on their own cycle if you protect them and don’t restore deleted data. Confirm your obligations with an adviser.
Who decides retention periods? Legal or compliance should set the constraints, business owners should supply the operational need, and security should advise on risk.
How do customers’ deletion requests fit in? They are a separate trigger. Your schedule covers routine disposal, while individual requests need their own process, deadlines and identity checks.
Next Step
Choose the single data category you most suspect is over-retained, such as old support tickets or applicant files, and draft one row of the schedule for it. Getting one row approved teaches you how the rest will go.
By CRMCyberBase Editorial · Updated November 4, 2026
- data retention
- data deletion
- privacy
- records management