ICS/OT Security Audit Checklist: What to Verify Before Your Next SCADA Upgrade

A standard IT security checklist assumes you can patch on Tuesday night, isolate a compromised host instantly, and rotate credentials without asking anyone's permission. None of that holds on the factory floor. A PLC running firmware from 2011 cannot be patched without a vendor-certified maintenance window; isolating a compromised HMI can mean stopping a production line mid-batch; and a "temporary" remote-access account set up by an integrator three years ago is often still open, because nobody owns the process of closing it. Auditing industrial control systems requires a different checklist, one built around physical consequence rather than data confidentiality.

This is also where most audits quietly fail before they start: they get treated as a compliance exercise rather than an operational one, run by a security team that has never walked the plant floor, against a checklist copied from an IT environment. The result is a report full of findings nobody on the operations side can act on, because the recommended fix assumes an uptime tolerance the process doesn't have. The gap between "what the audit recommends" and "what an operations team can actually implement without stopping the line" is exactly the gap a dedicated IT/OT security audit team, such as YuSMP Group, is built to close before the next SCADA upgrade or new OT segment goes live.

This guide works as a practical checklist, organized the way an actual audit should run: start with what you have (asset visibility), define where the boundaries are (segmentation and remote access), control who can touch it (identity and third-party access), manage what's broken (vulnerability and patch strategy for legacy OT), and close the loop with monitoring and a repeatable audit cadence. Each section includes a numbered sub-checklist you can use directly during a walkthrough.

Why a Standard IT Security Checklist Falls Short on the Factory Floor

The starting assumption behind most IT security frameworks is that confidentiality, integrity, and availability matter roughly in that order: protect the data first. In an OT environment, that priority order is inverted. Availability and safety come first, because a loss of control over a physical process can mean a safety incident, environmental release, or equipment damage measured in the millions, not a data breach measured in records exposed. A ransomware attack that encrypts a file server is a business disruption; the same attack hitting a PLC controlling a chemical reactor's temperature setpoint is a physical-safety event.

Three structural differences explain why the IT checklist doesn't transfer directly:

• Patch cadence. IT environments patch on a monthly or weekly cycle. OT environments patch during planned shutdowns, sometimes only once a year, because a reboot can mean hours of lost production or a full restart sequence for a continuous process.
• Device lifespan. A laptop is replaced every three to five years. A PLC, RTU, or HMI panel is often in service for 15 to 25 years, which means a meaningful share of any plant's control assets were designed before modern authentication, encryption, or even TCP/IP networking were standard features.
• Consequence of downtime. Isolating a suspicious IT host is a routine incident-response step. Isolating a suspicious OT device mid-process can itself cause the safety event the isolation was meant to prevent, which is why OT incident response has to be designed around the process, not just the network.

None of this means OT systems should get a lighter audit. It means the audit has to be built around consequence analysis rather than a generic severity score, and that's the lens every section below applies.

How to Use This ICS/OT Audit Checklist

This is not a checklist where every item applies equally to every facility. A water treatment plant, a discrete-parts manufacturer, and a pharmaceutical production line have different regulatory obligations, different safety consequences, and different legacy footprints. Use the checklist in three steps.

First, run a rapid consequence pass before you start checking boxes: for each production line or process cell, ask what the worst physical or safety outcome would be if that system were compromised. This determines priority: a line where a compromise could cause a safety incident gets audited and remediated before a line where the worst case is a production delay.

Second, make sure the right people are in the room. A security-only audit team will misjudge operational risk; a process-engineering-only team will miss the security gaps entirely. The audit needs process engineers who understand what each device actually controls, alongside security staff who understand attack paths, plus, where the facility uses one, the OT/ICS integrator who built the current architecture and knows where the undocumented shortcuts are.

Third, treat findings as a prioritized remediation backlog tied to the next maintenance window, not a document that sits in a drawer. An ICS/OT audit that doesn't result in a scheduled fix for its highest-consequence findings within the next planned shutdown has not actually reduced risk. It has only documented it.

Asset Visibility and Governance: The Foundation

