Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.4.5OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.4.5 — Change access restrictions

3.4 Configuration Management · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Only defined, approved people can physically or logically make changes to systems — and the restriction is enforced, not merely written down. The change process says who may change things; this requirement makes sure nobody else can.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Document who may approve and who may perform each class of OT change
  • Route vendor and remote changes through the same approval gate as internal ones
Evidence this produces
  • The written approver and performer definitions per change class
  • Change records demonstrating the gate applied to vendor work

Review status: Pending OT SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Map who holds change-capable access — admin rights, repository write access, production credentials, server-room keys — against who is approved to hold it, and close the gap.
  • Enforce through the platforms: role assignments, branch protections, and privileged-access grants are the mechanism, the document is just the intent.
  • Review the list when people change roles; access that outlives its justification is how 'defined and approved' quietly becomes fiction.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The documented change-access restrictions with approvals
  • Permission exports from the systems that enforce them
  • A dated access review reconciling holders against approvals

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

RECORD · REVIEW A PACKAGE IS COMPLETED FOR EVERY CHANGE; THE TEMPLATE ITSELF IS REVIEWED ANNUALLY AND AFTER ANY CHANGE-RELATED INCIDENTChange Request and Validation Package
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated