CM-4 Impact analyses: requirements and evidence

What CM-4 impact analyses require before a change goes live

CM-4 requires an organization to analyze proposed changes to a system for potential security and privacy impacts before those changes are implemented. The point is timing and scope: the analysis happens while a change is still a proposal, so that a change that would weaken a control is caught before it reaches production rather than discovered in a later assessment. The catalog's guidance assigns the analysis to personnel with security or privacy responsibilities, not to the engineer who wants the change or the operator who will deploy it. An assessor will expect that split to be visible in your records.

The risk CM-4 addresses is the change that quietly breaks a control. A firewall rule added to fix a connectivity problem, a logging agent disabled to free resources, or a library upgrade that alters authentication behavior can each leave the system looking unchanged to its owner while the control it was supposed to satisfy no longer works. The control is hard to meet for two reasons that usually appear together. Change handling is often informal, with requests arriving by chat or email and approvals given verbally, so there is no point where an analysis is forced to happen. And many organizations have never defined what counts as in scope for impact, so a reviewer cannot tell whether a database schema change or a new cloud region needs a privacy or security review at all.

Before your next assessment, confirm three things: which change categories must pass through an impact analysis, which roles are qualified to perform it, and where the completed analysis is recorded and linked to the change ticket. Your configuration management plan and change procedures should state these answers, because an assessor will test whether they are followed in practice by sampling recent changes. Where your environment is self-hosted, the impact analysis can be attached to the change record in your own ticketing system, which keeps the analysis, the approval and the implementation evidence together.

Which systems, changes and teams fall under CM-4 scope

CM-4 applies to the changes you make to a system, so scope starts with three questions: which system and components are inside the boundary, which kinds of change must be analyzed, and who has to take part. SP 800-53B selects CM-4 in the low, moderate and high baselines and the privacy baseline, so the impact level of the system sets how deep each analysis needs to go.

System boundary and components

Start with the authorization boundary in your system security plan and list every component inside it, including hosts, databases, network devices, identity services and logging pipelines. An impact analysis cannot judge a change to a component that nobody has recorded as in scope. Confirm that the boundary in your documentation matches the boundary your configuration management tooling actually tracks, and note any shared services that cross it.

Code and application changes

Source code changes, dependency upgrades and new libraries all alter system behavior and can open new attack paths. Define which repositories and branches feed production, and decide which code changes need a documented security impact analysis versus a lighter review. Automated scanning in the pipeline supports the analysis but does not replace the analyst's judgment about data flows and privileges.

Infrastructure and configuration changes

Infrastructure-as-code, firewall rules, identity policies and secure settings can change the security posture of many components at once. Treat a change to a shared configuration as broader in scope than a change to one host. Record which configuration keys, network paths and access policies each proposed change touches, so the analysis covers privacy and security effects and not just the immediate target.

Vendor and patch updates

Vendor releases, firmware updates and emergency patches are changes too, even when a third party writes them. Decide in advance which vendor updates need a documented analysis, and how emergency changes are analyzed after implementation without skipping the record. Ask each vendor what the release modifies, which defaults change and whether any new components or outbound connections are added.

Cloud-managed and third-party components

Cloud-managed services and third-party components often sit partly outside your control, so your analysis depends on what the provider discloses. Document which parts of each change the provider controls, what change notices you receive and how you will verify effects inside your boundary. Where the provider does not share enough detail to analyze a change, record that gap as a risk for the system owner to accept or act on.

Required roles in each analysis

CM-4 guidance places the analysis with personnel who hold security or privacy responsibilities, so the security lead and privacy lead must review changes that affect personal data. System owners supply the functional description and the operational impact, and the change control body decides whether the analysis is complete. Confirm named individuals for each role, along with backups, before the first change window.

How to implement CM-4 in your change workflow

This sequence turns CM-4 from a policy statement into a working habit: every proposed change gets a documented security and privacy impact analysis by named people before it is approved and deployed. Each step produces an artifact an assessor can examine, from the analysis template to the periodic review record.

