What CM-3 configuration change control requires and why assessors focus on it
When an assessor or a contract asks for CM-3, the question is whether the organization can show that changes to its system are controlled from request to record. CM-3 asks the organization to do six things: define which changes are under configuration control, review each proposed change with security and privacy impact analysis, approve or reject it, document that decision, implement only approved changes, and keep change records for a defined period. The organization must also monitor change activity and oversee the process through a defined change control body that meets and keeps minutes. In SP 800-53B Release 5.2.0, CM-3 is selected for the moderate and high baselines and is not part of the privacy baseline, so the requirement applies to the systems in those baselines rather than to privacy-only processing.
Assessors focus on CM-3 because the control is only as good as the match between paper and production. SP 800-53A Rev. 5 directs assessors to examine change control records, audit and review reports, and minutes from the change control body, and to interview the people who hold change control responsibilities. The gap they most often find is between the change ticket and what actually changed: a ticket approved for one firewall rule, a deployment that touched three, or an emergency change that was never written up. Before an assessment, a security lead should sample several recent changes from the production system's logs and trace each one back to an approved request, an impact analysis, and a recorded implementation.
Start with a decision on what counts as a controlled change, written down in the configuration management plan, since that definition drives everything else. Then confirm which records your change system keeps, how long they are retained under your own policy, and whether the change body's minutes show that security and privacy representatives took part in reviews. Open-source tools such as GLPI's Assistance module can hold change requests, and Wazuh's file integrity monitoring can flag edits to monitored files that were never ticketed. The organization still owns the process and the decisions, and an independent assessor is the only party that tests and reports on whether the control operates.
Which changes, systems and teams fall under CM-3 change control
CM-3 only works if the organization decides, in writing, what counts as a configuration-controlled change and who may make one. The cards below cover the scoping choices an assessor will test first, from the components in scope to the third parties that touch them. Each choice feeds the change records and approvals that CM-3 requires.
Configuration items in scope
Start by listing the system components and configuration items that CM-3 covers, including operating systems, network devices, databases, cloud control planes, container images and security tooling. Tie each item to the baseline configuration and the component inventory so an assessor can trace a change back to a recorded item. Check whether the list covers items that change outside the usual release path, such as firewall rules and identity provider policies.
Standard and significant change categories
Define which changes are pre-approved standard changes, such as routine patch installs from an approved catalog, and which are significant changes that need review and approval with security and privacy impact analysis. The boundary must be written down and applied consistently. Ask whether the category rules name the triggers, such as changes to authentication, encryption, logging or data flows, rather than leaving the call to individual engineers.
Emergency change handling
Emergency changes often bypass the normal board, so CM-3 expects a defined path for them. Document who can declare an emergency, what minimum record is created before or immediately after the change, and when the change must go back through full review. Assessors commonly sample emergency changes to see whether the post-implementation review happened and whether the decision was documented.
Third parties and managed service providers
Vendors, managed service providers and support engineers can make configuration changes without passing through the internal queue. Identify every third party with change rights, the systems they touch, and how their requests reach the change control body. Contracts and access agreements should require them to submit changes through the same records. Confirm this in your own environment, since remote support sessions are a frequent gap.
Baseline selection and enhancements
CM-3 is selected in the moderate and high SP 800-53B baselines but not in the privacy baseline. In the high baseline, CM-3(1) covers automated documentation, notification and prohibition of changes, and CM-3(6) covers cryptography management. CM-3(2) (testing, validation and documentation of changes) and CM-3(4) (security and privacy representatives) apply in both moderate and high. Confirm which baseline your system is categorized under before deciding which enhancements to implement.
Change scope and tooling sources
Decide which sources generate change records: ticketing systems, configuration tooling, and file integrity monitoring. Open-source options include GLPI's Assistance module for change tickets and Wazuh file integrity monitoring for detecting changes to monitored files. Map each source to the configuration items it covers so unrecorded changes can be found by comparison.
How an assessor tests CM-3 under SP 800-53A
This table maps the SP 800-53A examine, interview and test methods for CM-3 to what the assessor does, the evidence requested and the findings that most often appear. Read it as a checklist of what to have ready before an assessment starts, since the assessor will work through each object in turn.
| Assessment element | What the assessor does | Evidence the assessor expects | Common finding |
|---|---|---|---|
| Determination statements (10) | Checks each of the 10 CM-3 determination statements, covering the defined change scope, review and approval, impact analysis, documented decisions, implementation, retention, monitoring and oversight | A mapping from each determination statement to the procedure, record or owner that satisfies it | Statements answered with policy text only, with no operating record behind them |
| Examine: configuration management plan and architecture documentation | Reads the plan and the system architecture and configuration documents to confirm which items fall under change control | Approved plan, defined configuration-controlled items, current architecture diagrams | Plan describes change control in general terms but does not name the systems or items it covers |
| Examine: change control records | Samples change requests and compares each one to what is recorded as deployed | Tickets with request, impact analysis, approver, implementation date and closure, plus retained records for the defined period | Records that do not match deployed changes, or changes with no approval record |
| Examine: change control audit and review reports | Reviews reports showing how change activity is monitored and whether unauthorized changes were caught | Periodic reports of change activity, reconciliation results and follow-up on exceptions | Reports produced but no evidence that exceptions were investigated or closed |
| Examine: oversight meeting agenda, minutes and documentation | Checks that the defined change control body met as stated and reviewed proposed changes | Agendas, minutes, decisions and membership showing security and privacy representation | Body defined on paper, with minutes missing or showing no decisions on security impact |
| Examine: privacy impact assessments | Confirms that changes affecting personally identifiable information were reviewed for privacy impact | Privacy review entries linked to change requests that touch personal data | No privacy review recorded for changes that process personal data |
| Interview: personnel with change control responsibilities | Asks change approvers, implementers and the body chair how a change moves from request to closure and who can stop it | Consistent answers that match the written process and the records sampled | Interviewees describe an informal process that the documented procedure does not reflect |
| Test: change control processes | Walks a sample change through the process from request to implementation, or observes a live change | Evidence that the process runs as written, including approval before implementation and records created at each step | Emergency changes bypass approval and are not recorded afterward |
How to implement CM-3 change control step by step
This sequence turns CM-3 from a policy statement into a working change control process, with each step producing a record an assessor can examine: a defined scope, a chartered body, documented decisions, and a tested workflow that runs under periodic oversight.
Define the controlled configuration items and change classes
Start by listing which system components, baselines and configuration items fall under configuration control, using the baseline configuration and component inventory as the reference. Then define change classes, such as standard, normal and emergency changes, and state which classes need board review and which can be pre-approved. The output is a scoped register of configuration items and a written change classification that the control body and engineering teams both sign off. Confirm the scope with the assessor's expectations before you build workflows around it.
Charter the change control body with security and privacy representation
Create the defined body that oversees change control, with a written charter covering membership, quorum, decision authority, meeting cadence and escalation paths. Include security and privacy representatives as named members, since CM-3(4) expects them in the moderate and high baselines. The output is an approved charter, a membership roster with alternates, and a record of the first meeting. Confirm the charter with the system owner and whoever is accountable for privacy decisions.
Set review and approval criteria with impact analysis
Write the criteria the body applies to each proposed change, including required security and privacy impact analysis, testing evidence, rollback planning and the conditions for approval, rejection or deferral. Link the criteria to the impact analysis procedure so that every request states its expected effects before review. The output is an approved criteria checklist and a request template that cannot be submitted incomplete. Confirm that privacy impact assessment triggers are explicit, since the privacy impact questions belong in this review.
Configure the change workflow and record retention
Set up the ticketing or change system so each request moves through submission, impact analysis, decision, implementation, verification and closure, with timestamps and named approvers. Define the record retention period in the configuration management plan and apply it to the change system. Self-hosted options such as GLPI's Assistance module can support ITIL-style change records, and Zammad can route requests, but confirm each tool's approval and audit capabilities against your criteria. The output is a configured workflow with a sample record that shows every required field.
Run a pilot change cycle
Select a small set of low-risk, representative changes and run them through the full workflow, including review, approval, implementation and closure. Test the escalation path with at least one rejected or deferred change and one emergency change. Record what slowed the cycle or left gaps in the evidence. The output is a pilot report listing each change, the decision, the implementation evidence and the corrections made to the charter, criteria or workflow before go-live. Ask the assessor or an internal reviewer to examine the pilot records.
Implement approved changes and verify them
Require that implementation starts only from an approved record and that the implemented change matches what was approved. Use change identifiers in deployment and configuration tooling, and compare the post-change state with the approved design. Tools such as Wazuh file integrity monitoring can alert when monitored files change, and Bareos verify jobs can compare files against cataloged attributes, which helps detect changes made outside the process. The output is a closed change record with verification evidence and, where an unapproved change is found, a documented investigation.
Monitor change activity and oversee the process periodically
Review change activity on a defined schedule, comparing monitoring alerts and deployment logs against approved changes to find unrecorded or mismatched changes. The change control body reviews metrics, exceptions, emergency changes and open items at its regular meeting, and minutes record its decisions and actions. The output is a periodic oversight report, the minutes and agenda of each body meeting, and a documented follow-up for every exception. Confirm the review frequency with your governance owners and record it in the plan, since the body's oversight is a core expectation of the control.
How the change record, impact analysis and decision log connect
An assessor testing CM-3 wants to pick one change and follow it from request to closure without relying on memory or email threads. The point of the section is that every change gets one change record that carries a unique identifier, and every other artifact points back to that identifier: the security and privacy impact analysis, the approval or rejection decision, the implementation record, the test results and the closure entry. If the impact analysis lives in a document that the ticket does not reference, the assessor cannot prove that the analysis was considered before approval. Decide the identifier scheme and the mandatory fields before the first change is raised, not after the first audit request.
In practice the flow runs in a fixed order. A request is logged with the affected configuration items, then the impact analysis is attached and dated before the change control body meets. The body's decision (approve, reject or defer, with conditions) is recorded against the same identifier, with the names of the members present and any dissent. Implementation then references the approved version of the change, not a later edited one. Closure confirms what was actually deployed and whether the post-change state matches the baseline. Ticketing tools such as GLPI's Assistance module, which supports change records and planning under ITIL practices, can hold these links, but you must confirm that the fields you need are mandatory and that approval timestamps cannot be overwritten. Wazuh file integrity monitoring or Bareos verify jobs can then show whether files changed outside an approved record, which gives the assessor an independent check.
Keep two further records separate from the decision log, because they answer different questions. Test and validation evidence for CM-3(2) should show what was tested, in which environment, against which version, and the result, and it belongs in its own artifact linked to the change identifier. Privacy representative involvement for CM-3(4) should show that a privacy representative was part of the review where the change affects personally identifiable information, with their input recorded even when they raised no concern. Confirm with your privacy office which change types route to them, since the SP 800-53B baselines select CM-3(4) for moderate and high systems and the privacy-specific trigger is an organizational decision you must document.
Evidence that passes a CM-3 assessment
An assessor testing CM-3 looks for a complete chain of records, from the plan that defines controlled changes through each request, decision, implementation and oversight meeting. The cards below cover the artifacts SP 800-53A names for examination and the habits that keep them current between assessments.
Configuration management plan
The plan defines which changes are configuration-controlled, who sits on the change control body, and how requests move from submission to closure. Assessors check that the plan matches what people actually do. Confirm that its change categories, approval roles and retention period are the same ones your ticketing records follow, and that the plan has an owner and a review date.
Change requests with impact analysis
Each change request should record the proposed change, the systems affected and a security and privacy impact analysis completed before the decision. A request that reads only "apply patch" without an analysis is a gap an assessor will find. Check that every closed request contains the analysis, the analyst's name and the date it was done.
Approval and rejection decisions
Records of who approved or rejected each change, and why, show that the change control body actually reviewed proposals. Rejections matter as much as approvals, because they show the body can say no. Confirm that approvers are the roles named in the plan and that conditions attached to an approval are written down and tracked to completion.
Implementation and change records
Implementation records tie an approved request to the change that was made, with timestamps, the executing person or automated job, and the configuration before and after. Assessors use them to test whether unapproved changes reached production. Compare the change log from your configuration management or monitoring tools against the approved requests and investigate every mismatch.
Change control audit and review reports
Periodic reviews of change activity, including reports of changes made outside the process, show that the organization monitors change behavior rather than only documenting it. Wazuh file integrity monitoring or a similar tool can supply the raw alerts for these reviews. Confirm that each review has a reviewer, a date, findings and a record of how each finding was resolved.
Oversight meeting minutes and privacy impact assessments
Agendas and minutes from change control body meetings prove oversight is happening on a schedule. Where a change touches personal information, the privacy impact assessment should be attached to the request and referenced in the minutes. Keep these documents together so an assessor can follow one change from proposal through oversight without searching several systems.
Who owns CM-3 and what an implementation partner can take on
Your organization owns CM-3 in full. The control asks for a defined set of configuration-controlled changes, a review and approval decision for each proposed change that considers security and privacy impact, documented decisions, and oversight by a body you name. No outside party can make those decisions for you, and an assessor will look for named people and minutes that show the body meets and acts.
- Defining the scope: Decide which change classes are configuration-controlled, such as production settings, network rules, images and access changes, and write that scope into your configuration management plan.
- Chartering the change control body: Name the members, including security and privacy representatives, set a meeting cadence and define quorum and escalation rules.
- Making the decisions: Approve, reject or defer each proposed change with the security and privacy impact analysis attached, and record the rationale.
- Setting retention: Decide how long change records are kept, because CM-3 asks for a defined period and the assessor will test against your own number.
- Monitoring and oversight: Review change activity and unplanned changes on a schedule and report results to the body.
Before engaging any partner, confirm that your change policy names an accountable owner and that your own staff can explain a recent approved change from start to finish.
An implementation partner prepares the systems and evidence that your change control body relies on. The partner does not approve changes, sit on the body as a decision maker, or write the risk acceptance. Its work is configuring the tools that carry the process and making sure the records they produce are complete, consistent and retrievable.
- Ticketing configuration: Set up change request workflows, approval states, required fields for impact analysis and links to affected configuration items in a self-hosted service management tool.
- Change record design: Define the record template so each change captures the request, the impact analysis, the decision, the implementer, the test result and the closure.
- Evidence collection: Export change logs, approval history and monitoring reports into a repository your auditor can sample from.
- Change monitoring: Deploy file integrity monitoring or backup verification to detect changes that bypassed the ticket, and route those alerts to your team.
- Documentation handover: Write the operating procedures your staff will follow once the engagement ends.
Confirm in the written scope which of these items are delivered, who maintains the workflows afterward, and how records are retained in your environment.
The independent auditor or assessor tests whether CM-3 operates and reports the result. The assessor is independent of both your organization and any partner that prepared the controls. That separation is why an assessor cannot design the change process it later tests, and why a partner's dashboard is never itself an audit finding.
- Examination: The assessor reviews the configuration management plan, change control records, audit reports and minutes from the change control body.
- Interviews: The assessor speaks with the people who hold change control responsibilities to confirm they understand and follow the process.
- Testing: The assessor samples real changes and traces each one back to a request, an approval and a closure.
- Reporting: Findings and conclusions come from the assessor alone. DeployOpen prepares systems and evidence and does not issue audit reports or certifications.
- Independence checks: Ask the assessor how it handles any prior work by the implementation partner before the scope is agreed.
Before the assessment, agree in writing with the assessor which evidence samples it will request and the period they cover.
What meeting CM-3 costs in money and effort
This table lists the cost components of running CM-3 change control, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no price is published here and most costs depend on how many changes the organization handles and how its change board works. The main takeaway is that open-source tooling removes license spend but not hosting, configuration or review time.
| Cost component | One-time or recurring | Who is paid or who bears it | What drives it up or down |
|---|---|---|---|
| Tooling and hosting | One-time setup, then recurring | Organization or cloud provider for infrastructure; implementation partner for installation | Hosting size, high availability, backup and retention of change records; open-source licenses are typically free but hosting is not |
| Workflow configuration | One-time, with later changes | Implementation partner or internal platform engineers | Number of change types, approval routing, integration with ticketing and CI/CD pipelines; fewer custom states keep it lower |
| Change board time | Recurring | Internal staff from security, privacy, operations and system owners | Change volume, meeting frequency, whether standard changes are pre-approved; clear criteria for routine changes reduce review load |
| Security and privacy impact analysis | Recurring, per change | Internal security and privacy representatives, sometimes supported by external testers | Complexity of the system, number of interfaces, and whether impact checklists are standardized |
| Evidence upkeep | Recurring | Internal compliance or operations staff | Tickets with complete approval, test and rollback records reduce rework; gaps in records create follow-up work at audit time |
| Verification and monitoring | Recurring | Internal security operations, or a managed service provider if one is used | Scope of file integrity monitoring and verification jobs, alert tuning, and how often reviewers check unauthorized changes |
| External review or testing | Periodic, when scheduled | Independent testers or assessors, paid under a separate agreement | Scope of testing, whether change-related testing is included, and how many systems are in the assessment boundary |
| Assessor sampling | Periodic, per assessment | Independent assessor or auditor, paid by the organization | Number of changes sampled, quality of change records, and whether the organization can produce them quickly |
Where CM-3 programs usually fall short
Most CM-3 failures are not missing policies. They are gaps where a change slips around the process, the record is incomplete, or nobody notices. Each card below names one gap an assessor is likely to probe, with the action that closes it before the assessment begins.
Untracked emergency changes
Emergency fixes often go straight to production with a promise to document them later, and the later record never gets written. CM-3 expects proposed changes to be reviewed and decided, so an emergency path still needs a defined route to approval, even if it is retrospective. Check whether the change ticketing tool accepts an emergency class, whether it forces a named approver within a set window, and whether a sample of recent production fixes can be traced to a record.
Impact analysis missing from records
A change ticket that says only what changed and who approved it does not show that security and privacy impacts were considered. Assessors look for the analysis itself, attached to the decision, for the changes in scope. Action: make a completed security and privacy impact field a required step before the approval status can move forward, and sample closed changes to confirm each one carries it.
No privacy representative on the body
The CM-3 oversight body is expected to include the right people for the decisions it takes. Where privacy is in scope, a body made only of operations and security staff tends to approve changes that touch personal data without a privacy view. Action: record the membership of the change control body, confirm a privacy representative is named, and keep minutes showing that privacy-relevant changes were reviewed with that person present.
Records not kept for the defined period
Organizations often define a retention period in the policy but let the change system purge closed tickets or let backups roll off sooner. When the record is gone, the organization cannot show how a past change was decided. Action: compare the retention period written in the configuration management documentation with the actual purge settings in the ticketing system and backup jobs, and test by restoring an old change record.
Changes made outside the process
Direct edits on servers, console changes and scripts run by administrators can alter a system without any ticket. Process alone will not reveal these, so the gap stays hidden until an assessor compares the system against the approved record. Action: run file integrity monitoring against defined configuration paths, alert on modifications, and reconcile each alert against an approved change. Confirm that the tool can alert in real time or on schedule and that alerts reach a person who reviews them.
CM-3 questions buyers ask before hiring help
How much effort does CM-3 configuration change control take to set up?
Effort depends mostly on how many systems fall under change control, how many change types exist, and how many approval steps already run through a ticketing or change process. CM-3 is selected in the moderate and high baselines of SP 800-53B Release 5.2.0, and it has eight enhancements, of which CM-3(1) and CM-3(6) apply only in the high baseline. Expect the largest share of work in defining what counts as a controlled change, setting up the change control body, and building records that show each decision. Ask any provider to split its quote into design, configuration of tooling, and evidence collection, so you can see what is one-time and what recurs.
How long does a first CM-3 implementation usually take?
No duration for CM-3 is set by NIST, and NIST does not set federal implementation timelines. The time it takes depends on how mature your current change process is, whether tickets and approvals already exist, and how many environments are in scope. Organizations with a working change board and tracked tickets usually need less time to show evidence than those working from email approvals. Ask for a timeline tied to named deliverables and a written scope, and confirm with your assessor which evidence period they expect before they test the control.
What does our internal team need to provide for CM-3?
Your team owns the control. CM-3 requires you to define which changes are controlled, decide who reviews and approves them, and oversee the process through a defined change control body. That body should include security and privacy representatives, which CM-3(4) addresses in the moderate and high baselines. Your team also needs to name the people who will be interviewed during assessment, supply the configuration management plan and system documentation, and make sure change records are kept for the period you define. An implementation partner can prepare systems and evidence, but cannot make these decisions for you.
Can we run CM-3 in-house with open-source tools?
Often yes, provided your team can operate the tools and keep records consistent. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view, which can hold change requests and approvals. Wazuh file integrity monitoring can record a baseline of checksums and attributes and alert when a monitored file changes, with details on who changed it. Bareos Verify jobs compare files against cataloged attributes, which can support detection of unexpected changes. Confirm each tool's fit for your environment and integration needs before relying on it, because a tool produces evidence but does not define your approval policy.
Which tools produce the strongest evidence for CM-3?
Assessors look for change control records, review and approval records, and evidence that approved changes were implemented as approved. A change ticket with a documented security and privacy impact analysis, an approval entry, and a link to the monitored system change is stronger than a summary report. File integrity alerts from Wazuh can show that a change occurred and who made it, which helps test whether unapproved changes are detected. Keep the change control audit and review reports and oversight meeting minutes as well. Ask your assessor which artifacts they expect to examine before you configure the tools.
What should we ask for in a fixed-scope quote for CM-3?
Ask for a written scope that names the systems in scope, the baseline you are targeting, and the CM-3 enhancements included, because CM-3(1) and CM-3(6) apply only in the high baseline. The quote should list deliverables such as the change control procedure, ticket workflow configuration, integrity monitoring setup, and evidence packages, along with what the partner will not do. Ask who performs the impact analysis, who signs off on acceptance, and what happens if your assessor requests additional evidence. Clarify that DeployOpen prepares systems and evidence but does not issue assessment reports or certifications, which only an independent assessor or certification body can do. Pricing follows from the written scope, so ask for it in writing before work starts.
Who is responsible if an unapproved change reaches production?
The organization remains responsible for its controls, including the consequences of an unapproved change. CM-3 expects you to monitor change activity and respond when changes occur outside the defined process, so detection and response should be part of your design. A partner can help configure detection, such as file integrity monitoring and change records, but the decision to investigate, roll back, or report belongs to your change control body and incident process. Confirm with your partner how alerts are routed, who receives them, and how exceptions are documented, and review those responsibilities in the statement of work.
How DeployOpen prepares CM-3 change control evidence
DeployOpen starts with a written scope that names the controlled items: the platform components under configuration control, the environments where changes are made, and the change types that go through the change control body. Those boundaries are the first thing an assessor will test against CM-3, so they should be agreed before any tooling is configured. The organization decides which changes are controlled, who sits on the change control body and what counts as a security or privacy relevant change. DeployOpen then maps that decision into the self-hosted workflow, so the rules the organization wrote are the rules the system enforces.
For the workflow itself, DeployOpen can configure a self-hosted service desk, such as GLPI with its Assistance module, to carry change requests from submission through review, approval, implementation and closure. The request form can capture the security and privacy impact analysis fields the organization requires, and the approval step can record who decided and when. Monitoring is the second half of the evidence. Wazuh file integrity monitoring can record a baseline of checksums and attributes for monitored files and directories and alert when a change occurs, and Bareos Verify jobs can compare files against cataloged attributes. Confirm with your own environment which paths, retention periods and alert routes you need, because those settings are yours to set.
DeployOpen then prepares the records an assessor will sample: the change requests, approval and rejection decisions, implementation evidence, monitoring alerts matched to approved changes, and minutes or agendas from change control body meetings. Unmatched alerts, meaning changes with no approved request, are the findings most worth resolving before fieldwork. DeployOpen does not issue audit reports or certifications. Independent assessors do that work, and the organization owns every control decision, including which changes to approve. Ask any implementation partner for the written scope, the deliverables and the evidence list before work starts.
