An IT incident handover must respect the physical process

A suspicious connection from an office laptop and the same observation from a system supporting a production line can require very different responses. The security evidence may look similar. The operational consequences of interrupting the device may not.

For a security operations lead, the challenge is to bring the right evidence into the OT response without assuming that familiar IT containment actions are appropriate. The handover should accelerate a joint decision, not create a contest over which team owns the incident.

The physical process changes the question

NIST SP 800-82 Revision 3 treats performance, reliability and safety as distinctive OT requirements. Its scope includes industrial control, building automation and other systems that interact with the physical environment. Revision 4 has entered public draft, while Revision 3 remains the published final guide.

The implication for an IT responder is to identify what the observed system does before proposing a change. A label in an asset inventory may be incomplete or outdated. The operational team can explain the current process state, dependencies and consequences that an IT-only view does not show.

That does not mean waiting silently while an incident develops. It means escalating a precise observation to someone who can assess both cyber and process consequences, using the site’s established response arrangements.

Transfer facts that another team can use

The initial handover should identify the device or service, time of observation, relevant evidence and confidence in the association. Separate what was observed from what is inferred. “Connection to this destination at this time” is a different statement from “the controller is compromised”.

Include actions already taken and information still missing. If an IT team has changed a related account or network rule, the OT team needs to know. If the device identity is uncertain, preserve that uncertainty instead of allowing a plausible hostname to become an established fact.

In a hypothetical incident, IT sees unusual traffic associated with a host used by an engineering team. The first useful step is to establish whether it currently supports a physical process, maintenance activity or an unrelated workload. That answer shapes who should assess the event and which interventions are available.

Authority needs to survive a shift change

Agree the decision route before the incident. The operational contact should be able to reach the people responsible for process continuity and safety, while the security team supplies evolving evidence and threat assessment. A generic instruction to “contact operations” is too weak if it reaches an unattended mailbox overnight.

Keep the rationale for accepted and rejected actions in the incident record. Incoming responders should not repeat a proposal already ruled out because of a process dependency. Equally, a restriction that made sense earlier may need reassessment when the operating state changes.

The shared record should make the next decision clear without pretending every team has the same authority. That is a useful extension of the incident response plan, rather than a separate plan that starts from scratch whenever OT is involved.

Recovery has more than a technical finish line

Restoring a host, reconnecting a network path or clearing an alert does not by itself establish readiness to resume the physical process. The operational team needs its own acceptance conditions and a controlled return-to-service decision.

Include dependencies on specialist suppliers and site personnel in planning. If a recovery step requires someone who cannot be reached, that is a capability gap to resolve before relying on the plan. Exercises should test the handover and authority route under appropriate site controls.

Practise the conversation, not only the escalation number

A tabletop can expose whether the teams understand each other’s evidence and decision needs. Ask the IT team to describe an ambiguous observation, then have operations explain what additional context would change its response. Follow the exchange through a shift handover and recovery decision.

The result should be a faster route from credible evidence to an authorised action. IT contributes visibility and investigation; operations contributes process knowledge and authority. A joined-up response makes both stronger without assuming that an office IT procedure can be transferred unchanged.