CM.L2-3.4.3 System change management: requirements and evidence

What CM.L2-3.4.3 system change management requires and why assessors look at it

CM.L2-3.4.3 asks you to track, review, approve or disapprove, and log every change made to an organizational system that handles CUI. It is worth 1 point under the scoring rules in 32 CFR 170.24. That weight is small, but the requirement sits underneath much of the rest of the configuration management family, so a gap here usually means the baseline and the SSP are no longer trustworthy. If your change records live in a ticket queue, a mailbox, a shared spreadsheet and the admin logs of a few servers, the assessment will expose that fragmentation quickly. The practical first step is to list every path by which a system can change (service desk tickets, emails to administrators, vendor remote sessions, cloud console edits, emergency fixes) and decide which of them must feed one controlled record. The risk is straightforward. An unrecorded change to a system holding CUI can open a port, weaken a logging setting, or replace a component without anyone knowing it happened, and later incidents become hard to explain or contain. In practice the hardest changes to capture are the informal ones: an administrator who fixes a service at 2 a.m. and plans to document it later, a managed service provider or software vendor who logs in through a remote tool, or a patch applied by an automated job that nobody reviewed. NIST SP 800-171A breaks the requirement into four assessment objectives: changes are tracked, changes are reviewed, changes are approved or disapproved, and changes are logged. Assessors check each one with evidence, so a change that was approved but never recorded still fails the objective for logging. To prepare, confirm with your assessor and your own environment which change records they expect to see, and whether any changes are excluded from the process. Then sample three or four recent changes end to end and check that each has a request, a reviewer's decision, a timestamp and a closure entry. Keep the change record linked to the system security plan entries it affects, because the SSP is where the assessor compares what you say the system is with what the change log shows it became. For the current assessment status of Level 2 requirements, confirm the latest guidance on the DoW CIO About CMMC page before you set your timeline.

Which systems, changes and teams fall under the change control requirement

CM.L2-3.4.3 only applies to what sits inside your CUI boundary, so the first work is deciding which systems, change types and people are in scope. Each decision below changes how many change records you must keep and who must appear in your approval trail.

Systems inside the CUI boundary

Start with the system security plan boundary and list every asset that stores, processes or transmits CUI, plus the components that protect them, such as identity services, logging collectors and management consoles. Change records must cover these assets. Assets outside the boundary can stay under lighter change practices, but you must be able to show the boundary line to an assessor and explain why each excluded asset cannot affect CUI. Confirm the boundary with your SSP before you scope change control.

Hardware and firmware changes

Physical changes such as adding a server, replacing a firewall, swapping a network card or updating firmware on a router are changes to organizational systems. Each one needs a record showing what changed, when, who approved it and the outcome. Firmware updates on in-scope appliances are often missed because they run outside normal software release processes. Include vendor-driven firmware updates and emergency hardware swaps in the same change log.

Software and application changes

Operating system patches, application upgrades, new packages and plugin installs on in-scope systems all count as changes. Patch cycles are often the largest volume of change records, so decide early whether routine patches follow a standard pre-approved change type or each patch gets its own ticket. Whichever you choose, document the rule and show that it was applied consistently in the evidence you give an assessor.

Configuration and cloud resource changes

Changes to security groups, firewall rules, IAM roles, storage access policies, logging settings and infrastructure-as-code templates alter how CUI is protected even when no server is touched. In cloud environments, a single console edit or pipeline run can change many resources at once. Route these changes through the same change records, and make sure infrastructure-as-code commits and console changes both leave a traceable record that ties back to an approval.

Internal administrators and change-making teams

Every team that can alter an in-scope system is in scope, including network, server, database, identity and help desk staff with elevated rights. Build a list of accounts and groups with change privileges and map each to the change process. Shared administrative accounts or emergency access accounts need extra attention, because actions taken under them must still be attributable to a named change record.

Managed service providers and cloud administrators

Managed service providers and external cloud administrators who change in-scope systems fall under the change control requirement, whether or not they sit in your organization. Put them in the change process with the same records, approvals and logs you require of your own staff, and write this into the service agreement. Ask each provider how they record changes they make on your behalf, and confirm you can review those records during an assessment.

