IT/OT Cybersecurity Integration Checklist

Introduction

IT/OT integration can improve visibility, maintenance, planning and analytics. It also creates pathways between enterprise systems and environments where availability, safety and physical process integrity are central.

Industrial cybersecurity cannot be copied directly from office IT. Patching, scanning, identity, remote access and incident containment must account for vendor support, control-system timing, equipment lifecycle, production schedules and safe shutdown. At the same time, “OT is isolated” is no longer a sufficient control when remote support, historians, cloud platforms, engineering workstations and business integrations already cross the boundary.

This checklist helps organizations secure IT/OT integration through asset knowledge, architecture, access, monitoring, resilience and joint operational governance. It supports assessment and planning; it does not replace a site-specific engineering, safety or cybersecurity review.

Table of Contents

1. Establish governance and safety context
2. Inventory assets and communication
3. Classify zones, conduits and criticality
4. Control identity and privileged access
5. Secure remote access and vendors
6. Protect endpoints and engineering activity
7. Govern data flows and cloud integration
8. Manage vulnerabilities and change
9. Monitor the OT environment
10. Prepare incident response and recovery
11. Secure new IIoT and AI initiatives
12. Assess suppliers and lifecycle
13. Measure cybersecurity readiness
14. Common integration failures
15. Detailed checklist
16. Frequently asked questions

Establish Governance and Safety Context

Assign accountable roles across:

• plant and operations leadership;
• OT/control engineering;
• corporate IT and infrastructure;
• cybersecurity operations;
• process safety and physical security;
• maintenance and reliability;
• application and data ownership;
• vendors and system integrators;
• risk, legal, privacy and compliance;
• business continuity and crisis management.

Define who can approve architecture, remote access, production change, emergency action and risk acceptance. Cybersecurity controls that affect process operation require coordination with qualified operational and safety owners.

Document critical processes, safe state, unacceptable consequences and maximum tolerable disruption. Security design should protect confidentiality where required, but industrial priorities often emphasize integrity, availability, safety and recoverability.

Use recognized frameworks as references, adapted to the environment. Do not declare compliance or certification without a formal applicable assessment.

Inventory OT Assets

Build and maintain an inventory covering:

• PLCs, DCS, SCADA and safety systems;
• human-machine interfaces;
• engineering workstations;
• historians and application servers;
• network switches, routers, firewalls and wireless;
• sensors, gateways and IIoT devices;
• remote-access appliances;
• domain, identity and time services;
• virtualization and backup systems;
• vendor laptops and removable media;
• firmware, software and operating-system versions;
• physical location and process served;
• owner and support vendor;
• criticality and safety relevance;
• network addresses and communication;
• backup, recovery and replacement availability;
• lifecycle and support status.

Use passive discovery where active methods could affect sensitive devices. Validate findings with engineering documentation and physical inspection.

Inventory does not end at detection. Assign an owner, approved configuration and change process. Identify unknown devices and investigate them safely.

Map Communication and Dependencies

Document:

• source and destination;
• protocol, port and direction;
• business or control purpose;
• frequency, latency and volume;
• authentication and encryption;
• data classification;
• owner and approval;
• required availability;
• behavior during failure;
• external and cloud endpoints.

Include dependencies on DNS, directory, certificates, time, licensing, update services, databases and enterprise applications. A control application may fail when an apparently unrelated corporate service is unavailable.

Compare observed traffic with intended architecture. Remove or restrict unnecessary pathways through controlled change.

Classify Criticality and Consequence

Assess assets and flows by consequence to:

• personnel and process safety;
• environment;
• product quality;
• production and service;
• equipment damage;
• financial and customer obligations;
• regulatory and legal requirements;
• recovery time and spare availability.

Use consequence to prioritize controls, monitoring and recovery. A low-value sensor gateway and a safety-related control component should not receive identical treatment.

Consider common-cause dependencies. One identity, hypervisor, network core or remote-access platform may affect several lines or sites.

Design Zones and Conduits

