Official intent
Review every change to OT for safety and security before it is made. The official source remains authoritative.
Read the official campaign ↗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.
Who this applies to: Every environment. This is the lowest-cost practice on the OT list and the one that keeps every other practice from eroding.
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.
Risks this reduces
- Process disruption caused by an untested or unreviewed modification
- Security controls quietly weakened by a change made for operational reasons
- Undocumented adjustments that make the inventory and baselines untrue
- Emergency changes that are never reviewed once the incident is over
Who owns it
Plant / OT leader
OT engineer, IT / security lead, Operations
Low
Low
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: nothing else on the list. You can start this today.
- Agreement on who must approve safety-relevant and security-relevant changes
- A change record simple enough that people will actually complete it
- A defined path for emergency changes, so urgency does not mean 'no process'
Action timeline
- Confirm whether OT changes currently require any review
- Identify who must approve safety- and security-relevant changes
- Agree the minimum change record — what changed, who approved it, what was tested, how to roll back — and start using it
- Define how an emergency change is handled and reviewed afterwards, before you need it
- Define a simple change-review process with safety and security checks
- Require documentation for every OT change
- Add testing and rollback expectations to the process
- Define how emergency changes are handled and reviewed afterward
- Tie change records to inventory and segmentation updates
- Audit recent changes for compliance with the process
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- 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.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Changes are made and remembered informally, if at all.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A change-review process exists in writing, naming approvers for safety and security impact.
Is the intent written down, with a named owner and a scope? - Configured
A change record is in use for planned changes, capturing approval and testing.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Every change to OT systems, networks, and configurations goes through review, including changes made by vendors.
Does it cover everything in scope, with the exceptions written down? - Measured
Change records are audited against what actually happened, and the compliance rate is reported.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
Change records drive inventory, segmentation, and baseline updates, and the process is owned and reviewed.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not 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.
Evidence to retain
OT change-management policy covering safety and security review
Change records with approvals, testing, and rollback notes
Emergency-change log and post-change reviews
Audit of recent changes against the process
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| 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%. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
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.
Two sized paths
A shared log with five columns — what changed, who approved it, what was tested, how to undo it, and what it affects — is a complete change process at small scale. The discipline is the value, not the tooling. Include changes made by vendors, which is where most undocumented change originates.
Integrate change review with inventory, segmentation, and monitoring so a change automatically updates the environment's record and an unrecorded change surfaces as a detection. Audit periodically against what the monitoring actually observed.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
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.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication treats change management with combined safety and security review as a core control system practice.
What this does not claim: 800-82 is guidance, not a compliance standard. Pinpointing individual overlay controls is part of the pending SME pass.
Why: The 2024 edition's security program elements include management of change for control system environments.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. The 2024 edition restructured the 2010 requirements into Security Program Elements; The specific requirement identifiers are pending verification against the licensed normative text and should be treated as directional until that check completes.
Why: The configuration management outcome covers maintaining approved configurations through change.
What this does not claim: The CSF describes outcomes, not testable controls.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.4.3Change tracking and approvalPartial implementation supportModerate
Why: The practice is change control: every OT change tracked in a record, reviewed by named approvers, approved or deferred, and logged — including vendor-performed and emergency changes, the two places change discipline usually fails.
What this does not claim: May partially address the requirement, and only for the OT estate where it falls within the assessed CUI boundary; changes to IT systems need their own process. The requirement also expects the discipline across organizational systems broadly, so an assessor will look well beyond the plant floor.
Review status: Technical review complete.
Open the 3.4.3 page →3.4.4Security impact analysisPartial implementation supportModerate
Why: The practice's combined review assesses safety and security impact together before a change is approved — the pre-implementation analysis this requirement asks for, applied where a wrong change stops production.
What this does not claim: The review's security-impact depth depends on who the plant names as the security approver; a safety-led review can pass changes whose security consequences nobody was qualified to see. Scope is also limited to the OT estate within the assessed boundary — impact analysis for IT changes is untouched by this practice.
Review status: Technical review complete.
Open the 3.4.4 page →3.4.5Change access restrictionsPartial implementation supportModerate
Why: Naming who must approve safety-relevant and security-relevant changes — and bringing vendor changes inside that gate — is the definition-and-approval part of restricting who may change OT systems.
What this does not claim: Defining who may approve a change is not enforcing who can make one: the requirement also demands enforced physical and logical restrictions — permissions on engineering workstations, locked panels, controlled controller access — which a review process does not itself configure. The relationship should be evaluated within the organization's defined system boundary, where much OT may sit outside scope.
Review status: Pending OT SME review.
Open the 3.4.5 page →NIST SP 800-171 Rev. 3
03.04.03Configuration Change ControlPartial implementation supportModerate
Why: Reviewing, approving, documenting, and auditing every OT change — including vendor-performed ones — is this requirement's discipline practiced where it is hardest to sustain. The practice's change records are configuration change control operating, for the estate it covers.
What this does not claim: May partially address the requirement, and only for the OT estate — enterprise IT changes inside the CUI boundary need their own change process, and that is where most of a defense contractor's boundary usually sits. Defining which change types are configuration-controlled system-wide, and monitoring change activity beyond OT, remain separate work.
Review status: Pending NIST SME review.
Open the 03.04.03 page →03.04.04Impact AnalysesPartial implementation supportModerate
Why: The practice's review asks the impact question before implementation — security and safety assessed together, by approvers qualified to judge each — which is this requirement's pre-change analysis performed for OT changes.
What this does not claim: The requirement also wants verification after implementation that security requirements still hold, which the practice reaches only where its change-record audits actually compare intended and realized state. And as with its sibling mappings, the OT scope leaves the enterprise portion of the boundary unaddressed.
Review status: Pending NIST SME review.
Open the 03.04.04 page →03.04.05Access Restrictions for ChangeGovernance supportModerate
Why: Access restrictions for change start with someone deciding who may change what and writing it down — and the practice's review process makes exactly that decision for the OT estate, then keeps the record of who changed what under whose approval.
What this does not claim: Deciding and recording approvers is not enforcing physical and logical access restrictions: engineering-workstation lockdown, management-network isolation, and panel access hardware are implementation work outside this practice. Contributes the governance the requirement's enforcement relies on rather than the restrictions themselves.
Review status: Pending NIST SME review.
Open the 03.04.05 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.