Every other section of this checklist depends on this one. You cannot segment, patch, or monitor a device you don't know exists, and in most facilities that have never run a dedicated asset-discovery exercise, the as-built network diagram and the actual network bear only a loose resemblance to each other. Audits routinely turn up devices that nobody on staff knew were there: a vendor's remote-support modem, a contractor's laptop bridging two network segments, an unmanaged switch added during a line expansion.

Passive discovery is the right starting method for OT environments, because active network scanning can crash legacy devices that were never built to handle unexpected traffic. A passive sensor tapped into a network span port builds an inventory by observing traffic rather than probing devices, which is safe to run on a live process. Only once you have a passive baseline should you consider targeted, carefully scoped active scans on non-critical segments, and even then with the process owner's sign-off. The connectivity architecture that feeds edge-to-cloud telemetry is itself worth mapping during this phase, since unmanaged MQTT brokers and gateways are exactly the kind of connectivity that passive discovery tends to surface.

Map every discovered asset to its Purdue model zone: Level 0 (sensors and actuators), Level 1 (PLCs and RTUs), Level 2 (SCADA and HMI), Level 3 (historian and MES), and Level 4 (ERP and the corporate network). An asset that can't be placed cleanly into a zone is usually a sign of an undocumented bridge between zones, which is the single most common root cause auditors find when tracing how an IT-side compromise reached the OT network.

Asset Visibility Checklist

1. Build a passive, non-intrusive asset inventory covering every PLC, RTU, HMI, historian, and network device, including vendor, model, firmware version, and IP/MAC address.
2. Map each asset to its Purdue model zone and flag any asset that bridges two zones without a documented, approved reason.
3. Identify every device with a vendor-installed remote-access tool (TeamViewer, vendor VPN clients, cellular modems) and confirm it's still needed.
4. Cross-check the inventory against procurement and change-management records to find "shadow OT": devices added outside the normal process.
5. Assign a documented owner to every asset class; an asset with no owner is an asset nobody will patch, monitor, or decommission.

Network Segmentation and Secure Remote Access

Segmentation is the control that turns "one compromised device" into "one compromised device," rather than "the whole plant." The IEC 62443 zones-and-conduits model is the reference framework here: group assets into zones by function and consequence, then define every conduit (every permitted connection) between zones explicitly. Anything not explicitly permitted should be blocked by default, which is the opposite of how most legacy OT networks were actually built, where flat, unsegmented topologies were the norm because segmentation wasn't considered necessary until the network was already connected to the corporate side.

The audit should trace every firewall rule between the IT network and the OT network and ask, for each one, whether it's still in active use and whether it's scoped as narrowly as the use case requires. A common finding is a firewall rule permitting broad RDP or SMB access between IT and OT "for convenience" that was never revisited after the project that required it ended. The same scrutiny applies to protocols: an OT segment should expose only the specific ports and protocols its function requires: Modbus, OPC UA, or EtherNet/IP on the ports those protocols actually use, not a general-purpose open network.

Remote access deserves particular attention because it is consistently one of the highest-value targets for an attacker and one of the most common historical neglect areas. Vendor and integrator remote-access accounts, often set up years earlier for a specific commissioning project, are frequently still active long after the project ended, sometimes with credentials that were never rotated. If a facility is planning a SCADA interface refresh as part of this work, see our guide on phased SCADA and HMI modernization for how to restructure remote-access architecture at the same time, rather than carrying legacy access patterns forward into the new system.

Segmentation and Remote Access Checklist

1. Document every IT/OT and OT-zone-to-zone firewall rule; remove or narrow any rule that is broader than the current use case requires.
2. Confirm OT zones expose only the protocols and ports their function requires, with no general-purpose IT connectivity into process networks.
3. Inventory every remote-access path into the OT network (VPN, vendor modem, jump host) and disable any that aren't in active, documented use.
4. Require time-limited, logged, approval-gated remote sessions for vendors and integrators instead of standing access.
5. Verify that OT zones cannot reach the public internet directly, and that any outbound connection (firmware updates, cloud telemetry) goes through a controlled gateway.

Identity, Access, and Third-Party Risk Controls