Define which changes need analysis
Start by writing down the change types that must pass through an impact analysis, such as changes to authentication, network boundaries, data stores, logging, cryptographic settings, software versions and third-party integrations. Decide who may mark a change as standard or pre-approved, and what evidence that decision needs. Ask your assessor or auditor to confirm the scope against your system boundary before you finalize it. The output is a short change classification standard, approved by the change control owner, that defines which changes trigger analysis and which do not.
Build a repeatable analysis template
Create one analysis template that every triggered change must complete. It should ask about security impact (confidentiality, integrity and availability of affected components, new attack surface, changes to access or logging) and privacy impact (new or changed personally identifiable information, data flows, retention and purpose). Include fields for affected components, dependencies, rollback approach and the test evidence expected. Keep the template in version control so changes to it are themselves traceable. The output is the approved analysis template, with an owner and a revision history.
Assign analysts and their responsibilities
Name the personnel who conduct security and privacy impact analyses, and write their responsibilities into the configuration management plan or equivalent procedure. Separate the roles where possible: the change requester describes the change, a security analyst assesses security impact, and a privacy lead assesses personal data impact when the change touches it. Confirm that each analyst has the knowledge and access needed, and record who is authorized to sign off. The output is a responsibility matrix and a roster of qualified analysts that an assessor can interview.
Link analysis records to change tickets
Connect each completed analysis to its change request in your ticketing system so that no change can move forward without a linked record. A change ticket in a self-hosted service desk such as GLPI, which provides ITIL-style change handling, can require the analysis to be attached before approval. Where code or infrastructure changes pass through a repository, protected branches can block merges until the linked review is recorded. Confirm the exact enforcement options in your chosen tools before relying on them. The output is a traceable link from each change ticket to its analysis record, and a sample of linked records ready for examination.
Define how analysis results feed approval
Specify what happens when an analysis finds impact. Set rules for when a change is approved as proposed, approved with conditions such as added testing or monitoring, deferred, or rejected, and who holds approval authority at each level. Route high-impact findings to the change control body and record the rationale for each decision. Confirm that approvers can see the analysis before they decide. The output is an approval decision record for each change, showing the analysis reviewed, the decision, the conditions and the approver.
Verify controls after implementation
Where your baseline includes the verification enhancement or separate test environment enhancement, define how you confirm that security and privacy controls still work after a change is deployed. Document the test environment used, the checks run against the changed system, and the person who signs off the results. Automated static analysis, such as Semgrep Community Edition running in CI/CD, can supply some of this evidence for code changes, but it does not replace functional or control testing. The output is a post-implementation verification record linked to the original analysis.
Review the process periodically
Schedule a recurring review of the analysis template, the change classification standard, the analyst roster and a sample of completed records. Use the review to find analyses that were skipped, records that lack verification evidence and triggers that no longer match the system. Set the review frequency in your configuration management plan and confirm it with your assessor. The output is a dated review record with findings, owners and updates to the template or procedure where needed.

How an assessor tests CM-4 under SP 800-53A

This table shows how SP 800-53A assesses CM-4 through its two determination statements, using the examine, interview and test methods. Read each row as one thing the assessor asks for, the evidence that answers it and the gap that most often causes a finding. The main takeaway is that the assessor looks for impact analyses completed before a change is made, not reconstructed afterward.

Method	What the assessor asks for	Evidence requested	Common finding
Examine: configuration management plan	Whether the plan defines when and how security and privacy impact analyses happen within change control	Approved CM plan, its revision history and the section describing impact analysis roles and triggers	Plan mentions impact analysis only in general terms with no defined trigger or owner
Examine: security and privacy impact analysis documentation	Completed analyses for a sample of recent changes, dated before implementation	Analysis records linked to change tickets, with approval timestamps earlier than deployment timestamps	Analyses dated after deployment or written as a formality with no identified risks
Examine: privacy impact assessments and privacy risk assessment documentation	Whether changes touching personally identifiable information received privacy analysis, not only security analysis	Privacy impact assessment or privacy risk assessment entries for changes that process PII	Privacy content missing from change analyses even where systems hold personal data
Examine: system design documentation and analysis tools with outputs	Whether design documents and tool outputs show what the analysis considered, such as dependencies and affected components	Current architecture diagrams, dependency or scanning outputs and the analysis tool reports attached to changes	Design documents out of date, so the analysis describes a system that no longer exists
Interview: personnel responsible for conducting analyses	Who performs the analysis, whether they hold security or privacy responsibility, and how they judge impact	Role descriptions, named reviewers and examples of analyses they led, explained in their own words	Analyses assigned to engineers without security or privacy responsibility or without review
Test: organizational processes for impact analyses	Whether the process runs in practice: triggers, steps, sign-off and what happens when an analysis finds risk	Walkthrough of a sample change from request to approval, with records at each step	Process exists on paper, but emergency changes skip analysis and no one records the exception

Evidence that satisfies CM-4 and how to keep it current