Segment systems by function, trust and consequence. Typical concepts may include enterprise, industrial DMZ, site operations, supervisory control, basic control, safety-related and vendor/remote-access zones, adapted to the actual architecture.

For each zone define:

• permitted systems and users;
• allowed conduits and protocols;
• firewall and routing policy;
• administration path;
• monitoring;
• data transfer pattern;
• availability and recovery;
• physical controls.

Use default-deny principles where operationally feasible and permit documented business flows. Avoid flat networks in which compromise of an office or vendor device can reach control components broadly.

An industrial DMZ can broker data and services between IT and OT. It is not effective if uncontrolled alternate pathways remain.

Test segmentation during commissioning and periodically after change. Preserve safe process behavior if the enterprise connection is lost.

Identity and Access Management

Reduce shared and standing privilege.

Define:

• named user identities where supported;
• role-based access;
• separate operator, engineering and administration privileges;
• service and device identity;
• joiner, mover and leaver process;
• privileged-access approval and recording;
• multifactor authentication at appropriate boundaries;
• emergency/break-glass access;
• password and credential storage for legacy devices;
• periodic access review;
• inactivity and account expiry;
• audit and investigation.

Legacy components may not support modern identity. Use compensating controls such as jump hosts, network restriction, physical access, credential vaults and monitored sessions.

Do not integrate OT blindly into corporate identity without assessing dependency and outage behavior. Design local or emergency operation where required.

Secure Remote Access

Remote access is valuable for specialist support and a frequent high-risk pathway.

Require:

• business and asset owner approval;
• named identity and multifactor authentication;
• controlled gateway or jump host;
• least-privilege destination and protocol;
• time-bounded access;
• session logging or recording proportional to risk;
• monitored file transfer;
• vendor device requirements;
• prohibition of uncontrolled direct inbound access;
• rapid revocation;
• emergency process;
• periodic review of active methods.

Disable persistent vendor tunnels unless a documented operational requirement and appropriate controls exist. Review access after every support event and vendor personnel change.

Separate remote observation from configuration or control. A vendor who needs diagnostic logs may not require programming rights.

Vendor and Contractor Control

Maintain an inventory of vendors, products, support contacts and access. Contracts should address:

• security responsibilities;
• supported versions and lifecycle;
• vulnerability notification;
• patch and mitigation guidance;
• remote-access method;
• personnel changes;
• incident cooperation;
• backup and recovery information;
• component and dependency transparency where appropriate;
• data handling;
• end-of-support and transition.

Validate vendor laptops and removable media through an approved process before connection. Provide controlled tools rather than relying on personal or unmanaged devices.

Do not assume a system integrator’s access ended when a project ended.

Protect Engineering Workstations and Endpoints

Engineering workstations can change the physical process and require strong control.

Apply compatible measures:

• hardened approved build;
• application allowlisting where feasible;
• least privilege;
• controlled software installation;
• malware protection tested for compatibility;
• restricted internet and email;
• removable-media control;
• secure project-file storage and versioning;
• backup of programs and configurations;
• time synchronization;
• physical security;
• monitoring;
• change audit.

Avoid using engineering stations for general office work. Separate development/test from production where the platform supports it.

For legacy operating systems, reduce exposure through segmentation, allowlisting, access restriction, monitoring, virtualization or planned replacement. Document residual risk.

Vulnerability and Patch Management

Maintain awareness of:

• asset and software versions;
• vendor advisories;
• known vulnerabilities;
• exposure and exploitability;
• process consequence;
• available patch or mitigation;
• test requirement;
• maintenance window;
• rollback and recovery;
• compensating controls;
• acceptance and expiry.

Do not scan or patch sensitive systems using standard IT methods without OT review and representative testing. Conversely, operational caution should not become indefinite inaction.

Prioritize using asset consequence, exposure, pathway and exploit evidence—not a vulnerability score alone.

Test patches and configuration changes in a representative environment where possible. Back up configuration and verify recovery before production change.

Configuration and Change Control

Control changes to:

• PLC/DCS logic and parameters;
• HMI and SCADA configuration;
• accounts and access;
• network and firewall rules;
• firmware and software;
• historian and integration;
• sensor and gateway settings;
• remote-access platforms;
• security tooling.