Access control in OT environments inherits two long-standing weaknesses: default vendor credentials that are never changed, and shared accounts used by multiple operators and contractors because individual accounts are seen as an operational inconvenience. Both are easy to find in an audit and both are disproportionately high-impact, because an attacker who obtains a default or shared credential inherits whatever access that account has across the entire system.

Multi-factor authentication for remote access into OT networks is now considered a baseline control rather than an enhancement, specifically because a single stolen password is the most common initial-access method in documented ICS intrusions. The practical obstacle in OT environments is usually not technical feasibility (MFA is straightforward to layer onto a VPN or jump-host gateway) but organizational inertia, because the remote-access pattern was set up years ago by an integrator who is no longer involved and nobody has revisited it since.

Third-party access is its own risk category. Equipment vendors, system integrators, and maintenance contractors routinely need access to specific devices for specific, time-bound purposes, but that access is frequently granted as broad, standing network access instead of scoped, logged, time-limited access to exactly what the task requires. An audit should ask, for every third party with network access: what can they reach, is that access still needed, and is there a log of when they last used it.

Identity and Access Checklist

1. Inventory every default vendor credential still in use and replace it with a unique, managed credential.
2. Eliminate shared/generic operator accounts in favor of individual accounts with role-based access.
3. Require MFA for all remote access into the OT network, without exception for vendor or integrator accounts.
4. Scope third-party and contractor access to the specific devices and time windows a task requires, with session logging.
5. Review and revoke dormant accounts: a departed employee or an integrator whose project ended should lose access immediately, not eventually.

Vulnerability Management and Patch Strategy for Legacy OT

Patch management in OT is a strategy problem, not just an execution problem, because a meaningful share of the fleet often cannot be patched at all without a vendor-certified maintenance window, and some legacy devices have no patch path left because the manufacturer no longer supports them. The audit's job here is not to demand patching on an IT timeline. That's not achievable, and asking for it undermines the rest of the audit's credibility. Instead, the job is to produce an accurate picture of exposure and a realistic compensating-control plan for what can't be patched immediately.

Start by cross-referencing the asset inventory against CISA's ICS advisories and the NVD for every vendor and model in the plant. This single step routinely surfaces vulnerabilities that the operations team had no visibility into, because OT asset owners don't typically monitor security advisories the way IT teams do. A recent example of exactly this kind of disclosure is the padding-oracle vulnerability CISA reported in the Eclipse Milo OPC UA stack, the kind of finding that only surfaces if someone is actively tracking advisories against the specific software components running in the plant, rather than assuming the control system vendor will proactively notify every affected customer.

Where a patch isn't available or can't be applied without unacceptable downtime, document a compensating control: tighter network segmentation around the affected device, more aggressive monitoring for exploitation attempts, or restricting the device's communication to only the minimum set of peers it needs. This should be a written, time-bound exception, reviewed at the next maintenance window, not a permanent workaround that quietly becomes the new normal.

Penetration Testing on Live Systems

Penetration testing deserves a specific note here: testing live ICS/OT devices carries real risk, because some legacy equipment can be destabilized by traffic patterns a modern network stack would handle without issue. A responsible ICS pentest scopes testing to a lab replica or a tightly bounded, non-production segment first, and only extends to live systems with the process owner's explicit sign-off and a rollback plan in place.

Vulnerability Management Checklist

1. Cross-reference every asset's vendor and firmware version against CISA ICS advisories and the NVD on a recurring basis, not just once.
2. Classify each finding as patchable now, patchable at the next maintenance window, or unpatchable, and assign a compensating control to the last two categories.
3. Document every compensating control with a review date; an "exception" with no expiration is a permanent vulnerability.
4. Scope any penetration testing to a lab environment or isolated segment before touching live production devices.
5. Track end-of-support dates for every OT platform and flag devices approaching end-of-life for a replacement or isolation plan.

Monitoring, Incident Response, and Audit Cadence

An audit is a snapshot; monitoring is what keeps that snapshot from going stale the day after the auditors leave. OT-specific monitoring, watching for anomalous Modbus or OPC UA traffic patterns, unexpected changes to PLC logic, or new devices appearing on the network, catches the gradual drift that reintroduces risk between audits. This is where the asset inventory from the first section pays off again: a monitoring system that knows what "normal" looks like for a given device can flag deviations far faster than a generic IT intrusion-detection tool tuned for office networks.

