The Least Data That Answers the Question
Most deployments collect a continuous breadcrumb trail because that is the default. What each operational question actually needs.
Location systems collect continuously because that is how they ship. Working out what each purpose requires usually reduces the collection dramatically.
Dispatch
Needs: current position, refreshed often enough to choose the nearest vehicle.
Does not need: history. Once the job is assigned, yesterday's position has no dispatch value.
Design: current position visible, history discarded after a short window, or not stored at all.
Proof of attendance
Needs: a point — this vehicle was at this address at this time.
Does not need: the route taken, the speed, the stops in between.
Design: record arrival and departure at known customer locations. A geofence around the site produces exactly this and nothing else.
This is the single largest reduction available in most field-service deployments, and it answers the billing dispute the continuous trail was collected for.
Lone worker safety
Needs: current position on demand, plus an alarm the worker can raise.
Does not need: a stored history of where they have been.
Design: position available when an alarm is raised or a check-in is missed, not continuously logged. Several safety products work this way and it is worth asking for.
Mileage and cost
Needs: distance and duration, per journey or per day.
Does not need: the route.
Design: aggregate at the device and transmit totals. A vehicle reporting "94 km, 3 hours 20 minutes" answers the expense and utilisation question completely.
Route optimisation
Needs: historical journeys in aggregate, to find patterns.
Does not need: attribution to individuals.
Design: strip the driver identifier before analysis. Route patterns are a property of the round, not of the person driving it.
The exercise worth doing
List your purposes. For each, write what data it needs.
Compare against what the system currently collects.
The gap is what you are holding without a reason, and it is usually most of it.
Then turn the collection down rather than adding an access policy on top of it, because data that does not exist cannot be misused, requested, breached or subpoenaed.
Turn it down rather than layering policy
The choice between two approaches that look similar.
Collect everything and restrict access — which leaves the data existing, requestable, breachable and available to whoever gets an exception.
Collect less — which removes all of that permanently.
Data that does not exist cannot be misused, disclosed, subpoenaed or leaked.
An access policy is a promise; a configuration is a fact, and regulators examining these deployments have consistently looked at the second.
An implementation prompt
During configuration, the available feature overview 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 ICO resources. The regulator's data-minimisation guidance is an appropriate external check on each proposed field and retention period.