What Is a Data Retention Policy?

A data retention policy is a document that defines how long an organisation keeps each type of record or data, what starts the clock, and when and how that data must be securely deleted, destroyed, or anonymised once the period ends. It answers two questions that otherwise get answered by accident: “why do we still have this?” and “who said we could delete that?”. In practice it sits alongside the wider asset management policy, because the data it governs lives on the laptops, phones, and drives that policy tracks.

That is the retention policy meaning in one paragraph. The rest of this page is the operational half: a worked schedule you can copy, the periods people actually use, the legal hold that overrides all of them, and the evidence that proves deletion really happened.

What you will learn

• What a data retention policy covers
• Data retention policy example (a worked schedule)
• Typical retention periods by record type
• How retention periods are set - and what starts the clock
• How to write a data retention policy
• Retention, archiving, backup and anonymisation
• Legal holds and other exceptions
• Retention and GDPR
• What the frameworks and regulators expect
• Who owns the policy and how often it is reviewed
• What it means for retired devices
• Proving that data and devices were actually disposed of
• Retention events hide in offboarding
• Data retention policy checklist
• Common mistakes
• FAQ

What a data retention policy covers

A usable policy is a table, not an essay. For each category of record it states:

• The record type - invoices, contracts, employee files, CCTV footage, email, customer data, system logs.
• The retention period - how long it is kept.
• The deletion trigger - what starts the clock: creation, contract end, last interaction, employee departure, end of the financial year.
• The legal or business justification - the law, regulation, or operational need behind the period.
• The disposal method - secure deletion, data sanitization of the device, physical destruction, or anonymisation.
• The owner - who is accountable for the category and who executes the disposal.

Around that table sits the prose: scope, who approves exceptions, how legal holds work, how backups and SaaS copies are handled, and when the whole thing gets reviewed. Together they are usually described as the records retention policy and its retention schedule - and it is the schedule, not the prose, that people actually work from.

Data retention policy example

Searchers asking for a data retention policy template almost always want one thing: a sample schedule to adapt. Here is what a workable one looks like. The periods below are illustrative rather than legal advice - check the rules that apply in your own jurisdiction and sector before adopting any of them.

Two things make that table work rather than just look good. First, every row has a trigger, not only a duration - “six years” is meaningless until you say six years from what. Second, every row has a named owner, because a schedule with no owner is a schedule nobody runs.

Typical retention periods by record type

The most common follow-on question is simply how long to keep business records. The well-known statutory anchors give you a starting frame, though every one of them carries a jurisdiction:

• Company accounting records - UK limited companies must keep them six years from the end of the financial year they relate to. In the US, seven years is the common working figure under IRS and SOX practice.
• Financial services - FCA-regulated firms commonly work to five years for client and transaction records, longer for pension and life business.
• Anti-money-laundering records - typically five years after the end of the business relationship, with some regimes extending to ten.
• Employment and payroll - usually measured in years after the employment ends, driven by tax rules and the limitation period for employment claims.
• Health records - HIPAA requires covered entities to keep required documentation six years; clinical records themselves are governed separately and often far longer.
• Workplace exposure records - OSHA requires certain employee exposure records to be kept for up to thirty years.
• Contracts - commonly six to ten years after expiry, tracking the statute of limitations for claims under the contract.
• Email and general correspondence - one to three years unless a specific record or a hold requires longer.

Underneath all of it sits a single rule that is worth memorising: statute sets the floor, data protection law sets the ceiling for personal data, and everything in between is a documented business judgement. If you cannot name the floor or justify the gap, the honest default is a shorter period, not a longer one.

How retention periods are set - and what starts the clock

Periods come from three directions. Statute sets minimums, as above. Contracts, insurers, and customers may add requirements of their own - a client agreement that demands deletion within 30 days of termination beats your standard schedule. Everything else is a business judgement, and the honest default for data with no justification is “delete it”, not “keep it forever just in case”.

