ServiceNow Security Incident Response for Manufacturing

Security incident response in manufacturing has to protect two kinds of system with different priorities. IT systems hold data that must stay confidential, while operational technology controls equipment where human safety and production continuity come first. This guide covers OT considerations, network segmentation, detection, isolation and containment, recovery, and who can stop a production system.

How Manufacturing Organizations Use Security Incident Response

Manufacturing organizations face security threats to their information systems and to their operational technology systems. A breach of IT systems might expose business plans or financial data. An attack on operational technology might disrupt production, compromise product quality, or create safety risks to employees. Security Incident Response in manufacturing must address both types of threats with different approaches and different response teams.

Manufacturing organizations also supply products to customers; a security incident that affects their manufacturing capability can affect customer supply chains and damage business relationships. This creates pressure to restore operations quickly while investigating the incident thoroughly to prevent recurrence.

Operational Technology Security Considerations

Operational technology systems—manufacturing equipment, process control systems, safety systems—have different security characteristics than IT systems. OT systems are often older, designed before security threats were anticipated. Many OT systems cannot be patched without risking production downtime. OT systems may have complex interdependencies where changes to one system affect others in ways that are not obvious.

Security incident response in OT must account for safety. If a safety system is compromised, human safety is at risk immediately. Response may require taking equipment offline even if it impacts production significantly. Coordinate with safety teams and equipment manufacturers when investigating OT security incidents.

Segmentation and Isolation Strategies

Implement network segmentation between IT and OT systems so that an attack on one does not directly compromise the other. OT systems should be on separate networks with controlled access from IT systems. If an IT system is compromised, this segmentation prevents the attacker from accessing OT systems directly. However, the attacker might find other ways to access OT, so segmentation is defense-in-depth, not complete protection.

Document the connections between systems so you can trace how an attack might spread. If IT is compromised, what OT systems are reachable? What happens if critical OT systems are affected? Use this understanding to design incident response procedures and to test response playbooks.

Detection and Response Priorities

In manufacturing, the priority is different from other industries. In IT, the priority is protecting data confidentiality and system integrity. In manufacturing, the priority is ensuring safety and maintaining production. An incident that threatens safety requires immediate response even if it affects production. An incident that threatens data confidentiality can be handled with more deliberation and investigation time.

Establish incident severity levels based on impact to safety and production, not just on technical severity. A minor malware infection affecting an office system is low priority. The same malware affecting a production control system is critical priority. Educate incident responders about these manufacturing-specific priorities so they make appropriate decisions.

Isolation and Containment Strategies

When a manufacturing system is compromised, immediate containment is critical. If the attacker is disrupting production, the fastest response might be to take the affected equipment offline to stop the disruption. This is a trade-off: stopping production to prevent further damage. However, if the equipment is safety-critical, isolation may be necessary for safety reasons regardless of production impact.

Work with operations and safety teams on containment decisions. Do not make these decisions unilaterally from IT. The operations team understands production impact and can advise whether it is better to take equipment offline or to continue operating while investigating. Safety team must make the final call on safety-critical systems.

Recovery and Restoration Procedures

Recovery of manufacturing systems requires more than restoring from backups. Equipment must be verified safe before resuming production. Restored systems must be validated to ensure they are not re-compromised and that they work correctly with equipment. Product quality must be verified after incidents affecting manufacturing systems. Test batches may be needed to ensure quality was not compromised.

Some manufacturing environments may use air-gapped systems or immutable backups for critical OT systems. These provide faster recovery if compromised. Plan recovery approaches before incidents occur and practice them periodically.

Who holds the authority to stop a production system during an intrusion

The hardest decision in a plant security incident is rarely technical. It is who is allowed to pull a machine off the network or stop a line while the investigation is still open. In most plants that authority is split across three people who each see a different risk: the security lead sees the spread of an intrusion, the operations manager sees the cost of stopping, and the safety lead sees the hazard of a controller behaving unpredictably. If the incident record does not name who decides when those interests conflict, the decision gets made in a corridor by whoever is loudest. Settle this before an incident, write it into the response record as a named decision step, and make the platform route the decision to that person rather than to whoever opened the ticket.

Pre-agreeing the authority also protects the security team. An analyst who isolates a controller without the operations and safety sign-off has taken a decision outside their remit, even if it was correct, and that becomes the story of the review rather than the intrusion itself.

Choosing between isolate, restrict and observe

Containment on plant systems is not a single action. A useful response model offers three options and records which was chosen and why. Isolating a system stops the spread but may halt output. Restricting it, for example by blocking remote sessions and changing credentials while leaving local control running, keeps the line moving but accepts more risk. Observing it under heightened monitoring is only defensible where the evidence shows no path to a safety function. Use the rows here as a prompt for the decision record, with the plant’s own risk assessment still governing the outcome.

Evidence on systems that keep few logs

Many plant controllers record little beyond their own operating state, so the usual forensic routine of collecting centralized logs often finds very little. Plan for this before an incident. Identify which systems can export configuration and program state, which keep a local history, and which send events to a historian or a network monitor. Preserve those sources first, before any restart, because a restart can overwrite the only record of what the controller was doing. Where the vendor’s own tooling is needed to read a controller, record who had that tooling and where the copy of the project file is held.

1. Record the time the incident was first noticed and by whom, separately from the time it was confirmed.
2. Capture controller configuration and any available operating history before anyone restarts or reflashes a device.
3. Note the network path between the affected system and the nearest monitored segment, so the investigation can test whether traffic crossed it.
4. Agree the restart criteria with operations and safety before the system is brought back.
5. After restart, check the output against a known-good reference, not only that the controller reports healthy.

Communicating with customers and partners without guessing

A plant incident often reaches customers through delayed orders before anyone says the word security. Decide in advance who speaks to key customers, what they are told about delays, and what they are told about the cause. Early statements should describe the operational effect that is known and the next update time, rather than speculating about how the intrusion happened. Keep a log of every external statement in the incident record, because inconsistent accounts given to different customers are a common source of later dispute.

Signs the response process needs rework

A response process that works on paper can still fail on a plant. Watch for incidents where the operations or safety sign-off arrives after the decision was already taken, which indicates the authority step is not being used. Watch for restarts recorded without a verification step, and for incidents closed while the root cause was still open. Those patterns show that the record is being completed for compliance rather than for learning.

Questions that come up in the first tabletop exercise

Should the response plan cover controllers that the IT team does not know exist?

Yes. The plan should assume there are unlisted devices, and the first step of any OT incident should include a check of what is actually on the segment. A response written only against the asset register will miss the device that caused the problem.

How often should the playbook be rehearsed?

Rehearse on a schedule the plant can sustain, and rehearse the decisions rather than the technical steps alone. The most useful exercises test who is called, who decides, and what happens when the operations manager and the security lead disagree.

Can the platform trigger containment automatically?

It can open the record, route the decision and notify the people who hold authority. Automatic containment on a live production system should be limited to actions that are reversible and have been agreed with operations and safety in advance.

Related guidance is in the manufacturing vulnerability response guide and the manufacturing business continuity guide, which covers recovery sequencing. The security incident triage article sets out the intake side in more detail.