CM-4 is tested by looking for proof that impact analyses happened before changes went live, not by reading a policy. The cards below cover the artifacts an assessor typically asks for, and each one needs a routine owner so the evidence is still accurate when the next assessment starts.

Impact analysis section in the CM plan

The configuration management plan should state who performs security and privacy impact analyses, which changes trigger one, what the analysis must cover and who approves the result. SP 800-53A lists the plan as an examine object for CM-4, so it is usually the first document an assessor opens. Keep it current by reviewing the section whenever roles change or the change process is revised, and record the review date and approver in the plan itself.

Completed impact analysis records per change

For each change, keep a record showing the proposed change, the security and privacy effects considered, the people who reviewed them and the decision reached before implementation. Assessors check that the date of the analysis precedes the date of the change. Store these records alongside the change itself, and sample a set of recent changes each quarter to confirm that every one has a complete record.

Analysis template and reviewer assignments

A standard template makes analyses comparable across teams, and a named reviewer list shows that the people doing the analysis hold security or privacy responsibilities, as the CM-4 guidance requires. Keep the template under version control and record every reviewer assignment with its effective dates. When staff move on, reassign reviewers and update the list before the next change window opens.

Change tickets linked to analyses

GLPI's Assistance module lets teams create, follow and process change tickets using ITIL-style practices, which gives a single trail from request to approval to closure. Configure the change workflow so that an analysis is a required step before approval, and confirm that your change process matches the module's workflow before adopting it. Periodically check that closed changes link to their analyses.

Protected branch review records

For changes made as code, GitLab Community Edition protected branches can restrict who may push or merge, block direct pushes and keep force pushes disabled unless explicitly allowed. Those settings show that a second person reviewed the change before it reached the main line, which supports the analysis record. The MIT license is permissive, but confirm that the protection settings match your approval rules and export them periodically as evidence.

Repeatable scan results as verification evidence

Semgrep Community Edition, licensed under LGPL-2.1-only, can run in CI/CD pipelines and scan repositories continuously with community or custom rules. Its scan output can serve as post-change verification evidence for CM-4(2), showing that controls were checked after a change, and its results can cover test environment runs where CM-4(1) applies. Confirm that the rule set and language coverage fit your systems, and retain scan reports with the change record they support.

What meeting CM-4 costs in money and effort

This table breaks the cost of meeting CM-4 into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal effort against outside help and to decide what belongs in a written quote. No dollar figures or durations are given because NIST does not estimate compliance costs, and a DeployOpen quote follows from written scope.

Cost component	Who is paid or who bears the effort	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendor, or internal team for self-hosted open-source tools	Recurring for commercial licenses; one-time setup for open-source	Open-source tools such as GLPI remove license spend but still need hosting, configuration and upgrades
Engineering time to build templates	Internal platform or engineering staff, or an implementation partner under fixed scope	One-time, with periodic revision	Number of system types and baselines; integration depth with change tracking and version control
Analyst time per change	Internal security or privacy staff performing the impact analysis	Recurring, per change	Change volume, system impact level, and whether privacy impact is in scope
Evidence upkeep	Internal configuration management owners	Recurring	Retention rules for analysis records, and how many systems feed the same change process
Verification and separate test environments (CM-4(2), CM-4(1))	Internal operations staff; test environment hosting if CM-4(1) applies	Recurring for environments; one-time for test plans	Moderate baseline requires control verification; high baseline also requires a separate test environment
External review of the process	Independent assessor or consultant, engaged by the organization	Periodic	Scope of review, number of systems, and whether assessors need sampled change records
Assessor sampling and testing	Independent assessor, paid by the organization	Recurring with each assessment cycle	Number of changes sampled, quality of records, and how easily impact analyses can be traced to approvals
Quote contents to request	Written scope from any outside provider	Set once per engagement	Ask for named deliverables, system boundary, baseline level, privacy scope, and which evidence the provider will hand over

Separate test environments and verifying controls after a change

CM-4 has two enhancements, and they cover different moments in the change lifecycle. CM-4(1) asks for separate test environments, so that proposed changes can be analyzed for security and privacy impact in a setting that is not production. CM-4(2) asks the organization to verify that security and privacy controls still work after a change is implemented. SP 800-53B selects CM-4(2) in the moderate and high baselines and selects CM-4(1) only in the high baseline. A moderate system therefore carries the verification requirement but not the separate test environment requirement, and a low system carries neither enhancement.

