Impact Analyses is the security check that wraps around your change process. Configuration Change Control (03.04.03) governs how changes move through review and approval, and Impact Analyses (03.04.04) requires you to understand the security consequences of a change both before and after you make it. It has two (2) parts: analyze changes to determine potential security impacts prior to implementation, and verify that the security requirements continue to be satisfied after the changes are implemented. Per the NIST discussion, personnel with security responsibilities conduct these analyses by reviewing system security plans, design documentation, and operational procedures, and by determining how potential changes create new risks and whether they can be mitigated.
A common difficulty with this requirement is doing the before analysis but never the after verification. R2 only asked you to analyze security impact prior to a change. R3 adds an explicit objective to confirm, after the change is live, that your security requirements are still met. A change that passes a pre-implementation review can still break a control in practice, and the post-change verification is what catches that.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.04.04 Impact Analyses. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source controls are CM-04 and CM-04(02) from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, impact analyses include risk assessments to understand the impacts of changes and determine whether additional security requirements are needed, changes may affect previously implemented safeguards, and not all changes to the system are configuration controlled. This requirement is related to Configuration Change Control (03.04.03). You can read the requirement directly at NIST 800-171 R3, 03.04.04 (p. 29).
None (0). Requirement 03.04.04 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.04.04 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.04.04 into two (2) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
The two (2) objectives are the before analysis (A.03.04.04.a) and the after verification (A.03.04.04.b). They carry separate evidence, and a pre-implementation analysis does not demonstrate that the security requirements still hold once the change is live. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.04.04 (p. 35).
Examine: configuration management policy and procedures; procedures for security impact analyses for system changes; configuration management plan; security impact analysis documentation; system design documentation; analysis tools and outputs; change control records; system audit records; system security plan.
Interview: personnel with security impact analysis responsibilities; personnel with information security responsibilities; members of change control board; system developers; system administrators.
Test: processes for security impact analyses.
03.04.04 maps from NIST 800-171 R2 requirement 3.4.4 (analyze the security impact of changes prior to implementation):
Mapped against the two (2) AOs, one (1) is direct (minimal effort) and one (1) is net new (significant effort), with none indirect and none with no mapping. The pre-implementation analysis carries forward unchanged, but the post-implementation verification is a new obligation. Even though the requirement is short, half of it is new work, so do not assume a R2 impact analysis process fully satisfies it.
Source Controls in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.04.04 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about the post-change step and coordination, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.04.04 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.04.04 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.04.04.
With one AO mapping directly and one net new, 03.04.04 is a light lift with one real gap to close. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.04.04 have? NIST 800-171A R3 breaks 03.04.04 into two (2) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 controls does NIST 800-171 R3 03.04.04 come from? CM-04, CM-04(02).
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.04.04 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.04.04 sit in the NIST 800-171 R3 Kill Chain? Phase 7, Data Protection Practices. The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.04.04 Impact Analyses analyzes the security impact of changes before implementation and verifies that the security requirements still hold afterward. It maps from R2 3.4.4 with the pre-change analysis transitioning directly, while the post-change verification is net new. The recurring problem is analyzing before but never verifying after. Keep the pre-change analysis, add the post-change verification, and link both to your change control records.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