The part most schedules get wrong is not the number but the deletion trigger. A period only becomes computable when something concrete starts it: the date a record was created, the day a contract ended, the last time a customer interacted with you, the date an employee left, the close of the financial year. Pick the wrong trigger and the whole schedule drifts - “six years from creation” and “six years from contract end” can be a decade apart on the same file. Write the trigger next to the period in every row, and make sure the system that executes deletion can actually read that date. This is also where data classification earns its keep: you cannot apply a rule to a category you have never defined.

How to write a data retention policy

You do not need a download so much as a method. Nine steps produce a policy that survives contact with an auditor:

1. Set the scope. Name the systems, the record classes, and the physical world too - paper files, archived boxes, and the devices data sits on, not just databases.
2. Inventory and classify what you hold. Derive the personal-data entries from your record of processing activities (the GDPR Article 30 ROPA); everything else comes from finance, HR, and the systems inventory. An information asset register is the natural home for this.
3. Set a period and a start trigger for each category. Both, always.
4. Write down the justification. One line per category naming the law, contract, or business need. This is the sentence you will be asked to produce.
5. Decide the action at expiry. Delete, destroy, or anonymise - and say which, per category.
6. Name an owner per category. A department, and ideally a role, not “the business”.
7. Decide how copies age out. Backups, exports, data warehouses, shared drives, and SaaS copies. A copy that outlives its period silently defeats the policy.
8. State how holds and exceptions are approved. Who can suspend deletion, who releases it, and how each is recorded.
9. Set a review cadence. Annual by default, plus an off-cycle review on any material legal or system change.

That sequence - scope, inventory, periods, justification, expiry action, owners, copies, exceptions, review - is the whole document. Everything else is formatting.

Retention, archiving, backup and anonymisation

Four words get used interchangeably and mean very different things:

• Retention is how long data is allowed to exist. It is a permission with an end date.
• Archiving moves data that is still within its retention period to cheaper, colder storage. It changes the cost and the access speed; it does not reset or extend the clock.
• Backup is a copy taken so data can survive an incident. Backups are the most common silent breach of a retention policy: the production record is deleted on schedule while the same personal data sits in a snapshot nobody thought to age out. State a backup retention period explicitly, and accept the reality that restoring an old backup can resurrect deleted records - which is why restores need a re-application step.
• Anonymisation is a third legitimate outcome at expiry. If data is genuinely and irreversibly stripped of identifiers, it stops being personal data and falls out of scope entirely - which is often the practical answer for analytics, trend reporting, and historical figures you do not want to lose. Note the trap: pseudonymisation is not anonymisation. If a key exists anywhere that can re-link the record to a person, it is still personal data and still on the schedule.

Legal holds and other exceptions

The schedule is the default. The legal hold - also called a litigation hold or preservation notice - is the override.

A hold arises when litigation or a regulatory investigation begins, or when either becomes reasonably foreseeable. From that moment, scheduled deletion is suspended for the affected records until Legal formally releases the hold. Three practicalities decide whether it actually works:

• It must be documented at both ends. Who placed it, when, over what scope, and when it was released. An undated hold is impossible to defend, and a hold nobody released quietly turns into permanent retention.
• Automated deletion must be able to honour it. The classic failure mode is a hold placed on the “official” copy in the records system while a nightly job in another platform deletes the same data on schedule. Deleting under hold is a far worse outcome than over-retaining.
• It reaches hardware. A laptop, phone, or drive belonging to someone under hold cannot be wiped, reissued, resold, or recycled. That means the asset record needs a visible flag, because the person deciding to send a batch of retired machines to an ITAD vendor is rarely the person who knows about the case.

Holds are not the only exception. Ongoing contractual obligations, open insurance claims, and unresolved disputes all justify keeping data past its normal period - but each should be recorded as a deliberate, dated exception rather than an informal decision to leave the data alone.

Retention and GDPR

For personal data, GDPR’s storage limitation principle turns retention from good housekeeping into a legal duty: personal data may be kept no longer than necessary for its purpose. Its sibling, data minimisation, asks whether you needed the field at all. Together they cut both ways - the policy must justify keeping data, and it must also respect legal minimums that force you to keep some records even after an erasure request. The retention schedule is where those two pressures get reconciled, in writing, before a regulator or auditor asks.

Three practical points that generic write-ups skip:

• The schedule should be derived from the record of processing activities. Article 30 already requires you to list your processing purposes and, where possible, the envisaged erasure time limits. If your ROPA and your retention schedule disagree, at least one of them is wrong, and an auditor will find the seam.
• Erasure requests do not beat statutory minimums. Where you are legally required to retain a record - tax, employment, AML - you keep it, and you tell the requester why, restricting further processing rather than deleting.
• Anonymisation is a compliant answer. Irreversibly anonymised data leaves the scope of the regulation, which is why it is often better than a dispute over whether analytics data must go.

The blunt version: a schedule nobody technically enforces is worse than no schedule at all, because it documents in your own words an obligation you are demonstrably missing.

What the frameworks and regulators expect

Treating retention as a GDPR-only topic makes a policy read EU-only, and in 2026 that is no longer where the pressure is coming from.

• ISO 27001:2022 puts it in two controls: A.5.33 on protection of records, which expects retention schedules and protection against loss or unauthorised disclosure, and A.8.10 on deletion of information when it is no longer required. See ISO 27001 asset management for how this fits the wider control set.
• SOC 2 auditors ask for evidence that expiry actually fired - deletion logs, job runs, disposal certificates - not just a policy document with a version number on it.
• US state privacy laws. Twenty comprehensive state privacy laws are in force in 2026, and several push retention into public view rather than leaving it internal. California requires a retention period (or the criteria for determining one) per category in the privacy notice; Minnesota expects a description of the retention policy with a last-updated date; and Illinois BIPA requires a publicly available retention and destruction schedule for biometric data.

The common thread is that retention has stopped being a private internal document. Where a period is published, the published period becomes a promise - and an inaccurate one is a disclosure defect in its own right, independent of whether the underlying data was ever misused.

Who owns the policy and how often it is reviewed

“The business owns it” is how policies die. Split the roles explicitly:

• The controller stays accountable. Handing data to a SaaS provider does not hand over the obligation, so processor contracts must carry matching deletion terms and a way to get data back or destroyed at exit. This is exactly where shadow IT hurts: a tool nobody registered is a retention obligation nobody is meeting.
• Information asset owners approve deletion. Typically the department head for the category, confirming the data genuinely is no longer needed before the job runs.
• IT or the platform team executes. They run the deletion, the mailbox policy, the log rotation, and the device sanitization.
• Legal issues and releases holds, and rules on anything ambiguous.
• Privacy or compliance keeps the schedule aligned with the record of processing, the privacy notice, and any new law.

Review annually as a baseline, and off-cycle whenever a new system, a new jurisdiction, a merger, or a change in law lands. Put the review date on the face of the document - it is the cheapest possible signal that the policy is alive, and some regimes now expect to see it. Clean role separation here is also a straightforward application of segregation of duties: the person who wants the data gone should not be the only person who confirms it went.

What it means for retired devices

The part most policies under-specify is hardware. Every laptop, phone, or server that leaves service is a data-bearing device, and the records on it do not stop being governed by the policy just because the machine is in a cupboard. Worse, a drawer of retired kit is retention without a schedule: nobody knows what is on those drives, so nobody can say whether the period has expired.

A retention policy with teeth says what happens at end of life: which devices must be sanitized before reuse or resale, which must be physically destroyed, how long a retired device may wait before it is dealt with, and what evidence is kept. Setting a maximum dwell time - say, disposed of within 90 days of being marked retired - turns asset decommissioning from an intention into a measurable target. Teams that keep an asset register find this part easy to evidence, because the device, its status, and its disposal proof already live in the same record.

Proving that data and devices were actually disposed of

Deletion you cannot evidence is, for audit purposes, deletion that did not happen. Two vocabularies matter here.

The first is sanitization method. NIST SP 800-88 splits it into three levels: Clear (overwrite using standard read/write commands, suitable for reuse inside the organisation), Purge (cryptographic erase or a firmware-level sanitize, appropriate before a device leaves your control), and Destroy (shred, disintegrate, incinerate - the only option for failed drives that cannot be addressed). Matching the level to the sensitivity and the device’s destination is the whole decision.

The second is the disposal record. A defensible one names:

• the date and time of the sanitization or destruction;
• the device’s serial number and asset tag;
• the method and tool used, and the standard it maps to;
• who performed it and who witnessed or verified it;
• the facility where it happened;
• and an unbroken chain of custody from collection to final disposal.

File that against the asset record rather than in a shared folder, because the auditor’s question is never “show me your certificates” - it is “show me what happened to serial number ABC123”. A certificate of destruction that cannot be tied back to a specific device proves very little. The methods themselves are covered in data sanitization, and the disposal route in ITAD.

Retention events hide in offboarding

The day someone leaves, several retention clocks start at once. Their laptop and phone must come back and be sanitized or reissued. Their mailbox and files enter a defined retention window rather than being deleted on the spot - or, just as often, being kept forever “in case someone needs something”. Their SaaS accounts have to be deprovisioned without orphaning records that other people still rely on. And if that person is under legal hold, none of it can proceed.

Most organisations execute the HR half of offboarding cleanly and forget the data half entirely. The fix is unglamorous: an offboarding checklist tied to the asset register, so equipment return, account deprovisioning, and the mailbox decision are one process with one owner rather than three teams assuming the others handled it. Our guide to employee offboarding and hardware recovery walks through the equipment side in detail.

Data retention policy checklist

Run the policy against this before you call it finished:

• Every category has a retention period, a start trigger, a justification, an owner, and a disposal method.
• Backups, exports, data warehouses, and SaaS copies are explicitly covered, not just the production system.
• Legal holds have a documented placement and release path, and the automated deletion jobs can honour them.
• The schedule matches what your privacy notice tells the public, including any published periods.
• Physical records and retired devices are in scope, with a maximum dwell time before disposal.
• No device leaves without disposal evidence tied to a serial number.
• Deletion is evidenced, not assumed - logs, job records, or certificates you can produce on request.
• The document carries a review date and a named reviewer.

Common mistakes

• Keeping everything forever. Storage is cheap, but old data is pure liability - it can be breached, subpoenaed, or subject to access requests long after it stopped being useful. Over-retention is the single most common finding.
• A policy nobody executes. A schedule that says “delete after the period ends” with no named owner and no recurring task is shelfware - and, unhelpfully, documented shelfware.
• Periods without triggers. “Six years” is not a rule until you say six years from what.
• Forgetting copies. Exports, backups, shared-drive duplicates, analytics warehouses, and the drive in a leaver’s old laptop all outlive the “official” copy unless the policy addresses them.
• Holds that do not reach the hardware. Legal freezes the mailbox; IT wipes and resells the laptop the same week.
• No disposal evidence. When asked to prove a record or device was destroyed, “we are pretty sure it was” is not an answer an auditor accepts.
• A published period you do not meet. Once a retention period is in your privacy notice, missing it is a disclosure problem as well as an operational one.

FAQ

How long should a company keep data? There is no single number. Statute sets the floors - tax, accounting, employment, and sector rules often mandate minimum periods measured in years. Data protection law sets the ceiling for personal data: it may be kept no longer than necessary for the purpose it was collected for. Everything between those two lines is a business judgement, and the retention schedule is where that judgement gets written down, justified, and given an owner. Check the rules in your own jurisdiction before fixing a period.

What is a legal hold, and does it override the retention policy? Yes. A legal hold (also called a litigation hold or preservation notice) suspends scheduled deletion for records relevant to litigation, a regulatory investigation, or a credible expectation of either. It overrides the schedule until Legal releases it, and both the placement and the release should be dated and documented. Holds also reach hardware: a laptop belonging to someone under hold cannot be wiped, resold, or recycled, so the asset record needs a visible flag.

Who is responsible for a data retention policy? Accountability sits with the controller - the organisation that decides why and how data is processed - even when a SaaS provider or other processor physically holds it, which is why processor contracts have to carry matching deletion obligations. Day to day, each category has an information asset owner (usually a department head) who confirms the data really is no longer needed, IT or the platform team executes the deletion, Legal issues and releases holds, and the privacy or compliance function keeps the schedule aligned with the record of processing.