Require scope, risk, test, approval, timing, backup, rollback and post-change validation. Include cybersecurity and safety review proportional to consequence.

Detect unauthorized or unexpected configuration changes. Preserve approved baselines and versions offline or in protected storage.

Emergency change needs a fast controlled path and retrospective review.

Govern IT/OT Data Flows

For each flow to ERP, CMMS, analytics, cloud or external partners, define:

• business purpose;
• minimum required data;
• owner and recipient;
• direction and protocol;
• gateway or broker;
• identity and authorization;
• validation;
• encryption;
• retention and privacy;
• availability and fallback;
• logging and support.

Prefer architectures that prevent enterprise or cloud compromise from creating direct control authority. Read-only data export is lower risk than bidirectional command, although it still needs security.

Validate commands or write-back through deterministic policy and appropriate operational approval. Never rely solely on an AI model or dashboard for control authorization.

IIoT and Edge Security

Assess devices and gateways for:

• unique identity and credential provisioning;
• secure boot and firmware integrity where available;
• signed updates and lifecycle support;
• disabling default passwords and services;
• network segmentation;
• local storage and encryption;
• physical tamper exposure;
• certificate renewal;
• offline behavior and buffering;
• inventory and remote management;
• data validation;
• secure decommissioning.

Low-cost devices can create high-consequence access. Evaluate product support and update capability before large deployment.

Treat sensor and gateway configuration as controlled production assets, not disposable project hardware.

Cloud and AI Integration

For cloud analytics or AI, define:

• which OT data leaves the site;
• aggregation and minimization;
• tenant and environment isolation;
• provider and regional placement;
• identity and keys;
• model or service access;
• logging and retention;
• data used for provider training, if any;
• response to cloud outage;
• output review and write-back authority;
• exit and data deletion.

An AI recommendation should not directly control equipment without a separately engineered and authorized control path. Test manipulation of untrusted data, model errors and unavailable services.

Monitoring and Detection

Use methods compatible with operational systems. Monitor:

• asset appearance and disappearance;
• unexpected communication;
• new external destinations;
• authentication failure and privilege use;
• remote sessions;
• configuration and firmware change;
• malware and endpoint alerts;
• firewall and gateway events;
• data-flow volume and timing anomalies;
• sensor and time-service health;
• backup and logging failure.

Passive network monitoring may reduce risk of disruption. Tune alerts with OT context and asset criticality.

Integrate relevant OT detections into the security operations process while preserving qualified OT participation. A corporate analyst should not isolate a critical controller without an approved response procedure.

Incident Response

Prepare joint IT/OT playbooks for:

• ransomware or enterprise compromise affecting OT dependencies;
• unauthorized remote access;
• malicious or accidental logic change;
• compromised engineering workstation;
• suspicious network activity;
• loss of view or control;
• data manipulation;
• vendor compromise;
• IIoT/cloud service incident;
• safety or environmental consequence.

Define detection, validation, escalation, command, communication, evidence, containment, safe operation, recovery and regulatory/customer coordination.

Practice through tabletop and technical exercises. Include operations, engineering, safety, security, leadership and vendors. Test decisions under production pressure.

Containment actions must account for physical process state. Disconnecting a system can worsen an unsafe condition.

Backup, Recovery and Resilience

Maintain protected, tested backups of:

• controller and safety-system programs where appropriate;
• HMI/SCADA configuration;
• historian and application configuration;
• engineering projects;
• network and firewall configuration;
• certificates and license information;
• virtual machines and databases;
• recovery procedures and vendor media.

Store copies offline or immutably according to risk. Test restoration on representative equipment or environments.

Document replacement lead time for obsolete hardware. A backup is insufficient if no compatible device or expertise exists.

Plan for manual or degraded operation where safe and feasible. Reconcile data after recovery.

Metrics and Assurance

Track measures that support decisions:

• inventoried and owned critical assets;
• approved vs observed communication;
• unsupported systems and mitigation ageing;
• privileged and vendor access review;
• patch or mitigation by risk tier;
• backup and restore test success;
• configuration-change authorization;
• detection coverage and investigation time;
• incident exercise findings;
• segmentation test results;
• expired risk exceptions;
• recovery readiness for critical processes.

Avoid presenting device count or number of blocked connections as security outcome. Use evidence from tests, incidents and recovery exercises.

Common IT/OT Security Failures

• Assuming OT is air-gapped without verifying pathways.
• Running disruptive scans or patches without OT review.
• Keeping flat networks and broad remote access.
• Sharing vendor or engineering credentials.
• Connecting cloud analytics directly to control networks.
• Ignoring engineering workstation and project-file integrity.
• Allowing unsupported systems without compensating controls or plan.
• Monitoring network events without process context.
• Letting IT contain an OT incident without safe-operation input.
• Backing up configurations without testing restoration.
• Treating IIoT gateways as low-risk accessories.
• Completing integration without retiring temporary access.

IT/OT Cybersecurity Checklist

Governance

• [ ] IT, OT, safety, security and business decision rights are documented.
• [ ] Critical processes, safe states and consequence are defined.
• [ ] Risk acceptance has owner, evidence and expiry.

Assets and architecture

• [ ] OT hardware, software, firmware, owner and lifecycle are inventoried.
• [ ] Observed communication is compared with approved flows.
• [ ] Zones, conduits and industrial DMZ controls are documented and tested.
• [ ] Critical external and enterprise dependencies are understood.

Access

• [ ] Named identity and least privilege are used where supported.
• [ ] Shared legacy credentials have compensating controls.
• [ ] Remote vendor access is approved, time-bounded and monitored.
• [ ] Privileged access and break-glass procedures are reviewed.

Protection and change

• [ ] Engineering workstations are hardened and separated from general use.
• [ ] Removable media and vendor devices follow a controlled process.
• [ ] Vulnerabilities use consequence-based patch or mitigation decisions.
• [ ] Logic, network, firmware and integration changes have backup and rollback.

Data and integrations

• [ ] Every IT/OT flow has purpose, owner, minimum data and authorization.
• [ ] Enterprise/cloud systems lack uncontrolled direct control authority.
• [ ] IIoT devices have identity, update, inventory and decommissioning plans.
• [ ] AI outputs have human and deterministic control boundaries.

Detection and recovery

• [ ] Monitoring uses OT context and reaches a joint response process.
• [ ] Incident playbooks account for physical process and safety.
• [ ] Backups include configurations and have been restored successfully.
• [ ] Exercises test vendor, cloud, identity and enterprise dependencies.

Frequently Asked Questions

What is IT/OT cybersecurity?

It is the protection and resilient operation of enterprise IT and operational technology where digital systems interact with physical processes, equipment and industrial control.

Why is OT security different from IT security?

OT controls physical processes and often has strict availability, timing, safety, vendor and lifecycle constraints. Security practices must be adapted without abandoning core principles such as inventory, segmentation and least privilege.

Should OT be completely isolated from IT?

Not necessarily. Many operations need controlled data and support flows. The objective is purpose-built, monitored and restricted integration with safe behavior when dependencies fail.

Can standard vulnerability scanners be used in OT?

Only after qualified review of device sensitivity and production risk. Passive discovery or controlled testing may be more appropriate for some systems.

How should vendor remote access be secured?

Use named identity, MFA, an approved gateway, least privilege, time-bound authorization, monitored sessions, controlled file transfer and rapid revocation.

Which framework should an organization use?

Select applicable authoritative frameworks and standards based on jurisdiction, sector and risk, then adapt them to the site. A framework does not replace system-specific engineering and safety analysis.

Conclusion

Secure IT/OT integration requires joint ownership of cyber risk and physical operations. Asset knowledge, segmentation, controlled identity, vendor access, monitoring and tested recovery provide the foundation.

The goal is not to prevent useful connectivity. It is to make every pathway intentional, constrained and recoverable while preserving safe plant operation. Organizations should begin with critical processes and observed communication, then improve controls in risk-led stages.