03.04.03 Configuration change control: evidence and tests

What 03.04.03 configuration change control asks for

A contract or assessment that requires NIST SP 800-171 expects you to show that every change to a CUI system is controlled, not just the changes you remember. Requirement 03.04.03 asks for four things: define which kinds of changes count as configuration-controlled, review proposed changes and approve or disapprove them with security impacts explicitly considered, implement and document the approved changes, and monitor and review change activity over time. NIST lists CM-3 from SP 800-53 Rev. 5 as the source control, and the Rev. 3 discussion points to 03.04.04 (impact analyses) for how the security review itself is carried out. Expect an assessor to ask for the written definition of controlled changes, the change records behind a sample of recent changes, and evidence that someone with security responsibility reviewed them.

The risk is quiet erosion. A firewall rule opened for a vendor, a patch applied directly on a server, or a logging agent turned off to fix a performance problem can each weaken a CUI boundary without anyone deciding that it should. Over months, the running system drifts away from the documented baseline and the System Security Plan describes a system that no longer exists. Teams find this hard for predictable reasons: change habits are informal and live in chat threads, emergency fixes skip the queue and are never written up afterwards, and ticketing or deployment tools do not record who approved what. Each gap is easy to close on its own, but together they leave no trail an assessor can follow.

Start by writing down which changes need a record, for example changes to network rules, identity settings, security tooling, operating system builds and any component that stores or transmits CUI, and confirm with your assessor or contracting officer how they read that scope. Then decide who sits on the change control board or equivalent, how emergency changes are approved and documented after the fact, and which system holds the record. Open-source ticketing tools such as GLPI, which includes an ITIL-style change module, or Zammad can hold that record, and endpoint tools such as Wazuh or Fleet can show whether configurations still match what was approved. Confirm each tool's change-tracking features in your own environment before you rely on them as evidence.

Which changes, systems and teams fall under 03.04.03

Scope under 03.04.03 is set by three questions: which systems hold or process CUI, which kinds of change count as configuration changes, and who besides your own staff can make those changes. Each card below is a decision you should record before you write change procedures, because each one changes how much review, evidence and monitoring you need.

Systems that hold or process CUI

Start with the system security plan boundary, not the whole IT estate. Any system that stores, processes or transmits CUI, and any security tool that protects those systems, falls under configuration change control. Check file shares, email, collaboration platforms, engineering workstations and backup targets, since CUI often sits in places nobody listed. Record the boundary and the reason each system is inside or outside it, so an assessor can trace the decision.

Operating system and firmware patches

Operating system updates, kernel changes, firmware updates and BIOS settings change how a system behaves and may alter security functions. Decide whether emergency security patches follow the same review path as planned feature changes, and document any expedited route. Confirm that patches are tracked with their approval, implementation date and verification result, because an assessor will look for that trail rather than a general statement that patching occurs.

Security tool and endpoint settings

Changes to endpoint protection, logging agents, encryption settings, and vulnerability scanner policies are configuration changes even though they are made by the security team. Disabling a logging agent or relaxing a detection rule can remove the evidence other requirements depend on. Include security tool settings in your change scope and require security impact review for any change that reduces monitoring or protection.

Network rules and firewall changes

Firewall rules, routing changes, VPN settings and segmentation between the CUI enclave and other networks are high-impact configuration changes. A rule added to solve a connectivity problem can open a path into the enclave. Require a documented business reason, an approver outside the requesting team, and a check that the change does not weaken the boundary protections that the system security plan describes.

Cloud IAM roles and policies

In cloud environments, identity and access management policies, role assignments, security groups and key policies are configuration. A new administrator role or a wildcard permission can change who can reach CUI without touching a server. Decide who may approve IAM changes, how temporary privilege is recorded, and how the change log from the cloud provider is retained and reviewed.

Third parties that make changes

Managed service providers, hosting companies, software vendors and support contractors that make changes to in-scope systems must follow your change process. Write this into contracts and access procedures, and confirm that their changes reach your change records. Ask each provider how they log remote sessions, who approves their changes, and how you learn about changes made on your behalf.

How an assessor tests 03.04.03 and what passes

This table walks through how an assessor works through the seven SP 800-171A Rev. 3 determination statements for 03.04.03, grouped by examine, interview and test method. Read each row as the question the assessor asks, the records that answer it, and the gaps that most often lead to a finding. The main takeaway is that a written change policy is not enough; the assessor needs records that show each change was reviewed for security impact, approved before it was implemented, and traceable to the process.

