OT Top 10 Implementation Checklist
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Every implementation step and validation check for the ten OT practices, generated from the live practice guides and ordered by the Resource Center's recommended sequence.
How to use it
Work top to bottom. A practice is not deployed until its validation checks pass, and it is not measured until you can put a number in the final column of its metrics table.
Scoring ladder
This checklist doubles as a maturity baseline. Record a level per practice as you work through it.
Score each practice against this ladder. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
| Level | Name | What it means | The question that separates it from the level below |
|---|---|---|---|
| 0 | Absent | The capability does not exist in any form. | Is there anything at all — a tool, a document, a person who owns it? |
| 1 | Documented | Intent exists on paper. Deployment has not happened or is incomplete. | Is the intent written down, with a named owner and a scope? |
| 2 | Configured | The technology or process is configured, but not yet applied to the intended scope. | Is it switched on and set up somewhere — even if only in part of the estate? |
| 3 | Deployed | It is applied across the scope it was meant to cover. | Does it cover everything in scope, with the exceptions written down? |
| 4 | Operating | It functions consistently during normal operations, not only when someone is watching. | Does it keep working through a normal month without manual rescue? |
| 5 | Measured | Coverage and effectiveness are measured, monitored, and exception-handled. | Can you state a number for coverage or effectiveness, and show the trend? |
| 6 | Governed | Ownership, scheduled review, continuous improvement, and evidence retention are established. | Is there an accountable owner, a review cadence, and retained evidence? |
OT-01 — Identity and Access Control
Stage 1 · Know and control · Owner: Plant / OT leader · Effort: Medium · Cost band: Medium
OT access is often shared logins, default passwords, and standing vendor accounts nobody tracks. Bringing identity and access control to production means unique accountability, least privilege, controlled use of engineering functions, and removing the generic and default credentials attackers look for first — done in a way that never blocks a safe, timely operator action.
Access changes on production systems can lock out operators when they need control most. Never remove or alter credentials on a live system without the process owner's agreement, a tested rollback, and break-glass access that works during a network or identity outage. Prioritize safety and availability over tidy identity design.
Implementation steps
- Inventory who and what can access each production system, including vendor and shared accounts.
- With the process owner, change default and vendor-set passwords within maintenance windows.
- Move toward unique, least-privilege accounts so actions are attributable and over-access is removed.
- Restrict engineering and administrative functions to authorized personnel and log their use.
- Establish and test break-glass access, then review accounts on a schedule tied to change control.
Validation
Run these before recording the practice as deployed.
- Pick a production device and confirm it no longer uses a default or vendor-set password.
- Verify break-glass access works with the identity system or network unavailable.
- Review the account list for shared logins and disabled-but-not-removed vendor accounts.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Devices on default credentials | Inventoried OT devices still using vendor-set or default passwords. | Zero where the vendor supports a change; the remainder documented with compensating controls. | |
| Standing vendor accounts | Vendor accounts enabled outside an active engagement. | Zero. | |
| Break-glass test currency | Days since break-glass access was last successfully tested. | Within the interval the plant agreed, and never unknown. |
A password change can break an automated process or an integration that used it. Identify every consumer of a credential before changing it, schedule inside an approved window with the process owner present, keep a rollback, and never change break-glass and production credentials in the same window.
OT-02 — Validated Asset Inventory
Stage 1 · Know and control · Owner: Plant / OT leader · Effort: Medium · Cost band: Low
You cannot protect equipment you have not counted. A validated OT inventory is built passively, confirmed by physical walk-downs, and maintained through change control — not by scanning fragile devices.
Active network scanning can interrupt fragile OT devices. Use passive discovery and physical walk-downs first; schedule any active technique inside an approved maintenance window with the process owner present.
Implementation steps
- Assign an accountable inventory owner with plant authority.
- Start from vendor documentation, purchase records, and project files.
- Physically walk down each line and verify networked and serial-connected devices.
- Record criticality and process impact with the operators who run it.
- Feed the inventory into change review so it stays current.
Validation
Run these before recording the practice as deployed.
- Pick five random devices on the floor; all five must appear in the inventory.
- Compare passive network observations to the list and investigate unknowns.
- Confirm the inventory changed when the last plant change happened.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Walk-down coverage | Production lines and remote sites physically verified within the agreed interval ÷ all lines and sites. | 100% within the plant's chosen cycle. | |
| Unknown observed assets | Devices seen by passive monitoring that are not in the inventory. | Zero unresolved; each investigated and either added or removed. | |
| Spot-check accuracy | Randomly selected floor devices found in the inventory with correct detail ÷ devices checked. | Five of five on each spot check. |
The inventory is only maintainable if every plant change updates it. Attach an inventory update to the change record itself; otherwise the list ages out between walk-downs and every dependent control degrades quietly. Walk-downs are themselves plant activity: agree floor access with the process owner, and record safety-instrumented and serial-connected devices deliberately rather than counting only what appears on the network.
OT-03 — Strict Network Segmentation
Stage 2 · Contain compromise · Owner: OT / network administrator · Effort: High · Cost band: High
The single most valuable OT control is keeping the plant network separate from the business network. Strict segmentation uses zones and conduits, a controlled boundary (ideally a DMZ) between IT and OT, and default-deny rules so that a phished laptop in the office cannot pivot to a controller on the floor. Inside OT, further zoning contains a problem to one line or cell.
Introducing segmentation, firewalls, or new boundary rules can disrupt real-time OT traffic and safety functions. Design with the process owner, validate against production timing requirements, stage changes in maintenance windows, and keep a tested rollback. A control that improves security but risks a safety trip is not an improvement.
Implementation steps
- Map all connections between the business and OT networks, including forgotten and vendor links.
- Define zones (by line, cell, or criticality) and the conduits allowed between them, with the process owner.
- Establish a controlled IT/OT boundary — ideally a DMZ — that brokers all cross-boundary traffic under default-deny.
- Direct remote and vendor access into controlled zones rather than straight onto the OT network.
- Monitor and log traffic crossing the boundary and between zones so unexpected flows are visible.
Validation
Run these before recording the practice as deployed.
- From a business-network host, attempt to reach an OT controller directly — it must be blocked.
- Confirm no undocumented direct path bypasses the IT/OT boundary.
- Verify vendor/remote access terminates in a controlled zone, not the production network.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Unbrokered IT-to-OT paths | Network paths from the business network into OT that bypass the boundary. | Zero. | |
| Any-any boundary rules | Rules permitting unrestricted traffic across the IT/OT boundary or between OT zones. | Zero outside a dated, safety-reviewed exception. | |
| Segmentation test result | Blocked cross-boundary attempts ÷ attempts in the periodic test. | 100% of paths the design says should be blocked. |
Filtering can break real-time and safety-related traffic in ways that are not obvious in a lab. Learn the actual traffic in permit-and-log mode first, validate against the process's timing requirements, stage in approved maintenance windows with the process owner present, and keep a tested rollback and a person at the panel.
OT-06 — Remote Access Pathways
Stage 2 · Contain compromise · Owner: OT / network administrator · Effort: Medium · Cost band: Medium
Remote access is how vendors keep equipment running — and how attackers get to the plant floor. The safe pattern is brokered access: connections pass through a controlled jump host in a DMZ, require strong authentication, are enabled only for the window they are needed, and are fully logged and ideally supervised. No always-on VPNs into OT, no direct vendor tunnels to a controller.
Tightening remote access can cut off a vendor mid-support or during an emergency. Coordinate with operations and vendors before changing pathways, keep a tested emergency-access procedure, and stage changes so support is never silently severed when the plant needs it.
Implementation steps
- Inventory all remote and vendor access into OT, including modems and forgotten tunnels.
- Force remote access through a brokered jump host in an IT/OT DMZ — never directly to a device.
- Require strong authentication and least privilege for every remote connection.
- Enable access only for the session or window it is needed, then disable it.
- Log — and where possible supervise or record — remote sessions, and revoke vendor access after each engagement.
Validation
Run these before recording the practice as deployed.
- Attempt to reach an OT device remotely without going through the jump host — it must fail.
- Confirm no always-on vendor tunnel remains enabled between support visits.
- Verify remote sessions are logged and vendor access was revoked after the last engagement.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Brokered access share | Remote sessions arriving through the jump host ÷ all remote sessions into OT. | 100%. | |
| Standing access outside engagements | Vendor accounts or tunnels enabled with no active engagement. | Zero. | |
| Session log review | Remote sessions reviewed against an expected engagement ÷ sessions logged. | 100% of vendor sessions; sampled for internal sessions. |
Tightening remote access can cut off a vendor during a breakdown — and a vendor who cannot reach a misbehaving system when the plant needs them is a safety problem, not only a support problem. Coordinate with operations and the vendor before changing a pathway, keep a tested emergency-access procedure that does not require the vendor's old tunnel, and stage changes so support is never severed without notice.
OT-05 — Manage Known Vulnerabilities
Stage 3 · Reduce exposure · Owner: OT engineer · Effort: Medium · Cost band: Medium
You cannot patch OT like IT. Many devices can only be updated during rare maintenance windows, run vendor-certified firmware, or cannot be taken down at all. Managing known vulnerabilities in OT means knowing what you are exposed to, deciding per device whether to patch or compensate, and doing it on a risk-ranked schedule the process can tolerate — not on IT's clock.
Patching or updating firmware on live OT can disrupt a validated process or trip safety functions. Apply vendor-approved patches only, test in a lab or during an approved maintenance window with the process owner present, and keep a tested rollback. When a patch is too risky, a documented compensating control is the correct answer — not forcing the update.
Implementation steps
- Map known vulnerabilities to the validated OT inventory using vendor advisories and ICS sources.
- Rank each by real risk — exposure, reachability, and impact on the process — not raw score.
- For each, decide patch or compensate with the process owner, honoring vendor certification.
- Apply patches through vendor guidance and maintenance windows, tested first and with rollback.
- Where patching is unsafe, apply and document compensating controls, and review decisions on a cadence.
Validation
Run these before recording the practice as deployed.
- Confirm every high-risk OT vulnerability has either an applied patch or a documented compensating control.
- Verify no OT device with a known-exploited vulnerability is reachable from outside its zone.
- Check that patches were vendor-approved and applied in an authorized window with a rollback on hand.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| High-risk findings addressed | High-risk OT findings with an applied patch or documented compensating control ÷ high-risk findings. | 100%. | |
| Internet-reachable OT devices | Inventoried OT devices reachable from the internet. | Zero. | |
| Advisory-to-decision time | Days from a relevant vendor or ICS advisory to a recorded patch-or-compensate decision. | Within the interval the plant agreed. |
Every patch is a change to a validated process. Apply only vendor-approved updates, test on a bench or non-critical unit first, schedule inside approved windows with the process owner present, keep a tested rollback, and record the decision either way. Declining to patch is a legitimate outcome when it is documented and compensated.
OT-04 — OT-Specific Incident Response and Recovery Plan
Stage 4 · Recover operations · Owner: Plant / OT leader · Effort: Medium · Cost band: Medium
An IT incident-response plan does not fit the plant. OT response has to weigh safety and physical process first, involve engineers and operators alongside IT, and account for the reality that you may run degraded or in a safe state rather than simply pulling systems offline. A written, exercised OT plan — with roles, safe-state procedures, and tested recovery — is what prevents improvisation during a crisis.
Containment actions in OT — isolating a device, cutting a network path — can directly affect physical operations and safety systems. Every response and recovery procedure must be reviewed with process and safety owners, define safe-state options, and be exercised in a way that never puts production or people at risk.
Implementation steps
- Build an OT-specific IR plan with named roles spanning IT, OT engineering, operations, and leadership.
- Define containment options that weigh safety and process impact, including safe-state and degraded operation.
- Ensure recovery relies on validated backups of controller logic, configurations, and set points.
- Write playbooks for the incidents most likely to hit your environment.
- Exercise the plan at least annually with all stakeholders and update it from what you learn.
Validation
Run these before recording the practice as deployed.
- Confirm the OT plan names specific people and reachable after-hours contacts, not just titles.
- Test-restore a controller configuration or logic backup to prove recovery works.
- Verify the last tabletop involved OT engineers and produced changes to the plan.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Plan currency | Days since the OT plan was last reviewed against the current plant and contact list. | Within the agreed review interval; contacts verified reachable. | |
| Recovery proven | Critical control systems for which a logic or configuration restore has been successfully tested. | 100% of critical systems within the agreed cycle. | |
| Exercise-to-improvement rate | Exercises that changed the plan, a playbook, or a runbook ÷ exercises run. | 100%. |
Response actions are changes made under pressure. Pre-authorize the containment options that are safe, name the ones that require the process owner regardless of urgency, and require an after-the-fact review of every emergency change made during an incident.
OT-08 — System Resiliency
Stage 4 · Recover operations · Owner: Plant / OT leader · Effort: High · Cost band: High
Resiliency is the ability to keep operating, or return quickly, when something fails — whether a disk, a controller, or an attack. In OT that means backups of controller logic and configurations, spares and redundancy for critical components, defined safe-state and manual-operation fallbacks, and recovery that has actually been tested against how long production can be down.
Testing failover, recovery, or safe-state transitions on live systems can itself cause a disruption. Exercise recovery in a lab or during planned windows with the process owner, validate that safe-state and manual fallbacks behave as expected, and never assume an untested redundancy will engage cleanly under real failure.
Implementation steps
- Back up controller logic, configurations, and set points, and store copies safely off the device.
- Identify critical single points of failure and the processes that cannot tolerate downtime.
- Define acceptable downtime and document safe-state and manual-operation fallbacks with operators.
- Add redundancy or spares for the most critical components.
- Test recovery against the downtime target and exercise realistic failure and attack scenarios.
Validation
Run these before recording the practice as deployed.
- Test-restore a controller's logic/configuration and confirm the process resumes correctly.
- Verify a defined safe-state or manual fallback exists and is understood by operators.
- Confirm the last recovery exercise met — or exposed a gap against — the downtime target.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Controller backup coverage | Critical controllers with a current logic and configuration backup ÷ critical controllers. | 100%, refreshed after every change. | |
| Tested recovery time | Elapsed time of the most recent restore test, compared with the agreed acceptable downtime. | Within the target; shortfalls documented and funded. | |
| Unmitigated single points of failure | Critical components with neither redundancy nor an obtainable spare. | Zero, or an accepted risk with a named owner and a date. |
Backups age out the moment logic changes, so make a backup refresh part of the change record itself. Test failover and recovery in a lab or planned window with the process owner — an untested redundancy that fails during a real event is worse than a known gap.
OT-09 — Supply Chain Security
Stage 5 · Engineer securely · Owner: Procurement + OT · Effort: Medium · Cost band: Medium
Every vendor, integrator, and component is a path into your environment. OT supply-chain security means knowing who your critical suppliers are, setting security expectations in agreements, checking equipment and firmware before it is connected, and watching for advisories about the products you run. You are managing risk that arrives through other people's software and hardware.
Implementation steps
- Identify critical suppliers, integrators, and components — especially anyone who can update firmware.
- Set security expectations in agreements: patch support, vulnerability disclosure, and access rules.
- Verify equipment and firmware integrity and provenance before it is connected to the plant.
- Hold integrator and vendor access to the same brokered, logged remote-access controls.
- Monitor product advisories and assess supplier risk, feeding it back into procurement.
Validation
Run these before recording the practice as deployed.
- Confirm critical vendor agreements include security and vulnerability-disclosure expectations.
- Verify a recent firmware or device was integrity-checked before connection.
- Check that advisories for your key OT products are being monitored and triaged.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Agreements with security terms | Critical supplier agreements containing patch support, disclosure, and access terms ÷ critical supplier agreements. | 100% at renewal. | |
| Pre-connection verification | New devices and firmware integrity-checked before connection ÷ new devices and firmware. | 100%. | |
| Advisory triage coverage | Products you run that are covered by a monitored advisory feed ÷ products you run. | All critical products. |
Commissioning is where supply-chain risk enters. Make integrity verification and access provisioning explicit steps in the commissioning change record, and treat an integrator connecting their own laptop to the control network as a change requiring safety and security review, not a routine event. New equipment and firmware entering a live process carry the same safety obligations as any other change: process-owner agreement, an approved maintenance window, and a tested rollback.
OT-10 — Review Processes
Stage 5 · Engineer securely · Owner: Plant / OT leader · Effort: Low · Cost band: Low
In OT, an unreviewed change can trip a process or open a security hole — and the two concerns are inseparable. A change-review process ensures every modification to control systems, network, or configuration is assessed for both safety and security impact, approved by the right people, tested, and recorded. It is the low-cost governance control that keeps all the others from silently eroding.
Implementation steps
- Require that every change to OT systems, networks, and configurations goes through review.
- Assess each change for both safety and security impact, with the right approvers involved.
- Test changes and define rollback before they are applied to production.
- Document every change — including emergency changes, reviewed after the fact.
- Feed change records into inventory, segmentation, and monitoring so the environment stays accurate.
Validation
Run these before recording the practice as deployed.
- Pick a recent OT change and confirm it was reviewed, approved, tested, and documented.
- Verify the review explicitly considered safety and security, not just functionality.
- Confirm emergency changes were captured and reviewed after the fact.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Reviewed change rate | OT changes with a completed review record ÷ OT changes identified in an audit of the period. | 100%, including vendor-performed changes. | |
| Emergency change closure | Emergency changes reviewed after the fact within the agreed window ÷ emergency changes. | 100%. | |
| Downstream update rate | Changes that produced a corresponding inventory or design update where one was needed. | 100%. |
This practice is change control. Safety and security impact are assessed together in the same review, by the approvers qualified to judge each — separating them is how a change that is secure but unsafe, or safe but exposing, gets approved. Reviews are scheduled against production reality: the process owner decides which maintenance window a change belongs in, and a change with no viable window is deferred rather than forced. The two failure points are scope and emergencies: vendor-performed changes must be inside the process, and emergency changes must be captured and reviewed once the fire is out rather than exempted.
OT-07 — Continuous Monitoring
Stage 6 · Sustain performance · Owner: OT engineer · Effort: Medium · Cost band: Medium
You cannot respond to what you cannot see. OT monitoring is built passively — from network taps and SPAN ports, not agents on fragile devices — to baseline normal traffic and flag the abnormal: new devices, unexpected connections, protocol anomalies, and changes to controller logic. The aim is early warning, tuned to an environment where the traffic is predictable and deviations matter.
Deploying monitoring must not disturb the process. Use passive collection (taps, SPAN) rather than active scanning or agents on control devices, and place sensors with the process owner so nothing loads or interrupts real-time traffic. Visibility is the goal; a monitoring rollout that risks a trip has defeated its purpose.
Implementation steps
- Identify passive capture points (SPAN ports, network taps) that see critical OT traffic.
- Deploy an OT-aware monitoring capability without placing load or agents on control devices.
- Baseline normal assets and communications with the people who run the process.
- Alert on meaningful anomalies — new devices, unexpected flows, protocol errors, controller logic changes.
- Route alerts to a responder, tune out noise, and connect OT detection to your overall response.
Validation
Run these before recording the practice as deployed.
- Introduce a benign test device or connection and confirm monitoring detects it.
- Verify sensors are passive and add no measurable load to control networks.
- Confirm recent alerts reached a named person and were investigated, not just logged.
| Operating metric | How it is calculated | Directional target | Your number |
|---|---|---|---|
| Monitored zone coverage | OT zones with passive monitoring ÷ zones in the segmentation design. | All critical zones; the remainder scheduled. | |
| Alert investigation rate | Alerts investigated and dispositioned ÷ alerts raised. | 100% of high-severity alerts. | |
| Detection test result | Whether a benign test device or connection was detected within the expected interval. | Detected every time the test is run. |
Sensor placement itself is a plant change and belongs in the change record, with a rollback that is as simple as removing the tap. Place taps with the process owner, verify sensors are genuinely passive and add no measurable load, and never install agents on control devices to save deployment effort. Where a vendor supplies or manages the monitoring, hold their access to the same brokered remote-access controls as everyone else. Re-baseline after every significant plant change or the alerts become noise.
Limitations
Nothing on this list should be actioned on a live operational-technology system without the process owner's agreement, an approved maintenance window, a tested rollback, and a safety review. Where a security action conflicts with safe operation, the safe operation wins and the control is compensated instead.
This is independent educational material. It supports planning and evidence collection; it does not establish compliance with NIST SP 800-171, DFARS 252.204-7012, CMMC, export-control obligations, or any contract requirement, and it is not an assessment. Tailor every item to your own technical, operational, contractual, regulatory, and safety requirements.
Printing produces a paginated document. Choose “Save as PDF” in the print dialog and name it batb-ot-top-10-implementation-checklist to keep filenames consistent across your team.