If you have ever opened a folder of old files and thought, "Should we still be keeping this?", you have already felt the problem a data retention schedule solves.
Most companies keep data for two bad reasons. Either they keep everything forever because deleting feels risky, or they delete things randomly because storage is getting full. Both approaches create problems. Keeping everything forever increases cost, security risk, and legal exposure. Deleting randomly can get you in trouble with regulators, customers, or in court.
A data retention schedule fixes this. It is a simple table that says: this type of data gets kept for this long, for this reason, and then it gets deleted or archived.
The hard part is figuring out the "this long" and "this reason" without just guessing. You do not want to invent periods like "keep invoices for 7 years because it sounds good." You want periods based on law, contracts, business need, and risk.
Here is how to build one without making up the numbers.
STEP 1: START WITH WHAT YOU ACTUALLY HAVE
You cannot set rules for data you do not know about.
Before you write any retention period, do a quick data inventory. You do not need expensive software. A spreadsheet works.
List the main types of data your organization creates and stores. Think in business terms, not technical terms. Examples:
Customer data: name, email, phone, address, payment info
Employee data: CVs, contracts, payroll, performance reviews
Financial data: invoices, receipts, tax filings, bank statements
Legal data: contracts, NDAs, correspondence with lawyers
Marketing data: email lists, campaign results, website analytics
Product data: designs, source code, support tickets
For each type, note where it lives. CRM, accounting software, shared drives, email, paper files. Also note who owns it. Usually the department that uses it most.
This step takes 1 to 2 weeks for most small to mid-size companies. The goal is not perfection. The goal is to stop guessing.
MAY LOVE THIS: MTN NIGERIA: HOW THE BIG YELLOW GIANT IS QUIETLY BUILDING NIGERIA’S DIGITAL ECONOMY
STEP 2: FIND THE RULES THAT ALREADY EXIST
This is where most people try to invent periods. Do not. The periods already exist. You just have to find them in four places.
1. The law
Every country and often every industry has laws that say how long you must keep certain records. You are not deciding 7 years. The law already did.
Examples:
Tax and accounting records: In many countries this is 5 to 10 years. In the US the IRS generally recommends 7 years. In the UK it is 6 years. In Nigeria, the Companies and Allied Matters Act and tax laws often require 6 years.
Employee records: Labor laws often require you to keep payroll and employment contracts for 3 to 7 years after an employee leaves.
Health and safety records: These can be 5 to 30 years depending on the industry.
Financial services: Banks and fintechs often have 5 to 10 year requirements from regulators.
How to find them: Google "[your country] record retention requirements" plus your industry. Check your tax authority website, labor department website, and industry regulator. Ask your accountant or lawyer for a list. They already have one.
2. Contracts
Your customer contracts, vendor contracts, and insurance policies often include retention clauses.
Example: "Supplier shall retain all project records for 5 years after project completion." Or "Data Processor shall delete personal data within 30 days of contract termination."
You are not choosing 30 days. The contract chose it.
How to find them: Ask legal or procurement for standard contract templates. Search for the word "retain" and "delete."
3. Business need
Some data has no legal requirement, but you still need it to run the business.
Example: You probably do not need a customer support ticket from 8 years ago to answer a new question. But you might want 2 years of tickets to spot trends. Or you might need product design files as long as the product is sold plus 5 years for warranty claims.
The key is to tie it to a real business process, not a feeling. "We keep it because we might need it" is not a reason. "We keep it for warranty claims until 2 years after product end-of-life" is a reason.
How to find it: Talk to the department owner. Ask, "What is the last time you needed data older than X? What would happen if we deleted it after X?"
4. Risk
Some data is dangerous to keep too long. Personal data is the big one.
Laws like GDPR, CCPA, and Nigeria's NDPR all have a principle called "storage limitation." It means you should not keep personal data longer than necessary for the purpose you collected it.
So if you collected an email for a one-time webinar, you probably do not need it 5 years later. If you collected it for a customer account, you need it while the account is active, plus a short period after.
You are not inventing the period. You are matching it to the purpose.
STEP 3: BUILD THE SCHEDULE TABLE
Now you take everything from steps 1 and 2 and put it into one table. Keep it simple. 5 columns is enough.
Column 1: Data Category. Example: Customer Invoices
Column 2: Description. Example: PDFs of invoices sent to customers
Column 3: Retention Period. Example: 7 years
Column 4: Basis for Period. This is the most important column. Example: Nigerian tax law + Company finance policy
Column 5: Action at End of Period. Example: Secure delete. Or: Archive to cold storage.
Here are 10 example rows to show you what it looks like without inventing anything:
Customer personal data for active accounts: Keep while account active + 2 years after closure. Basis: Purpose limitation under NDPR and GDPR. Action: Anonymize or delete.
Payroll records: 7 years after employee leaves. Basis: Labor law and tax law in [your country]. Action: Secure delete.
Signed customer contracts: 7 years after contract ends. Basis: Standard contract clause + statute of limitations for lawsuits. Action: Archive then delete.
Marketing email list contacts: Until contact unsubscribes + 1 year. Basis: Consent and legitimate interest. Action: Delete.
Website analytics: 26 months. Basis: Google Analytics default and not needed for business. Action: Auto-delete.
Invoices and receipts: 7 years. Basis: Tax authority requirement. Action: Archive.
Job applications from candidates not hired: 1 year. Basis: Equal opportunity law and reduce bias claims. Action: Delete.
Product designs: Life of product + 5 years. Basis: Warranty and liability. Action: Archive.
Support tickets: 3 years. Basis: Business need to track recurring issues. Action: Delete.
Board meeting minutes: Permanent. Basis: Corporate governance law. Action: Archive permanently.
Notice that none of those numbers came from thin air. Each one is tied to a law, contract, or business reason.
STEP 4: GET APPROVAL FROM THE RIGHT PEOPLE
A retention schedule only works if people follow it. That means legal, IT, security, and the business owners all need to sign off.
Send the draft table to:
Legal: To check if you missed any laws or contract terms
Finance: To confirm tax and audit requirements
HR: To confirm employee record rules
IT/Security: To confirm you can actually delete data on that schedule
Department heads: To confirm business needs are covered
You will get pushback. Someone will say "we need that forever." Ask them to show you the law or business reason. If they cannot, the default should be to set a period and delete.
This meeting usually takes one hour. Get it in writing.
STEP 5: PUT IT INTO PRACTICE
A schedule in a Word doc does nothing. You need to operationalize it.
1. Update your systems: Set auto-delete in your email marketing tool, CRM, and cloud storage where possible. For systems that cannot auto-delete, create a quarterly calendar reminder.
2. Train staff: Tell people that "delete after 3 years" is now policy. Give examples.
3. Document exceptions: Sometimes you need to keep something longer because of a lawsuit. Have a process to "legal hold" data and pause deletion.
4. Review yearly: Laws change. Business changes. Set a calendar reminder to review the schedule once a year.
COMMON MISTAKES TO AVOID
1. Inventing round numbers: 5 years, 10 years. If you cannot cite a source, do not use it.
2. One period for everything: "We keep all data for 7 years" is lazy and risky. Different data has different rules.
3. Forgetting backups: If you delete from the main system but it lives in backups for 3 more years, you have not deleted it. Note backup retention in the schedule.
4. No owner: Every data category needs a person responsible for deleting it.
5. Ignoring personal data: This is where regulators fine you. Be extra careful and keep it as short as possible.
A QUICK TEMPLATE YOU CAN COPY
Data Category | Description | Retention Period | Legal/Business Basis | Action
Customer Account Data | Name, email, address | Active + 2 years | NDPR/GDPR purpose limitation | Anonymize/Delete
Employee HR File | Contract, reviews | 7 years after exit | Labor Law Section X | Secure Delete
Invoices | Customer bills | 7 years | Tax Authority Rule | Archive
Contracts | Signed agreements | 7 years after end | Contract + Statute of Limitations | Archive then Delete
Marketing Leads | Email from website form | 1 year if no engagement | Consent | Delete
Support Tickets | Customer service records | 3 years | Business process improvement | Delete
Website Logs | IP addresses, access times | 12 months | Security need | Auto-delete
Product IP | Designs, code | Product life + 5 years | Warranty/Liability | Archive
Replace the periods and basis with the ones that apply in your country and industry.
FINAL THOUGHT
Building a data retention schedule is not about guessing. It is about collecting the answers that already exist in law, contracts, and your business processes, and putting them in one place.
Start with an inventory. Then go find the rules instead of making them up. Tie every period to a specific reason. Get sign-off. Then actually delete the data when the time comes.
The benefit is immediate. Less storage cost. Less risk if you get breached. Less stress during an audit. And you stop having that "should we keep this?" conversation every time you open an old folder.
You do not need to be a lawyer or a compliance expert to do this. You just need to be disciplined about sourcing your periods instead of inventing them.
Start with 10 data categories this week. In a month you will have a schedule that protects the business and that you can defend to a regulator, a customer, or a judge.
Want me to turn this into a downloadable retention schedule template with the columns pre-filled for you?