What happens to data when the retention period ends? Three legitimate outcomes: delete it, physically destroy the media it sits on, or anonymise it so irreversibly that it stops being personal data at all. Anonymisation is often the practical answer for analytics and historical reporting, where the aggregate is useful but the identities are not - though pseudonymised data is not anonymised and stays in scope. Whichever route you take, a short review before deletion fires, and a record afterwards that it did, are what make it defensible.

How often should a data retention policy be reviewed? Annually is the common baseline, but the calendar is not the only trigger. Review off-cycle whenever something material changes: a new system or SaaS tool that holds records, a new jurisdiction, a merger or acquisition, a change in law, or a new category of data you did not collect before. Record the review date on the document itself - several privacy regimes now expect a visible last-updated stamp.

What is the difference between a data retention policy and a records retention schedule? The policy states the rules, scope, responsibilities, and the process for exceptions such as legal holds. The schedule is the table underneath it - every category of record with its period, its start trigger, its justification, its disposal method, and its owner. In most organisations the schedule is an appendix to the policy, and it is the part people actually use. A policy without a schedule is a statement of intent; a schedule without a policy has no authority behind it.

What are the risks of keeping data too long? Over-retained data is pure liability. It expands the blast radius of any breach, it is discoverable in litigation, it widens the scope of every subject access request you have to answer, and it costs money to store and back up. There is a compliance angle too: where a privacy notice states a retention period, holding the data longer than the notice says turns an operational lapse into a disclosure defect.

What is the difference between a data retention policy and a backup policy? A backup policy is about keeping copies so data survives an incident; a retention policy is about how long data is allowed to exist at all. The two collide constantly - a retention policy that says “delete after the period ends” is not satisfied if the same records live on indefinitely in backups. Mature policies state explicitly how and when backup copies age out too.

Does GDPR set specific data retention periods? No. GDPR’s storage limitation principle says personal data may be kept no longer than necessary for the purpose it was collected for, but it does not prescribe periods. Organisations set their own, justified by purpose or by other laws - tax, employment, and health rules often mandate minimum periods. The policy is where those justifications are written down and made consistent.

Do retention policies apply to physical equipment? Indirectly, yes. The policy governs the data, but data lives on laptops, phones, and drives, so retiring a device becomes a retention event. A device cannot be resold, recycled, or binned until the data on it has been handled according to policy - usually meaning sanitization or destruction, with a record of who did it and when.

The takeaway

A data retention policy is the document that says how long each type of record may exist, what starts the clock, who owns it, and what happens at expiry - delete, destroy, or anonymise. The prose sets the rules; the schedule underneath it does the work. Get five things right and the rest follows: a trigger next to every period, an owner on every category, backups and SaaS copies inside the scope, a legal hold process that can actually stop a deletion job, and disposal evidence tied to a serial number rather than a hopeful memory. Statute sets your floors, data protection law sets your ceiling for personal data, and everything between is a judgement you should be able to explain in one sentence.

Tools that make this easier

AMPthilly gives the hardware half of a retention policy somewhere to live. Every laptop, phone, or drive gets a record with its serial number, owner, location, and status - in use, in storage, in repair, or retired - so you can see exactly which data-bearing devices are past their retirement date and still sitting in a cupboard. Attach the wipe log or certificate of destruction directly to the asset, and the audit history keeps a per-device trail of every transfer, status change, and document added, so proving what happened to one serial number takes a search rather than an archaeology project. Print a QR label for each item and anyone can open its record from a phone browser - no app to install. Start free - 3 users and 25 assets, no credit card required - or talk to us about a larger rollout.

Related terms

• Asset Management Policy - the wider policy governing the equipment the data lives on
• Acceptable Use Policy - the rules for how staff use the devices and data day to day
• ITAD - the disposal process that executes the policy at hardware end of life
• Data Sanitization - the methods used to make deletion permanent
• Data-Bearing Device - any asset that stores data and therefore falls under the policy
• Certificate of Destruction - the proof that a device’s data was really destroyed
• Chain of Custody - the unbroken handover trail behind that proof
• Information Asset Register - where the categories on your schedule come from
• Audit Trail - the per-record history that evidences the policy was followed
• Asset Decommissioning - the end-of-life process a retention period triggers