For CM-4(1), the evidence is a record that the test environment exists, how it differs from production, and that changes were tested there before approval. Assessors typically ask for the environment's architecture documentation, the access rules that keep it apart from production, and sample change tickets showing test results attached to the impact analysis. Confirm with your assessor which environment documentation they expect, and whether shared staging systems or cloud sandboxes count as separate in your architecture. In a self-hosted deployment, the configuration repository, change tracker and deployment pipeline usually hold this evidence, so the environment definitions should be stored under version control like any other configuration item.

For CM-4(2), the evidence is a post-change verification record: which controls were checked after a specific change, the method used, the results and who signed off. Practical examples include re-running configuration compliance scans against the baseline, confirming logging still captures required events, and checking that access restrictions remain in place after a change. A low-baseline system can still meet the base CM-4 requirement without either enhancement, because the base control only requires that security and privacy impacts be analyzed before implementation. Those analyses must still be documented, so a low system should keep a clear record of its impact analysis even when it has no separate test environment.

Who does what for CM-4: your team, a partner and the auditor

Your organization owns CM-4. That means you decide which proposed changes need an impact analysis, who performs or approves each analysis, and what the analysis must consider. The control text and its guidance place this work with personnel who hold security or privacy responsibilities, so the people doing the analysis must be named and trained for it. Your team also keeps the records that prove the analysis happened before the change was implemented.

Scope of changes: Define which change types trigger an analysis, such as network, identity, data store or application changes, and which are routine and pre-approved.
Analysts and approvers: Name the individuals who perform security and privacy impact analyses and the people who approve the results.
Decision authority: Keep the accept, modify or reject decision with your own accountable owners. No partner or auditor makes that call.
Records: Retain each analysis, its inputs, its outputs and the approval in a system you control, linked to the change ticket.
Privacy input: Confirm that privacy staff review changes that touch personal data, because the control refers to privacy impacts as well as security impacts.

Check that someone on your side can show, for a sample of recent changes, who analyzed each one, when, and who approved it before deployment.

Where CM-4 programs usually fall short and how to close each gap

CM-4 programs tend to fail in the handoffs between change requests, analysts, test environments and assessors rather than in the analysis itself. The cards below name the gaps that assessors most often find and a practical fix for each, so the impact analysis happens before implementation and leaves records an independent assessor can trace.

Analyses run after deployment

Some teams write the security impact analysis once the change is already in production, which turns CM-4 into a record of what happened rather than a check on what was proposed. CM-4 asks for analysis before implementation. Fix this by making the analysis a required field that must be completed and approved before a change moves to the scheduled window, and check that approval timestamps precede deployment timestamps in your change records.

Privacy impact left out

Many analyses only ask about confidentiality, integrity and availability, so changes that alter how personally identifiable information is collected, stored or shared pass without a privacy review. CM-4 covers privacy impacts as well as security impacts. Add a privacy question to every change template, route affirmative answers to the privacy function, and keep the privacy impact assessment or privacy risk assessment reference on the change record.

Analyses not linked to change tickets

An analysis stored in a document folder or a wiki page cannot be matched to the change it describes, so an assessor sampling changes cannot confirm that each one was analyzed. Require a unique change identifier on the analysis, store the analysis as an attachment or linked record in the ticket, and sample a set of closed changes to confirm each links to its analysis. GLPI's Assistance module, which supports change records under ITIL practices, is one self-hosted option to confirm against your process.

No defined change trigger

If the organization has not defined which changes require an impact analysis, analysts decide case by case and routine patches or configuration edits go unreviewed. Write down the categories that always trigger analysis, such as changes to authentication, network boundaries, data stores and security tooling, and the categories that are pre-approved as standard changes. Review the list at a set frequency and record who approved each change to it.

Test environment separation undocumented

The CM-4 enhancement for separate test environments applies in the high baseline, and assessors will ask how changes are tested before reaching production. Undocumented or informal test setups make it hard to show that proposed changes were evaluated where they could not harm live systems. Document which environments exist, how they differ from production, who can promote changes between them, and how test results feed the impact analysis. Confirm the moderate and high baseline selections in SP 800-53B against your system's categorization.

No post-change verification record

The moderate and high baselines include the CM-4 enhancement for verifying that security and privacy controls still operate after a change. Many teams close a ticket once the deployment succeeds and never record whether the affected controls were rechecked. Add a verification step to the change template that names the controls the analysis flagged, records the check performed, and captures the result and the person who signed it off before the ticket closes.

CM-4 questions buyers ask before hiring outside help

What does CM-4 impact analysis cost in effort, and what drives it up?

