TL;DR
A data retention policy normally schedules systems you administer and says nothing about the laptops those systems were read on. That is where the uncontrolled copies live, and the gap only becomes visible when somebody leaves.
- Devices are a retention location. Most schedules never name them.
- Deleting is not sanitising. Only one of them is defensible later.
- A schedule with no named executor is a document, not a control.
- The retention policy and the offboarding process have to agree.
- Map what you hold before arguing about how long to keep it.
- Review the device clause first. It ages fastest.
When a short version is enough
Four stages, and only the last two need detail.
A few systems, one country. Your tool list fits on one hand and you could describe what you hold from memory. A one-page schedule is proportionate.
Best tools for HR Operations
Tools multiplying. New systems arrive without anybody cataloguing them, and the honest answer to “where is that data” has become “probably several places”. The policy now has a job.
Regular departures, remote staff. Every exit leaves a device holding copies. This is where the server-shaped policy starts to mislead you about your own position.
Regulated, certified or responding to requests. Somebody will ask what you hold about a named person and where. Now the schedule has to be true rather than tidy.
Why a data retention policy stops at the server
Retention schedules are written by people thinking about records, and records live in systems. The HRIS, the finance system, the shared drive, the mailbox. Each has an administrator, a defined scope and a delete button, so each can carry a period and an owner.
A laptop has none of that. It holds whatever its user downloaded, in no particular order, with no inventory and no administrator who could tell you what is on it. Scheduling something you cannot enumerate feels impossible, so the clause gets dropped rather than written badly.
And there is a timing problem. Server retention runs on a clock: a period elapses, something is deleted. Device retention runs on an event, which is somebody leaving or swapping machines, and events are easier to miss than calendars.
The frameworks assume you close the loop. The privacy information management extension in ISO/IEC 27701 treats disposal as part of the same lifecycle as collection, and media sanitisation guidance in NIST SP 800-88 exists precisely because deleting a file is not the same as removing it. A schedule that covers systems and skips devices satisfies the paperwork and not the intent.
The five clauses that close it
- Devices as a named location. List laptops, phones and removable media alongside your systems, so they appear in the schedule rather than between its lines.
- The event, not the clock. State that device data is handled at return, reissue or disposal, and name who starts that.
- Method and verification. Which sanitisation method applies, and the check that confirms it worked. A method with no verification step is a claim.
- Evidence and where it lives. The certificate or record attached to the asset, with a named owner, not an inbox.
- The failure case. What happens when a device cannot be recovered, because that case is common and most policies pretend it is not.
Five short paragraphs. The last one is the one teams resist writing and the one an assessor will ask about first.
Five questions before you draft
Can you list every system holding personal data? If not, the schedule covers less than it claims, and that is the first finding.
What is on a typical laptop in your company? Ask one person to look. The answer usually surprises whoever wrote the policy.
Who executes a deletion when a period ends? A name, or it does not happen.
What did you do with last year’s returned devices? If you cannot show it, the device clause is already unevidenced.
What happens when a laptop never comes back? Write that answer down, because it is the real one.
How teams handle the device copy
Trust the cloud and ignore local files. Best for simplicity, and defensible in a strictly browser-based company. It struggles the moment anybody downloads an export, which is most roles in most companies.
Policy plus user responsibility. Best for cost. It struggles because compliance is unverifiable and depends on people deleting things they have no reason to notice.
Remote wipe through device management. Best for speed and for lost devices. It struggles when a machine is never switched on again, which is exactly the case you most want covered.
Collect and sanitise on return. Best for evidence, since the device is in hand and the method is verifiable. It struggles entirely on logistics, because it only works if the device actually arrives.
A lifecycle service that recovers and wipes. Disclosure: RemoAsset is owned by the same people who publish this site. It handles retrieval, storage and certified wiping across 80 or more countries, which matters to this policy because the device clause is unenforceable where collection is not possible. Where it struggles: it will not tell you what retention period applies, map your systems or decide your legal basis, which are the substance of the policy. The narrow part it covers is whether the device is recovered and sanitised with a record.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Few systems, one country | Under 20 | No owner | Nothing written | A one page schedule |
| Tool sprawl | 20 to 100 | Part time owner | No data map | Map first, schedule second |
| Remote staff, regular exits | 50 plus | HR owner | Device copies unscheduled | Name devices as a location |
| Cloud only, in theory | Any | Any | Downloads nobody counts | Check one real laptop |
| Facing a data request | Any | Legal owner | Schedule is not true | Fix accuracy before wording |
| Devices rarely recovered | Any | Any | Clause unenforceable | Fix collection, then the policy |
What the gap costs
The first cost is a claim you cannot support. Telling somebody their data was deleted, when a copy sat on a laptop you never recovered, is not a lie anybody intended. It is still wrong, and the person who said it had no way to know.
The second is the request you cannot answer. Asked what you hold about a named individual, a team with a server-shaped schedule answers for systems and guesses about devices. The guess is the part that gets examined.
The third is retention drift in the other direction. Devices in a cupboard hold data long past any period anybody set, because no schedule applies to a machine that is simply sitting there. That pile grows quietly and belongs to nobody.
The fourth is the mismatch between two documents you both wrote. Your offboarding process says equipment is returned. Your retention policy says data is removed on a timetable. Neither mentions what happens when the first one fails, which is the case that actually occurs.
So the test is not whether you have a retention schedule. It is whether you could say, for last year’s leavers, where their data is now.
When the schedule needs a recovery route
The device clause is the only part of a retention policy that depends on physical logistics. That makes it the part most likely to be correct on paper and absent in practice.
Three signals say the route is the weak link. You cannot list which devices are currently with former staff. Collections from outside your main market stalled or never finished. And you have no wipe record for a meaningful share of last year’s departures.
Rewriting the clause touches none of those. What closes them is an accurate record of who holds what and one collection route that works wherever you employ people, because sanitisation is only available once the hardware is in hand.
It is cheap to check and worth doing before the next review. Seeing how recovery and certified wiping run as one recorded process tells you whether the problem is your wording or your logistics.
See how device data handling is evidenced
Read our guide to the data protection policy
Related reading
- The data protection policy
- Writing an offboarding policy
- Evidencing equipment compliance
- The information security policy
- Equipment under legal hold
Frequently Asked Questions
What should a data retention policy contain?
A list of data categories, how long each is kept, the reason for that period, and who deletes it when the period ends. Most policies do the first three. The fourth is where they stop being documents and start being controls, because a schedule nobody executes is not retention.
Do laptops count as a retention location?
Yes, and they are the location most often missed. Local copies of documents, cached mail, downloaded exports and browser data all sit outside whatever your server schedule covers. A policy that deletes the master record while a copy survives on a device has not retained or deleted anything cleanly.
How long should we keep employee data?
Periods differ by jurisdiction, by data category and by the legal basis you relied on, so take local advice rather than adopting a number from a template. What you can do without advice is write down what you hold and where, because no retention period can be applied to data nobody has mapped.
What happens to a leaver’s device?
It should be recovered and sanitised to a stated method, with the evidence attached to the asset record. Until that happens the device is an unscheduled copy of whatever that person worked on. This is the point where the retention policy and the offboarding process have to agree, and often do not.
Is deleting the same as wiping?
No. Deleting removes the pointer and leaves the data recoverable, which is fine inside a managed system you still control and inadequate for a device leaving your possession. Sanitisation to a recognised method with a verification step is what gives you something defensible to show later.
Who should own the policy?
One named role, usually in legal or operations, accountable for whether the schedule is executed rather than merely published. Shared ownership reliably produces a document that is reviewed annually and applied never, which is the most common failure mode in this whole area.
How often should it be reviewed?
Annually, and whenever you add a system that holds personal data. Most policies age badly because the tool list underneath them changes faster than the document does. Check the device clause first, since it is the one most likely to have been written once and never revisited.
