Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
OT-10OPERATIONAL TECHNOLOGYOFFICIAL INTENTEXPERT REVIEWED

Review Processes

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.

EXPLAINER · 5 SCENES · ≈40 SEC · CAPTIONS, NO AUDIO

OT-10 in 40 seconds

The problem, the plain-words meaning, three key moves, and what “done” looks like.

Official intent

What the campaign asks for

Review every change to OT for safety and security before it is made. The official source remains authoritative.

Read the official campaign ↗

Why it matters

Most OT disruptions come from changes, not attacks — a misconfiguration, an untested update, an undocumented tweak. Reviewing changes for safety and security together catches the modification that would break the process or weaken a control before it ships, and the record it produces is what keeps your inventory, segmentation, and baselines honest over time.

Minimum / Strong / Advanced

1
Minimum

Changes to OT systems, networks, and configurations require review and approval before they are made.

2
Strong

Review explicitly assesses both safety and security impact, changes are tested and documented, and emergency changes are reviewed after the fact.

3
Advanced

Change review is integrated with inventory, segmentation, and monitoring, and change records drive continuous verification of the environment.

Implementation timeline

First 24 hours
  • Confirm whether OT changes currently require any review
  • Identify who must approve safety- and security-relevant changes
Next 30 days
  • Define a simple change-review process with safety and security checks
  • Require documentation for every OT change
Next 60 days
  • Add testing and rollback expectations to the process
  • Define how emergency changes are handled and reviewed afterward
By day 90
  • Tie change records to inventory and segmentation updates
  • Audit recent changes for compliance with the process

Implementation steps

  1. Require that every change to OT systems, networks, and configurations goes through review.
  2. Assess each change for both safety and security impact, with the right approvers involved.
  3. Test changes and define rollback before they are applied to production.
  4. Document every change — including emergency changes, reviewed after the fact.
  5. Feed change records into inventory, segmentation, and monitoring so the environment stays accurate.

Validation

  • 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.

Evidence to retain

Governance

OT change-management policy covering safety and security review

Configuration

Change records with approvals, testing, and rollback notes

Operations

Emergency-change log and post-change reviews

Validation

Audit of recent changes against the process

Common failure modes

What looks done but is not

A change process that checks function but not security, undocumented “quick fixes” on the floor, and emergency changes that are never reviewed once the fire is out. Every unreviewed change quietly ages your inventory and baselines out of date.

Framework mappings

Independent mappings are aids, not authoritative equivalence or compliance determinations.

FrameworkRequirementRelationshipConfidence
NIST SP 800-82 Rev. 3Configuration & change mgmt (ICS overlay)DirectHigh
NIST SP 800-1713.4.3SupportingModerate
NIST CSF 2.0PR.PS-01SupportingModerate