Incident Response and Audit Cadence

Incident response for OT needs its own runbook, separate from the IT incident-response plan, because the first decision in an OT incident is often whether isolating the affected system is safer than leaving it connected, and that decision depends on the specific process, not a generic playbook. The runbook should name who has the authority to order a process shutdown, what the rollback procedure is, and how operations and security teams communicate during an active incident.

How often should you run an ICS/OT security audit? A full audit on the schedule in this guide is appropriate annually for most facilities, with a lighter-weight review triggered by any material change: a new OT segment, a SCADA or HMI upgrade, a new third-party integration, or a significant vendor remote-access arrangement. Waiting a full year after a major architecture change to re-audit leaves exactly the kind of drift this section is meant to catch.

Linking back to the acceptor section: this is also a natural point to bring in outside audit capacity, since an internal team auditing its own architecture tends to miss the gaps it created in the first place. A second, independent IT/OT audit pass on segmentation, access, and monitoring design is one of the highest-value checks a facility can run before signing off on a new SCADA deployment.

Monitoring and Cadence Checklist

1. Deploy OT-aware monitoring that baselines normal traffic and device behavior, not a repurposed IT intrusion-detection tool.
2. Maintain a separate OT incident-response runbook with named decision authority for process shutdown.
3. Re-run a full audit annually, and a targeted review after any material architecture change.
4. Log and review every remote-access session and every change to PLC/HMI logic against an approved change list.
5. Report audit findings to both operations leadership and security leadership: a finding that only reaches one side rarely gets fixed.

Frequently Asked Questions

What is the difference between an ICS security assessment and a penetration test?

An ICS security assessment is a broad review of architecture, asset inventory, segmentation, access control, and patch posture; it tells you where your structural weaknesses are. A penetration test is a narrower, more active exercise that attempts to exploit specific weaknesses to prove they're real and measure their actual impact. Most facilities should run a full assessment first; a pentest without that context risks testing the wrong things or, on live OT equipment, testing them unsafely.

How often should an ICS/OT security audit be performed?

Annually for most facilities, with an additional targeted review whenever there's a material change: a new OT network segment, a SCADA or HMI upgrade, a new third-party remote-access arrangement, or an acquisition that brings in unfamiliar plant infrastructure. An architecture change without a follow-up review is the most common way new risk gets introduced between scheduled audits.

Is it safe to scan or actively test live ICS/OT devices?

Not without careful scoping. Many legacy PLCs, RTUs, and HMI panels were never designed to handle unexpected network traffic and can crash or behave unpredictably under active scanning. Start with passive discovery for inventory and start any penetration testing in a lab replica or a tightly isolated non-production segment. Extend testing to live systems only with the process owner's sign-off and a documented rollback plan.

What frameworks should an ICS/OT audit follow: NIST 800-82 or IEC 62443?

They're complementary, not competing. NIST SP 800-82 (Guide to OT Security) provides a comprehensive risk-management framework widely used by U.S. facilities and often referenced by regulators. ISA/IEC 62443 provides the more granular technical architecture, zones and conduits, and Security Levels SL1 through SL4, that defines concrete segmentation and control requirements. A thorough audit uses NIST 800-82 for overall program structure and IEC 62443 for the segmentation and control-level specifics.

Who should be in the room for an ICS/OT security audit?

At minimum: process or controls engineers who understand what each device actually does in the production process, security staff who understand network architecture and attack paths, and, where one exists, the integrator who built or last modified the current OT architecture. Leaving out the process engineers is the single most common reason audit findings turn out to be operationally unworkable.

What's the biggest blind spot in most OT security assessments?

Asset inventory gaps. Facilities routinely discover devices during an audit that nobody on staff knew were connected: a vendor's remote-support modem, a contractor's bridge between two network segments, or an unmanaged switch added during a line expansion years earlier. Every other control in this checklist, segmentation, access control, patch management, monitoring, depends on knowing what's actually on the network, which is why asset visibility is the foundation this guide starts with.

Sources: NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security; ISA/IEC 62443 series; CISA ICS Advisories and the National Vulnerability Database.