03.04.04 Impact analyses: requirements and evidence

What 03.04.04 impact analyses requires before and after a change

03.04.04 requires two things for every change to a system that holds CUI: an analysis of its potential security impact before the change is implemented, and a check afterward that the system still satisfies its security requirements. If your contract requires NIST SP 800-171, an assessor will expect to see both halves for changes that touch the CUI environment, not just a change ticket with an approval box ticked. The requirement is the analysis step inside the change control process described in 03.04.03 (Configuration change control), which the Rev. 3 discussion points to directly. Change control decides what gets reviewed and approved. 03.04.04 asks what the change could do to security and whether anyone verified that it did not.

The risk behind this is mostly well-meant change. An engineer opens a firewall rule to fix a vendor integration, a platform team turns off a noisy audit source, or an administrator widens a role so a batch job runs. Each change looks local, yet together they can quietly weaken a boundary, reduce logging coverage or grant access that no one reviewed. A useful analysis asks specific questions: does the change alter the system boundary or its data flows, does it touch authentication, logging or encryption settings, does it add a component that holds CUI, and does it change anything listed in the system security plan. Your team should confirm which of these questions its change board actually asks and where the answers are recorded.

This is hard in practice for two reasons. Changes often happen outside the formal process, through emergency fixes, cloud console edits or updates pushed by a managed service, so there is no analysis at all. When a formal process exists, the analysis is frequently written after the change, as a justification rather than a decision input. An assessor will test both gaps: they will interview change board members and security impact analysis owners, examine the analysis documentation and the change records, and test whether the process actually runs. Ask your team to pick a sample of recent changes, including emergency ones, and check whether each has a pre-implementation analysis and a post-implementation verification that someone other than the implementer signed off on.

Which changes, systems and teams fall under impact analysis

Impact analysis under 03.04.04 applies to whatever sits inside the CUI boundary and changes there, so the scope you draw determines how many analyses you run. The cards below are the decisions that most often move that volume, and each one changes who must review a change and how much evidence each review produces.

CUI boundary membership

Every system inside the boundary where CUI is processed, stored or transmitted needs its changes analyzed. Systems outside the boundary that share identity, network or management planes can still affect CUI protection, so they belong in the analysis even when they are not in scope. Before you start, confirm the boundary in your system security plan and list the components that cross it. A narrow, well-documented boundary reduces the number of analyses. An unclear one forces you to analyze more changes than necessary or leaves gaps that an assessor will find.

Firmware and operating system patches

Firmware updates and operating system patches change the behavior of the platform on which CUI controls depend, including encryption, logging and authentication. Analyze these changes before rollout and verify afterward that the settings your baseline depends on still hold. Patch cycles are frequent, so a rule that analyzes every routine patch in full will consume the team's capacity. Many organizations define a standard impact template for routine patches and reserve full analysis for changes that alter security functions. Ask your assessor whether that split is acceptable and record the criteria in the configuration management plan.

Cloud configuration and network rules

Changes to cloud security groups, identity policies, storage access settings and firewall rules can expose CUI in minutes. Treat them as configuration changes that require analysis, even when they are made through infrastructure-as-code or a console. Check whether automated pipelines or drift correction apply changes without a ticket, since those changes still need an impact determination and a record. Teams often under-scope network rule changes because they look small. Confirm that boundary protection and deny-by-default rules are reviewed with the same discipline as application releases.

Application releases and third-party connectors

New application versions and new integrations with third-party connectors can add data flows, service accounts and logging gaps that change CUI exposure. Analyze the data each release touches, the credentials it uses and whether it writes audit records. Connectors deserve particular attention because they often hold broad permissions and ship updates on their own schedule. Keep an inventory of connectors that reach CUI systems and tie each update to a review. Organizations that skip connector updates frequently discover later that the connector changed its data handling without a corresponding analysis.

Change-raising and review teams

