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
03.04.04OFFICIAL TITLEPENDING NIST SME REVIEW

03.04.04 — Impact Analyses

03.04 Configuration Management · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires analyzing changes to the system to determine potential security impacts prior to implementation, and verifying after implementation that the system's security requirements continue to hold.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

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

What this requirement is after

Before a change ships, someone asks 'what could this break, security-wise?' — and after it ships, someone checks that the answer held. Impact analysis is the thinking step that change control exists to force.

Across revisions

Carried from 3.4.4 with post-implementation verification that security requirements still hold added explicitly.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Assess security impact alongside safety impact in every OT change review
  • Compare post-change state to the approved change during periodic audits
Evidence this produces
  • Change records showing pre-implementation security-impact assessment
  • Audit findings comparing records to observed configuration

Review status: Pending NIST 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
  • Scale the analysis to the change: a standing checklist question — does this touch authentication, logging, network exposure, or CUI handling? — is a real analysis for routine changes, while architectural changes deserve a written assessment.
  • Post-change verification can ride existing signals: drift detection, vulnerability scans, and the monitoring already running, checked deliberately after significant changes rather than assumed.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Change records showing the pre-implementation security-impact assessment
  • Post-change verification records for significant changes

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 came from in Rev. 2

Provenance

Sources and review status

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