A small business can accumulate sensitive information far faster than it creates rules for managing it. Customer messages remain in shared inboxes, former employees’ files survive in cloud accounts, exports sit on laptops and backups keep copies nobody can easily locate. “Keep everything” feels safe, but it increases breach exposure, discovery cost and operational confusion.
A data retention policy sets a controlled lifecycle for business records. It states what the organisation keeps, why it keeps it, when the clock starts, how long the information remains available, what can pause deletion and how disposal is verified. The policy is the rule; a retention schedule is the working table that applies the rule to specific record categories.
The Federal Trade Commission advises businesses to understand the personal information they hold, keep only what is essential, protect retained information and properly dispose of what is no longer needed. Privacy authorities also emphasise storage limitation: personal data should not be kept indefinitely without a defensible purpose.
Key takeaway: A useful retention policy does not begin with a generic list of years. It begins with a data inventory and assigns each category a purpose, authority, owner, trigger, period, disposal method and exception process.
This guide offers a practical system for small organisations. It is not legal advice. Required periods vary by country, state, industry, contract, record type and dispute status, so qualified legal, tax, employment and privacy advisers should validate the final schedule.
What a data retention policy should accomplish
A good policy has five outcomes.
First, it makes decisions consistent. Staff no longer improvise when a customer asks for deletion or when a shared drive fills up. Second, it reduces unnecessary exposure. Information that no longer serves a legitimate purpose cannot be lost in a future incident if it has been securely removed. Third, it preserves records the business genuinely needs for operations, rights, obligations and disputes.
Fourth, it makes responsibilities visible. Every category has an owner who can approve a change and confirm disposal. Fifth, it creates evidence. A schedule, deletion log and exception register show that retention is governed rather than arbitrary.
A policy should not promise instant or perfect deletion across every system. Backups, immutable logs, fraud controls and legal holds may justify delayed or restricted removal. The policy should describe those limits accurately and ensure copies are no longer used for ordinary purposes while they await expiry.
Inventory data before assigning periods
Start with systems, not just document names. List email, customer relationship management, ecommerce, payroll, support, collaboration, analytics, file storage, devices, archives, paper cabinets, external drives and service providers. For each system, identify the main record categories and whether copies are exported elsewhere.
At minimum, capture these fields:
- Record category and a plain-English description
- Business purpose
- People or organisations represented in the data
- Sensitivity level
- System of record and known copies
- Record owner
- Legal, regulatory, contractual or operational authority
- Retention trigger
- Retention period or decision rule
- Disposal or anonymisation method
- Backup treatment
- Legal-hold applicability
- Review date and approver
Avoid a category called “miscellaneous.” If staff cannot tell which rule applies, they will either retain everything or delete inconsistently. Split broad buckets until an ordinary employee can choose the right line without legal interpretation.
Use the RETAIN framework
The RETAIN framework converts the inventory into a policy that people can run.
R — Record the category, purpose and owner
Describe the record precisely enough to distinguish it from similar information. “Customer data” is too broad; customer account profile, support conversation, signed contract and marketing suppression record serve different purposes. Name one accountable owner even when several teams use the data.
E — Establish the authority
Document why the organisation may or must retain the record. The basis could be a statutory requirement, a contract, a documented operational need, protection of legal rights or a security purpose. A vague phrase such as “just in case” is not a retention rationale.
Do not copy a period from a foreign template simply because it looks official. Ask which jurisdiction and rule apply to the organisation and when the period begins. Where legal duties conflict, obtain advice and document the decision.
T — Tie the period to a trigger
“Keep for six years” is incomplete. Six years after what: creation, transaction completion, account closure, final payment or contract termination? The trigger determines when deletion becomes due. For rolling data such as security logs, the trigger may be the event timestamp. For an employee file, it may be the end of employment.
A — Automate archiving and deletion where practical
Manual reminders fail at scale. Use native retention settings in email, cloud storage, ticketing and backup platforms when they match the approved schedule. Automate only after testing scope, exclusions, time zones, inherited folders and restore behaviour. Keep a human approval step for high-risk categories until the process is proven.
I — Isolate exceptions and legal holds
A legal hold temporarily suspends ordinary disposal for information potentially relevant to a dispute, investigation or preservation duty. It should identify the matter, custodians, systems, scope, start date, approver and release condition. Access should be limited, and the hold should be reviewed rather than left open forever.
Security incidents, audit commitments and unresolved customer disputes can create other documented exceptions. An exception is not permission to abandon the policy; it is a controlled deviation with an owner and expiry or review date.
N — Note evidence and review results
Keep evidence proportionate to risk: deletion-job logs, certificates from disposal vendors, anonymisation checks, legal-hold acknowledgements and review minutes. Evidence should confirm the process without creating a new unnecessary archive of sensitive content.
Build a workable retention schedule
Use this structure as a template. Replace every example rule with one validated for your business.
Record category | Purpose | System of record | Owner | Authority | Trigger | Period or rule | Disposal | Hold eligible
Signed customer agreement | Prove terms and obligations | Contract repository | Operations | Contract and legal rights | Contract ends | Validate locally | Secure delete; retain minimal audit evidence | Yes
Support ticket | Resolve and improve service | Help desk | Support lead | Operational need | Ticket closes | Risk-based period | Delete or de-identify attachments and messages | Yes
Job applicant file | Hiring process | HR system | HR owner | Employment/privacy rules | Role closes or decision made | Validate by jurisdiction | Secure delete; preserve required decision record | Yes
Marketing suppression entry | Respect opt-out | Marketing platform | Marketing owner | Compliance and user preference | Opt-out received | Keep minimal suppression proof while needed | Restrict fields; do not reactivate | Usually no
Authentication log | Detect and investigate misuse | Security log platform | IT/security | Security purpose | Event occurs | Based on threat and investigation needs | Expire through tested lifecycle rule | Yes
The table deliberately avoids universal periods. A financial record, medical record, tax document or employee record may be governed by specialised rules. Even two businesses in the same country may have different obligations because their sectors and contracts differ.
Prioritise high-risk categories first. A simple risk score can help:
Priority score = Sensitivity (1–3) × Copy count (1–3) × Uncertainty (1–3).
A score near 27 deserves rapid review; a score near 1 can follow later. This is a workflow tool, not a legal or security risk model. Its purpose is to stop a small team from spending its first week debating low-impact files while sensitive exports remain unmanaged.
Handle backups, SaaS tools and paper records
Backups are a common source of false promises. Some platforms delete an active record promptly but retain protected backup copies until a rotation expires. Document the backup window, access restriction and restoration procedure. If a backup is restored, make sure deletion decisions or suppression lists are reapplied so expired data does not quietly return to production.
For software-as-a-service tools, check settings and contracts before writing policy language. Determine whether an administrator can configure retention by workspace, user, folder or record type; whether deleted items remain recoverable; whether the provider retains logs; and what happens after account termination. Include vendor exit steps in the retention schedule.
Paper records need the same governance. Name storage locations, control keys or cabinet access, schedule secure destruction and record the vendor or internal process used. A recycle bin is not an appropriate disposal route for documents containing personal or confidential information unless an approved destruction process protects them.
Local copies are often the hardest gap. Restrict bulk exports, set approved storage locations and remove data from downloads folders and former employees’ devices. Training should make clear that moving a file to an archive folder does not satisfy deletion.
Add deletion, legal-hold and exception controls
Define disposal in technical terms. Deleting a database row, removing a user-facing object, cryptographically erasing encrypted media, sanitising a device and physically destroying a drive are different actions. NIST’s media-sanitisation guidance can inform a risk-based method for storage media. Match the approach to sensitivity, technology and the possibility of reuse.
Anonymisation must be more than removing a name. If remaining fields or linked datasets can reasonably identify a person, the data may still be personal. Have a knowledgeable reviewer test the result and document limitations. When full anonymisation is not feasible, deletion or restricted archival may be more honest.
Create a short hold procedure:
- Authorised person opens a hold with defined scope.
- IT and record owners identify affected systems and custodians.
- Automated deletion is paused only where necessary.
- Custodians acknowledge preservation instructions.
- The owner reviews the hold at a set interval.
- An authorised person releases it in writing.
- Normal retention rules resume and overdue disposal is assessed.
Build an exception register with reason, scope, risk, approver, compensating controls and review date. Permanent exceptions should be rare; if an exception recurs, change the policy or fix the system.
Write the policy in plain English
A concise policy can use this structure:
- Purpose and scope
- Definitions
- Roles and responsibilities
- Retention principles
- Retention schedule ownership
- Secure storage and access
- Disposal and anonymisation
- Backups and restored data
- Legal holds and exceptions
- Vendor responsibilities
- Training, monitoring and review
- Approval and version history
Keep detailed periods in the schedule rather than burying them in policy prose. That allows the business to update one controlled table when a system or requirement changes. Link the policy and schedule, assign version owners and retain the approval record.
Roll out the policy in 30 days
Days 1–7: discover and prioritise
List systems, owners, categories and high-risk copies. Freeze unnecessary new exports. Identify specialist records that require legal or professional review.
Days 8–14: draft and validate
Use RETAIN to fill the schedule. Ask legal, privacy, tax, HR and security advisers to validate the categories in their scope. Reconcile contracts and vendor capabilities with the proposed rules.
Days 15–21: configure and test
Set retention rules in a non-production environment or limited pilot. Test deletion, backup expiry, restores, holds, audit logs and permissions. Record unexpected behaviour.
Days 22–30: approve and operate
Approve the policy and schedule, train staff, assign a contact for questions and begin with a supervised disposal batch. Review at least annually and whenever a law, contract, system, product or data use materially changes.
The first version does not need hundreds of categories. A defensible schedule for the highest-risk systems is more useful than a perfect-looking policy nobody can execute. Expand coverage, measure exceptions and improve automation over time.
FAQ
What is the difference between a retention policy and a retention schedule?
The policy sets principles, responsibilities and controls. The schedule applies them to individual record categories with a trigger, period, owner and disposal method.
Should a small business keep records forever to be safe?
Usually not. Indefinite retention increases exposure and may conflict with storage-limitation duties. Keep records only for a validated legal, contractual, security or operational reason.
Can one retention period cover all customer data?
That is rarely practical. Contracts, support conversations, account profiles, transaction records and opt-out evidence have different purposes and risks.
What happens when a legal hold conflicts with scheduled deletion?
The hold should pause ordinary deletion for the defined information until an authorised release. The business should preserve only the necessary scope and document both the hold and release.
Does deleting a live record remove it from backups?
Not always. The policy should describe backup rotation, access restrictions and what happens when a backup is restored.
