Organisations should treat IT and OT as linked risk surfaces, not separate silos. A workable programme starts with continuous risk assessments across both domains, then maps how business systems can affect operational systems and vice versa. That approach helps teams prioritise controls, test recovery assumptions, and reduce the chance that an IT incident cascades into safety or operational disruption.
How to structure a single programme across IT and OT
The strongest programmes start by defining one governance model and two operating contexts. IT and OT should share the same risk language, ownership model, escalation paths, and recovery objectives, while still allowing OT-specific engineering constraints such as safety interlocks, uptime sensitivity, and patch windows that cannot mirror standard IT cadence.
The practical implication is that the programme cannot be built around a generic checklist alone. It needs a clear view of business services, plant processes, remote access paths, third-party dependencies, and the points where an IT control change can alter an OT outcome. That is where a combined industrial control systems security view and an OT-specific reference point such as NIST SP 800-82 Rev 3 help teams translate shared policy into environment-appropriate controls.
A useful internal navigation point is NHIMG’s Ultimate Guide to NHIs, because many IT to OT pathways are driven by service accounts, API keys, integrations, and automation that sit between business systems and operational tooling.
Control priorities that matter in both domains
The programme should prioritise segmentation, asset visibility, identity and access governance, logging, and recovery testing before lower-value optimisation work. In mixed environments, the common failure is assuming that a control is effective because it exists in IT, when the OT implementation may have different tooling, different monitoring fidelity, or different operational blast radius.
That is why recovery planning has to be grounded in realistic dependencies. If an identity, endpoint, or network control in IT can interrupt historian access, patch orchestration, remote engineering, or vendor support into OT, then the control must be assessed for both security benefit and operational side effects. The same logic applies in reverse: OT visibility gaps can mask compromise that later reaches IT through trusted interfaces. For broader control design, CIS Controls v8 gives a practical baseline for inventory, access control, logging, and vulnerability management, while CISA Secure by Design is useful for pushing vendors and internal teams toward safer defaults.
Where shared credentials, service accounts, and third-party access paths are material, NHIMG’s 52 NHI Breaches Report is a useful reminder that compromise often enters through operationally convenient but weakly governed access rather than through a dramatic perimeter failure.
Risk, resilience, and practitioner judgment
Mixed IT and OT programmes fail when leaders treat resilience as a restoration exercise only. The real question is whether an incident in one environment can safely degrade the other without causing unsafe states, loss of visibility, or uncontrolled manual workarounds. That means testing not just backups, but assumptions about isolation, remote access revocation, failover timing, and who is authorised to override automated controls.
Failure mechanism: Shared dependencies, overly trusted connections, and uneven control maturity let an IT compromise move into OT, or let an OT issue disrupt critical business systems, before defenders detect the coupling.
Impact: The result can be safety exposure, production interruption, delayed recovery, or loss of confidence in both environments at once, which is far harder to contain than a single-domain incident.
Practitioner Guidance: Start with the highest-consequence pathways, especially remote access, engineering workstations, identity brokers, and vendor interfaces, because those are the links most likely to turn a contained issue into cross-environment impact. Verify that every shared service has a named owner, a recovery test, and a documented break-glass process that still works when normal tooling is down.
Practitioner takeaway: The programme should be designed around coupled failure modes, not organisational charts, because the control that looks strongest in one environment can be the control that creates the largest cross-domain dependency in the other.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | A unified IT/OT programme needs enterprise risk treatment across both environments. |
| PR.AC-1 — Identity Management, Authentication, and Access Control | Cross-environment access paths and remote access are central to IT/OT coupling. | |
| RC.RP-1 — Recovery Plan Implementation | The question centres on recovery assumptions and avoiding cascade effects between environments. | |
| Recommendation — Define one shared risk model for IT and OT and use it to prioritise cross-domain controls. Restrict shared access paths and enforce least privilege across IT and OT. Test recovery plans for cross-domain dependencies and operational failover constraints. | ||
| CIS Controls v8 | 1 — Inventory and Control of Enterprise Assets | A joint programme depends on visibility into assets spanning IT and OT. |
| 6 — Access Control Management | Shared accounts, remote access, and third-party pathways drive cross-domain exposure. | |
| 17 — Incident Response Management | A common programme must coordinate response when incidents cross IT and OT boundaries. | |
| Recommendation — Maintain accurate asset inventories for both IT and OT and tie them to control ownership. Review and restrict access paths that can bridge IT and OT. Build incident playbooks that account for IT to OT escalation and containment. | ||
| NIST Zero Trust (SP 800-207) | SC-4 — Enforcement of Dynamic Policy | Zero Trust policy enforcement is useful where trust boundaries span IT and OT connections. |
| SC-7 — Continuous Diagnostics and Mitigation | Continuous assessment is needed because IT and OT conditions change independently. | |
| Recommendation — Apply policy enforcement at shared access points and do not assume network location implies trust. Continuously validate device posture and access conditions across both environments. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Identity assurance matters for the human and service access used to operate coupled environments. |
| AAL — Authenticator Assurance Level | Stronger authentication is material for privileged and remote access into shared operational paths. | |
| Recommendation — Set assurance requirements for operators and privileged access that touches OT. Require strong authenticators for access paths that can affect OT operations. | ||
Related resources from NHI Mgmt Group
- How should organisations build a GDPR compliance programme that actually covers data collection, processing, and retention requirements?
- How should organisations build a VCDPA compliance programme that covers notices, access requests, assessments, and third-party contracts?
- How should organisations manage privileged access in IoT and ot environments?
- How should organisations build a PII protection programme that actually holds up in practice?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
