The hardest problem in many aviation incidents is not finding information. It is joining the right information quickly enough to act. One system knows where a crew is scheduled to travel. Another holds a recent device location. An intelligence source reports disruption near the destination. Messages are sent through separate channels, while decisions are recorded in calls, emails, or personal notes.
The gap between those systems is where uncertainty grows. A warning may be credible without being operationally relevant. A traveller may appear close to an event without still being there. A message may show as sent without confirming that its recipient is safe. A regional operations team may be acting while the central security function is still trying to establish who owns the response.
ISO 31030 treats travel risk management as a structured discipline covering policy, threat and hazard identification, risk assessment, prevention, mitigation, evaluation, and review. That breadth matters because protecting people who travel for work requires more than a destination rating or a list of alerts.1
AtlasNXT is designed to connect those operational elements. It does not replace crew scheduling, flight operations, specialist intelligence, or an organisation's own judgement. It provides a shared environment in which authorised data can be turned into an exposure assessment, targeted communication, coordinated action, and a time-stamped incident record.
What operational problem does AtlasNXT solve?
AtlasNXT gives security and operations teams one place to turn a potential exposure into a managed response.
A risk alert is only the beginning of the work. The security or operations team still needs to decide whether the event is relevant, identify who may be affected, understand which information is current, contact the right people, manage silence or requests for help, allocate actions, and retain a reliable account of the response.
Intelligence may sit in one platform, itinerary data in another, live or last-known locations in a third, and communications in several more. When those functions sit in separate systems, the people coordinating the incident become the integration layer, transferring information manually while the situation continues to change.
AtlasNXT creates an operational layer across those sources. It brings incidents, available location context, selected intelligence, communications, check-ins, tasks, and decisions into one workflow. The aim is not to create a busier map. It is to help the team answer five practical questions: what has happened, who may be exposed now or later, who can be reached, what is being done, and what evidence will remain.
How does AtlasNXT identify who may be affected?
Exposure is not the same as proximity at the instant an alert arrives. It is a relationship between an event, its likely area and duration, people's movements, their roles, and the quality of the available evidence.
Within AtlasNXT, an operator can define an incident area and consider it alongside authorised information about people, journeys, sites, and assets. When a configured integration or import supplies planned movement data, operators can compare current or last-known location with expected travel. The precise method for identifying people expected to enter an affected area should be validated against the source data, update frequency, and required time window.
Consider disruption near an airport. One crew may already be at nearby accommodation, another may be due to arrive later, and a third may have diverted even though the original itinerary still names the destination. A search based only on recent device locations can miss the incoming group. A search based only on itineraries can include people who never arrived. A useful exposure picture preserves those distinctions so that the operator can assess each person using the best evidence available.
That makes provenance and time important. A planned destination, a last-reported position, an actively shared location, and a direct welfare response do not mean the same thing. AtlasNXT helps bring these signals into the same operating context, while the organisation defines how each should inform its procedures.
Can AtlasNXT account for future travel as well as current location?
Yes, provided that the organisation can supply the relevant travel or crew-movement information in a usable form.
An itinerary is a statement of intent rather than proof of presence, but it is still valuable. Planned flights, accommodation, transfers, duty periods, and other approved movement data can reveal future exposure before a person reaches an affected location. This gives the organisation time to issue guidance, change arrangements, brief an operations team, or make a different risk decision.
ISO's official explanation of ISO 31030 includes pre-planning, the assessment of destinations and travel arrangements, travel logistics, communication, and emergency response within the discipline of travel risk management.2 Bringing planned movement into the operational picture therefore supports a more complete process than reacting only after a device enters a boundary.
AtlasNXT can receive agreed travel, crew, or operational records where a suitable integration or import has been configured. Operators should treat those records as planned or source-system information rather than as proof of live location. The value comes from showing what is planned alongside what is known, then allowing the response team to resolve any difference.
How does AtlasNXT connect with existing aviation and travel systems?
The integration method depends on the source. An existing system may provide an application programming interface, a webhook, a scheduled export, or a structured file. Useful records normally need a stable person or asset identifier, a relevant location, a timestamp, a status, and enough context to interpret the event or movement correctly.
Travel data might describe a scheduled journey or hotel. A crew system might show an assignment. An aircraft or facility system might provide an alert, position, status, or time. AtlasNXT can receive and present suitable information where access, permission, format, and security requirements have been agreed.
Integration does not make stale data current or ambiguous data certain. Update frequency, identifiers, time zones, cancellation handling, and data ownership all need to be designed deliberately. If an aircraft communications service can expose authorised location or event data in a supported format, AtlasNXT may be able to represent it alongside people, incidents, and other operational information.
This avoids asking a crew-scheduling or flight-operations system to perform a different role. AtlasNXT receives the information relevant to safety and response, preserves its meaning, and makes it usable by the people authorised to act.
Does AtlasNXT require everybody to be tracked continuously?
No. Communication and safety support should not depend on permanent visibility.
AtlasNXT can send broadcasts and Check-Ins to configured audiences without requiring every recipient to share a live location. User location can remain private by default and become visible with consent for a defined safety purpose. Overwatch and Panic can add location-enabled safety context when activated, subject to the customer's policy, permissions, and deployment configuration.
For smartphone users, the AtlasNXT app brings alerts, communication, Check-Ins, Overwatch, Panic, and location-enabled safety functions together. Organisations can combine the app with itinerary information and other contact channels without requiring continuous live sharing merely to receive safety communications.
Privacy still requires governance. Where the GDPR or UK GDPR applies, the organisation must identify a lawful basis and follow principles including purpose limitation, data minimisation, accuracy, and data protection by design and by default.3 UK Information Commissioner's Office guidance also says worker monitoring should be necessary, proportionate, transparent, and consistent with reasonable expectations, and that organisations should not collect more information merely in case it becomes useful later.4 Other jurisdictions may impose different requirements.
Can an organisation choose its own intelligence sources?
Yes. AtlasNXT is intelligence-provider agnostic. It can bring authorised third-party feeds, internal reporting, weather information, locally sourced intelligence, and other relevant operational data into the same environment, subject to the available integration.
This matters because no single source is equally strong for every geography, threat, sector, or decision. ICAO's public guidance for aircraft operator security managers says risk assessments should use direct information collected by the operator alongside relevant information from authorities, other operators, and aviation security service providers.5 EASA similarly describes its conflict-zone system as joining multiple information and intelligence sources into a common risk picture, and it states that its own bulletins should not be treated as the sole source of relevant information.6
The practical principle is that a threat feed should inform the operating picture, not own it. Intelligence arrives with a source, a time, a geography, and an assessment. The organisation's team remains responsible for deciding what the information means for its people and operations.
That separation also improves resilience. If an organisation changes or adds an intelligence supplier, its incident process, communication structure, and audit method should not have to be rebuilt around a new content provider.
What happens when an alert becomes an incident?
An incident can begin with an intelligence item, a SmartGeofence event, a Panic alert, an Overwatch activation, an external signal, or a manual report. The operator can define the relevant area, assess who may be affected, and open an Incident Room for the response.
Imagine an alert reporting unrest near a destination. The first task is not to send the same message to everybody. The team needs to distinguish people already nearby, those moving through the area, those scheduled to arrive later, and those whose status is uncertain. It may issue immediate safety guidance to one group, changed travel instructions to another, and a welfare check to people whose presence needs confirmation.
Responses then improve the picture. An acknowledgement confirms that the recipient acted on the prompt, but it does not establish that the person is safe. A welfare response can provide that additional information. A request for assistance creates a different priority, while non-response remains an unresolved condition that may require another channel or escalation under the organisation's procedures.
Within the Incident Room, significant updates, communications, tasks, decisions, and changes in status can remain connected to the same event. This lets operators move between awareness and action without rebuilding the context in a separate document.
How does AtlasNXT handle crisis communication and non-response?
AtlasNXT supports push notifications, SMS, email, voice, and satellite delivery where a compatible device and service are in place. Operators can broadcast broadly or target configured audiences, such as defined groups or locations and people identified as relevant to an incident.
The channel count is less important than the distinction between communication states. Sent, delivered, acknowledged, and safe are different facts. The most dangerous green tick in crisis communication is the one that encourages a team to treat a technical delivery status as a human outcome.
AtlasNXT Check-Ins allow people to confirm their status. The response team can identify unanswered Check-Ins and escalate them through the organisation's agreed procedures. ReachScore™ evaluates readiness using five current signals: SMS availability, notification permissions, location access, recent device engagement, and battery life. It helps expose likely contactability gaps before an urgent message is sent.
This distinction gives the response team a more honest picture. A precisely located person may be unreachable. Another person may receive and answer an instruction without sharing a live position. Location and reachability are related, but they are not interchangeable.
What happens when cellular coverage is weak or unavailable?
AtlasNXT can use smartphones where mobile data or Wi-Fi is available, while supported satellite devices provide an alternative for selected users and operations where terrestrial coverage cannot be assumed. A separate aircraft-satcom integration depends on the data and interface available from the aircraft system.
The objective is not to issue every person with every possible device. It is to design communication around credible failure modes. A traveller moving between connected airports may need only the app and normal contact channels. A team operating beyond dependable terrestrial coverage may need a suitable satellite device, an active service, appropriate training, and a clear monitoring procedure.
Satellite resilience has limited value if it creates a second map and a separate incident process. AtlasNXT can bring supported satellite-origin location and communication into the same operating picture as app users.
How can distributed operations teams work from one picture?
A global map does not by itself create a global operating model. The organisation still needs clear ownership, relevant access, and a reliable handover between teams working across locations and time zones.
AtlasNXT Remits provide geographically defined areas of responsibility, while roles and permissions help determine who can see and manage relevant information. A central security function can retain appropriate oversight as operational teams work within their responsibilities. When operational ownership passes between teams, the incident timeline, open tasks, communications, and decisions remain attached to the same record.
ISO 22320 describes incident management in terms of process and structure, roles and responsibilities, tasks, resource management, joint direction, and cooperation. It applies both to a single organisation and to several organisations working together.7 AtlasNXT supports the coordination elements relevant here through its shared Incident Room, Incident Team, and task record. The customer remains responsible for defining its response structure and escalation model.
What evidence remains after the incident?
A useful record should show more than the final version of events. It should show the original trigger, the information available at successive points, who was considered exposed, which messages were sent, who responded, what actions were assigned, what decisions were taken, and when the situation changed.
ICAO describes an aviation emergency response plan as an operational document setting out specific roles, actions, and timeframes, and it stresses the importance of coordinated action among aviation stakeholders.8 ISO 22361 also places decision-making, crisis communication, training, validation, learning, and continual improvement within a strategic crisis-management capability.9
AtlasNXT's Incident Room keeps the response timeline and task activity together while the incident runs. That contemporaneous record supports handover, management review, assurance, and learning. It should help the organisation explain not only what eventually proved true, but what the team knew at the time and what it did next.
How should an aviation organisation evaluate AtlasNXT?
The most useful evaluation is not a generic feature tour. It is a realistic, anonymised scenario containing the failures that the operating model must withstand.
Begin with an imperfect alert near a destination. Include one person already present, one expected later, one whose plans changed outside the original booking record, one who cannot use a cellular channel, and one who receives a message but does not provide a welfare response. Require ownership to pass between operations teams while the incident remains active.
Then ask whether the platform can preserve the difference between planned and observed location, identify present and future exposure, use the organisation's chosen intelligence, communicate without requiring continuous tracking, keep satellite-connected users in the same workflow, make non-response visible, and retain one coherent incident record.
Book an AtlasNXT demonstration and test the platform against an anonymised version of your own aviation scenario, data sources, operating structure, and communications constraints.
References
2. International Organization for Standardization, Better business trips, an introduction to ISO 31030
3. European Union, Regulation (EU) 2016/679, Articles 5, 6, and 25
4. Information Commissioner's Office, Data protection and monitoring workers
6. European Union Aviation Safety Agency, Information on Conflict Zones
8. International Civil Aviation Organization, Emergency Response Planning