Impact analysis is only as complete as the set of people who raise changes and the people who review them. Engineering, cloud operations, network, identity and business application owners can all originate changes that affect CUI. Assign a change control board that includes someone with information security responsibility, and make the requirement explicit in the process. Confirm that each team knows which changes route through the board and which are pre-approved as standard changes. Assessors interview members of the change control board, so the membership, responsibilities and meeting records must match what the process describes.

Managed IT and service provider changes

When a managed service provider or IT vendor makes changes on your behalf, those changes still fall under your impact analysis obligation. Decide in the contract whether the provider submits each change for review, whether it works under your change tickets, and how it records what it did. NIST states that the federal agency holding the contract bears responsibility for application and compliance issues, so the nonfederal organization must still show control over vendor activity. Ask providers for their change logs and verify that they can produce impact determinations for changes they make. Changes made outside those channels create the largest gaps in the evidence.

How an assessor tests 03.04.04 impact analyses

This table maps the two SP 800-171A Rev. 3 determination statements for 03.04.04 to the examine, interview and test methods an assessor uses. Read each row as the evidence to prepare, the questions to expect and the gaps that most often stop a finding from passing.

Assessment object	What the assessor asks for	What passes	Common findings
Examine: configuration management policy and procedures	The written policy and procedures that require security impact analysis before and after changes, and who owns them	A current document that names the impact analysis step, the approvers and the review frequency	Policy exists but never mentions security impact, or was last reviewed years ago
Examine: impact analysis procedures for system changes	The step-by-step procedure for analyzing a proposed change and the triggers that start it	Procedure defines inputs such as system design and boundary data, and outputs such as a documented impact decision	Procedure covers change approval only and skips the security-specific analysis
Examine: configuration management plan	How the plan links change control, baselines and impact analysis into one process	Plan names the impact analysis as a gate and points to the procedure and responsible roles	Plan describes change control in general terms with no reference to impact analysis
Examine: impact analysis records	A sample of completed analyses for recent changes, including changes to security-relevant components	Each sampled record shows the change, the security functions examined, the findings and the approver	Records are missing for emergency changes, or they restate the change request without analysis
Examine: system design documentation	Design and boundary documents the analyst used to judge whether a change affects security functions	Design documents are current enough to show which components protect CUI and how they connect	Design diagrams predate major changes, so analyses rely on outdated assumptions
Interview: staff who perform impact analyses	How they decide whether a change needs analysis and what they check after implementation	Staff describe the same steps as the written procedure and can explain a recent example	Staff are unaware of the procedure or treat impact analysis as a formality
Interview: information security staff	How security reviews feed into the analysis and how they confirm requirements still hold after a change	Security staff describe a verification step that checks affected requirements after implementation	Security is consulted only after a change is already in production
Interview: change control board members	How the board uses impact analysis results when approving or rejecting changes	Board members can state that analysis results are reviewed before approval and that open concerns block approval	Board approves changes on schedule and cannot point to where analysis influenced the decision
Test: impact analysis process	A walkthrough of one or more changes from request through analysis, approval, implementation and post-change verification	The process runs as written and the post-change check confirms security requirements still hold	Post-change verification is not performed or is not recorded, so the second half of the requirement is unproven

Implementing impact analysis in a change process

This sequence turns 03.04.04 from a policy statement into a working gate: every configuration-controlled change gets a documented security impact analysis before approval, and a verification step confirms afterwards that the security requirements still hold. Each step ends with a named artifact that an assessor can examine.