Test approach	Evidence requested	Common findings
Examine: change control policy and procedures	Written policy and procedures defining which changes are configuration-controlled, who reviews them and how security impact is considered	Procedures omit security impact review, or do not define which changes fall under control
Examine: configuration management plan	Plan that names the change control board or equivalent, approval criteria, and how changes are documented and monitored	Plan describes a board that no longer meets or has no defined membership
Examine: system architecture and configuration settings	Architecture documents and current configuration settings showing which components are under change control	Components in the architecture are missing from the change scope, so their changes are not governed
Interview: staff with change responsibilities	Walkthrough of how a change moves from request to implementation, with consistent answers across the team	Staff describe steps that differ from the written procedure, or emergency changes handled informally
Interview: information security staff	Explanation of how security impact is assessed for proposed changes and who signs off on that assessment	Security staff are not involved in reviewing changes, so impact is never analyzed
Interview: change control board or similar members	Account of how proposed changes are reviewed, approved or disapproved, and how dissent or deferral is recorded	Board members approve changes by email without a recorded rationale or security consideration
Test: change control process	Sample of recent changes traced from request through review, approval, implementation and documentation	Approvals recorded after implementation, or change tickets closed without evidence of testing or review
Test: mechanisms that implement change control	Ticketing, workflow or configuration tooling that enforces approval before deployment, with logs of change activity	Changes made directly on systems bypass the process, and monitoring does not detect them

How to set up change control that passes an assessment

This sequence turns 03.04.03 into a working process: scoped change types, a written procedure, approvers who consider security, recorded and enforced changes, and a periodic check that every change activity has a matching record. Each step leaves an artifact an assessor can examine, interview against and test.

Define configuration-controlled change types and systems in scope
Start by listing the systems that hold or process CUI and the component classes inside each boundary, such as operating systems, network devices, endpoint agents, cloud configurations and security tooling. Then define which kinds of change count as configuration-controlled, for example firmware updates, security setting changes, new services, account policy changes and changes to logging or boundary rules, and which are routine and pre-approved. Your configuration management plan should record the list. The output is a scoped change catalog that an assessor can compare against your system boundary.
Write the change procedure with roles and approval thresholds
Write a change control procedure that names who requests, implements, reviews and approves each change type, and set the thresholds that decide which changes need a board decision and which a named approver can authorize. Include emergency change handling, with the rule that emergency changes still get documented review after implementation. Have the system owner and the information security lead sign off on the procedure. The output is a current, approved procedure that matches how the team actually works, since interviews test whether staff know it.
Set up the change record and the approval body
Configure a single system of record for change requests, such as a ticketing tool with change workflows. Each record should capture the requester, description, affected components, planned implementation and rollback steps, testing evidence and approver decisions. Establish the change control board, or name the approvers if the organization is small, and document membership and meeting or approval cadence. Open-source options such as GLPI include change management modules that follow ITIL practices, but confirm the workflow fields and approval steps in your own environment before relying on them. The output is a working record template and a documented approval body.
Require a security impact statement on every change
Add a required field to every change record that asks the requester to describe the security impact: effects on access, logging, encryption, boundary protection, and the configuration baseline. Reviewers should approve or disapprove a change only after reading this statement, and the record should show that they did. Where the impact is unclear, route the change to a formal impact analysis under 03.04.04 before approval. The output is a completed statement on each record, which is the clearest evidence that security was considered during review.
Enforce the process with technical controls where possible
Reduce reliance on memory by tying the process to systems. Restrict who can apply changes to production systems through privileged access groups, require change record numbers in deployment pipelines or configuration management tooling where your stack supports it, and alert on configuration drift. Endpoint and host tools can flag unexpected configuration changes, for example Wazuh's Security Configuration Assessment checks endpoints against YAML policies, and Fleet policies can show which devices pass or fail a yes or no check. Confirm each tool's capability and coverage in your environment before naming it as an enforcement control. The output is a list of enforcement points and their configured alerts.
Implement, test and document each approved change
Once approved, implement the change through the documented route, record the actual implementation date, the people involved and the test results, and note any deviation from the plan. Failed or partial changes should be rolled back or re-approved, and the record should say which happened. Where the change alters a system's configuration, update the baseline configuration under 03.04.01 and the settings documentation under 03.04.02 so they reflect the current state. The output is a closed change record linked to the updated baseline.
Review change activity against recorded changes
On a schedule you define and document, compare logs of configuration activity from your monitoring and audit tools against the change records. Each logged change should map to an approved record, and each record should map to an observed implementation. Investigate unmatched activity as a possible unauthorized change, and feed recurring gaps back into the procedure and the change catalog. Keep the review output, including the reviewer, date and findings. The output is a dated review record that demonstrates monitoring and review, which is the part of 03.04.03 assessors most often ask to see.

