Policy template · ISO 27001
Data retention policy template
The policy that turns "no longer than necessary" into dates you can defend. A ready-to-edit Word template with a retention schedule of UK statutory periods, written for UK GDPR's storage limitation principle and ISO 27001 A.5.33, for a UK firm of 25 to 250 people.
Key takeaways
A data retention policy sets how long an organisation keeps each kind of record, and what happens when that time is up. UK GDPR Article 5(1)(e) requires personal data to be kept no longer than necessary, and ISO 27001 A.5.33 requires records to be protected. This template gives UK firms of 25 to 250 staff a policy and retention schedule.
- Required by
- UK GDPR Article 5(1)(e) storage limitation; ISO 27001:2022 control A.5.33
- Approved by
- Top management, with a named owner for each category of record
- Review cycle
- At least annually, and when systems, suppliers or the law change
- Format
- Word, about 11 pages, with a retention schedule
What's in the template
One Word document, about 11 pages, version 1.0. It has four parts:
- The data retention policy. The rules: purpose and scope, who owns retention, how a retention period is set and justified, how records are protected while you keep them, legal holds, how deletion and disposal happen (including backups and suppliers), how erasure requests fit with the schedule, and how the policy is monitored and reviewed.
- A retention schedule. A table with one row per category of record: its owner, where it's held, the retention period, what starts the clock, the reason, and how it's disposed of. It comes with example rows for UK company, tax and employment records, each with its legal source, so you check each one applies to you rather than starting from nothing.
- A getting-started guide. It shows how to build the schedule from your record of processing, which rows to check with your accountant or adviser, and what to cut at your size.
- Next steps and a policy management checklist. They cover approval, the first deletion review, supplier deletion confirmations and review dates: the records an auditor asks to see alongside the policy.
The appendices also hold a deletion and disposal log, so you can show that deletion happens and not just that it's planned, and a short glossary. Every placeholder is in square brackets, so you replace names, systems and periods rather than writing from a blank page.
What is a data retention policy?
A data retention policy is the document that sets how long your organisation keeps each kind of record, and what happens when that time is up. It has two halves. The policy states the rules and who is responsible for them. The retention schedule lists each category of record and its period. Keep them apart: the rules rarely change, but the schedule changes every time you add a system, a supplier or a new type of data.
A data retention policy matters because UK GDPR's storage limitation principle, in Article 5(1)(e), says personal data must be kept in a form that identifies people "for no longer than is necessary for the purposes for which the personal data are processed". The law doesn't say what "necessary" means for your data. You decide, and the accountability principle in Article 5(2) means you must be able to show why.
Keeping everything isn't the cautious option. It's an unmanaged liability with your clients' names in it.
Which laws and standards ask for one
| Source | What it asks for |
|---|---|
| UK GDPR, Article 5(1)(e) | Storage limitation: personal data kept in a form that identifies people for no longer than necessary for the purposes it's processed for. Longer storage is allowed only for archiving in the public interest, research or statistics, under the safeguards in Article 84B. |
| UK GDPR, Article 5(2) | Accountability: the controller is responsible for, and must be able to demonstrate, compliance with the principles, including storage limitation. |
| UK GDPR, Articles 13(2)(a) and 30(1)(f) | Privacy notices must say how long personal data will be stored, or the criteria used to decide. The record of processing should include, where possible, the envisaged time limits for erasure of each category of data. |
| ISO 27001:2022, control A.5.33 | Records must be protected from loss, destruction, falsification, unauthorised access and unauthorised release. In practice, a retention schedule is how firms show which records they keep, and for how long. |
| ISO 27001:2022, control A.8.10 | Information held in systems, devices and other storage media must be deleted when it's no longer required. |
| The ICO's storage limitation guidance | Expects a policy setting standard retention periods wherever possible, and confirms UK GDPR sets no specific time limits: you set and justify your own, then review, and erase or anonymise what you no longer need. |
For the ISO 27001 detail, see the A.5.33 guide on protecting records and the A.8.10 guide on deletion.
Since 30 September 2026 the regulator is legally the Information Commission; it is still known as the ICO.
The policy, the schedule and your data protection policy
A data retention policy sits beneath your data protection policy. The data protection policy commits you to the storage limitation principle. The retention policy and its schedule show how you meet it: which records, how long, why, and who deletes them. GRCMANA's data protection policy template is written as its companion, and the two use the same roles and review cycle.
The schedule is the part people read most. Staff use it to answer "can I delete this?", auditors sample it against your systems, and your privacy notices quote from it. That's why it's a separate, living table and not a paragraph buried in the policy.
Example UK retention periods
Some records have a minimum period set by law. The periods below apply to a typical UK limited company, and each was checked against official government guidance or the published legislation in October 2026. Check each one applies to your firm, and that it hasn't changed, before you rely on it.
| Record | Minimum period | The clock starts | Source |
|---|---|---|---|
| Accounting records (Companies Act) | 3 years for a private company, 6 years for a public company | The date the record is made | Companies Act 2006, section 388(4) |
| Company records for Corporation Tax | 6 years, or longer in some cases, such as a late return or an open compliance check | The end of the last company financial year they relate to | HMRC guidance on company and accounting records |
| VAT records | Generally at least 6 years | Agree the start point with your accountant | HMRC VAT Notice 700/21 |
| PAYE payroll records | 3 years | The end of the tax year they relate to | HMRC guidance on keeping PAYE records |
| Minutes of directors' meetings | At least 10 years | The date of the meeting | Companies Act 2006, section 248(2) |
| Working time records | 2 years | The date they were made | Working Time Regulations 1998, regulation 9 |
| Right to work check copies | For the whole employment, and 2 years after | The end of employment | Home Office right to work guidance |
| Customer due diligence records (only firms within the Money Laundering Regulations) | 5 years, then delete the personal data unless an exception applies | The end of the business relationship, or completion of an occasional transaction | Money Laundering Regulations 2017, regulation 40 |
| Contracts and client engagement records | No statutory retention period. Many firms keep them for 6 years after the contract ends, because a claim on a simple contract can be brought up to 6 years after the cause of action | Usually the end of the contract | Limitation Act 1980, section 5 (a time limit for claims, not a retention rule) |
| Unsuccessful candidates, CCTV, marketing contacts, client project files | No statutory period. Set one you can justify, and write the reason down | Your choice, stated in the schedule | UK GDPR Article 5(1)(e) |
Two things stand out. First, where two rules cover the same record, the longer one wins: a private company's accounting records need 3 years under the Companies Act, but HMRC expects 6 for Corporation Tax. Second, most personal data has no statutory period at all. That's where the schedule needs your judgement and a written reason. If you're FCA-regulated or work under sector rules, they may set longer periods for some records, so check them with your compliance adviser.
How to create your data retention policy with this template
If you already have a record of processing, this takes about a day: half for the policy and half for the schedule, plus one management meeting. If you don't, list what records you hold first, because the schedule is built from that list.
Before you start
A retention schedule can only cover records you know you hold. Check you have:
- A list of what you hold. Your record of processing, or an information asset register, showing the personal data and business records in each system. No list yet? Run a short data-mapping exercise first; the A.5.34 guide shows what to capture.
- Your data protection policy. The retention policy delivers its storage limitation commitment, so the two should share owners and language. No data protection policy yet? Write it alongside this one, and if you have no top-level policy either, start with the information security policy template.
- Owners who can press delete. For each main system, someone who knows what's in it and can delete or set retention rules. If no one can, the schedule will stay a document and never become a practice. No owner for a system yet? Give the job to whoever administers it, often your IT lead or IT provider, and name them in step 1.
- Your contracts and your adviser. Client contracts often set their own retention or return-and-delete terms, and some tax periods depend on your circumstances. Have the main contracts to hand, and a route to your accountant for the tax rows. No adviser yet? Leave those rows marked "check with your accountant" and don't delete anything under them until someone has.
If none of these exist yet, the job is bigger than one document. That's the point where most firms bring in help.
1. Set the scope and name the owners (about an hour)
- Do this: decide which records the policy covers: personal data at minimum, and ideally all business records, paper and electronic. Name the policy owner, the approver and an owner for each category of record.
- The template: has scope and roles sections with placeholders for entities, systems and record category owners.
- Watch for: a scope that only covers the systems IT knows about. Shared drives, mailboxes, messaging tools, backups and a supplier's CRM all hold records too.
2. Build the schedule from your record of processing (about half a day)
Next, turn each processing activity in your record of processing into one or more schedule rows: the category, its owner, where it lives, the period, what starts the clock, the reason, and how it's disposed of. Start with the template's example statutory rows, keep the ones that apply, then add your own. The trigger matters as much as the period: "6 years" means nothing until you say 6 years from what.
3. Decide what happens at the end (1 to 2 hours)
- Do this: for each category, decide whether records are deleted, anonymised or archived, how and by whom. Set how long backups run before they expire, and how a legal hold stops deletion when a dispute or investigation is likely.
- The template: has deletion and disposal and legal hold sections, and an appendix log for recording what was deleted, when and by whom.
- Watch for: backups, retired equipment and suppliers. Data deleted from the live system often survives in backups, on old laptops and in a supplier's systems after the contract ends. The A.8.10 guide covers deletion, and the A.7.14 guide covers wiping and disposing of equipment.
4. Line up your notices, records and contracts (about an hour)
Then make sure the rest of your documentation tells the same story. Article 13(2)(a) requires your privacy notices to tell people how long you keep their data, or the criteria you use to decide. Article 30(1)(f) expects your record of processing to include, where possible, the time limits for erasure. If a privacy notice says six years and the schedule says two, one of them is wrong. Check your supplier contracts too: under Article 28(3)(g), a processor must delete or return your personal data at the end of the service, at your choice, unless the law requires it to keep a copy.
5. Approve, run the first deletion review, and keep the log (one management meeting, then half a day)
- Do this: take the policy and schedule to top management for approval, and set a review date no more than a year out. Share them with everyone who creates or deletes records. Then run the first deletion review straight away, not in twelve months.
- The template: includes a policy management checklist and a deletion and disposal log for the approval, review and deletion records.
- Watch for: a policy that's approved and never run. The first review is where you find the records nobody wants to delete. What to keep as evidence is covered in How to use it so it holds up at audit.
Do it yourself, or have us do it with you
| Do it yourself with the template | Do it with GRCMANA | |
|---|---|---|
| What you end up with | An approved data retention policy and a completed retention schedule | The policy and schedule, built from a mapped record of processing, consistent with your privacy notices, data protection policy and client contracts, with retention rules set in your main systems. Ongoing support from a virtual DPO if you want it |
| Your time | About a day, if you have a record of processing. Considerably more if you don't | Depends on how much of the groundwork exists. We agree it with you at the start |
| Best if | You know what data you hold and where, and someone on your team is comfortable making the judgement calls above | Data protection landed on you alongside your day job, you hold years of data no one has reviewed, a client is asking for evidence, or you're not sure which rules apply to you |
Prefer the second column? Talk to us about a virtual DPO.
What good looks like
Most retention policies say data is kept "no longer than necessary". Fewer say how long that is, from when, and who deletes it. Here is the difference.
Weak and strong, side by side
| Section | Weak | Strong | Why the strong one works |
|---|---|---|---|
| Scope | "This policy applies to personal data." | "This policy applies to all records [entity] creates or receives, in any format, including email, shared drives, backups and records suppliers hold for us." | It covers the places records actually live, which an auditor can sample. |
| Retention period | "Client records are kept for seven years." | "Client contracts and engagement records: 6 years from the end of the engagement, to cover the limitation period for contract claims. Owner: [Head of Operations]." | It has a trigger, a reason and an owner. |
| Deletion | "Data is deleted when no longer needed." | "[IT lead] runs a deletion review each [quarter] against the schedule and records each deletion in the deletion log. Backups expire after [35] days." | A log and a backup cycle can be tested. A promise can't. |
| Legal holds | "Records may be kept if required." | "When [COO] issues a legal hold, deletion of the named records stops until the hold is lifted in writing." | It says who can stop deletion, and how it restarts. |
| Suppliers | "Our suppliers comply with GDPR." | "At contract end, processors delete or return our data and confirm deletion in writing. [Owner] files the confirmation." | It produces evidence that deletion reached the supplier. |
What an auditor checks in the first five minutes
Before reading the detail, most auditors and client privacy reviewers check that:
- It's current and approved. It has a version, an approval by top management and a review date that hasn't passed.
- Every row has a reason. Each period in the schedule names its source: a law, a rule, a contract or a business need.
- The schedule matches the systems. They pick a system and look for records older than their period.
- Deletion is evidenced. The deletion log has entries, and they're recent.
- The notices agree. The periods in your privacy notices match the schedule.
- Backups and suppliers are covered. The policy says how long backups run and how supplier deletion is confirmed.
If all six hold, the reviewer moves on with confidence. If one fails, they usually look harder at everything else.
What good looks like at 25 staff and at 250
| Feature | Around 25 staff | Around 250 staff |
|---|---|---|
| Schedule | 15 to 30 rows in a single table | 50 or more rows, grouped by department, with system-level detail |
| Owner | A director, alongside their main role | A data protection or records lead, with an owner in each department |
| Enforcement | Calendar reminders and a manual deletion review | Automatic retention rules in the main platforms, with manual reviews for the rest |
| Deletion evidence | A simple deletion log | System audit logs, plus the deletion log for manual deletions |
| Legal holds | Decided case by case by a director | A written procedure, with holds issued by legal or compliance |
| Review | Annually | Annually, and whenever a new system or supplier is added |
The common mistake at 25 staff is keeping everything because deleting feels risky, until a breach or a subject access request shows how much there is. The common mistake at 250 is a tidy schedule in a spreadsheet while dozens of systems each keep data their own way.
How to use it so it holds up at audit
The policy is only half the evidence. An auditor, a client or the ICO tests whether deletion actually happens, and these are the records they usually ask for:
- The approval record: who in top management approved this version, and when.
- The schedule: current, with an owner, a trigger and a reason for every row.
- The deletion log: what was deleted or anonymised, when, by whom and under which schedule row.
- Supplier confirmations: written confirmation that processors deleted or returned your data when a contract ended.
- The review history: the date of the last review, what changed, and the next review date.
The most common reasons a data retention policy fails audit:
- Its periods have no stated reason, or were copied from another firm's schedule.
- The policy says delete, but the systems still hold records years older than the schedule allows.
- Backups, archives and old equipment aren't covered.
- Privacy notices give different periods from the schedule.
- No one can show that any deletion has ever happened.
Each of these is cheap to fix before an audit and expensive to explain after a breach.
Data retention policy questions
Its scope, who owns retention, how retention periods are set and justified, how records are protected while you keep them, how legal holds work, and how deletion, anonymisation and disposal happen, including backups and suppliers. The retention schedule, listing each category of record with its period, trigger and reason, sits alongside it.
For no longer than you need it for the purposes you collected it for. UK GDPR sets no fixed periods, so you decide and justify them. Some records, such as accounting, tax and payroll records, have minimum periods set by other laws, and those set the floor for that data.
The policy sets the rules: who is responsible, how periods are decided and how deletion happens. The schedule is the table that lists each category of record with its retention period, trigger, reason and disposal method. The policy changes rarely, and the schedule changes whenever your systems or data change.
You should delete it, or anonymise it so it no longer identifies anyone, unless there's a clear reason to keep it, such as a legal hold or a longer period required by another law. Record what you did in a deletion log.
At least once a year, and whenever you add a system, a supplier or a new type of data, or the law changes. Review the schedule's periods at the same time, and keep a record of each review, even when nothing changes.
Get the template
Start from a policy and schedule that already follow UK GDPR's storage limitation principle, with example UK statutory periods and their sources built in, written for a firm your size. Download the Word template, put your records and owners in, and take it to your next management meeting for approval.
This template is a starting point to adapt to your organisation, not legal advice. Statutory periods change, so check each one against its source before you rely on it.