Most of the effort is internal staff time, because only the organization knows its system design, change history and data flows well enough to judge impact. The main cost drivers are the number of components and interfaces in scope, how many changes flow through the process each month, whether privacy impact analysis is required alongside security analysis, and how much system design documentation already exists. Under the Rev. 5 catalog, CM-4 is selected in the low, moderate and high baselines and the privacy baseline, so a system at a higher baseline carries a larger analysis scope. NIST does not estimate compliance costs, so no figure is given here. Ask any partner for a written scope that separates one-time setup work, such as defining the analysis template and review steps, from recurring work such as analyzing each change.

How long does CM-4 work take, and what does the schedule depend on?

The timeline depends on how mature the existing change process is, how much system documentation must be produced, and how quickly the organization's reviewers can make decisions. No duration is stated here because NIST does not set implementation timelines for SP 800-53, and no researched figure is available for this control. Ask for the timing in the written scope, and check that it lists the dependencies: access to architecture and design documents, named reviewers with security and privacy responsibility, a test environment if the high baseline enhancement applies, and the change tooling that will hold the analysis records. A reasonable scope will also state when the work is considered complete and what evidence will be handed over at that point.

What does CM-4 require from our own staff?

CM-4 is performed by personnel with security or privacy responsibilities, so the organization must name those people and give them enough system knowledge to judge impact. In practice, this means:

A system owner or architect who can explain the design, interfaces and data flows.
A security reviewer and, where personal data is involved, a privacy reviewer who signs off on the analysis.
Engineers who can describe each proposed change and test whether controls still work afterward.
A configuration management or change board member who holds the analysis records and decides whether the change proceeds.

An implementation partner can prepare templates and the tooling, but the analysis decisions and the responsibility for them stay with the organization.

Can our team run CM-4 impact analysis without an outside partner?

Yes, a capable internal team can perform CM-4 without a partner, because the control is an organizational process rather than a product purchase. The partner question is about capacity and skills: whether the team has time to write the procedure, build the records, and test the enhancements for separate test environments and control verification. Reasonable reasons to bring in help include a small security team, a first assessment cycle, or a system at the high baseline where CM-4(1) applies. A useful self-check is to take three recent changes and confirm that each has a dated impact analysis, a named reviewer, and a record of whether the affected controls were rechecked afterward. If any of those is missing, the gap is the scope to discuss with a partner.

How does CM-4 differ from CM-3 configuration change control?

CM-4 asks the organization to analyze a proposed change for its potential security and privacy impacts before it is implemented. CM-3 covers the wider change control process around that analysis: which changes are controlled, who reviews and approves them, how decisions are documented, and how approved changes are implemented and recorded. In short, CM-4 produces the impact analysis and CM-3 decides what happens with it. The Rev. 5 catalog links the two, and CM-3 is one of the related controls listed for CM-4. An assessor will usually test them together, so one change record should show both the analysis and the approval that followed from it.

Can an implementation partner issue the CM-4 assessment or certify our compliance?

No. An implementation partner can prepare the analysis process, templates, records and evidence, but only an independent assessor, auditor or certification body issues assessment results or reports. DeployOpen prepares systems, controls and evidence for assessment and does not issue audit reports, attestations or certifications. The assessor tests CM-4 against the SP 800-53A procedure, which looks at determination statements and uses examine, interview and test methods, including reviewing analysis documentation, interviewing responsible personnel, and testing the process. Ask any partner to state in writing which parts of the work it performs and which parts remain with the organization and the assessor.

How DeployOpen scopes, implements and prepares CM-4 evidence

DeployOpen helps organizations set up the change analysis process that CM-4 expects, inside their own infrastructure. We prepare the systems, records and evidence; the organization owns its controls, and only an independent assessor can test and report on them.

How we scope

Agree in writing which systems, change types and impact domains the CM-4 analysis process covers.
Confirm with the organization which roles perform security and privacy impact analyses before any change is approved.
Identify the existing change records, design documents and planning tools that the scope will reuse or extend.

How we build

Configure a ticketing and change workflow, such as GLPI's change module, so each proposed change carries an impact analysis field.
Set up protected branches and code scanning in GitLab and Semgrep so code changes pass a recorded review before merge.
Where the high baseline applies, provision a separate test environment to verify controls after a change is made.

How we hand over

Deliver written procedures describing how analyses are requested, performed, reviewed and retained.
Provide sample change records and a mapping of each CM-4 assessment objective to the artifact that shows it.
Walk the organization's staff through the workflow so the analysis records are produced by the people who own them.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and periodic review of change records are available as a retainer.
Confirm with your assessor which evidence formats and sampling they expect before the assessment begins.