Define which changes require an analysis
Start by listing the change categories that count as configuration-controlled for the system under assessment, such as operating system patches, firmware updates, network rule changes, identity and access changes, new software, and changes to the CUI boundary. For each category, state what a complete analysis must contain: the components affected, the CUI and security functions touched, the requirements that could be affected, and the rollback approach. The output is a written scope statement, approved by the system owner and the security lead, that the change process references. You know it is done when every change type in your change log maps to either an analysis requirement or a documented exemption.
Set a standard analysis template
Create one analysis template that every change record uses, and tie its fields to the system security plan and the CUI boundary diagram. The template should ask the reviewer to identify the affected system components, whether the change touches CUI processing, storage or transmission, which security requirements in the system security plan could be affected, and what testing or verification will follow. The output is a versioned template stored with the configuration management plan. Confirm with your assessor that the template references the same boundary and component inventory the system security plan uses, so the analysis cannot describe a system that differs from the one under assessment.
Route changes through a change record that requires the analysis
Configure your ticketing or change management tool so a change record cannot move to approval until the analysis fields are complete and attached. Open-source options such as GLPI, which provides ITIL-style change handling with plannings and statistics, or a helpdesk such as Zammad can hold this workflow, but confirm that your chosen tool enforces required fields before approval rather than relying on reviewers to check. The output is a change record that carries the analysis, the approver's decision, and a link to the implementation record. You know it is working when a test change with an empty analysis field is blocked from approval.
Train reviewers and change board members
Brief the people who write, review and approve analyses on the template, the categories that need analysis, and how to tell a security-relevant impact from an operational one. Include the change board members, because they are the people an assessor will interview about how impacts are weighed. Keep attendance and the training materials on file. The output is a training record for each reviewer and a short reviewer guide that explains the decision criteria. You know it is done when each named reviewer can explain, without notes, what a complete analysis contains and what they would reject.
Define post-change verification checks and owners
For each change category, decide which checks confirm that the security requirements are still satisfied after implementation, and name an owner for each check. Checks might compare current settings against the hardening baseline, confirm that logging still runs, confirm that access restrictions still apply, or run a scan of the affected endpoints. Tools such as Wazuh Security Configuration Assessment, which scans endpoints against YAML policies and recommends remediation, or Fleet policies, which report which devices pass or fail each osquery-based yes or no check, can produce this evidence if they are configured to cover the affected systems. The output is a verification checklist per change category with a named owner. Confirm the checks with your assessor and the tool vendor's current capabilities before relying on them.
Run a first cycle of real changes and review the records
Apply the process to a set of real, scheduled changes, then review each record end to end: the analysis, the approval, the implementation, and the post-change verification result. Note where reviewers skipped fields, where the analysis missed an affected component, and where verification checks were not run. Record the findings in the change process and correct the template, the workflow or the training. The output is a review report with dated corrections and a sample of closed change records ready for an assessor to examine. You know the cycle is complete when every sampled change shows an analysis before approval and a verification result after implementation.

Evidence that shows 03.04.04 impact analyses is met

An assessor testing 03.04.04 looks for a documented analysis procedure, proof that it ran on real changes, and proof that someone checked the system afterwards. The cards below cover the artifacts that connect those three steps, and each one needs to stay current between assessments, not just exist on the day of the review.

Impact analysis procedure

The written procedure defines what counts as a change that needs a security impact analysis, who performs it, which security requirements the analyst must consider, and what outcome blocks or conditions a change. Check that it names the system owner, the security function and the change board as participants, and that it is approved and version-controlled. An assessor will compare what staff describe in interviews against this document, so gaps between the two are a common finding.

Completed analysis records for sampled changes

For each sampled change, the record should show the proposed change, the analyst's assessment of potential security effects on confidentiality, integrity and availability, the affected components, and the decision reached. Records that only say "low risk" without reasoning rarely satisfy an examine step. Ask your assessor how many recent changes they expect to sample, and keep a register that makes those changes easy to pull.

Change board minutes and approvals

Minutes and approval entries show that the analysis was reviewed before implementation, not written after the fact. Look for timestamps that place the analysis ahead of the approval, named attendees who match the change board roster, and recorded conditions or rejections. Interviews with change board members will test whether they understand the security impact questions they are asked to review, so their minutes should reflect that discussion.

Post-change verification results

The second half of 03.04.04 asks whether the security requirements still hold after the change. Keep scan output, configuration checks, or test results captured after each sampled change, tied to the change record by ticket number. A verification that is run but not linked to the change is hard to show. Confirm with your assessor which verification evidence they accept for changes that were rolled back.

Configuration management plan section

