The language of cyber incident response was largely developed around information systems. Detect, contain, eradicate, recover, and learn is a useful sequence when the principal assets are data, applications, identities, and network services.
Manufacturing complicates that model because operational technology, or OT, interacts with the physical world. NIST defines OT as programmable systems and devices that monitor or cause direct changes in physical processes. Its examples include industrial control systems, building automation, transport systems, physical access control, and environmental monitoring.1 A compromised system may therefore affect more than information. It may alter an operator’s visibility, interfere with alarms, change the condition of equipment, interrupt utilities, prevent safe access, affect product quality, or undermine confidence in the process state.
This is not a remote concern for the sector. ENISA’s 2025 threat landscape identified ransomware as the most impactful cyber threat in the European Union. Manufacturing accounted for 2.9 per cent of the incidents in its cross-sector dataset, and cybercrime represented 59.3 per cent of the activity assessed against manufacturing.2 Those figures should not be used to predict the probability of an attack on an individual facility. They do, however, support a more important conclusion: industrial cyber response belongs in mainstream operational resilience, rather than being treated as an exceptional IT exercise.
The decisive moment comes when a cyber event creates uncertainty about the physical operation. At that point, the organisation needs more than a technical incident team. It needs a command structure capable of reconciling cyber containment, process safety, workforce protection, continuity, regulatory duties, customer obligations, and recovery.
The IT–OT boundary is not the incident boundary
An organisation chart may place IT, engineering, operations, safety, physical security, and business continuity in separate functions. The incident will not respect those boundaries.
A compromised corporate identity can provide access to an engineering workstation. A remote-maintenance connection can become a route into an OT environment. Loss of an enterprise planning system can disrupt production even when controllers remain healthy. An unavailable access-control system can affect who may enter a restricted area. Operators may retain control of the plant while losing the data needed to confirm product quality or trace raw materials. A communications outage can leave a technically safe process without a reliable way to direct the workforce.
The UK National Cyber Security Centre’s 2026 guidance explains why the boundary has become more difficult to manage. OT environments, historically centred on safety, uptime, and continuity, are increasingly connected for analytics, remote monitoring, administration, and predictive maintenance. The NCSC warns that legacy technology, third-party vendors, remote access, and supply-chain integrations expand the attack surface, while an intrusion can create physical harm, environmental impact, or disruption to essential services.3
The first governance decision should therefore be a threshold, not a team name. The organisation should define when a cyber event must be managed as a wider operational incident. Useful triggers include loss of confidence in safety-related information, suspected access to an OT zone, degradation of operator visibility, interference with physical access or communications, an unplanned process change, uncertainty about product integrity, or a cyber containment action that could alter the safe state of the plant.
Once such a trigger is met, “IT incident” becomes an inadequate description. Cyber specialists remain essential, but they no longer own every consequence or decision.
Containment can itself change the risk
In conventional IT, rapid isolation or shutdown may be the obvious way to limit spread. In OT, that intervention can affect the process it is meant to protect. Disconnecting a host, disabling remote access, blocking a protocol, or powering down equipment may remove visibility, interrupt an interlock dependency, strand material in an unsafe condition, or prevent engineers from performing an orderly shutdown.
International guidance issued by the Australian Signals Directorate and endorsed by CISA, the UK NCSC, and other national cyber authorities makes “safety is paramount” its first principle for OT cyber security. It asks difficult response questions: whether it is safe to send personnel into a facility when software required for safety may be compromised, whether a restored system can be trusted after an intruder has had access, and whether backups can be validated before they are used.4
These are not questions for the security operations centre alone. The person who understands malicious persistence may not understand the consequence of stopping a furnace, isolating a control link, or losing a particular display. The engineer who understands the process may not know what evidence of compromise remains or whether an apparent recovery can be trusted. Neither perspective is sufficient by itself.
The response structure should give explicit decision rights to people capable of integrating them. Depending on the operation, that may require cyber incident leadership, OT engineering, production, process safety, site management, facilities or physical security, workforce communications, legal and regulatory advice, supply-chain management, and product quality. The full group need not attend every technical discussion. It does need a defined way to decide whether to continue, reduce, isolate, shut down, evacuate, move to manual control, or restore.
This also changes what “containment complete” means. Blocking an attacker’s route may complete a cyber action while leaving the plant in a degraded or uncertain state. Operational containment is achieved only when the organisation understands the new physical condition, has controlled the associated hazards, and has communicated the restrictions to the people expected to work within them.
The common operating picture needs more than a network diagram
During a combined cyber and operational incident, each function sees a different truth. The cyber team may be following indicators of compromise and privileged sessions. Engineering may be concerned with control logic, alarms, instrument readings, and manual alternatives. Production may be assessing output, work in progress, and delivery commitments. Safety staff may be evaluating exposure, isolation, and evacuation. Human resources or site security may be trying to account for employees and contractors.
A common operating picture should not flatten these perspectives into one reassuring status colour. It should show how they relate.
At minimum, the incident team needs a current view of the physical process, the digital systems that support it, the degree of trust in relevant data, the people exposed to the changed conditions, the operational dependencies, and the decisions awaiting authority. Information should retain its source and time. It should also carry a status that distinguishes direct observation from technical verification, reasonable inference, disputed information, and the unknown.
This discipline is particularly important when familiar displays may themselves be untrustworthy. “The tank level is normal” has a different meaning if it comes from a potentially affected human-machine interface, an independent instrument, and an operator’s physical inspection. The response record should preserve that distinction. It should also state which source is being used for the decision and why.
Decision logging must go beyond recording an instruction. A defensible entry explains the option selected, the safety and cyber considerations, the person with authority, any dissent or uncertainty that remains material, the action owner, and the condition that will trigger review. This creates an operational memory for shift changes and provides the basis for regulatory reporting, customer communication, and later learning.
Workforce communication becomes a safety control
People are not merely recipients of a cyber update. They may need to change how they work in order to keep the site safe.
Operators may be told not to trust a particular display, not to connect portable media, or to move to an approved manual procedure. Maintenance personnel may need to stop remote sessions and remain available for verification. Contractors may be prevented from entering an area or asked to account for tools and devices. An incoming shift may need different reporting instructions. Drivers may need to use another gate. A specialist may be required at a remote facility, while non-essential personnel are kept away.
These instructions need an audience, an owner, an issue time, and a way to confirm receipt. A message sent to everybody can create noise while still missing the individual whose task has become hazardous. Conversely, silence from an employee does not prove that they are safe, absent from the site, or refusing an instruction. It is an unresolved information gap that must be handled according to the situation.
The normal communications system may also be part of the incident. If corporate identity, email, collaboration software, or local networks are unavailable or untrusted, the organisation needs pre-agreed alternatives. Those alternatives must be usable with the contact data, permissions, and devices actually available during a disruption, not merely named in a plan.
The European Commission’s July 2026 guidance on resilience measures for critical entities gives this operational problem unusual clarity. It recommends predefined roles, escalation protocols, incident-command structures, documented action plans, and both primary and alternative communication channels. It also addresses surge rosters, competency depth, succession, and workforce recovery.5 The Critical Entities Resilience Directive applies only to entities identified under its scope and national implementation. Nevertheless, the design principle is relevant to any industrial operation: workforce communications are part of the control system for the response.
Suppliers and contractors belong inside the command model
Modern plants often depend on external organisations for automation, maintenance, cloud services, specialist equipment, connectivity, and engineering support. A vendor may hold detailed system knowledge and privileged access while being physically distant from the site. A local contractor may be standing next to the affected equipment without access to the incident record.
NIS2 requires covered essential and important entities to address incident handling, business continuity, crisis management, and supply-chain security, including security aspects of relationships with direct suppliers and service providers.6 Specified manufacturing subsectors fall within the Directive, subject to the entity-size rules, national transposition, and other scope provisions. Organisations should obtain jurisdiction-specific advice rather than assuming that every manufacturer is covered in the same way.
Whatever the legal position, supplier integration is an operational necessity. The response plan should establish who can suspend or reauthorise remote access, how a vendor proves the identity of an engineer, which diagnostic information may be shared, how emergency access is monitored, who can direct an on-site contractor, and how supplier evidence becomes part of the main incident record.
The NCSC advises that emergency “break-glass” access should not become a normal remote-access method and that any attempt to use such an account should generate the highest-criticality alert in the security operations centre.7 This is a useful example of cyber and operational governance meeting at one point. Emergency access may be necessary to support recovery, but its use must be visible, attributable, time-bound, and reviewed.
The same principle applies to physical attendance. Before a vendor engineer is sent into an affected area, somebody must be able to confirm that the task is necessary, that the conditions are safe enough, that the individual has received the current instructions, and that the activity will not destroy evidence or introduce another uncontrolled change.
Regulatory reporting depends on an evolving, honest record
NIS2’s reporting sequence recognises that significant incidents develop over time. Covered entities must provide an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report generally within one month of that notification.8 National implementation determines the precise reporting route and obligations.
The important operational lesson is that the first account will often be incomplete. A response system should allow the organisation to update its understanding without rewriting history. It should show what was believed at the 24-hour point, what evidence changed the assessment before the 72-hour notification, what consequences became known later, and which remedial measures were completed.
This protects credibility. A premature claim that production is unaffected, no data was accessed, or safety systems remained trustworthy may be difficult to correct once it has been communicated to regulators, customers, employees, and the public. It is better to identify a fact as unverified than to give an assumption the authority of a conclusion.
Legal reporting is only one audience. Customers may need to understand product or delivery implications. Insurers may require notice. Workers and representatives may need safety information. Emergency services or environmental authorities may need operational details. Each communication should draw from the same controlled incident record while respecting the recipient’s purpose, confidentiality, and legal basis.
Recovery is not the same as restoring a backup
Backups are essential, but possession of a backup does not establish that a physical process is ready to resume. NIST’s 2026 OT Backup Quick Start Guide says effective OT backup management should be integrated with change management, performed regularly, tested, and reviewed during recovery exercises.9 The emphasis on change management matters because a technically clean but obsolete configuration can still be operationally wrong.
The European Commission’s 2026 critical-entity guidance recommends phased restart protocols, prioritisation based on risk and business impact, systematic validation of critical systems, integrity and functionality testing, quality control, gradual capacity increases, and performance monitoring.10 This is a considerably richer model than “systems restored”. It treats restart as a controlled transition between operational states.
That approach is consistent with long-established process-safety guidance. The UK Health and Safety Executive says start-up and shutdown should be ordered and phased so that interlinked plant operations resume or cease safely and under control. It also stresses that procedures should reflect actual plant practice, identify roles, address emergency operation, and verify that equipment and instrumentation are fit for purpose.11
After a cyber incident, the restart authority should therefore ask several kinds of question. Is the recovered configuration the intended one? Has the organisation established an acceptable basis for trusting the control logic, displays, alarms, and engineering data? Are independent safety protections available? Are temporary manual controls understood and staffed? Have remote connections and supplier accounts been reauthorised deliberately? Can raw materials, work in progress, and finished product be traced and accepted? Are environmental, access, and emergency arrangements functioning? What conditions will stop the restart if new evidence appears?
The answer may be a staged resumption, not a single decision. One line, utility, or support function may return while another remains isolated. Production output may need enhanced inspection. Operators may require additional briefings or supervision. Cyber monitoring may remain elevated. The incident is not closed merely because equipment is moving again.
Exercise the decisions, not just the malware
Many cyber exercises reward the technical team for identifying an attack. Industrial exercises should also expose the operational decisions that the attack makes necessary.
A valuable scenario might withhold confidence in a safety-related display, place a contractor inside the affected zone, make corporate communications unavailable, and introduce pressure to meet a customer deadline. The purpose is not to surprise participants with ever more dramatic injects. It is to test whether the organisation can recognise the operational threshold, convene the right authority, preserve uncertainty, issue usable instructions, control third-party access, and define a safe basis for recovery.
The exercise record should capture where teams used different terminology, where approval stalled, which contact data failed, whether alternative channels worked, and which restart criteria were missing. The Commission guidance recommends after-action reviews and root-cause analysis, with findings integrated into procedures, training, and risk assessments.12 An action is not complete when a recommendation is entered into a tracker. It is complete when the revised control has been implemented and, where practicable, tested.
Where AtlasNXT fits
AtlasNXT is not an OT security product, a malware-detection system, or a replacement for engineering control. Its relevant role is in the human and incident-management layer around the technical response.
It can help an organisation bring incident information, affected people, location context, communications, acknowledgements, and the developing event history into a shared operational view. That can support targeted instructions, workforce accounting, cross-functional handover, and a clearer record of decisions and actions. Specialist cyber, engineering, process-safety, quality, and regulatory systems remain necessary.
The value of joining those layers is practical. A cyber team may know which asset is compromised. An operations team may know what the asset means to the process. A site team may know who is currently exposed. Leadership needs those facts to meet in one controlled response without pretending that any one function possesses the whole picture.
The most resilient manufacturer is not the one that can restore a server fastest. It is the one that can recognise when a digital event changes physical risk, exercise authority across IT and OT, communicate with the people whose work must change, and restart only when the organisation has a defensible basis for doing so.
Book an AtlasNXT demonstration to explore how joined-up incident management and workforce communication can support an industrial response.
References
2. European Union Agency for Cybersecurity, ENISA Threat Landscape 2025, revised January 2026
8. European Union, Directive (EU) 2022/2555, Article 23: Reporting obligations
11. UK Health and Safety Executive, Operating procedures, updated August 2025