Evidence that proves 03.04.03 is working between audits

An assessor testing 03.04.03 wants to see a defined change process, then proof that people followed it for real changes over time. The six artifacts below connect the written procedure to the ticket trail, approvals, implementation records and monitoring that show it operating between assessments.

Change control procedure and configuration management plan

This is the document that defines which changes are configuration-controlled, who reviews them, and how security impact is considered. Keep it under version control, and review it at least when the system boundary, tooling or change board membership changes. Check that the definitions of a configuration-controlled change match what your ticketing system actually records, because assessors compare the two. Ask the assessor's interview questions of your change manager before the assessment and confirm the answers match this document.

Change tickets with classification

Every configuration-controlled change should have a ticket that records the type of change, its requester, its scope and its priority or category as defined in your procedure. A helpdesk or ITSM tool such as GLPI's Assistance module can hold these records with change workflows. Sample tickets monthly, checking that emergency and standard changes are classified as your procedure says and that no change reached production without a ticket. Expect assessors to ask for a complete change population for a sample period.

Security impact statements and approvals

For each proposed change, the record should show that the security impact was considered before approval, including effects on access, logging, encryption and boundary controls. Require a short, written impact statement as a mandatory ticket field, and record approval or rejection with the approver's name and date. Review a sample each month for blank impact fields or approvals given by someone outside the defined approver group. Assessors will ask who decided and what they considered.

Change board minutes and approval logs

Where a change advisory or change control board reviews changes, keep minutes that list the changes discussed, decisions made, dissent and follow-up actions. Approval logs from the ticketing tool should match the minutes, so a reviewer can trace each approved change to a meeting or to a documented delegated approval. Confirm the board's membership includes people with information security responsibilities, as the procedure defines. Assessors commonly interview board members to confirm they understand their role.

Implementation and post-change verification records

Approved changes need records showing what was implemented, when, by whom, and whether the system was verified afterward. Link each change ticket to the deployment record, configuration diff or pull request, and to a verification result that confirms the change worked and did not weaken security settings. Failed or rolled-back changes should be recorded too. Check monthly that closed tickets have both an implementation record and a verification entry, since gaps here are a frequent finding.

Monitoring reports comparing recorded and observed changes

Monitoring shows whether changes happened outside the approved process. Configuration assessment tools such as Wazuh's Security Configuration Assessment compare endpoint settings against policies and recommend remediation, and Fleet policies show which devices pass or fail a yes or no check. Schedule a recurring report that compares these observed changes against approved tickets, and document how each unexplained difference was investigated. Confirm with your tool vendor what each check can detect before relying on it as evidence.

What your team, a partner and the assessor each own

Your organization owns the configuration change control requirement itself. That means deciding which changes are configuration-controlled, who sits on the change board, what counts as a security impact, and whether a risk is accepted. These are management decisions, and no outside party can make them on your behalf. The partner and the assessor both depend on the answers your team records.

Change policy and scope: Define the change types that require review, including emergency changes, and document them in your configuration management policy and procedures.
Approvers and the change board: Name the people or roles who approve or disapprove changes, and record their authority and alternates.
Approvals and risk acceptance: Keep the approval record for each change, including the security impact considered and any risk accepted by a named owner.
Execution and documentation: Your staff or contracted engineers implement approved changes and update the configuration records afterward.
Ongoing monitoring: Review change activity on a defined cycle and investigate changes that bypassed the process.

Before engaging anyone, confirm with your assessor which artifacts they expect to see for each of these points.

What meeting 03.04.03 costs in money and effort

This table lists each cost component of configuration change control, who is paid for it, whether it is one-time or recurring, and what drives it up or down. No supplied source prices this work, so use the drivers to decide what a written quote must itemize. Recurring change board and evidence work usually costs more over time than the initial setup.