How an assessor tests change management under CM.L2-3.4.3

This table maps the four SP 800-171A assessment objectives for CM.L2-3.4.3 to the test approach, evidence an assessor requests and the findings that appear most often. Read each row as one objective the assessor must see satisfied with evidence in final form, since a requirement is MET only when every applicable objective is met.

Assessment objective	How the assessor tests it	Evidence requested and common findings
Changes are tracked	Selects a sample of changes from the period under review and traces each one back to a change record, then checks that changes seen on the system have a matching record.	Change tickets with requester, description and affected system. Finding: changes made outside the process, such as direct edits on production servers with no ticket.
Changes are reviewed	Reads review notes or board minutes for sampled changes and checks that someone other than the implementer examined the change before a decision was made.	Agendas, minutes and reviewer sign-off on each record. Finding: review recorded as a rubber stamp, or no review entry at all for emergency changes.
Changes are approved or disapproved	Confirms that each sampled change carries a dated decision by an authorized approver, and interviews change control board members on how decisions are made and who has authority.	Approval records with approver identity and timestamp dated before implementation. Finding: approvals recorded after implementation, often added to tickets once the change is already live.
Changes are logged	Compares change records with system audit or configuration history for the same window to confirm the log shows what changed, when and by whom.	Change log entries, system configuration history and audit records that match. Finding: change records that do not match actual configuration state, or gaps in the log.

How to implement a change control process that produces assessable evidence

This sequence turns CM.L2-3.4.3 from a policy statement into a working change process in which every system change leaves a record, an approval, a logged closure and a link back to the System Security Plan. Each step names the output an assessor can inspect.

Define the change process and its scope
Start by writing a short change management procedure that states which systems, components and configurations fall under change control, which change types exist (standard, normal and emergency), and who may request, approve and implement each type. Scope it against the CUI boundary defined in your SSP so that every in-scope asset is covered. The output is an approved change management procedure with a scope statement. You know this step is done when every in-scope asset class has a named owner and a change path.
Build the change record template and workflow
Create a standard change request form and a ticket workflow in your service management tool. Each record should capture the requester, the system affected, a description of the change, the reason, the planned implementation window, the rollback approach, the approver and the status. Open-source options such as GLPI, whose Assistance module supports tickets, problems and changes following ITIL practices, can hold this workflow. The output is a live workflow with mandatory fields, and you can confirm it by creating a test change and checking that every required field is enforced.
Establish the change control board
Charter a change control board with named members, a quorum rule, decision criteria and a fixed meeting cadence. Include representatives from system administration, security and the system owner, and record who is responsible for the board's agenda. Assessors may interview board members and review agendas and minutes, so the charter should say how decisions are recorded. The outputs are a signed charter and the first set of agendas and minutes. You know this step is done when the board has met and its decisions appear in the change records.
Require approval before implementation
Configure the workflow so that no normal change moves to implementation until the board or a delegated approver has recorded an approve or disapprove decision with a name, a date and a rationale. Disapproved changes stay in the log with the reason. For emergency changes, define the retroactive review step so that the approval is still recorded and reviewed. The output is approval evidence attached to each record. You can test this by sampling records and confirming that no implementation timestamp precedes an approval.
Log implementation and closure with post-change verification
Record the actual implementation date, the people who performed the work, any deviation from the plan and the result of a post-change check that confirms the system behaves as intended and that security settings were not weakened. Close the record only after this verification is complete. The output is a closed record with its full history, which covers the logging element of 3.4.3. You know this step is done when open records older than your procedure allows are reviewed rather than left to drift.
Link change records to the SSP and configuration baseline
Tie each closed change to the system component it modified, and update the SSP and the configuration baseline where the change altered the documented environment. Use the same asset identifiers in the inventory, the change record and the SSP so that an assessor can trace a component from its baseline entry to its change history. The output is a traceable set of records and updated SSP sections with revision dates. Confirm this step by picking one component and tracing it from the baseline to every change that touched it.
Review the change log on a recurring schedule
Set a recurring review of closed changes to confirm that every change followed the procedure, that no unauthorized changes appear in the system logs, and that unrecorded changes are investigated. Document the review as a dated record with findings and follow-up actions. The output is periodic review evidence, which supports the broader assessment of your controls and the ongoing monitoring expected under the CA family. Ask your assessor which review frequency and sampling method they expect before you set it.

