Mature infrastructure groups already hold large volumes of safety information. A project may use digital permits, access control, vehicle systems, operational telemetry, inspection records, weather feeds, site inductions, and formal incident reporting. Each system has a legitimate purpose and may be well established.
The harder problem appears when an event crosses the boundary between them. A security report may affect access to a work area. A utility failure may alter a safe system of work. Severe weather may isolate a site, interrupt communications, and delay specialist support. A vehicle incident may require local action, a contractor response, central oversight, and a reliable account of what happened. The facts needed to manage the event exist, but they are held by different people, at different levels, in different systems.
For a multi-project organisation, duty of care therefore depends on more than strong arrangements at each location. It needs a group-wide operating model that can connect local control with wider support. That model should preserve project authority, reflect different privacy and security requirements, and continue to function when the preferred communications channel is unavailable.
The aim is consistency in how an incident is understood and managed, rather than uniformity in how every person, site, or asset is monitored.
Why is the enterprise problem different from a site safety problem?
A site team can build procedures around a known workforce, a defined geography, and a familiar set of hazards. A large infrastructure group must also manage the boundaries between projects, employers, clients, joint ventures, suppliers, and operating phases. Those boundaries change over time.
During planning and design, decisions determine whether risk is eliminated, reduced, or carried into delivery. During mobilisation, the main concern may be whether people have been inducted, contact details are current, and escalation routes are understood. During construction, the operating picture may involve multiple contractors, temporary access arrangements, changing work fronts, and high-risk activities. Commissioning introduces new interfaces between construction and operational teams. Long-term maintenance creates a different pattern, with smaller teams travelling between assets and sometimes working without close supervision. A response model built only for a fixed construction site will not cover that full lifecycle.
UK construction guidance reflects the importance of these interfaces. Under the Construction Design and Management Regulations 2015, principal contractors must plan, manage, monitor, and coordinate health and safety during the construction phase. They must also organise cooperation between contractors and coordinate their work.1 The legal duties remain with the relevant dutyholders, but the operational lesson is broader. Information has to cross organisational boundaries without making responsibility ambiguous.
Other jurisdictions allocate duties differently, so the legal analysis and operating procedures must be adapted locally.
This becomes difficult when each business unit has its own reporting routes, each project has local tools, and central teams receive information only after a threshold has already been crossed. The group may have strong controls at every level and still struggle to create a timely, shared account of an event.
Where do mature digital systems still leave operational gaps?
Digital maturity can make fragmentation less visible. More data arrives, dashboards improve, and individual processes become faster, but the response still depends on people reconciling separate records under pressure.
A permit system can confirm that work was authorised. Access control can record an entry. A fleet platform can show a vehicle event. A building or operational system can report an alarm. A safety platform can hold an investigation. None of those records necessarily establishes who has taken charge of the combined situation, which people may be affected, what instruction is in force, or which decision is overdue.
The remaining problem sits between specialist systems. The answer is not to discard useful platforms to create a single screen. It is to bring the signals relevant to a live response into a controlled workflow that adds context, assigns ownership, reaches the affected population, and retains the resulting decisions and actions.
A useful incident layer has a narrow role: use only the information needed for a defined decision while leaving specialist source systems authoritative. The incident record then shows how that information shaped the response.
Operational technology requires particular care. The National Cyber Security Centre advises that data exchange between operational and information technology should use controlled, segmented connections, with secure and standardised protocols, rather than direct access from business systems into operational environments.2 Where operational data is relevant to duty of care, the integration should be justified, brokered through an approved architecture, and limited to what the response genuinely needs.
What should remain consistent across every project and service?
The group needs a common incident language. The details of a major project, an operational asset, a mobile maintenance team, and a higher-assurance site will differ, but the governing questions are stable.
A reliable incident record answers a small set of questions. What happened, where is it happening, what is confirmed, and what remains uncertain? It names the incident lead, the people and assets potentially affected, and the current objective. Communications identify their audience, authority, and required response. Actions have owners and due times. Decisions retain the information available and the reasoning used. Unresolved matters remain visible until deliberately accepted, reassigned, or closed.
ISO 22320 describes incident management through roles and responsibilities, tasks, resource management, joint direction, and cooperation. It applies when several organisations work together while retaining their own structures.3 That is a useful model for infrastructure delivery, where the principal contractor, client, specialist suppliers, public authorities, and asset operator may all participate in the same response without surrendering their separate responsibilities.
Consistency belongs in the structure of the response. It does not require identical site procedures or a central team taking control of every local event. Local plans can still reflect the asset, contract, hazards, security restrictions, and available resources. The common structure allows another authorised team to understand the position quickly and offer support without first translating an unfamiliar process.
How should location be used without turning safety into surveillance?
Location can be valuable during remote work, travel, an evacuation, or an incident that affects a defined area. It can also become disproportionate when it is collected continuously without a clear operational purpose.
The right model depends on the work and the risk. A person operating alone in an isolated location may need planned contact, a reliable way to request help, and a process that identifies a missed return. HSE guidance emphasises risk assessment, communication, monitoring, support, and procedures for confirming that lone workers have completed their work safely.4 A person working routinely in a low-risk office has a different relationship with location data.
Current ICO guidance makes that difference explicit. Worker monitoring must be lawful, transparent, necessary, and proportionate. Organisations should define the purpose, use the least intrusive approach that can achieve it, minimise the information collected, control access, set appropriate retention, and carry out a data protection impact assessment where the risk warrants one.5 Employment consent should not be treated as an easy answer because the imbalance between employer and worker can prevent consent from being freely given.
An infrastructure group should consequently support several visibility modes. Live location may be appropriate for a time-limited journey or high-risk activity. Event-based sharing can provide context when a person raises an alert, begins a task, or chooses to check in. Where it is configured and site policy permits, a fixed QR code can open a site- or asset-specific reporting form. A managed check-in can establish welfare without collecting a continuous trail. Some sites will require a manual or delayed update because personal devices cannot be used.
These methods are not equivalent evidence. A reported position does not prove that somebody is safe. Scanning a code does not establish continuous presence or identity by itself. Failure to respond is an unresolved status, not automatic evidence of danger or safety. The operating procedure must state what each signal means and what a responsible person should do next.
What should happen when connectivity is weak or unavailable?
Digital duty-of-care workflows can fail when they assume mobile data will always be available. Coverage can be intermittent in rural areas, tunnels, cuttings, temporary compounds, and newly developed sites. Network congestion or local disruption can also affect otherwise well-connected locations.
Resilience starts by identifying which communications are essential, who needs them, and how long the organisation can safely tolerate a delay. The Cabinet Office advises organisations to consider diverse technical solutions, layered fallback arrangements, and planned information exchange because no single communications method provides complete resilience.6
For an infrastructure group, that can mean using smartphones where cellular service is available, approved satellite devices for defined remote operations, and site-specific alternatives where neither is suitable. The workflow must preserve the distinction between a message being created, sent, delivered, acknowledged, and acted upon. A silent device or missing data point should remain visible as uncertainty.
A resilient platform fails intelligibly. Operators need to see which connection or data source is unavailable, when it was last known to be current, and what fallback procedure applies. Describing a system as continuously connected can encourage unsafe assumptions. A tested response to loss of connection is more useful than a promise that disconnection will never occur.
How can higher-assurance projects fit the same group model?
Some projects impose stricter rules on devices, data, access, retention, or third parties. Those controls change what can be captured and shared, but they do not change the need for clear incident ownership, communications, actions, decisions, and closure.
NPSA guidance for major infrastructure projects stresses clear governance, early risk assessment, and an accountable client role in setting security requirements and risk appetite.7 Before deployment, the organisation must determine what information is permitted, where it may be processed, who may see it, which integrations are authorised, how long records are retained, and which fallback applies when normal devices or networks cannot be used.
Different projects can then use different technical modes within the same response structure. A connected site may use the full relevant capability, a remote project may add communications resilience, and a higher-assurance environment may reduce or delay data flows. Group consistency comes from shared governance and evidence, not from forcing one configuration everywhere.
How should operational responsibility be divided between project teams and group functions?
Local teams know the asset, immediate hazards, available resources, and client arrangements. Group functions can see dependencies across projects, provide specialist support, allocate scarce resources, and identify repeated weaknesses. An effective model allows each level to act within defined authority.
Local ownership must be visible from the start of the incident. The project team needs enough control to assess the event, issue immediate instructions, and coordinate the response permitted by its plan. Group oversight becomes valuable when consequences cross a project boundary, specialist advice is required, communications affect a wider population, or a decision exceeds local authority.
The platform should show this division instead of obscuring it behind broad administrator access. Geographic or organisational areas of responsibility can direct alerts and information to the right team. Role-based permissions can limit what each participant sees and changes. Group leaders can receive an appropriate summary and open the underlying record when authorised, while project teams retain a working view suited to their responsibilities.
Joint ventures and major suppliers need the same clarity. A shared operational picture does not imply shared legal authority. Each participant needs to know who leads, what they are responsible for, what information they may access, and how decisions move between organisations. The common record helps cooperation, while the governance model preserves accountability.
What turns an alert into an accountable response?
An alert identifies a condition that may require attention. Incident management begins when somebody assesses that information, defines the scope, takes ownership, and sets the first objective.
The initial record should be useful even when facts are incomplete. It can distinguish confirmed information from reports or assumptions, identify potentially affected people and places, and state what must be established next. As the event develops, relevant updates, communications, tasks, decisions, and changes in status should accumulate in one chronological thread.
Communication is part of that process. The response team may need to contact a single field worker, a work group, everyone associated with a site, or a wider organisational population. A message count alone is of limited value. Operators need to see whether people could be reached, whether a message was delivered, whether a response was requested, who responded, and which exceptions still require attention.
ReachScore™ helps AtlasNXT customers examine communication readiness before an incident by showing potential gaps in reachability. It does not guarantee that a message will be delivered or that a recipient will act. It makes known weaknesses easier to address while there is still time to do so.
During the response, tasks connect decisions to accountable action. A task needs a named owner, a time expectation, and a clear completion state. If a decision depends on a field update, the relationship should be visible. If incident leadership passes at the end of a shift, the incoming lead should inherit the current objectives, open actions, unresolved information, and active instructions rather than a separate narrative assembled from memory.
UK emergency-response guidance places similar weight on information management. It says information must be collected, assessed, verified, and disseminated through systems that support decision-making.8 The relevant organisational structures will differ, but the underlying requirement applies just as strongly to a private infrastructure group.
How can incident records improve the next project?
A useful incident record is built as the response unfolds. It captures the sequence of material information, decisions, communications, and actions without requiring the team to reconstruct that history afterwards.
Its immediate purpose is continuity and scrutiny. Its longer-term value is organisational learning. A single project can identify a local corrective action. A group can look across comparable incidents and ask whether the same communication delay, unclear ownership, missing contact data, or integration failure appears elsewhere.
The Cabinet Office describes a lesson as an evidence-based conclusion drawn from incidents, exercises, and reviews. Its lessons-management guidance connects the capture and analysis of observations to assigned recommendations, implementation, and the retention of change.9 That process needs reliable source material. If the record is reconstructed from separate calls, messages, and recollections, the review may spend more time establishing what happened than improving what should happen next.
Group learning must still respect security and privacy boundaries. A sensitive incident may need to be abstracted before it is shared. Personal data may need to be removed, and restricted operational detail may remain within the authorised project team. The transferable lesson can often be expressed as a change to a threshold, procedure, role, or fallback without distributing the full source record.
What should a serious proof of concept test?
A feature demonstration proves only that individual functions exist. A serious proof of concept tests whether the operating model survives real constraints.
Use scenarios drawn from several parts of the business. One might involve a connected project with a mixed workforce. Another should involve remote activity with intermittent cellular coverage. A third should impose device and information restrictions. The purpose is to see whether the same governance structure can work through different technical modes.
Include incomplete or conflicting information, an unavailable data source, a worker who does not respond, a handover between teams, and a decision that exceeds local authority. Test how the platform records uncertainty, how operators recognise a communications failure, and how the fallback procedure is activated. The scenario should also show what information reaches central oversight and what remains within the project.
Put security and privacy inside the proof. Test identity and access management, separation between projects or clients, data minimisation, retention, auditability, authorised integrations, and the effect of a lost or compromised device. If a client imposes higher-assurance requirements, test those controls directly rather than inferring them from a general demonstration.
Measure operational outcomes. The group should ask whether the right team took ownership, whether affected people were identified with appropriate confidence, whether messages and non-responses were visible, whether decisions became assigned work, whether a handover preserved continuity, and whether the record supported a meaningful review.
How does AtlasNXT support this operating model?
AtlasNXT connects location context, communications, Check-Ins, incident management, and operational responsibility in one response workflow. It complements established safety, project, fleet, intelligence, and operational systems and uses only the authorised information needed for the response.
Remits define geographic areas of responsibility and determine which authorised operators can manage relevant information. The Incident Room keeps significant updates, communications, tasks, decisions, and status changes attached to the same event. Mass notifications and Check-Ins help teams contact configured audiences and keep non-response visible for an operator to manage under the agreed procedure.
The AtlasNXT app lets smartphone users receive alerts, respond to Check-Ins, and use location-enabled safety functions where appropriate. Compatible satellite devices can provide an alternative for selected users beyond cellular coverage, subject to the hardware, airtime service, available data, and integration configuration.
Where an approved integration or import exists, AtlasNXT can present authorised data from existing systems within the incident workflow. The precise configuration should follow the risk assessment, privacy model, site rules, connectivity plan, integration architecture, and authority structure. AtlasNXT does not replace statutory duties, project leadership, specialist safety systems, or human judgement. It gives those responsible for the response a common place to understand what is happening, coordinate the next action, and retain the evidence needed to learn.
For a large infrastructure group, that creates a practical form of consistency. Each project can use controls suited to its environment, while the organisation retains a common approach to ownership, communication, incident coordination, escalation, and review.
Book a free AtlasNXT demonstration to explore how this operating model could be applied across your project and service portfolio.
References
1. Health and Safety Executive, Summary of duties under the Construction Design and Management Regulations 2015.
2. National Cyber Security Centre, Secure connectivity principles for operational technology, Principle 4, 2026.
3. International Organization for Standardization, ISO 22320:2018 Security and resilience, Guidelines for incident management.
4. Health and Safety Executive, Protecting lone workers, INDG73 rev4.
5. Information Commissioner’s Office, Data protection and monitoring workers.
6. Cabinet Office, Emergency response and recovery, section on resilient telecommunications.
7. National Protective Security Authority, Major infrastructure projects, security considerations for clients.
8. Cabinet Office, Emergency response and recovery, section on information management.
9. Cabinet Office, Lessons Management Best Practice Guidance, 2024.
