TL;DR
A data protection policy covers what personal data you hold, why, where it lives, who reaches it, how long you keep it and how it is destroyed. The weakest section in most is disposal, because wiping a database is a different job from recovering the laptop somebody exported a spreadsheet onto.
- Personal data lives on endpoints whatever your systems diagram shows.
- State retention periods, not the principle behind them.
- Name an owner who decides edge cases and answers individuals.
- The device section should match your security policy word for word.
- Evidence means serial numbers tied to sanitisation dates.
- An unrecovered laptop is an open data question, not a hardware loss.
When a short version is enough
Four stages, and the first two do not need a long document.
Employee data only. You hold records about your own people and nothing about customers. A short internal statement covering what you keep and for how long is proportionate.
Best tools for HR Operations
Light customer data. Names and contact details, nothing sensitive. Expand to cover where it lives and who can reach it. Still a page or two.
Meaningful customer data. You hold information people would mind losing. Now the document needs retention periods, access rules and a disposal process with evidence behind it.
Regulated or enterprise. Contracts impose specific obligations and somebody will test them. At this point the policy needs to match reality precisely, because mismatches are found rather than overlooked.
What a data protection policy should contain
- What you hold and why. Categories of personal data and the reason for each. Short, and the foundation for everything after it.
- Where it lives. Approved systems, and honestly, the places it also ends up. Writing only the approved list makes the rest of the policy wrong.
- Who can reach it. Roles rather than individuals, with how access is granted and removed.
- How long you keep it. Actual periods. This is the clause most often challenged and most often vague.
- How it is destroyed. Both in systems and on devices. The second half is usually missing.
- Who owns this. A name, plus how an individual asks a question about their own data.
For the destruction clause, point at a recognised method rather than describing your own. NIST Special Publication 800-88 separates clearing, purging and destroying, and naming which one you apply is far more useful than the word “securely”. Where your organisation also works to ISO/IEC 27001, the asset handling expectations there run alongside this and should not contradict it.
Where the personal data actually sits
Ask where personal data lives and most teams name three systems. Then somebody exports a report to help a customer, and the answer quietly becomes four systems and a laptop.
This is not misbehaviour, it is work. People download attachments, keep spreadsheets, cache files offline before a flight. Any policy premised on data staying inside approved tools is describing an aspiration.
The practical response is not a ban nobody follows. It is to accept endpoints as a location, apply encryption, and make sure the device can be recovered or wiped when the person leaves. That turns an uncontrolled risk into a managed one.
There is a timing point too. The window that matters most is between somebody’s last working day and the moment their device is wiped. During that period the organisation is accountable for personal data it cannot reach, and the length of that window is something you decide rather than something imposed on you. Most teams have never measured it, and the honest number is usually weeks rather than days.
Writing a target into the policy is only worth doing if you intend to measure against it. A clause promising sanitisation within five working days, in an organisation where the real figure is a month, is a claim somebody will eventually check.
It also changes what evidence you need. If endpoints are in scope, then “we deleted the records” is only half an answer. The other half is what happened to the machines, and that is a record about serial numbers and dates rather than about databases.
Five questions to pressure-test it
Where would a customer export actually end up? Trace one honestly through your tools.
What is the retention period for the thing you hold most of? If there is no number, write one.
How long between somebody leaving and their laptop being wiped? The honest average, not the target.
Could you produce destruction evidence for a specific device? By serial number, from a record kept at the time.
Who answers when an individual asks what you hold about them? A name and a route, not a shared inbox.
Where teams get the document, and the trade-offs
A regulator template. Best for structure and for language that matches expectations. It struggles on your specifics, particularly devices, which generic templates treat lightly.
A privacy consultant or lawyer. Best for jurisdictional accuracy and for anything sensitive. They struggle on operations, often writing a correct disposal clause your process cannot actually deliver.
Your HR or compliance platform. Best for distribution and acknowledgement. It struggles on the device half, because those platforms rarely know what hardware exists or where it is.
Writing it internally. Best for accuracy about how data really moves. It struggles on legal completeness, so have it reviewed rather than drafted externally.
Operational vendors for the device clause. Disclosure: RemoAsset is owned by the same people who publish this site. It handles retrieval, wiping, storage and reassignment across 80 or more countries, and produces records tying a device to a sanitisation event. Where it struggles: it is a logistics service, not a privacy adviser, and it is not a certified destruction specialist, so certified physical destruction remains a separate purchase. Its relevance here is narrow and real: whether your disposal clause is evidenced rather than asserted.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Employee data only | Under 30 | No HR function | Nothing external | One page, retention periods stated |
| Light customer data | 30 to 100 | One HR owner | No agreed locations | Map where data actually goes |
| Sensitive customer data | Any | Compliance owner | Disposal unevidenced | Serial-level destruction records |
| Remote team, many endpoints | 50 plus | Small IT team | Data on unrecovered laptops | Encryption plus a working return route |
| Enterprise contracts | 100 plus | Legal involved | Claims get tested | Match the policy to actual practice |
| Several jurisdictions | 100 plus | HR team | Rules differ by market | Core policy plus local annexes |
What the device gap costs
The expensive version is simple to describe. Somebody leaves, keeps a laptop, and that laptop holds exported personal data. Your policy says data is destroyed when no longer needed. It has not been, because the machine is in somebody’s flat.
Whether that becomes a notifiable matter depends on your jurisdiction, the data and the circumstances, and it is a question for advice rather than an article. What is certain is that the decision gets made without facts you would want, because nobody can say what was on the device.
The second cost is contractual. Customer agreements increasingly include deletion obligations with timeframes. An unrecovered device means you cannot confirm compliance, and that surfaces at renewal when somebody reads the clause properly.
The third is cumulative. Each unrecovered machine is a small open question, and thirty of them is a list nobody wants to present to a board or an acquirer.
So the question is not whether your policy covers disposal. It is how many devices are currently outside your control, and whether you could say what personal data was on them.
When the policy needs a working recovery route
A disposal clause is a promise that data stops existing when it should. On endpoints that promise needs two things: knowing which device held what, and being able to reach the device.
Three signals say the promise is currently unsupported. You cannot list devices outstanding from leavers. Nobody produces a sanitisation record per serial. And recovery from another country is treated as an exception rather than a process.
Closing that is less about policy wording than about having one route that works wherever your people are, with the record generated by the work rather than typed up afterwards. That record is simultaneously your evidence and your tracking, which is why doing it properly once answers several questions at the same time.
If the three signals above describe you, rewriting the clause will not help. Seeing how recovery and sanitisation records are produced together addresses the part that is actually missing.
See how device sanitisation evidence is recorded per serial
Read our guide to equipment compliance evidence
Related reading
- Equipment compliance evidence
- Equipment under legal hold
- Putting device policy in the handbook
- What to do about unreturned equipment
- IT asset disposal services
Frequently Asked Questions
What should a data protection policy cover?
What personal data you hold, why, where it lives, who can reach it, how long you keep it and how it is disposed of. The part most policies handle badly is the last one, because disposal of a database is a different operation from disposal of the laptop somebody worked on.
Does personal data really sit on laptops?
Almost always, whatever the architecture diagram says. Exported spreadsheets, email attachments, downloaded reports and cached files accumulate on endpoints. A policy that treats data as living only in approved systems describes an organisation that does not exist.
Is this the same as an information security policy?
Related but not the same. Security is about protecting information generally. Data protection is specifically about personal data and the obligations attached to it. They overlap heavily on devices, which is why the equipment section should say the same thing in both.
What happens when someone leaves with a laptop?
Personal data you are responsible for sits outside your control until the device is recovered or wiped. That is the gap the policy has to address, with a stated timeframe and a named owner. It is also the question a regulator or customer is most likely to ask.
How long should we keep personal data?
Only as long as the purpose requires, and the policy should state the periods rather than gesture at the principle. Where you are unsure, write the period you can defend and review it. A vague retention clause is the one most commonly challenged.
Do we need a named owner?
Yes, regardless of whether a formal role is required in your jurisdiction. Somebody has to decide edge cases and answer questions from individuals about their data. Without a name, requests circulate until somebody improvises, which is how inconsistent answers get given.
What evidence should we be able to produce?
What data you hold and where, who had access, and what happened to devices that held it. The third is the hardest and the one most often missing. Records tying a serial number to a sanitisation date are the usual answer, and they have to be captured as the work happens.