Change records and approval evidence that satisfy the requirement

Assessors test CM.L2-3.4.3 by checking whether each change was tracked, reviewed, approved or disapproved, and logged. The cards below cover the artifacts that show this, from individual change records to the oversight records that show the board actually runs. Each artifact must exist in final form and stay current between assessments.

Individual change request records

Each change needs its own record with the request, a description of the change, the affected system and configuration items, the requester, an impact analysis reference, the approval decision, and the implementation result. Assessors sample records to confirm every field is filled in and that the record shows the change was tracked before it was implemented. Check that records link back to the system components they affect so the change can be traced to the System Security Plan boundary. Ticketing tools such as GLPI include change objects that can carry these fields.

Approval and disapproval decisions

The requirement covers both approving and disapproving changes, so the record must show a decision for every request, including rejections with a stated reason. Capture the approver's name, role, date and decision in the record itself, not in a separate chat thread. Assessors will look for rejected or deferred changes as evidence that the board actually reviews requests rather than rubber-stamping them. Confirm that approvers are the people your change control procedure names.

Change control board agendas and minutes

Assessment objects for this requirement include agendas and minutes of configuration change control oversight meetings. Minutes should list the changes reviewed, the decisions made, any conditions attached to approvals, and the attendees. Assessors may interview board members, so the minutes must match what members can describe. Keep the agenda issued before each meeting and the minutes signed or approved, since a draft set will not satisfy the final-form test.

Change control audit and review reports

Periodic reviews of the change process produce reports that show whether changes were tracked, reviewed and logged as the procedure requires. Test a sample of implemented changes against their records, note any unauthorized or undocumented changes, and record the corrective action. Assessors look for evidence that someone outside the change process checks it, so assign the review to a person who does not approve changes. Date each report and keep prior versions so the review history is visible.

Logs of executed changes

The logging part of the requirement is met by records that show what was actually changed, when, by which account, and under which approved change number. Pull these from configuration management tools, hypervisor and cloud audit trails, and directory changes, then reconcile them against approved requests. Any change in the logs without a matching approved record is a finding to resolve before the assessment. Confirm that the logs are protected from edit by the people who make changes.

Retention and periodic sampling between audits

Evidence has to exist for the whole period an assessor will review, so set a retention period for change records, minutes and logs and apply it consistently. Run a recurring sample, for example each month, that pulls a set of changes and checks each one for the full chain of records. Store the sample results with the records they cover. Ask your assessor or consultant which retention period and sampling depth they expect, because neither is set by the requirement text itself.

What meeting CM.L2-3.4.3 costs in tooling, staff time and external review

This table breaks the cost of running change management for CM.L2-3.4.3 into its components, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to build a quote request, since no prices or durations are supplied here and every figure depends on your environment and written scope.

Cost component	Who is paid or who spends time	One-time or recurring	Main cost drivers
Change tool licenses (ticketing or ITSM)	Software vendor or reseller, if a commercial tool is chosen	Usually recurring (subscription or maintenance)	Number of named users, approvers and requesters; modules bought; hosting model
Self-hosted open-source change tooling	Staff time for hosting, upgrades and backups; implementation partner if engaged	Setup one-time, operations recurring; no license fee for the software itself	Number of systems tracked; integrations with inventory and monitoring; upgrade cadence
Process design and change procedure	Internal change manager, security lead and implementation partner if engaged	One-time, with periodic revision	Number of change types, emergency paths and approval levels; alignment with the SSP
Change control board meeting time	Board members across IT, security and system owners	Recurring	Meeting frequency; change volume; number of attendees needed for quorum
Change record and approval upkeep	Administrators and engineers who create, link and close records	Recurring	Change volume; quality of templates; whether records are created before implementation
Security impact review inputs	Security staff reviewing each change before approval	Recurring	Number of significant changes; complexity of affected systems; depth of review required
Evidence collection and retention	Compliance lead and system administrators exporting logs, minutes and records	Recurring, often before assessments	Retention period set by the organization; number of systems in the assessment boundary
External readiness review	Independent consultant or reviewer, if you choose one	Usually one-time per readiness cycle	Scope size; number of change records sampled; whether the review is fixed-scope
Assessor sampling	Independent assessor or certification body, paid by the organization	Recurring per assessment cycle	Assessor sampling plan; quality and completeness of change records at assessment time