The configuration management plan should describe how impact analyses fit into the wider change process, including the triggers, responsibilities and records. It is the document an assessor reads first to understand your intent, so it should match the procedure and the practice. Review it at the frequency your own plan sets, and record each revision so that the version in force during a sampled change can be shown.

System design documentation used in analysis

An impact analysis is only as accurate as the system description behind it. Keep architecture diagrams, data flow records, component inventories and interface lists current, because analysts use them to identify what a change touches. Stale diagrams are a frequent reason an analysis misses a dependency. Check that each design artifact carries a date or version, and that the analysis record cites the version it used.

What meeting 03.04.04 impact analyses costs in money and effort

This table compares the cost components of running security impact analyses for system changes, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are stated because none are supplied, so use it to structure a quote request and your own internal estimate. The main takeaway is that most of the recurring cost comes from change volume and approval steps, not from the tools.

Cost component	One-time or recurring	What drives it up or down	How to reduce it
Process design and analysis templates	One-time, revisited after major changes	Number of system types, CUI boundaries and change categories that need different analysis depth	Start with one standard template per change category and document which changes need a full analysis
Change tooling or ticketing licenses	Recurring if commercial, none for self-hosted open source	Number of seats, approvers and integrations with monitoring and inventory systems	Use a self-hosted ticketing system with a change workflow, and confirm its change management features against your process
Engineering time per impact analysis	Recurring and volume-driven	Change volume, system complexity, number of CUI components affected and whether dependencies are documented	Keep current system design documentation and component inventory so analysts do not rebuild context for each change
Change board review time	Recurring and volume-driven	Number of approvers, meeting frequency and whether low-risk changes need board review at all	Define pre-approved standard changes with defined security impact limits so the board reviews only exceptions
Post-change verification effort	Recurring per change	Number of configuration settings and controls that must be rechecked after each change	Automate configuration checks against the baseline so verification compares results rather than repeating manual reviews
Staff training	Initial, then recurring for new staff and role changes	Staff turnover, number of people holding impact analysis responsibilities and changes to the process	Train a small group of named analysts and change board members, and record training in your evidence set
Evidence upkeep	Recurring	Number of changes per period, how long records are retained and how many systems share one change record	Store analysis records in the same ticket as the change so evidence is created as work is done
External review or testing	Periodic, scoped by the assessor or the organization	Assessor expectations, scope of CUI systems and how many analysis records are sampled	Ask the assessor which evidence they will sample, and prepare that sample before the assessment

How self-hosted open-source tools produce impact analysis evidence

Under 03.04.04, an assessor looks for a written impact analysis before a change and proof that security requirements still hold afterwards. The four tools below can each generate part of that trail inside your own environment, but none of them performs the analysis or decides whether a change is acceptable. Your change control board still owns that judgment.

GLPI change records

The Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. Use change records to hold the proposed change, the security impact analysis, the approver and the post-implementation review in one place. Confirm that the change template captures the security impact field and that approval steps cannot be skipped. GLPI does not judge security impact on its own, and it cannot show that the analysis was accurate.

Zammad request intake

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It is useful for capturing where a change request originated, who asked for it and when, which feeds the examine evidence for procedures and change intake. Keep requests separate from approved changes. Zammad is a request queue, not a change record, so confirm that tickets link to the GLPI change or are routed there before implementation. Verify its license terms with counsel before deployment.

Wazuh configuration checks

Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, mostly based on CIS benchmarks and extendable with custom policies. It checks files, directories, registry keys and running processes and recommends remediation. Run scans before and after a change to show whether approved settings still hold. A passing scan shows only what the policy checks. It does not prove that a change was analyzed, so pair it with the change record. Confirm that the policies match your approved baseline.

Fleet policy results

Fleet policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices on each fleet are passing or failing each policy. Use them to confirm after implementation that endpoints still meet the security conditions you defined in the impact analysis, such as disk encryption or firewall state. A failing policy is the signal to reopen the change. Fleet cannot identify changes that were never recorded, and it reports only the questions you write, so confirm coverage against your analysis. Check the MIT license terms with counsel.

