At 07:20 local time in Paris, a demonstration outside a hotel in the central business district turned into something the overnight risk briefing had not predicted. By 08:00, the security team in London had opened the incident, raised the country and city risk levels, and issued a welfare message for the four employees it believed were in Paris.
Three replied within the hour. The fourth did not.
The travel risk management platform showed a last known position for the unlocated employee in central London, eleven days earlier. They had installed the safety app during onboarding, declined location permission because it was their own handset, and had not opened the app since. Their travel itinerary sat in the booking tool. Their phone was on a personal SIM over which neither IT nor the risk team had any visibility. The travel risk tools were operating exactly as specified; they simply had nothing to work with for the missing traveller.
They were safe and eventually checked in by email. That is how these stories usually end; and it is why the gap never gets fixed.
The GPS mechanism works perfectly, but only when deployed
Most duty-of-care programmes locate people through a GPS-enabled application on their smartphone. For an application to report a person’s location, three conditions must be met simultaneously: it must be installed, it must have been granted location permission, and the device must have a working cellular data connection or access to a Wi-Fi network. Each of those conditions may sit outside the organization’s direct control. The programme is only ever as good as the weakest of the three on the worst day of the year.
There is, however, a second source of location data that most programmes never touch: the mobile network itself.
The invisible vulnerability
Check-in and tracking tools are typically procured as communications tools, independently of mobile services. Budgets may sit with travel, HR, or security rather than IT. Success may be measured by app and service rollout completion and licence count, not by whether the service can access accurate location data when it is needed most. Failover testing may not be performed because location is treated as an assumed capability and IT is expected to ensure that users are always connected.
Classify the same tool under business continuity with a connectivity dependency and everything changes. It would carry a documented configuration and require a degraded or back-up mode, an evidenced test cycle and a named product owner, in the way a failover circuit or a disaster recovery site does. Instead, connectivity is taken for granted and any failure is filed as an temporary IT problem.
The tool is on the asset register. The risk created by its connectivity dependency is not on the risk register.
Why GPS and app-based location services fall down at adoption
The reasons are complex and both structural and attitudinal.
- Location permission is fundamental to the product, but many users decline it for privacy reasons, often as a default reaction or without understanding the implications. World Travel Protection surveyed 1,000 North American business travellers in February 2024. Around seven in ten said their employer encouraged the use of a travel safety app. Only about three in ten had downloaded one. The split beneath that number matters more than the headline: 31% of US and 17% of Canadian travellers were hesitant about the recommended app, while 22% of US and 23% of Canadian travellers had simply not prioritised it. Resistance to perceived corporate tracking and apathy (‘I won’t need this’) require different remedies; and neither is solved by constant reminder emails.
- Cellular or Wi-Fi connectivity is assumed rather than verified. Holafly’s Global eSIM and Travel Report 2025-2026 found that more than half of travellers cite slow or unreliable Internet as their main pain point abroad and 43% report losing signal when crossing a border. A border crossing is the exact moment when a location update carries the most value. However, data caps and tariff or configuration errors on corporate SIMs and devices can prevent data access even when local network coverage is available.
- App check-in asks the person under pressure to do the administration. Asking someone in a high-risk or degraded situation to confirm that they are safe puts the burden in the worst possible place.
- There is no defined fallback. When the app is silent, most programmes revert to international SMS and voice calls, which may be delayed, filtered, or dropped when a device is roaming.
Adoption is not always an end-user engagement problem. It is also a technical design problem.
The same gap, under rising pressure
In normal operations, the gap is invisible. Silence looks identical to safety and no one queries it. In a stress event, such as a delayed flight, systems outage, or natural disaster, the gap becomes an inconvenience. Someone in HR starts working through a spreadsheet of names and telephone numbers and the picture is assembled slowly enough to be useless but fast enough to feel adequate afterwards.
In a crisis, the first question asked by the board, the insurer, and eventually the regulator is the same: “Who was affected and when did you know?” That question cannot be answered from an unanswered check-in request. What arrives instead is a round of calls, an itinerary reconstruction, and an admission that the last confirmed position was days old.
The layer does not fail suddenly. It fails progressively and its impact is only truly visible at the end.
What the mobile network already knows
Every handset that attaches to a mobile network causes the network to generate connection and location reference information as a by-product: the country, the serving operator, and the serving cell. Once the relevant SIM or eSIM service has been provisioned, this requires no app, GPS permission, user action, or behaviour change; it is automated and passive. With appropriate end-user consent, that by-product becomes a continuity asset rather than network operational data.
Used appropriately, it answers questions that the app layer cannot answer when GPS tracking is not enabled. Which country is this person in now? When did they arrive? Have they moved into a higher-risk area? Have they been offline for longer than the policy allows?
Two qualifiers apply.
First, the data is generally coarse by design and may resolve to a country, city, city district, or airport rather than a specific street address. That level of granularity may be sufficient to inform duty-of-care decisions, while its limited precision is also relevant to privacy review.
Second, its use should be consent-based and configurable for each individual, with granularity, retention, and access rules agreed with privacy stakeholders before deployment, not afterwards.
Several specialist corporate connectivity and global eSIM providers now expose these network events to travel risk platforms through APIs and, as a by-product of their own services, provide alternative backup data connectivity for global travellers. SureSIM Global is one such example, offering near-real-time visibility of mobile connections in more than 200 destinations. The relevant point is the existence of the second source, not the choice of supplier.
What resilience leaders should be asking now
- What percentage of our travelling population has the safety app installed, permitted, and functional today, based on evidence rather than assumption?
- What is our documented degraded mode when the app layer produces nothing and when was it last tested end-to-end?
- Can we answer “Who is in this city right now?” without asking anyone to check in?
- Does our location capability depend on a single carrier relationship and a single data path?
- Would our current evidence trail withstand review against ISO 31030, including where the capability relies on voluntary participation?
Connectivity sits at the heart of duty of care for travellers
The primary risk is not that the app malfunctions. It is that the plan quietly assumes that users can always be reached – an assumption that is rarely stress-tested or verified.
The author
Matt Atkinson is the founder and managing director of Utelize Mobile, a UK enterprise mobility management specialist and the company behind SureSIM Global