Open-source ticketing tools that can hold change records

GLPI is an open-source IT service management platform licensed under GPL-3.0-or-later. Its Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices. For CM.L2-3.4.3, the change object is the closest fit: each request can record what is proposed, who reviewed it, the decision and the work performed. Because the module is designed around ITIL, it tends to suit organizations that already run change processes in a formal way.

Change objects: Each change request can be logged as its own record, which gives assessors a discrete item to sample for tracking.
Planning and statistics: Plannings and statistics help a change control board show how many changes were raised, scheduled and closed over a review period.
Recurring work: Recurrent tickets can cover standing changes such as scheduled patch windows, so each cycle leaves its own record.
Kanban view: A board view helps show which changes are awaiting review, approved or in implementation at a given time.
License caveat: GPL-3.0-or-later obligations apply if you modify and distribute the software, so have legal counsel review your deployment model.

Confirm in your chosen version whether approval steps can be enforced as a required gate before implementation, whether approver identity and timestamps are retained, and whether the full change history can be exported in a format your assessor can read.

Where change management programs fail assessment and how to close the gap

Most failures under CM.L2-3.4.3 are not missing change boards. They are gaps in coverage, timing and linkage: changes that never reached the board, approvals that appear after the work was done, and records that do not connect to the SSP. Each card below names one gap and the fix that closes it.

Emergency changes with no record

Urgent fixes often go in through an on-call engineer's console and are documented later, if at all. An assessor testing the tracking objective will look for emergency changes in the same log as routine ones. Fix it with an expedited change path that still creates a ticket before or at the moment of implementation, with a named approver who reviews it within a set period afterwards. Check that the ticket count reconciles with the system change logs for the same window.

Vendor changes outside the board

Managed service providers, hosting partners and software vendors often change configurations, patch systems or update firmware without entering your change process. Those changes still affect the system boundary. Put every third-party change under contract terms that require a request record, or have the provider's change tickets flow into your system. Confirm which party is accountable for each change type in the SSP and in the agreement.

Approvals recorded after implementation

A ticket that shows an approval timestamp later than the implementation timestamp fails the approving objective, because the record shows the change was not approved before it happened. Assessors compare these times directly. Enforce a workflow where implementation tasks cannot start until the approval state is set, and review tickets for approval timestamps that trail work logs. Explain any exceptions in the emergency change record rather than editing the original entry.

Missing board minutes

Assessors may ask for agendas and minutes of change control oversight meetings and may interview board members. A board that meets but keeps no agenda, attendance or decisions gives the assessor nothing to test for reviewing and approving. Keep a short written record for each meeting that lists the changes reviewed, the decision on each, the attendees, and any rejected or deferred items. Store it with the change records so the two sets can be matched.

Change records not linked to the SSP

When a change alters a boundary, a component or a security setting, the system security plan should reflect it. Change tickets that stand alone make it hard to show that the SSP and the live system agree. Require each change record to reference the affected system components and any SSP sections it touches, and schedule SSP updates as a closing step. This also gives your security impact analysis under CM.L2-3.4.4 a traceable input.

Logs that cannot be matched to tickets

Tracking changes requires that the ticket and the actual system activity can be linked. A common gap is a change ticket that describes one action while the system log shows several, or configuration drift with no ticket at all. Pull configuration and administrative logs for a sample period and trace each event to a change record or an approved exception. Unmatched events are the first thing an assessor will sample.

What buyers and practitioners ask about CM.L2-3.4.3 change control

How much effort does CM.L2-3.4.3 change control take to set up?

The effort depends mostly on how many systems change, how many people touch them, and whether change records already exist in a ticketing system. Setup covers defining the change process, choosing a record system, configuring approval steps, and writing the change procedure into the System Security Plan. Sustained effort is the weekly work of logging, reviewing and approving changes, plus periodic reviews of the change log. No supplied source gives a duration or hours figure for this work, so ask any provider to estimate effort from a written list of systems, change volume and existing tooling. Ask for the estimate to separate one-time setup from recurring review work.

