Holding the Line on What It Is For
Location data collected for dispatch will be requested for other things. What to decide in advance, and what happens the first time it is tested.
Every deployment in this field faces a request to use the data for something it was not collected for, usually within the first year.
The requests that arrive
"Was he really at that address on Tuesday?"
"Can we see who takes the longest breaks?"
"Show me her movements for the last month."
"Can we compare the team on time-on-site?"
"The police have asked for a driver's location history."
Each has a plausible framing, and each is a different purpose from the one in the impact assessment.
Why drift is expensive here
The legal basis was documented for a specific purpose. Using the data for another may have no basis at all, which is a breach rather than a policy lapse.
The workforce finds out. In a field operation, one use for discipline is known across the depot within a week.
And the operational data degrades: drivers start leaving phones in vehicles, taking routes that look better, reporting things differently.
The purpose limitation is therefore not only an obligation. It is what keeps the deployment working.
Writing it
What the data is for, listed: dispatch, proof of attendance, safety, mileage.
What it is not for, listed explicitly: individual performance assessment, comparison between workers, disciplinary matters absent a specific authorised investigation, checking on people out of curiosity.
Who may access individual history, by role.
What triggers an exception, and who authorises it.
Published to everyone, not filed with the policy set.
The legitimate exceptions
Some are real, and a policy admitting none becomes unusable.
A specific investigation into a specific allegation: authorised, scoped to a period, logged, with the person informed unless there is a stated reason not to.
A safety incident or collision.
A lawful request from authorities, which should go through a named person who checks that it is lawful rather than merely official.
In each: narrow scope, named authoriser, recorded reason, access logged, and the access removed afterwards.
The first hard case
It will come, usually from a manager with a genuine concern.
Decide in advance who decides, because deciding under pressure produces the wrong answer and sets the precedent.
If the answer is yes, everyone learns what the system is for within a week.
If the answer is no, and the reason is given publicly, the limitation becomes credible in a way no document achieves.
Detecting drift
Audit access to individual history quarterly against the stated purposes.
Look for browsing, and for derived reports ranking individuals, which appear in spreadsheets rather than in the system.
Report the result, including a clean one.
Decide who decides
Before the first request arrives.
Name the person or forum that rules on exceptions.
Name what evidence an exception requires.
Agree it with whoever owns risk.
Publish it, so a requester meets a process rather than one person's judgement.
The first decision becomes the precedent whether or not anyone intended it to.
A concrete product reference
When translating this principle into a buying test, this workflow reference provides a concrete workflow reference. Verify the current behaviour in a trial and judge it against the purpose and limits described above.