Who does the impact analysis work, and what to outsource

Your organization owns the impact analysis requirement. Under 03.04.04, the system owner and security staff must analyze a proposed change for potential security effects before it goes live, and then confirm afterward that the security requirements still hold. No outside party can make that call on your behalf, because the analysis is only meaningful when someone accountable for the system understands its design and its CUI flows.

Change policy: Set the rules that decide which changes trigger a security impact analysis, such as firewall rules, identity settings, encryption configuration, new software or new network paths.
Analyses: Staff with knowledge of the system design perform the analysis and record the findings in the change request.
Board decisions: The change control board approves or rejects each change using the analysis, and records conditions attached to the approval.
Post-implementation checks: Named owners confirm that affected requirements still pass after the change, using the verification results your tools produce.
Staffing: Confirm who holds these responsibilities and that they have time allocated, since the work recurs with every change.

Check that each person named in the change policy can explain the analysis they signed off on during an interview.

Where impact analysis programs usually fall short

Most impact analysis programs fail in predictable places: timing, scope, records and follow-up. Each card below names one gap an assessor is likely to find under 03.04.04 and the artifact that closes it, so the analysis exists before a change, covers CUI systems and is verified afterward.

Analyses written after deployment

An impact analysis completed once a change is already live records what happened, not what was assessed. 03.04.04 asks for analysis before implementation, so an assessor will look at timestamps against the change window. Close the gap by making a completed, signed security impact analysis a required field before a change ticket can move to approved. Check a sample of recent changes and compare the analysis date with the deployment date.

Analyses that never mention CUI systems

Many analyses address availability or functionality and say nothing about where CUI is processed, stored or transmitted. An assessor reviewing the analysis documentation will look for the security impact on CUI systems specifically. Close the gap with a standard analysis template that asks the reviewer to name the affected CUI system, enclave or boundary component. Where information location records exist, link each analysis to them so the reviewer does not have to rediscover the CUI scope.

Standard changes with no record

Routine patches, certificate renewals and template updates are often treated as too minor to document. Yet 03.04.04 applies to changes to the system generally, and an assessor sampling change records will notice gaps in the pre-approved categories. Close the gap by defining a standard change catalog in which each pre-approved change type carries a written, reusable impact statement, plus a log entry for every execution. Confirm the catalog with the change board at a defined frequency.

Post-change verification that nobody owns

The second half of 03.04.04 requires verifying after implementation that the security requirements are still satisfied. Programs often stop once the change ticket closes, so no one checks that firewall rules, logging or encryption settings still hold. Close the gap by naming a verifying role for each change and attaching a post-change check to the ticket, such as a configuration scan result or a re-run of the relevant control test. Without an owner and a result, the verification step will not be found in the evidence.

Analyses that drift from design documentation

An analysis based on an outdated architecture diagram assesses a system that no longer exists. Assessors compare the analysis documentation with the system design documentation, so mismatches in component names, data flows or interfaces are visible quickly. Close the gap by requiring the analysis to cite the design document version it used and by updating that document as part of the change closure step. Configuration scanners and inventory exports can help confirm which components are actually present.

Board minutes with no security discussion

Change advisory minutes that record only approvals and schedules give an assessor no evidence that security impact was considered. Interview objects in SP 800-171A include members of the change control board, so the assessor will ask them directly what they reviewed. Close the gap by adding a standing security item to the agenda, recording the impact analysis reference and the decision for each change, and noting any security objection. Minutes should show that the analysis informed the decision.

Questions buyers ask about 03.04.04 impact analyses

How much effort does a 03.04.04 impact analysis take, and what drives it?

The effort depends mostly on how many changes the system receives and how much design documentation exists to analyze each one. A system with a stable architecture and a small number of planned changes needs a light, repeatable template. A system with many integrations, frequent emergency changes or thin design records needs more analysis time per change and more upfront work to document the architecture. No public figure was supplied for typical hours, so ask for an estimate built from your own change volume. Ask the provider to state what it assumes about change frequency, the number of systems in the boundary and the state of your system design documentation before you accept any number.