Can an in-house team implement change control without an outside partner?

Yes, an in-house team can implement CM.L2-3.4.3 without an outside partner, because the requirement is about the organization's own change process and its records. The organization owns the control and must be able to show tracked, reviewed, approved or disapproved, and logged changes. A partner can help by configuring the ticketing system, building evidence templates, and preparing the SSP narrative, but a partner does not issue assessment results. Independent assessors, including C3PAOs for Level 2 certification assessments, test the control. Teams new to change boards should confirm the expected evidence format with their assessor before building it.

How long does it take to get change control ready for an assessment?

No supplied source gives a readiness timeline for CM.L2-3.4.3, so confirm the duration with your provider and your assessor rather than relying on a general estimate. The timeline depends on whether a change board already operates, how much historical change evidence exists, and how many systems fall within the assessment boundary. Teams with an existing change process mainly need to align it with the four assessment objectives and retain records in final form. Teams starting from nothing need time to run the process long enough to produce a real record of changes before assessment.

What does the requirement ask my staff to do day to day?

Staff must submit changes into the process, have changes reviewed, and record each approval or rejection. Change board members must attend reviews, decide on requests, and be able to explain their decisions if an assessor interviews them. System administrators must document changes before implementation and attach the record to the change. The DoW CMMC FAQ (July 2026) advises documenting each change before it is implemented, so the process has to happen in that order. Staff training should cover the submission path, the approval roles, and what counts as a change worth logging.

Can CM.L2-3.4.3 go on a POA&M, and what are the score rules?

Yes, CM.L2-3.4.3 can go on a POA&M for Conditional Level 2 status, because it is a 1-point requirement not on the exclusion list in 32 CFR 170.21(a)(2)(iii). Under 32 CFR 170.24, the requirement is worth 1 point, and a Conditional Level 2 status requires a score of at least 88 of 110 (0.8). Closeout of POA&M items is due within 180 days. A POA&M is a temporary arrangement, so plan to close the item before the deadline and retain evidence of the completed change process. Confirm the current status of these rules against the eCFR text before relying on them in a contract.

How do the Phase II suspension and Rev. 2 enforcement affect my planning?

On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The Department also said it will enforce NIST SP 800-171 Rev. 2 in the interim, so CM.L2-3.4.3 should be planned against Rev. 2 and SP 800-171A. Because the eCFR still shows the original phase schedule and the DoW CIO page describes a paused implementation, confirm the current timing with the DoW CIO before setting internal deadlines.

Which change tracking tools can support the evidence for this requirement?

Open-source service management tools can hold change records, approvals and logs in one place. GLPI, licensed under GPL-3.0-or-later, has an Assistance module that lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings and statistics. Zammad, licensed under AGPL-3.0-only, is a web-based helpdesk that brings requests into one ticket system, which suits intake from email and other channels. Neither tool is a substitute for the process itself. Confirm that the change workflow, approval steps and audit history in the chosen tool meet your assessment objectives before adopting it.

How DeployOpen scopes and prepares change management evidence

DeployOpen prepares the change management process, tooling and records that a CM.L2-3.4.3 assessment will examine, inside your own infrastructure. The organization owns its change control board and decisions, and only an independent assessor issues the assessment result.

How we scope

Written scope names the systems, change types and teams that fall under change control for CM.L2-3.4.3.
We confirm which ticketing or change records already exist and where approval evidence currently lives.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure an open-source change workflow with request, review, approval or rejection, and closure states.
We set up logging so every change record keeps requester, approver, dates and implementation notes.
We link change records to SSP entries and baseline references so reviewers can trace each change to its system.

How we hand over

We deliver a change control procedure, role definitions and sample records that show each assessment objective.
We document how the change control board meets, how agendas and minutes are kept and where they are stored.
We walk your team through testing the workflow so your own staff can produce evidence after handover.

How we support

Ongoing support is available as a retainer for workflow upgrades, reporting changes and evidence reviews.
We can run periodic internal reviews of change records to find gaps before your assessor does.
Your organization decides whether to engage a C3PAO or other assessor independently of DeployOpen.