When an incident is moving quickly, record-keeping can look like an administrative task that belongs after the urgent work. A good incident log is not a transcript created for the archive. It helps people establish what is happening, decide what to do, assign responsibility, and recognise when the situation has changed.
This matters when response is distributed across field teams, security, operations, logistics, leadership, and external partners. Each group may hold a valid piece of the picture. The challenge is to combine those pieces without erasing uncertainty, confusing reports with facts, or giving every participant the same unrestricted view.
Emergency-response doctrine reflects this need. JESIP defines a common operating picture as an overview created by assessing and combining information from multiple sources, then sharing it with the appropriate command and co-ordination groups to support joint decisions.1 The UK Government’s Amber Book similarly assigns a crisis situation function the task of maintaining a single, immediate, authoritative overview for decision-makers.2
The lesson for any international or field-based organisation is straightforward. The incident record and the operational picture are not separate products. The record is how the picture acquires memory, accountability, and the ability to improve.
Why must the log begin during the response?
An incident changes faster than memory can reliably reconstruct it. A decision that appears obvious at 14:00 may look inexplicable two days later unless the team can see what information was available, what remained unknown, what options were considered, and what constraint shaped the choice.
UK incident-response guidance calls for comprehensive, contemporaneous records and a central incident file. It treats record-keeping as part of the live response and the later record of what happened.3 The practical point is that a list of actions may show that a vehicle was redirected or a site was closed. It does not explain the information and judgement that led to the decision.
Starting the log during the response preserves context while it can still influence the work. A new shift can see what has been tried, whether actions remain open, and which reports were corrected. Managers can ask the next useful question rather than repeat the last one.
The aim is not exhaustive transcription. It is operational continuity.
What is a shared operational picture?
A shared operational picture is a maintained view of the incident that answers three different questions. What is happening now? What does it mean for people, operations, assets, and commitments? What might happen next?
JESIP uses the same progression, expressed as “what?”, “so what?”, and “what might?”. Its current doctrine describes the picture as a continuously evolving point of reference that may begin as a situation report and develop into a dynamic dashboard with maps, graphics, and contextual information.1, 4
This makes the picture more than a map and less than a data warehouse. A map can show where something has been reported, but not whether the report is verified, what decision followed, or who owns the response. A repository can contain every message, document, and spreadsheet, but still leave a decision-maker unable to see what matters now.
The useful picture is selective. It shows the current state, supporting evidence, material uncertainty, priorities, decisions, actions, owners, deadlines, and likely developments without overwhelming a busy operator or leader.
Why is a collection of messages not an incident record?
Email, chat, radio, telephone, and face-to-face updates are sources. They are not automatically a coherent account.
The same event may be described differently by a driver, a local manager, a security adviser, and a regional leader. Timestamps may reflect when a message was sent rather than when the event occurred. A forwarded update may lose its source, a correction may sit in another channel, and a decision made on a call may never appear in writing.
Bringing communications into one place is not enough. The team must assess and structure them, preserve provenance, make their status clear, and connect significant updates to resulting decisions or tasks. A superseded report should remain visible as part of the history.
“Single source of truth” can therefore be an unhelpful promise. During a live incident, information is incomplete and developing. A better objective is a common reference that distinguishes what is known, reported, inferred, and unresolved.
What deserves a place in the log?
The record should be proportionate to the incident and focused on information that changes understanding, risk, responsibility, or action.
A significant entry should make clear what was reported, when it occurred and was received, where it applies, its source and status, and any action required. A decision entry should preserve the decision-maker, material options or constraints, the reason for the choice, the action owner, and the review point.
UK Health and Safety Executive investigation guidance draws a useful boundary. A key decision log is a contemporaneous record of decisions that materially affect an investigation and the reasons for them. It is not a diary of every action. The guidance also stresses recording decisions not to act, changes to earlier decisions, and the distinction between making a decision and recording it later.5
If every routine update is treated as a major decision, the log becomes noise. If only dramatic moments are captured, it loses the chain of reasoning. An entry earns its place when it helps another authorised person understand the current state, the chosen response, or a consequential change.
How should uncertainty be recorded?
Uncertainty should be visible, specific, and revisable. Hiding it creates false confidence. Treating every unverified report as equally unreliable creates paralysis.
The record should distinguish direct observation from second-hand report, verified fact from working assessment, and current from last known status. It should show the source, time, confidence, and next step for resolving uncertainty. “Vehicle reported delayed at 09:10, cause unconfirmed, driver check-in due 09:25” is different from “vehicle missing”.
Non-response needs the same care. A missed check-in may indicate a device problem, changed work, lack of coverage, human error, or a person who needs help. AtlasNXT Check-Ins show responses and non-responses. They do not convert silence into a diagnosis. The operator applies the agreed standard operating procedure, considers the surrounding information, and records the action taken.
Corrections should update the operational picture without destroying the history. A team reviewing the incident later needs to know not only the final position, but also which information influenced decisions at the time.
Why must actions, decisions, and updates remain connected?
When messages, task lists, meeting notes, and decision logs are held separately, the response becomes harder to reconstruct. A status update says that access to a location has changed, but the task assigned in response sits elsewhere. The task is marked complete, but the person taking over cannot see which risk it addressed. A decision is recorded, but the evidence that prompted it is buried in a chat history.
Keeping those elements connected reduces reconstruction. It allows an operator to move from a significant update to the decision it shaped, the task created, the person responsible, the subsequent status, and the next review point. It also makes disagreement easier to manage because participants can see whether they are challenging the underlying information, its interpretation, or the proposed action.
AtlasNXT’s Incident Room is designed to keep significant updates, tasks, communications, decisions, and status changes with one event. This does not remove the need for judgement or command. It gives that judgement a coherent operational context and helps prevent the response from fragmenting across disconnected tools.
Who owns the picture?
A shared picture needs stewardship without centralising every decision.
The function maintaining the record should ensure entries are timely, sources identifiable, duplicates reconciled, uncertainty visible, and actions owned. Leaders still decide within their authority, while field teams and specialists contribute observations and interpretation.
JESIP’s joint doctrine separates these functions while requiring decisions, rationale, and subsequent actions to be recorded. It also recognises that shared situational awareness requires continuous effort as the incident and the responders’ understanding change.4
Access should reflect responsibility. A local operator may need personal and route information. A regional leader may need aggregated status and decisions requiring support. An external partner may require only the information necessary for an agreed task. Shared should mean appropriately shared, not visible to everyone.
AtlasNXT Remits can define geographic areas of responsibility and authorised operator views. Suitable external data can be presented where permissions, format, security, and an approved integration or import allow it. Those controls help structure the picture, while the organisation remains responsible for information governance, classification, and disclosure.
What makes a handover operationally safe?
A good handover transfers understanding, not just open tasks. The incoming team should see the current situation, major changes, people or assets of concern, decisions, unresolved assumptions, overdue actions, communications limitations, and upcoming decision points.
The UK Government’s Amber Book treats reporting cycles, meetings, shift rosters, record-keeping, and the maintenance of a recognised information picture as connected parts of crisis management.2 That is important because the operational rhythm determines whether the picture stays alive. If updates arrive after the meeting that needed them, or if decisions are recorded only at the end of a shift, the dashboard may be visually current while operationally late.
Handover should be built around the incident record. The outgoing team validates the present state, highlights change and uncertainty, and transfers pending actions. The incoming team confirms ownership and records any reinterpretation. A verbal briefing may add nuance, but it should not be the only place where essential context exists.
What happens when connectivity is degraded?
A shared operational picture cannot manufacture information that the field cannot send. It can, however, make the resulting limitations explicit.
The picture should show when an update was created and received, its channel, whether it was acknowledged, when contact is next expected, and whether information is live or last known. This stops an old status appearing current and helps teams prioritise follow-up.
The AtlasNXT app and compatible satellite devices can provide different channel options where appropriate, subject to hardware, airtime, configuration, and the operating procedure. The incident record still needs to show which channel was expected, when information was created and received, whether it was acknowledged, and what the operator did next. ReachScore™ can help expose communication-readiness gaps, but it does not guarantee delivery or replace fallback rules and human judgement.
How does the log become organisational learning?
An after-action meeting cannot recover information that was never captured. It also cannot turn a pile of anecdotes into improvement without analysis and ownership.
The Australian Institute for Disaster Resilience describes lessons management as collecting, analysing, disseminating, and applying learning from events, exercises, programmes, and reviews. It distinguishes observations from insights, lessons identified, and lessons learned through implemented change.6 A recommendation is not yet a learned lesson.
A usable record lets reviewers examine what people knew, how information moved, which assumptions persisted, where ownership was unclear, which channels failed, and whether actions worked. They can compare procedure with practice without relying entirely on memory.
The review should identify patterns, causes, and practical changes. A lesson may require an amended check-in rule, different device allocation, a clearer remit, revised permissions, training, or a new exercise. Someone must own and test the change. Otherwise, the incident has produced an observation, not a learned lesson.
How can privacy and accountability coexist?
Incident records may contain location, health, travel, security, or employment information. The OECD privacy guidelines cover collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, and accountability.7 Applied operationally, those principles support a clear purpose for each data type, role-based access, appropriate retention, correction, and safeguards against unauthorised use. An operator may need identity and last known location, while a senior briefing may need only numbers and status. The organisation remains responsible for the suitable lawful basis, transparency, retention, and access model. Product configuration can support that governance, but it does not replace it.
What should organisations change first?
Start with one realistic incident from initial report to closure. Identify where updates change channel, decisions are made, tasks lose their rationale, and handovers depend on private knowledge. Then decide what the shared picture must show, who is authorised to see it, and which events deserve a structured entry.
Rehearse the process under pressure with an uncertain report, an unavailable decision-maker, a failed channel, a shift change, and a correction. The test is whether the next authorised person can understand what is happening, why the current course was chosen, what still needs action, and when the picture must be reviewed.
An incident log built in this way is not paperwork added to response. It is the response’s working memory. It strengthens coordination while the event is live, supports accountable decisions, and gives later learning a reliable foundation.
References
1. Joint Emergency Services Interoperability Principles, Common operating picture. https://www.jesip.org.uk/joint-doctrine/common-operating-picture/
2. UK Cabinet Office, The Amber Book: Managing crisis in central government. https://www.gov.uk/government/publications/the-central-government-s-concept-of-operations/the-amber-book-managing-crisis-in-central-government-html
3. UK Health Security Agency, Incident response plan. https://www.gov.uk/government/publications/emergency-preparedness-resilience-and-response-concept-of-operations/incident-response-plan
4. Joint Emergency Services Interoperability Principles, Joint Doctrine: The Interoperability Framework, Edition 3.1. https://www.jesip.org.uk/wp-content/uploads/2022/03/JESIP-Joint-Doctrine-Update-April-2024_Web.pdf
5. UK Health and Safety Executive, Key Decision Log. https://www.hse.gov.uk/foi/internalops/og/ogprocedures/investigation/decisionlog.htm
6. Australian Institute for Disaster Resilience, Lessons Management Handbook. https://knowledge.aidr.org.au/resources/handbook-lessons-management/
7. OECD, Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data. https://legalinstruments.oecd.org/public/doc/114/body-text.en.html
