The Data a Safety System Holds

General orientation, not legal advice.

When the data a safety system holds also depends on reliable work records, the product website can support time, attendance and workload review without being treated as the emergency response itself. Compare any workflow with ICO employment guidance and keep alarm ownership, escalation and dispatch responsibilities explicit.

A lone worker system holds some of the most sensitive data an employer touches, and it does so for a purpose everybody agrees with.

What it holds

Position, during working time and sometimes beyond.

Audio, where that is enabled.

Health information, where a worker has disclosed a condition relevant to their safety.

Next of kin details.

And information about clients and their homes: addresses, access, behaviour, animals — which is personal data about people who are not employees and never agreed to anything.

That last category is routinely overlooked.

The design that minimises it

Position on alarm, not continuously.

Schedule instead of tracking, which answers the same question with far less.

Audio on activation only, never ambient.

Health information held with consent, accessible to responders at the moment of an alarm rather than browsable.

And risk flags about clients written as actions — "two workers required" — rather than as narrative about the person.

Why continuous tracking is hard to justify here

The purpose is finding someone who needs help.

A schedule plus a position obtained when an alarm fires serves that purpose.

Continuous position serves it marginally better and collects a complete record of a worker's day, including where they stopped for lunch and how long they took.

Which is the balancing test, and it usually comes out against continuous collection unless there is a specific reason the schedule cannot work.

Client information

Risk flags are personal data about the client.

They need a basis, accuracy, and a route for the client to know what is held — which in care and housing is an established process and in contracted services frequently is not.

Write flags you would be content to read aloud to the person, which is both a legal discipline and a practical one: a narrative flag about someone's character is unusable as an instruction anyway.

Retention

Alarm records and incident data: long enough for investigation and any claim.

Routine position and check-in data: days.

Audio: days, with an incident hold.

Client risk flags: reviewed rather than accumulated, because a flag from four years ago about a person whose circumstances changed is both wrong and harmful.

Telling people

Workers: what is collected, when, who sees it, how long it is kept, and specifically whether they are tracked when not in an alarm state.

That last question is the one they have, and a clear answer is what makes them carry the device.

Clients: that the service holds safety information about visits, in the normal privacy information rather than as a special disclosure.

Access control in practice

Who can see live position, and when?

In a well-designed system: nobody, until an alarm is raised.

Which is a configuration rather than a policy, and it is worth confirming rather than assuming because the default in several products is a live map available to any manager.

Log every access to historical data, and review the log, which is how a manager checking up on somebody is detected.

Subject access

Workers can generally request what is held about them, which here includes positions, check-ins, alarms and any audio.

Which means it must be retrievable per person and free of anything you would rather they did not read.

Rehearse it once on a volunteer. The exercise usually finds data in places nobody remembered and a free-text note somebody would not want to defend.

And a short retention makes the whole request small, which is a practical argument for the design this collection recommends.

The client's rights

People visited at home have rights over the information held about them, including risk flags.

Which means flags must be accurate, relevant and reviewed, and a client is generally entitled to know what is recorded.

Write them accordingly: a flag saying "two workers required following incident on this date" is defensible and useful. One characterising somebody's personality is neither.

And have a route for a client to query a flag, which is uncomfortable and is the correct position.

Audio, specifically

Recording in a private home engages obligations toward everyone present, not just the worker.

Activation-only, with a stated retention in days, and deletion verified.

Notice is difficult here — you cannot realistically warn every household — which is itself an argument for activation-only, since a system that records only during an emergency is far easier to justify than one that could record at any time.

The assessment

A data protection impact assessment is likely required for systematic monitoring of workers' locations.

Its most useful section is the alternatives: what less intrusive arrangement was considered, and why it was insufficient.

"Schedule plus position on alarm" is the alternative to name, and an organisation that considered and rejected it should be able to say why.

Retention in practice

Automated, verified, and including the supplier's copies.

Test it: ask for something older than the stated period and confirm it is gone rather than hidden from a report.

And remember the exports — a position history downloaded into a spreadsheet for an investigation sits outside every control you have configured.