Consider a hypothetical scenario. At 09:10, an intelligence alert reports unrest near an international airport. The security map displays several traveller icons in the surrounding area. One is based on a device update from a few minutes ago. Another is inherited from an itinerary. A third is a last-known position from the previous evening.
The apparent precision is comforting, but the operational position is not. One crew has diverted. Another is due to land later. A traveller shown near the airport has already left, while somebody absent from the map is moving towards it after changing plans outside the normal booking channel. Several messages show as delivered, but the security team does not yet know whether the recipients have read the instruction, are safe, or require assistance.
Does the organisation have an operational picture, or only a collection of partially related records?
The distinction matters because aviation security decisions span moving people, multiple time zones, several organisations, and uneven communications networks. A polished map can conceal the exact uncertainties that responders need to see. A feed can describe a threat without showing who is exposed. An itinerary can describe intent without confirming presence. A location point can identify a device without explaining where its user is heading. A delivery receipt can confirm a technical event without confirming a human outcome.
Effective exposure management begins when those differences are made explicit.
What does a traveller dot actually represent?
A dot is a visual conclusion. Before relying on it, the operator needs to know which evidence produced it.
The position may come from an actively reporting smartphone, a satellite device, a manual check-in, a travel itinerary, a hotel booking, an aircraft assignment, or an older observation. Each can be useful, but each answers a different question. A booking says that someone was expected to travel. A device report says that a particular device was at a location at a stated time. A welfare response says something about a person, although it may not establish a precise position. None should quietly inherit the certainty of another.
The aviation sector already treats position and time as inseparable. ICAO says the Aircraft Tracking function within its Global Aeronautical Distress and Safety System provides an automated four-dimensional position comprising latitude, longitude, altitude, and time.1 That system tracks an aircraft for defined aviation safety purposes. It does not claim to establish the location, condition, or future movement of every crew member or operational traveller. The comparison exposes a useful principle: a location that does not identify what it represents, where it came from, and when it was recorded is incomplete evidence.
A credible security interface should therefore show whether a point comes from a plan, an inference, a last-known position, or an active device report. A direct welfare confirmation is a different kind of evidence and should remain distinguishable. The interface should show when the information was produced, not merely when it was displayed. Precision on a screen is not the same as certainty in the field.
When does location become exposure?
Location becomes exposure when it is related to a defined hazard, a relevant period, the person's movement, their vulnerability, and the decisions available to the organisation.
A person outside an incident boundary may face greater prospective exposure than somebody inside it. The first may be travelling towards the event with no warning. The second may have already departed and confirmed safety. Distance alone does not resolve the question.
Time changes the boundary as well. Civil unrest may move along a route. Severe weather may affect an airport before it affects accommodation nearby. A temporary closure may matter to people scheduled to arrive several hours later, while having little operational effect on somebody who has completed the journey. The incident area and the assessment window must be able to change as information improves.
ICAO's conflict-zone risk guidance provides a demanding aviation example of this principle. It says that risk assessments should operate as a continuous cycle, that significant changes in the threat should prompt reassessment, and that mitigation should remain flexible and proportionate to changing circumstances.2 The same reasoning applies to traveller exposure at a smaller scale. The first alert is a starting hypothesis, not a permanent description of the incident.
Exposure is therefore better expressed as a reasoned relationship than a coloured icon. The operational question is not simply, “Who is inside the circle?” It is, “Whose safety or movement may be affected within the time and circumstances we are managing, and how certain are we?”
Why must planned and current movement be reconciled?
Itinerary data and device data have complementary strengths and weaknesses.
An itinerary provides forward visibility. It can show who is expected to travel, where they are due to stay, which destination matters, and when an organisation may still be able to change the plan. That makes it useful for preventive action. ISO 31030 frames travel risk management as a structured process that includes identifying threats and hazards, assessing risk, and developing prevention and mitigation strategies.3 Its official explanatory material also includes pre-planning, travel arrangements, logistics, communication, and emergency response.4
The weakness is that plans change. A flight diverts, a hotel changes, ground transport is rearranged, or a traveller makes a decision outside the channel that supplied the original record. An itinerary can remain internally accurate as a booking record while becoming operationally wrong as a location assumption.
A device position offers different evidence. It may show recent presence even when the plan changed, but its usefulness depends on reporting frequency, connectivity, battery state, device assignment, permissions, and the user's choices. A last-known point may be valuable, but it becomes less informative as time passes. It also says nothing by itself about where the person intends to go next.
The answer is not to choose one source and hide the other. It is to reconcile them. A system should surface the fact that an itinerary still shows an arrival while operational data shows a diversion. That contradiction is not clutter. It is information that may require a decision.
A disciplined operating procedure can distinguish evidence as “scheduled”, “observed”, “confirmed”, or “unknown”. These are analytical descriptions rather than incident workflow states. “Scheduled” means the journey is in the authorised plan. “Observed” means an approved source produced a position at a known time. “Confirmed” means the person or a responsible operator has supplied a relevant status. “Unknown” means the evidence is insufficient. Whether or not an interface uses those exact labels, a credible operating picture displays uncertainty instead of hiding it.
Why should intelligence remain an input rather than the operating system?
Intelligence providers, government advice, airport notices, weather services, internal reports, local contacts, and operational alarms answer different questions. The strength of an assessment depends on choosing and combining sources that fit the decision, then retaining responsibility for the judgement.
ICAO's public guidance for aircraft operator security programmes says security managers should base assessments on available information that includes material collected directly by the operator and information received from relevant authorities, other aircraft operators, and aviation security service providers.5 ICAO's conflict-zone manual likewise says operators should make their own determinations and can use government advisories, other operators, open-source intelligence, and in-house resources.2
EASA offers a further useful model. Its conflict-zone alerting system joins multiple information and intelligence sources to support a common risk picture. EASA also states that its bulletins should not be considered the sole source of relevant information.6
These sources do not prescribe a corporate technology architecture, but they support an important operating principle. A threat feed should arrive with provenance and context, while the organisation retains authority to interpret it. Intelligence informs the decision. It does not own it.
Bundling intelligence, traveller records, communication, and response into one supplier may appear convenient. It can also make an operating model unnecessarily dependent on a particular source of content. A more resilient test is whether the organisation can add, remove, or combine intelligence sources without rebuilding its incident procedures, audience structures, communications, and evidence model.
The question for a platform supplier is not how many feed logos appear on a slide. It is whether a feed item can become operational without losing its source, time, geography, or uncertainty. Can the team establish relevance, define the affected population, issue instructions, allocate actions, and retain the response in one coherent record? If not, the platform has delivered awareness but left the hard work elsewhere.
How should uncertainty affect operational decisions?
Security teams rarely wait for perfect information. They make proportionate decisions while facts are incomplete, then revise those decisions as the evidence changes.
This makes “unknown” an operational state. It is not the same as safe, outside the area, unreachable, or unresponsive. Treating those conditions as equivalent can create false reassurance.
Information age is one source of uncertainty. A location from two minutes ago may support a different decision from one reported two hours ago. Provenance is another. A direct welfare response, an itinerary record, a device signal, and an unverified report carry different weight. Contradiction is a third. If two sources disagree, the interface should expose the conflict rather than silently selecting the answer that makes the map look complete.
ICAO's conflict-zone manual says mechanisms should obtain up-to-date and valid threat information in time to ensure the resulting risk assessment is current, accurate, and complete. It also says information should be cross-validated through a variety of possible sources and that significant threat changes should trigger reassessment.2 The manual also warns, in that high-consequence context, that lack of evidence or low likelihood should not automatically delay action.2
The practical consequence is that an organisation needs decision rules for uncertainty. It may contact a wider group while the boundary is being confirmed. It may ask a traveller to delay movement until a report is verified. It may escalate non-response more quickly for somebody whose last-known position and planned route both suggest exposure. The appropriate choice depends on the context and risk appetite, but the underlying evidence should remain visible.
Later, when the incident is reviewed, the record should show what was reasonably knowable at each decision point. Judging a response only against facts discovered afterwards is poor analysis. The relevant question is whether the decision was proportionate to the information, uncertainty, and possible consequences known at the time.
Why is reachability different from location?
A traveller can be precisely located and still be unreachable. Another can receive and answer an instruction without sharing a live position.
This makes contactability a separate operational variable. The organisation needs to know which channels are available, whether contact details are valid, whether the relevant permissions are enabled, whether a compatible device has reported recently, and whether the person has responded. None of those facts should be collapsed into a single delivery tick.
Depending on the channel, “sent” may mean only that the platform handed a message onwards, while “delivered” is a technical status where the channel reports one. Neither establishes welfare. “Acknowledged” records a defined user action. “Safe”, “needs assistance”, and “no response” are separate operational states. Each can require a different next step.
This also explains why communication should not depend entirely on live tracking. A roster, journey, role, site, or operational group may provide a legitimate audience even when current location is unavailable or not being shared. The organisation should be able to issue relevant guidance and ask for a response without converting every communication need into continuous surveillance.
Communications readiness should be tested before an incident. Contact routes, app permissions, device status, and escalation procedures can then be corrected while there is time. Discovering during an urgent broadcast that a population is unreachable turns a preparedness gap into a response problem.
Can privacy improve the operating model?
Privacy is sometimes described as a restriction on situational awareness. The Information Commissioner's Office warns that unfair worker monitoring can damage trust and says organisations should choose the least intrusive means that achieves their purpose.9 A clearer, more proportionate location policy should therefore be treated as part of the operating model, not merely as a constraint on it.
The governing question should be purpose. What decision requires location information? How precise must it be? Who needs to see it? How long should it remain accessible? What event or activity justifies increased visibility, and what happens when that purpose ends?
The OECD Privacy Guidelines provide a globally framed set of principles that includes collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation, and accountability.7 Where the General Data Protection Regulation applies, Articles 5 and 25 require principles including purpose limitation, data minimisation, accuracy, and data protection by design and by default.8 UK regulatory guidance on monitoring workers adds that monitoring should be necessary, proportionate, transparent, and consistent with reasonable expectations, and that organisations should not collect more information than required merely in case it proves useful later.9
Those rules and principles do not create a universal formula. Legal bases, workforce relationships, risks, and jurisdictions vary. In employment, the Information Commissioner's Office cautions that consent may be inappropriate where workers lack genuine choice because of the power imbalance.9 The organisation needs appropriate legal and operational advice.
They do, however, expose a weak assumption: permanent visibility is not automatically the most responsible form of duty of care. Planned travel can support early assessment. Event-based or activity-based visibility can provide greater precision when the safety purpose requires it. Mass communication can reach a defined population without live tracking. Direct check-ins can replace inference with a user-supplied status.
A privacy-conscious system makes these modes distinguishable. It does not present data gathered for one purpose as indefinitely available for another. Continuous surveillance should not be the admission price for receiving safety support.
What should happen when cellular connectivity fails?
Communications architecture should be based on credible failure modes, not an assumption that one network will always be present.
Smartphones provide a practical interface for most routine travel. An app can combine alerts, messages, Check-Ins, and location-enabled safety functions while mobile data or Wi-Fi is available. SMS, email, and voice provide other routes with different strengths and dependencies. For selected travellers, mobile teams, or operating regions where terrestrial coverage cannot be assumed, a compatible satellite device can preserve a path for location or messaging.
Satellite is not a magical property of the platform. It requires suitable hardware, an active service, correct assignment, power, training, and an integration that can return usable data. The organisation should decide who needs that resilience and under which conditions.
The more important architectural test is what happens to the information. If satellite-origin messages and positions live on a separate portal, operators may still need to rebuild the event across two maps and two procedures. Satellite resilience has limited value if it creates a second operational picture. The useful design connects the remote channel to the same person, incident, communication history, and response team.
Who owns the incident in a distributed organisation?
A shared interface can still conceal several versions of responsibility.
Global aviation operations may involve a central security function, regional operations teams, duty managers, travel specialists, ground handlers, and external responders. Each may need different access and have different authority. The platform must route relevant information without obscuring who is accountable for the next decision.
ICAO says aviation emergency response plans should specify roles, actions, and timeframes, and should support immediate, coordinated action among stakeholders.10 ISO 22320 similarly places process, structure, roles, responsibilities, tasks, resource management, joint direction, and cooperation at the centre of incident management.11
Technology should make the active incident team, open tasks, decisions, and next actions easy to understand. When responsibility passes between shifts, the shared timeline and task record should reduce reliance on a separate verbal reconstruction.
Local action and central oversight are not opposites. A relevant operations centre may need to manage immediate contact while the central team considers wider exposure and executive decisions. Both can work from the same incident record while seeing only the information appropriate to their roles.
A global map without routed ownership merely centralises ambiguity.
What evidence must survive the event?
A message archive is not an incident record. A list of alerts is not a decision history. A post-incident report written from memory is not the same as a contemporaneous account.
The useful record links the original signal and its source to the assessment that followed. It shows how the incident boundary changed, which people were considered exposed at each stage, what information supported that view, which communications were issued, which responses arrived, and what remained unknown. It connects tasks to owners and deadlines, records significant decisions, and preserves handovers and status changes.
This has immediate value. A new team can understand the position without restarting the investigation. Leaders can see whether responsibility, priorities, and outstanding work are clear. Operators can identify silence, overdue work, and unresolved assumptions.
It also has value after closure. ISO 22361 includes decision-making under complexity, crisis communication, training, validation, learning, and continual improvement within strategic crisis management.12 Learning is stronger when it begins with an accurate chronology rather than a reconstruction shaped by hindsight.
The audit trail should therefore preserve uncertainty as well as action. It should show not only what eventually proved true, but what the team knew, when it knew it, and why its next step was reasonable. That supports review and assurance. It does not, by itself, prove that every decision was correct or that every legal duty was fulfilled.
How should an aviation organisation test a critical event management platform?
A procurement checklist can confirm that features exist. An operational test reveals whether they remain connected under pressure.
The test should begin with an imperfect alert near a destination. One traveller is present, one has already left, one is due to arrive later, and another has changed plans outside the system that supplied the itinerary. One person has a recent device location but cannot be reached. Another answers a message but is not sharing a live position. Cellular coverage fails for a selected user, responsibility passes to another operations team, and the incident boundary changes as new information arrives.
The platform should be required to show what each location means and when it was produced. It should identify present and prospective exposure without treating every planned journey as verified presence.
It should let the organisation use appropriate intelligence sources, target communications without forcing permanent tracking, distinguish delivery from welfare, preserve a satellite-connected user within the same workflow, and make ownership clear during handover.
Finally, the team should close the incident and retrieve the record without manually rebuilding it from email, telephone notes, chat messages, and spreadsheets.
This goes beyond asking whether a product has a map, alerts, workflows, integrations, and a dashboard. The harder question is whether the operational verbs connect: assess, decide, contact, confirm, assign, escalate, hand over, close, and learn.
If the security team must leave the risk platform and revert to phone trees, email, chat groups, or a separate operations system when an alert becomes an incident, the platform has delivered awareness, not a coordinated response.
Where does AtlasNXT fit?
AtlasNXT is designed as the coordination layer for this operating model. It combines its native location, communication, Check-In, Remit, and Incident Room capabilities in one environment. Authorised travel, crew, intelligence, and supported satellite data can be added where an agreed integration or import is available.
The AtlasNXT app brings alerts, communication, Check-Ins, Overwatch, Panic, and location-enabled safety functions together for smartphone users. Mass communication remains available to defined audiences without requiring everybody to share a live location.
ReachScore™ evaluates communication readiness using SMS availability, notification permissions, location access, recent device engagement, and battery life. It helps expose likely contactability gaps before an urgent message is sent.
AtlasNXT Remits help define geographic areas of responsibility, while the Incident Room keeps the timeline, tasks, communications, decisions, and status of an event together. External intelligence, travel, facility, or aircraft data can be brought in through an agreed integration, subject to authorised access, a usable interface, and technical validation.
AtlasNXT does not claim that one source always knows where everybody is. Its role is to bring available, information into a shared operational context, so the customer's team can interpret it and coordinate the response.
Book an AtlasNXT demonstration and run the exposure-to-accountability scenario against an anonymised version of your own data, communications constraints, and operating procedures.
References
4. International Organization for Standardization, Better business trips, an introduction to ISO 31030
6. European Union Aviation Safety Agency, Information on Conflict Zones
8. European Union, Regulation (EU) 2016/679, Articles 5, 6, and 25
9. Information Commissioner's Office, Data protection and monitoring workers
10. International Civil Aviation Organization, Emergency Response Planning
