The Impact Assessment
Location monitoring of staff will generally require one. What it has to contain, and why the proportionality section is where deployments fail.
General orientation, not legal advice.
An impact assessment for location tracking is not a form-filling exercise. It is where the deployment is either justified or shown not to be.
Why one is needed here
Location data about identified people, processed systematically, on a continuing basis.
Guidance on when an assessment is required lists criteria including systematic monitoring and large-scale processing, and location tracking of a workforce commonly meets both.
Regulators have treated its absence as a breach in its own right, separate from whatever the tracking itself did wrong.
Do it before deployment. An assessment written after the system is live is a justification exercise, and it reads as one.
What it contains
The purpose, specific rather than "fleet management": dispatch, proof of attendance, lone worker safety, mileage.
What is collected, field by field, including sampling interval and what is derived.
The legal basis, with the balancing test written out where it rests on legitimate interests.
Who has access, and when.
Retention, per data category, in days.
The risks to the people tracked, honestly: exposure of home address, of health-related visits, of associations, and the effect of being observed.
The mitigations, and whether they are actually implemented rather than available.
The proportionality section
This is the one that decides it, and the one usually written thinnest.
Name the less intrusive alternatives you considered: geofence events instead of a continuous trail, daily totals instead of routes, position on alarm instead of continuous logging, customer confirmation instead of location at all.
Say why each was rejected, in terms of the purpose rather than convenience.
If the honest answer is "the continuous version came as standard", that is not a reason — and writing it down is what forces the question.
Regulators examining these cases have asked precisely this, and deployments have failed on it repeatedly.
Keeping it alive
Review when the configuration changes, including after a vendor upgrade adds a feature.
Review when the purpose changes, which happens quietly when a new report is requested.
Date it, version it, and keep the old ones.
Record the decision-maker.
The test of whether it is real
Did anything change because of it?
A well-run assessment reduces the collection — a shorter retention, a narrower access rule, a feature turned off.
One that concludes the original plan was perfect has documented a decision rather than examined it, and that is visible to anyone reading it later.
Review it after upgrades
The assessment describes a configuration, and configurations change.
A vendor release that enables a feature makes the document inaccurate.
Which is a compliance consequence nobody notices, because the paperwork sits in a folder.
Tie the review to the post-release check: twenty minutes, same owner, same afternoon.
Version it, date it, keep the old ones, so it can be shown what the system did at any point.
An implementation prompt
During configuration, the connected-work reference can prompt questions about fields, ownership and output. Confirm current capabilities and document each plan, integration or policy assumption.
Independent reference
For an external point of reference, see the Information Commissioner's Office. Consult current regulator material when documenting necessity, alternatives, risk and safeguards.