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.3OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.4.3 — Change tracking and approval

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)

Track, review, approve or disapprove, and log 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

Changes to systems are tracked, reviewed, approved or rejected, and logged — so the environment you defend tomorrow is one you decided on, not one that accreted. The undocumented Friday-afternoon firewall change is exactly what this requirement exists to prevent.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Operate the minimum change record: what changed, who approved, what was tested, how to roll back
  • Capture and review emergency changes after the fact within an agreed window
  • Bring vendor-performed changes inside the process
Evidence this produces
  • Completed OT change records including vendor and emergency changes
  • Periodic audits of change records against what monitoring observed

Where this holds: Holds where OT assets are within the assessed boundary; contributes method and habit, but not records, for the IT estate.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Partial implementation supportModerate confidence

Why: Merge review and pipeline gates are change tracking, review, approval, and logging operationalized for code and infrastructure-as-code: every change carries an author, a reviewer, a decision, and an immutable record.

What this does not claim: 800-171 contains no secure-development requirement, so this is a reasoned relationship applied to one class of change. Systems changed outside the pipeline — network gear, hand-managed servers, SaaS configuration — are exactly where this practice's records stop, and the requirement does not.

Practice-side activities
  • Require review and approval on every merge to protected branches
  • Manage infrastructure as code so environment changes flow through the same gate
Evidence this produces
  • Merge records with reviewer, decision, and timestamp
  • Branch-protection configuration for production-bound repositories

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Keep the change record lightweight enough that people actually use it: what changed, who approved it, what was tested, how to roll back.
  • Define an emergency path in advance, with after-the-fact review, so urgency does not become an exemption.
  • Include changes made by vendors and MSPs — that is where most undocumented change originates in small environments.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A sample of completed change records spanning routine and emergency changes
  • The written process naming approvers and the emergency path
  • An audit comparing observed changes against the records for a period

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · Engineering lead · 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