Location data without permanent surveillance: a privacy-respecting model for field safety

Field safety does not require permanent visibility. A better model uses only the location data needed for a defined decision, for a defined period, and with controlled access.

Published on
September 8, 2026
Field engineer voluntarily checking in before remote work at a water-infrastructure site

Field safety discussions often begin with a false choice. Either an organisation knows where everyone is at all times, or it accepts that it may be unable to find people during an emergency. That framing turns location into a debate between total visibility and operational blindness. It also makes both security and privacy harder to achieve.

A better model begins with purpose. What safety decision must the organisation be able to make? Whose location is genuinely relevant to that decision? When should visibility begin, who should receive it, and when should it stop? Once those questions are answered, location can be used as a controlled operational signal rather than a permanent record of a person’s movements.

This is not simply a European compliance concern. The OECD’s privacy framework sets out internationally recognised principles including collection limitation, purpose specification, use limitation, security safeguards, openness, individual participation, and accountability.1 The ICRC’s guidance for humanitarian action connects personal-data protection directly with life, integrity, and dignity, particularly in volatile environments.2 Together, those principles support a practical conclusion: safety technology is strongest when it collects information deliberately, explains its use clearly, and limits access to people with an operational need.

 

Why is permanent tracking such an unhelpful starting point?

Continuous tracking promises a ready-made map, but it creates a sensitive record before the organisation knows whether each data point serves a safety purpose. A location history may reveal routines and places visited, which increases the consequence of misuse or unauthorised access.3 A device’s position is also not necessarily the position or welfare of its owner.

Regulators therefore focus on necessity, proportionality, and reasonable expectations. The UK Information Commissioner’s Office says employers should be clear about their purpose, use the least intrusive means capable of achieving it, inform workers, and balance organisational interests against workers’ rights and freedoms.3 Its guidance gives a revealing contrast: location monitoring may be reasonably expected in a hazardous mine, but not for an office worker in an ordinary office.3 Context changes what can be justified.

Live location can materially support safety during some remote journeys, lone work, or movement through a rapidly changing risk area. The test is whether the organisation can explain why that visibility is needed for that person, activity, and period, and why a less intrusive option would not meet the purpose.

When that explanation is absent, the system invites function creep. Information gathered for staff safety may later be used to assess attendance, productivity, route choice, or conduct. ICO guidance specifically warns against reusing monitoring information for a new purpose such as performance management without identifying a lawful basis and establishing necessity and proportionality.3 Even where a secondary use might eventually be defensible, silently changing the purpose undermines the conditions on which staff accepted the safety process.

 

What does purpose-led location look like?

Purpose-led design treats location as one of several possible inputs to a response. The organisation first defines the decision. For an office evacuation, the decision may be whether anyone who was expected on site remains unaccounted for. For a remote journey, it may be whether a traveller has failed to reach a planned point and requires contact. During civil unrest, it may be whether staff in a defined area need an instruction, a Check-In, or movement advice. In a medical incident, it may be where assistance should be directed after the individual asks for help.

The data mode can then match the event. Live location may be appropriate for a defined safety-critical activity. Event-led location can begin when an incident, journey, Panic alert, or temporary Overwatch period is activated. Consent-based location may support a voluntary assignment where the individual has a genuine choice and a workable alternative. A Check-In may sometimes provide the necessary welfare information without location at all.

These are not interchangeable legal bases, and “consent-based” is not a universal answer. The ICO states that consent is not usually appropriate for worker monitoring unless the person has genuine choice and control, can withdraw without detriment, and is not disadvantaged for refusing.4 Organisations should identify the applicable lawful or policy basis for each use in every relevant jurisdiction. A product setting cannot supply it.

AtlasNXT can support live, event-led, or consent-based location where appropriate. Its value is not a promise to track everyone. It is the ability to configure a workflow around the organisation’s approved purpose. An alert can request a response without requiring a permanent history. A temporary Overwatch period can support a specific activity. Panic and location-enabled functions can help an individual initiate assistance. The chosen mode should reflect the risk assessment, privacy assessment, local rules, and staff communication.

 

How little data is enough to make the safety decision?

Data minimisation is often described as collecting less. Operationally, it means collecting enough to answer the defined question and resisting information that is merely interesting. For organisations subject to the GDPR, Article 5 requires personal data to be adequate, relevant, and limited to what is necessary for the stated purpose. It also requires purpose limitation, accuracy, storage limitation, security, and transparency.5 OECD guidance expresses comparable principles in a technology-neutral form.1

For location, precision, frequency, duration, and population should all match the decision. A country-level alert does not necessarily require a street-level trail. A remote journey may justify periodic updates during the journey, not tracking on a rest day. A temporary safety watch should end with the activity, and an incident affecting one Remit does not justify revealing unrelated staff elsewhere.

The same discipline applies to history. Retaining every point indefinitely rarely improves today’s response. The organisation should state how long routine location, incident-linked location, Check-In responses, and decision records are retained, because they serve different purposes. An incident record may require a longer organisational history than an uneventful journey trace. Retention should follow the approved policy and applicable obligations, not the storage capacity of the system.

AtlasNXT Remits can define geographic responsibility and authorised views, allowing visibility to be organised around an operator’s role. This supports minimisation, but it does not complete it. The organisation still decides who belongs in a Remit, which roles may see identifiable data, when wider access is justified, and how access is reviewed. Suitable authorised data can be presented only where the required permissions, format, security conditions, and an approved integration or import are in place.

 

Who should be allowed to see location?

The most privacy-respecting data point can still cause harm if it is visible to the wrong person. Access should follow operational need, not seniority or curiosity. A security operator managing a live incident may require identifiable information. A regional leader may need aggregated status and material exceptions rather than every movement. A programme manager may need to know whether a journey has closed safely without seeing the full route. An analyst reviewing readiness may need trends with identifiers removed.

For organisations subject to the GDPR, this distinction reflects data protection by design and by default. Article 25 requires appropriate technical and organisational measures to integrate principles including minimisation into processing.6 Privacy should not depend on every operator remembering to hide unnecessary information during a stressful event. Views, permissions, and retention should start at the least intrusive level that supports the role.

Emergency access needs its own rule. Wider visibility for a defined incident role should be justified, recorded, time-limited, and reviewable. An emergency function must not become a standing route around access controls.

 

What should staff be told before the system is used?

Transparency is not a privacy notice buried in an onboarding pack. People should be able to describe the system in plain language before they are asked to rely on it. They need to know what information may be collected, the safety purpose, the activation conditions, who can see it, how long it remains available, whether it may be shared, and how to question or correct it.

They also need to understand what the system does not prove. A Check-In records a response, a recent location reports device data, and a missed response initiates a procedure. None establishes welfare with certainty.

The ICO warns that uncertainty about whether and why monitoring occurs can damage trust, while clear information helps workers understand and exercise their rights.3 This is particularly important where staff use personal phones or work across home, office, and field settings. ICO guidance cautions organisations not to capture private use of a personal device and notes that privacy expectations are higher at home.7

Training should cover both sides of the workflow. Staff need to understand activation, Check-Ins, safety modes, and the fallback when a device or network fails. Operators need to understand each status, their authorised view, and when to stop or narrow visibility.

 

How should organisations handle low or no cellular coverage?

Privacy-respecting design must survive the field environment. If the only approved workflow assumes continuous cellular data, staff in remote areas may face the worst of both worlds: an intrusive policy and an unreliable safety result.

The better approach maps communication methods to the risk and operating context. The AtlasNXT app can support alerts, Check-Ins, Panic, Overwatch, and location-enabled functions where appropriate. Compatible satellite devices can support selected users beyond cellular coverage, subject to hardware, airtime, configuration, and the organisation’s procedure. This does not create automatic failover or guarantee delivery. It gives the organisation additional channel options for people whose duties justify them.

ReachScore™ can expose gaps in communication readiness and prompt teams to check whether relevant roles have suitable, tested means of contact. It is not a guarantee of reachability or response, and it does not replace a defined procedure for non-response.

A harder-to-reach location can strengthen the safety case for a particular data use, but it does not erase the need for proportionality. The organisation should still collect only what the task requires, explain the mode, restrict access, and stop when the purpose ends.

 

What should a privacy impact assessment test?

A privacy assessment is most useful before procurement or configuration has hardened into an assumed solution. Under UK data-protection law, the ICO describes a data protection impact assessment as a systematic way to analyse processing, identify risks, and reduce them. It requires one for processing likely to create high risk, and recommends the process for major projects involving personal data.8 Within the EU framework, the European Data Protection Supervisor similarly assesses personal-data measures through necessity and proportionality.9

For a field-safety deployment, the assessment should begin with the harm the organisation is trying to prevent. It should test whether location is necessary for that purpose, whether a Check-In or event-led mode would be sufficient, and which groups genuinely require a live view. It should examine home and off-duty exposure, personal-device use, cross-border transfers, third-party access, data accuracy, retention, access during emergencies, the consequences of a breach, and the risk of safety data being used for employment decisions.

The assessment should also test exclusions. Contractors, drivers, visitors, local partners, and temporary personnel may appear in an incident population while sitting outside the usual privacy process. A policy for internationally deployed employees may not translate to a local contractor using a shared device.

Most importantly, the assessment must be able to change the design. It might reduce location precision, restrict a Remit, shorten retention, disable off-duty collection, provide a non-tracking alternative, or require consultation before a pilot proceeds.

 

How can a pilot test safety and privacy together?

A pilot should measure whether the workflow supports the safety decision, not how much data the platform can collect. The scenario might involve a defined journey, a localised security event, or an office accountability exercise. Participants should know the purpose and the test conditions. Operators should work from agreed roles and a clear procedure. The exercise should include ordinary responses, no responses, stale device data, a person outside the expected area, a communications failure, and a request for access from someone without the relevant role.

The review should ask whether the population was accurate, the message was understood, the operator distinguished response from welfare, location appeared only when needed, access remained appropriate, and collection ended as intended. A technically successful pilot can still fail if people experienced it as covert, excessive, or impossible to challenge.

Exercises should recur after material changes because a configuration proportionate for remote teams may be excessive for office staff, while a workflow for organisation-owned devices may capture unintended data on personal phones.

 

What does a mature model look like?

A mature field-safety model does not advertise permanent visibility as reassurance. It can explain each use of location as a chain of decisions. There is a defined risk, a specific purpose, an appropriate data mode, an authorised audience, a stopping condition, a retention rule, and a tested response when the information is absent or ambiguous.

It also keeps welfare at the centre. Location may help identify who could be affected or where requested assistance should go. AtlasNXT can support that wider operating model through proportionate location options, authorised Remits, Check-Ins, the Incident Room, and ReachScore™. None of these functions justifies assuming that a map equals safety.

Privacy and duty of care need not be competing objectives when the system is designed around purpose. The design aim is operational clarity: collect only decision-relevant information, give each role only the view it needs, make event-led activation intelligible to staff, and explain what people are being asked to share and why.

The goal is not to know where everyone is. It is to have the right information, for the right safety decision, at the right time, and to stop collecting it when the need ends.

 

References

1. OECD, “Privacy principles.” https://www.oecd.org/en/topics/privacy-principles.html

2. International Committee of the Red Cross, “Handbook on data protection in humanitarian action.” https://www.icrc.org/en/data-protection-humanitarian-action-handbook

3. UK Information Commissioner’s Office, “Data protection and monitoring workers.” https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/data-protection-and-monitoring-workers/

4. UK Information Commissioner’s Office, “Data protection and monitoring workers,” section on consent and power imbalance. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/data-protection-and-monitoring-workers/?search=example

5. EUR-Lex, “Regulation (EU) 2016/679, Article 5: Principles relating to processing of personal data.” https://eur-lex.europa.eu/eli/reg/2016/679/art_5/oj/eng

6. EUR-Lex, “Regulation (EU) 2016/679, Article 25: Data protection by design and by default.” https://eur-lex.europa.eu/eli/reg/2016/679/art_25/oj/eng

7. UK Information Commissioner’s Office, “Specific data protection considerations for different ways or methods of monitoring workers.” https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/specific-data-protection-considerations-for-different-ways-or-methods-of-monitoring-workers/

8. UK Information Commissioner’s Office, “Data protection impact assessments.” https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-impact-assessments/

9. European Data Protection Supervisor, “The EDPS quick-guide to necessity and proportionality.” https://www.edps.europa.eu/sites/default/files/publication/20-01-28_edps_quickguide_en.pdf