Securing the Location Data
A database of where your staff are, live, is attractive to people other than you. What a breach here means and what it needs.
Location data has a property that makes a breach worse than most: it tells someone where a named person is now.
Why this data is different
It shows current position, which enables physical harm in a way a leaked email address does not.
It shows home addresses, derived from where vehicles park overnight.
It shows patterns: when a house is empty, when a high-value vehicle is unattended.
And it shows customers' addresses, which is a disclosure about them as well.
A breach here is not only a compliance event. It is a safety matter for the people in the records.
Who wants it
Vehicle and cargo thieves, for whom a live fleet map is precisely the tool.
Anyone stalking an employee, which includes domestic abuse cases and is the scenario that should shape access design.
Competitors, for customer lists derived from visit patterns.
Which makes access control a security question, not only a privacy one.
The controls that matter most
Multi-factor authentication on every account with map access. This is the single highest-return control here and it is frequently absent.
No shared logins, which are common in dispatch offices and which make the access log meaningless.
Session timeouts, because a logged-in map on an unattended screen is the commonest real-world exposure.
Prompt removal on departure, including for the vendor's support accounts.
Read logging, which is both a privacy control and the way a misuse is detected.
The vendor's side
Where is it processed and stored?
Who at the vendor can see customer data, and is that access logged?
What is their breach notification commitment, in hours?
Have they had a breach, and what happened? Ask directly.
Get the answers in the contract, because this data is theirs to lose as much as yours.
The domestic abuse case
Worth naming explicitly because it is the one that causes real harm.
An abusive partner who works at the same employer, or who can influence someone who does, can find a person through this system.
Which is an argument for: read logging, restricted access, no shared accounts, and a route for an employee to raise a concern about who can see their data.
And for a documented procedure to restrict access to a particular person's records where there is a safety concern. Most organisations have never considered this and it takes an afternoon to arrange.
What to check
Is MFA enforced?
Are there shared accounts?
When was access last reviewed?
Are reads logged and looked at?
Could an employee ask for their records to be restricted, and does anyone know how to do it?
The restriction procedure
An afternoon of preparation for a situation that is rare and serious.
A documented way to restrict access to one person's records where there is a safety concern.
Who authorises it, who implements it, and how quickly.
Because the person who needs it will be asking under pressure, and "we've never done that" is the wrong answer at that moment.
Most organisations have never considered this, and it is the most consequential gap in this section.
Check the difficult case
Use the scheduling example to frame one representative test for this issue. The useful evidence is the record created when a worker challenges an event, a manager reviews it and an administrator exports it.
Independent reference
For an external point of reference, see NCSC guidance. Use the official cyber-security source when reviewing authentication, devices, suppliers and incident response.