Cost component	One-time or recurring	What drives it and how to keep it down
Ticketing or change tooling licenses	Recurring	Seat counts and add-on modules drive license spend. Self-hosted open-source tools such as GLPI or Zammad can remove license fees, but hosting, upgrades and support still cost money. Confirm which features you need before choosing.
Engineering time to define change types and set up enforcement	One-time, with later changes	Number of system types, integration with pipelines and endpoint tools, and how many change categories you define. Keep the first set of change types short and expand after the first review cycle.
Policy and procedure writing	One-time, with periodic review	Whether a configuration management policy and procedures already exist and how many systems they cover. Reuse existing change management documents and cite the system security plan rather than rewriting it.
Change board time	Recurring	Frequency of changes, number of reviewers and the depth of security impact review for each proposal. Use standard change templates and pre-approve low-risk standard changes so the board reviews only exceptions.
Evidence upkeep and sampling	Recurring	Volume of change records, how consistently approvals are captured, and how quickly an assessor's sample can be pulled. Store approvals and implementation records in one system with consistent identifiers.
Monitoring tool operation	Recurring	Number of endpoints monitored, alert triage workload and how many configuration policies are tuned. Start with the policies that cover your highest-risk systems and confirm the tool's licensing terms for each endpoint.
External readiness review	One-time or periodic	Scope of the systems reviewed and whether the reviewer tests change records against your own sample. Ask for a fixed-scope written plan listing systems, change records sampled and deliverables.
Assessor's sampling and testing fees	Per assessment	Assessment type and the number of change records and systems the assessor samples. Ask the assessor to state the sample method and the evidence list in writing before fieldwork starts.

Self-hosted open-source tools that can produce change control evidence

Configuration change control under 03.04.03 needs a record of what was proposed, who approved it, what changed and whether anything drifted afterward. The four tools below cover different parts of that trail, from the change request itself to the state of the endpoints. None of them decides whether a change is acceptable, and the organization still owns the change control process.

GLPI change tickets

The Assistance module of GLPI lets teams create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. It can hold the proposed change, the security impact review, the approver and the implementation record in one place. Check that your approval steps match your change board's actual workflow, and confirm with your assessor that the ticket history meets their expectations for review and approval. Confirm the license terms with your counsel, since GLPI is GPL-3.0-or-later.

Zammad requests from outside

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It suits change requests that arrive from business units, vendors or customers before anyone on the platform team has reviewed them. Recording those requests as tickets keeps the origin and the discussion attached to the eventual change. Zammad is licensed AGPL-3.0-only, so review your obligations if you modify and host it for users outside your organization.

Wazuh configuration drift checks

Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, most of them based on CIS benchmarks, and can be extended with custom policies. It checks files, directories, registry keys and running processes, and recommends remediation. Its results can show when an endpoint has moved away from its approved configuration without a logged change, which is useful evidence for monitoring change activity. Confirm which policies match your approved baseline and whether your assessor accepts scan results as monitoring evidence. Wazuh is licensed GPL-2.0-only.

Fleet policy pass and fail

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. Each policy can express a required setting, such as a disk encryption or firewall state, that a change should not break. A failing device after a change window is a visible signal to open a ticket and confirm whether the change was approved. Confirm that the query results are retained long enough for your assessment period, and that a failing policy triggers a documented response. Fleet is licensed MIT.

Where organizations usually fail 03.04.03 and how to close the gap

The most common failure under 03.04.03 is an emergency change that never gets reviewed after the fact. Under pressure, administrators patch a firewall rule, alter an identity provider setting or push a hotfix to a CUI system, and the ticket is either created days later or never created at all. An assessor will test whether the organization's change control process covers emergency changes, so the fix is a defined emergency change path written into the configuration management procedures. It should state who may authorize an emergency change, what minimum record must exist before or within a set window after the change, and a retrospective review by the change control board or a delegated reviewer. Ask your team to pull the last quarter of changes from the firewall, directory and endpoint management consoles and compare them against tickets. Any change without a ticket is a finding you should resolve before an assessor finds it.

The second failure is that no one owns the security impact of a proposed change. Change boards often review schedule, availability and cost, while the security question is assumed to be answered by someone else. The fix is to name a security reviewer as a standing member of the change control board, with the authority to disapprove a change or require conditions. Their review should be recorded on each change request, covering the components affected and the security settings that could move. The analysis of effect on protections belongs to 03.04.04, but 03.04.03 requires that approval or disapproval explicitly consider security impacts, so the record must show that consideration happened. Confirm with your assessor how they expect the security review to be evidenced.

The third failure is approvals recorded in chat or email. A message that says "fine by me" in a team channel is hard to tie to a specific change, a specific version of the configuration and a specific approver with authority. Move approvals into the ticketing system of record, where the change, its affected components and the approval decision live together. Open-source service management tools such as GLPI, whose Assistance module supports ticket-based change handling, can hold this record, though you should confirm that the workflow, approval fields and retention meet your own procedure. The fourth failure is monitoring that never reconciles with the change log. Configuration monitoring such as Wazuh Security Configuration Assessment or Fleet policies may detect drift, but unless someone compares those detections against approved tickets each month, unexplained changes accumulate without investigation. Set a monthly reconciliation with a named owner, record each unexplained change as an incident or a retroactive change request, and keep the reconciliation output as evidence.