Can a small team meet 03.04.04 without outside help?

Yes, a small team can meet the requirement without outside help if it has a documented procedure, a named reviewer for security impact, and a change record that shows the analysis happened before implementation and the security check happened afterward. The harder part is consistency, not complexity. Small teams often skip the written analysis for routine changes, which is the gap an assessor is most likely to find. Outside help is most useful for designing the template, setting up tooling to hold the records, and testing whether the procedure works on real change tickets before an assessment.

What do engineers and change board members need to contribute?

Engineers provide the technical facts: which components change, what data they touch, which interfaces and ports are affected, and what could break in the security configuration. Change board members decide whether the security impact is acceptable and approve the change. Assessors interview people with security impact analysis responsibilities and members of the change control board, so both groups must be able to explain the process in their own words. Plan a short training session and make sure board members know which records they are expected to sign.

How long does it take to get the first cycle of records clean?

No researched figure exists for this, so treat any timeline as unverified until the provider states its assumptions. The first cycle usually takes longer than later cycles because the template, the review roles and the records system are new, and because old changes often lack the required analysis. Ask the provider to split the work into template design, a pilot on live change tickets, and a review of past changes that will be sampled as evidence. Confirm the timeline in the written scope before work starts.

Can a partner write the impact analyses for us, and why must we still own them?

A partner can prepare the procedure, the template, the records and the evidence, and can help your team run a first set of analyses. The organization must still own the analyses because the people who approve and sign off on changes are accountable for their security impact. NIST states that the application and implementation of SP 800-171, and compliance issues, are the responsibility of the federal agency that holds the contract with the nonfederal organization. Only an independent assessor issues assessment results, so a partner's write-up does not replace your own analysis or the assessor's review.

Does 03.04.04 differ between Rev. 2 and Rev. 3?

Yes, the wording and classification change, but the core expectation is the same. NIST's change analysis traces 03.04.04 to Rev. 2 requirement 3.4.4 and classifies the change as significant, with more detail and foundational tasks. Rev. 3 also assesses it with two determination statements under SP 800-171A Rev. 3. CMMC Level 2 still uses the Rev. 2 numbering, so defense contractors assessed under that program should map their evidence to 3.4.4 (CM.L2-3.4.4, worth 1 point under 32 CFR 170.24). Confirm which version your contract names, because the answer changes which numbering your records must follow.

Which open-source tools can hold the change and verification records?

A ticketing tool can hold the change record and the analysis. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, with plannings and statistics. Zammad is a web-based helpdesk that brings requests into one ticket system. For the post-change check, Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, and Fleet policies run yes or no osquery checks and show which devices pass or fail. Confirm with each vendor which features fit your process, because these tools produce evidence but do not decide whether a change is acceptable.

How DeployOpen scopes and prepares impact analysis evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the change records, impact analyses and post-change verification that 03.04.04 asks for live in systems you control. We prepare the workflow and evidence for your assessment, while your organization owns the control and an independent assessor reaches its own conclusions.

How we scope

Agree in writing which systems, change types and approval roles fall under impact analysis for 03.04.04.
Confirm which change records, security impact analysis documents and system design documentation will serve as assessment evidence.
Identify the change control board members and personnel whose interviews an assessor is likely to request.

How we build

Configure a ticketing workflow so each change captures its security impact analysis before approval.
Set up configuration assessment checks that compare systems against approved settings after a change is applied.
Connect change tickets to inventory and baseline records so reviewers can see what a change affects.

How we hand over

Deliver a written procedure for security impact analyses, aligned with your configuration management policy and procedures.
Provide a documented walkthrough of sample changes showing pre-implementation analysis and post-implementation verification.
Hand over administrator runbooks and a list of evidence locations so your team can produce records for the assessor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Review the impact analysis workflow when platforms are upgraded or when the system boundary changes.
Confirm with your assessor which evidence format and retention period they expect before the assessment begins.