An incident is often described by its cause: a fire, a security concern, a medical emergency, an equipment failure, or a disruption at a site. The harder management problem begins immediately afterwards. Different teams hold different parts of the truth, the situation changes faster than routine reporting cycles, and every unresolved question needs someone to move it towards an answer.
That problem is particularly important in Libya because nationally significant operations are distributed across fields, pipelines, processing facilities, ports, and supporting services. The US Energy Information Administration describes most recoverable oil reserves as concentrated in the Sirte and Murzuq basins, while the wider system includes onshore and offshore production, coastal facilities, pipelines, refineries, storage, and export infrastructure.1 One event can therefore have consequences for people, assets, production, transport, contractors, and external stakeholders at the same time.
A public example from March 2026 shows the breadth of that coordination challenge. Libya's National Oil Corporation reported a leak and fire on the Sharara export pipeline, with emergency response, firefighting, safety, and maintenance teams at the location. It also described redirected production flows, board-level monitoring, and an investigation into the cause.2 The announcement does not reveal how the response was managed internally, and it should not be read as an assessment of that response. It does illustrate a wider point: an industrial incident does not remain inside one department.
The operational question is not simply whether every team has information. It is whether the organisation can turn incomplete information into owned action without losing the evidence, authority, and context behind each decision.
Why does an incident in Libya expose organisational boundaries so quickly?
Operational structures are designed for normal work. Human resources maintains personnel records, security manages protective measures, operations understands plant and site conditions, logistics manages vehicles, and contractors maintain their own rosters and reporting lines. Senior leaders retain authority for decisions affecting business continuity or residual risk.
During an incident, those divisions remain legitimate, but the information they contain must be connected. A site list may identify employees but omit a specialist contractor who arrived that morning. A vehicle record may show the asset without proving who is inside it. A supervisor may report that a team is safe without identifying whether every individual has been accounted for. A control room may know that an alarm was received while another function knows that work has already moved to a different area.
Accountability should therefore be designed around the event, not the organisation chart. The incident team must establish who or what may be affected, what evidence supports that assessment, which uncertainty requires action, who owns it, and when it will be reviewed.
What is the difference between a shared screen and shared command?
A dashboard can display many data points while leaving authority unclear. Shared command requires an agreed structure for turning those data points into decisions and tasks. ISO 22320 places roles, responsibilities, tasks, resource management, joint direction, and cooperation among its core incident-management components. It applies both to a single organisation and to several organisations that work together while retaining their own structures.3
That distinction matters in Libya, where an operating site may involve an asset owner, an operator, joint-venture personnel, service companies, transport providers, security teams, and public authorities. A common picture is useful only when participants know who can change the incident scope, who can task a contractor, who confirms welfare, who authorises an operating restriction, and who communicates outside the response team.
Libya has already produced a valuable public example of this principle in practice. In 2021, the National Oil Corporation conducted a multi-company marine oil-spill exercise involving several operating and downstream companies. Its account described a communications network connecting participating company emergency rooms, operating locations, and a main emergency room so that the event could be followed and decisions supported.4 The lesson is broader than the exercise scenario. Connecting rooms and screens helps, but the real capability lies in the agreed relationships between them.
Before the next event, each organisation should define the incident lead, functional leads, decision authorities, action owners, information owners, and handover rules. It should also state when a local event becomes a wider corporate incident and what information must accompany escalation.
Who should enter the affected population?
The affected population is not automatically the whole workforce, and it is not limited to people currently visible on a map. It is the set of people whose status could materially change the response.
At a field or facility, that population may begin with the current shift, visitors, contractors, vehicle occupants, and nearby support teams. It may widen as access, transport, or operating decisions create new exposure.
Every inclusion should carry a reason, a source, and a time. A roster shows an expectation, an access record may show entry without proving current presence, and a last-known location may no longer be current. A manager's confirmation may cover a team without identifying the evidence for each person.
Status language must be equally disciplined. “Message sent”, “delivered”, “acknowledged”, “reported safe”, “requires assistance”, “confirmed through a supervisor”, and “not yet contacted” describe different things. Combining them under a single green total gives leaders a comforting number at the cost of operational meaning.
AtlasNXT Check-Ins can support a targeted request and show responses and non-responses. The organisation defines the question, response options, time window, and follow-up procedure. Silence remains an unresolved status to be handled under that procedure, not an automatic conclusion about welfare.
People, vehicles, and sites should remain separate, even when linked. Locating a vehicle does not establish occupant welfare, and a facility status does not account for people who left or contractors just outside its boundary.
How should responsibility cross the client-contractor boundary?
Contractors are not an exception to the incident model. They are often part of the operation that the model must describe. The International Association of Oil & Gas Producers' guidance on health, safety, and environment management in a contract environment emphasises risk management throughout the contract lifecycle, clearer client and contractor responsibilities, subcontracting, assurance, and the interface between management systems.5
For incident accountability, the parties should agree who holds the current roster, who may initiate a welfare request, who can confirm status, who controls tasking, which organisation communicates with families, and how the contractor's response becomes visible to the incident lead.
A bridging document can describe responsibilities, but the response must make them executable. If an operator sends a Check-In to contractor personnel, who receives the non-response list? If a contractor confirms a team through its own process, who records the source and time? If one company's vehicle carries another's people, who owns the first welfare action?
The aim is not to transfer every duty to one organisation, but to remove ambiguity where duties meet. Each person can remain under the appropriate employer while the incident lead receives the authorised status required to coordinate the event.
The same principle applies to public authorities and specialist responders. The internal record should identify the liaison owner, the information requested, what was provided, and the next expected contact. External involvement does not close the organisation's own tasks unless responsibility has been explicitly transferred and that transfer is understood.
How does an observed problem become an owned action?
An incident can contain plenty of activity without enough progress. “Three technicians have not responded” is a status. “The maintenance supervisor will verify them through the site lead by 14:20” is an action.
A useful action states the outcome required, one accountable owner, the relevant method or constraint, and a review time. The owner does not need to perform every step personally. The owner must understand that the action has been accepted and must return with an outcome, a blockage, or a request for a decision.
One owner is not the same as one contributor. Security, logistics, and a contractor supervisor may each supply evidence to a welfare action owned by the site lead. If responsibility changes, the transfer should be explicit, timed, and acknowledged.
Dependencies also need to be visible. A vehicle recovery may depend on access, an evacuation on transport, and a workforce message on approval. An action marked “in progress” can conceal a blockage.
Review times create a rhythm for managing those dependencies. They are not promises that the action will be complete. They are the point at which the incident team will reassess the evidence, risk, blockage, and next step. If a deadline moves, the record should explain why and identify any effect on related actions.
AtlasNXT's Incident Room can keep tasks, communications, significant updates, decisions, and status changes with the event. The platform can make an unowned or overdue issue easier to see. It does not decide who should have authority, what level of evidence is sufficient, or when an operational risk is acceptable. Those remain leadership and procedural decisions.
What should leaders see without becoming parallel operators?
Senior leaders need a compressed view of the event, but compression must not remove the uncertainty that drives decisions. The UK Cabinet Office's current crisis-management doctrine describes shared situational awareness through perception of what has happened and what actions have been taken, comprehension of the implications, and projection of likely developments. Its commonly recognised information picture includes significant developments and decisions, trends, and upcoming decision points.6
For a corporate or industrial response, the leadership view should therefore show the current scope, material effects on people and operations, unresolved welfare cases, critical dependencies, blocked or overdue actions, decisions required, communications constraints, and the next review point. Totals should retain their definitions. “Forty people safe” is incomplete unless leaders can understand whether they self-reported, were confirmed by a supervisor, or were carried forward from an earlier report.
Leaders should intervene when the response needs authority, resources, strategic direction, or acceptance of significant residual risk. They should avoid issuing informal tasks that compete with the agreed command structure. If a senior instruction changes priorities, the incident team should record the decision, assign its operational owner, and show the effect on existing work.
The leadership brief and operator record should be two views of the same event. Rebuilding an executive update manually creates another point at which times, totals, and definitions can diverge.
Can a shift handover transfer control rather than merely describe events?
Libyan operations can continue while the people managing an incident change. Shift patterns, different organisational working hours, fatigue, and the duration of the event all make handover a control point rather than an administrative courtesy.
The UK Health and Safety Executive's human-factors guidance says effective communication is important when a task and its responsibilities pass to another person or team. It identifies handovers between shifts and between functions, such as operations and maintenance, and recommends giving greater attention to higher-risk handovers.7
A strong incident handover should enable the incoming lead to take a decision immediately. It should identify the current scope, unresolved people and vehicles, open and blocked actions, decision owners, evidence limitations, review times, communication arrangements, and changes expected during the next period. Each critical action should still have a named owner after the handover.
The outgoing lead should not transfer facts while keeping the logic in memory. The incoming team needs to know why scope, restrictions, and provisional statuses were chosen, and what evidence would permit escalation or closure.
Private messages that materially change scope, welfare, action, or decision status should be reflected in the shared record with their source and time.
What makes a decision record defensible?
An activity log shows what happened. A decision record explains why a material choice was made. The distinction matters because an apparently obvious action may have been taken under uncertainty, while a decision not to act may later require just as much explanation.
The Health and Safety Executive describes a key decision log as a contemporaneous record of significant decisions and their reasons. Its guidance stresses recording decisions not to act, changes to earlier decisions, the initial information that influenced the approach, and the date and time of entries. It also says the record should allow someone who was not involved to understand the reasoning.8 The guidance is written for investigations, but the discipline transfers well to incident management.
The threshold is materiality. Decisions that change protective action, incident scope, operating status, resources, workforce instructions, external commitments, or strategy belong in the record. Routine execution belongs in tasks and updates.
The record should capture what was known, what remained uncertain, the options or constraints considered, who decided, what action followed, and when the decision would be reviewed. If new evidence changes the direction, the later entry should not overwrite the earlier one. It should show why the judgement changed.
This lets a reviewer assess the decision against the information then available, rather than assuming the outcome was foreseeable. AtlasNXT's Incident Room can hold material decisions and supporting updates alongside the event. Retention, access, and legal requirements remain organisational responsibilities.
What should a Libya exercise prove before the next incident?
An exercise should test accountability, not merely whether an alert can be sent. ISO 22398 provides guidance for planning, conducting, and improving exercises and says the approach can be adapted to an organisation's objectives, resources, and constraints.9
The scenario should force the joins in the operating model to work. It might begin with an event at a facility that affects employees and contractors, introduces uncertainty about a vehicle, requires a temporary operating decision, and continues into a shift change. The test is whether participants establish the affected population, distinguish evidence from assumption, allocate one owner to every critical gap, expose dependencies, and give leaders a concise view with visible uncertainty.
The scenario should include delay or contradiction. A supervisor may confirm a team while one status remains unclear, or a contractor record may not match the site record. The purpose is to expose undocumented assumptions.
Libya's National Oil Corporation has used exercises to test coordination and improve preparedness. Its 2021 multi-company spill exercise was designed to assess joint response across participating organisations and locations.4 In 2023, it also reported an evacuation, rescue, firefighting, and emergency-response drill whose observed weaknesses were to be improved.10 Those public examples reinforce an important practice: an exercise should produce corrective actions, not simply a successful completion notice.
Each corrective action should have an owner, target outcome, review date, and closure evidence. The next exercise should test the improvement.
Where can AtlasNXT fit into the operating model?
AtlasNXT can provide a shared workspace without replacing organisational command. Remits can focus geographic responsibilities and authorised views. Check-Ins can collect defined responses and expose non-responses. The app can support alerts, Panic, Overwatch, and appropriate location functions. Compatible satellite devices can contribute for selected users, subject to hardware, airtime, configuration, and service.
Within the Incident Room, significant updates, tasks, communications, decisions, and status changes can remain connected to the event. That connection is the practical value. The affected population explains who may be involved and why. Evidence shows what has actually been confirmed. Tasks identify who owns the next action and when it will be reviewed. Decision records preserve the material choices and their rationale. Explicit unknowns can receive an owner, while hidden assumptions cannot.
Closure should reconcile the affected population, asset status, open actions, material decisions, and residual uncertainty. Each case or task should be complete, cancelled with a reason, or accepted by a named business owner. Unverified information should retain that limitation.
For an organisation operating in Libya, the test is direct. If an incident moves from a field or facility into contractor management, vehicle coordination, workforce welfare, business continuity, and senior oversight, can everyone work from an authorised account of the same event? Can leaders see what is known, what remains uncertain, who owns each next action, and why the current course was chosen?
If the answer depends on separate spreadsheets, private messages, manually rebuilt briefings, and one person's memory, the risk is not simply untidy administration. It is that a material gap can remain visible to several people while owned by none.
Book a free AtlasNXT demonstration to explore how an accountable incident workflow could be configured around your people, vehicles, sites, contractors, and decision structure in Libya.
References
1. US Energy Information Administration, Libya Country Analysis Brief, updated 3 December 2024. https://www.eia.gov/international/content/analysis/countries_long/libya/
2. Libya National Oil Corporation, NOC Statement on Sharara Pipeline Leak and Fire, 18 March 2026. https://noc.ly/en/noc-statement-on-sharara-pipeline-leak-and-fire/
3. International Organization for Standardization, ISO 22320:2018 Security and resilience: Emergency management: Guidelines for incident management. https://www.iso.org/standard/67851.html
4. Libya National Oil Corporation, Multi-company level-two marine oil-spill simulation exercise, 5 September 2021. https://noc.ly/%D9%84%D9%84%D8%B1%D9%81%D8%B9-%D9%85%D9%86-%D8%AF%D8%B1%D8%AC%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%AF%D8%A7%D8%AF-%D9%88%D8%A7%D9%84%D8%AA%D8%A3%D9%87%D8%A8-%D8%A8%D8%A7%D9%84%D8%B4%D8%B1/
5. International Association of Oil & Gas Producers, HSE management: Guidelines for working together in a contract environment, Report 423, April 2017. https://www.iogp.org/bookstore/product/hse-management-guidelines-for-working-together-in-a-contract-environment/
6. UK Cabinet Office, The Amber Book: Managing crisis in central government, April 2025. https://www.gov.uk/government/publications/the-central-government-s-concept-of-operations/the-amber-book-managing-crisis-in-central-government-html
7. UK Health and Safety Executive, Shift handover. https://www.hse.gov.uk/humanfactors/topics/shift-handover.htm
8. UK Health and Safety Executive, Key decision log. https://www.hse.gov.uk/foi/internalops/og/ogprocedures/investigation/decisionlog.htm
9. International Organization for Standardization, ISO 22398:2013 Societal security: Guidelines for exercises. https://www.iso.org/standard/50294.html
10. Libya National Oil Corporation, Health, safety, and environment teams conduct a fire evacuation and emergency-response simulation, 21 June 2023. https://noc.ly/%D9%81%D8%B1%D9%82-%D8%A7%D9%84%D8%B5%D8%AD%D8%A9-%D9%88-%D8%A7%D9%84%D8%B3%D9%84%D8%A7%D9%85%D8%A9-%D9%88-%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A9-%D8%A8%D8%A7%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A9-%D8%AA/