Questions buyers ask about 03.04.03 cost, effort and outside help

What does 03.04.03 require from our own staff?

Your organization owns the change control process, so its people must make the decisions: defining which changes are configuration-controlled, reviewing proposed changes, approving or rejecting them with security impacts considered, and recording what was implemented. The assessor will interview people with configuration change control responsibilities, people with information security responsibilities, and members of a change control board or similar group, so those roles need named owners who can explain the process. Expect staff time for a change board or approver, engineers who submit and document changes, and someone who reviews change activity on a defined basis.

Can a small IT team meet 03.04.03 without outside help?

Often yes, because the requirement is about a documented, repeatable process rather than a large tool purchase. A small team can usually write the change procedure, use one approver for low-risk changes, and keep a change log in a ticketing system it already runs. Outside help tends to become useful when the team lacks time to write the procedure, needs the change records tied to a system security plan, or wants the change workflow and monitoring configured on self-hosted platforms. Whether your team can do it alone depends on how many systems hold CUI and how often they change.

What drives the cost of meeting 03.04.03 up or down?

The main cost drivers are the number of systems inside the CUI boundary, the number of changes made each month, how many separate approval paths exist, and whether change records already exist in a ticketing system. Costs fall when one process covers all in-scope systems and records are generated automatically. Costs rise with manual change logs, multiple unconnected teams, and monitoring that must be built from scratch. Ask any provider for a written quote that lists the systems in scope, the deliverables (procedure, change workflow, monitoring configuration, evidence package), and which items are one-time and which recur, such as ongoing change reviews and tool upkeep.

How long does it take to be ready for a 03.04.03 assessment?

No researched duration is available for this requirement, so treat any date a vendor gives you as an estimate to test, not a fact. In general terms, readiness depends on whether a change process already exists, how many people must be trained on it, and how long it takes to collect several cycles of change records, since an assessor needs evidence that the process actually ran. Ask any partner to break the timeline into scoping, process definition, tool configuration, staff onboarding and evidence collection, and to state which steps depend on your own staff availability.

Can an implementation partner issue the 03.04.03 evidence or certify our compliance?

No. Your organization owns its controls, and an implementation partner such as DeployOpen can prepare the systems, change workflow, monitoring configuration and evidence for review. Only an independent assessor, such as a DCMA DIBCAC assessor for DoD contracts or a qualified assessor under the applicable program, can assess the requirement and issue a result. Under DoD's assessment process, the organization submits its own score, so the accuracy of the change records it produces matters. Confirm the assessment method with the contracting officer or the sponsoring agency before you commit to a scope.

How does 03.04.03 relate to the Rev. 2 wording in DoD contracts today?

Current DoD contracts reference Rev. 2, where the closest requirement is 3.4.3, and CMMC Level 2 assesses it as CM.L2-3.4.3, worth 1 point under the 32 CFR 170.24 scoring methodology. NIST's change analysis maps 03.04.03 to Rev. 2 3.4.3 and classifies the change as significant, with more detail and foundational tasks. DoW Class Deviation 2026-O0025, Revision 3 names Rev. 2 explicitly, while a proposed FAR overhaul would require Rev. 3 with values set by the DoW CIO. Because the rule was not final when this was written, confirm which revision your contract cites and build the change process so it meets both wordings.

How DeployOpen scopes and prepares change control evidence

DeployOpen works on 03.04.03 as an implementation partner. We prepare the change control process, the tooling that records changes and the evidence an assessor will examine, while your organization owns the decisions, approvals and the system security plan. Independent assessors, not DeployOpen, issue any assessment result.

How we scope

Agree in writing which system components fall under configuration control and which change types the process covers.
Define the change categories that require security impact review before approval, with your change control board membership named.
Record in the written scope which existing tickets, change records and policy documents will be reused and which will be created.

How we build

Configure a change request workflow in the ticketing platform, including fields for proposed change, security impact and approver.
Set up endpoint and configuration monitoring so changes outside approved records are detected and reported for review.
Test the workflow with sample changes so the approval and implementation trail can be shown end to end.

How we hand over

Deliver the configuration change control procedure, the change record template and a mapping of each determination statement to its evidence.
Provide a sample evidence package with approved change records, review minutes and monitoring reports for your assessor to examine.
Document how changes link to the impact analysis (03.04.04) and baseline records (03.04.01) so reviewers can trace them.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your organization wants it.
Review change activity samples with your team on a schedule agreed in the written scope, so gaps are caught before an assessment.
Confirm with your assessor and contracting officer which parameter values and evidence formats they expect before final delivery.