CM-3(3): Automated Change Implementation

CM-3(3): Automated Change Implementation requires you to implement approved changes into the system baseline and deploy that updated baseline across your installed base using automation you define (for example, CI/CD, configuration management, imaging, or orchestration). To operationalize it, standardize “baseline as code,” enforce automated rollout gates, and retain machine-verifiable evidence of what changed, who approved it, and where it was deployed. ¹

Key takeaways:

• Treat the baseline as a deployable artifact (image, config bundle, IaC module, golden AMI/container base) and update it through an automated pipeline.
• Prove deployment coverage across the installed base with authoritative inventory and automated rollout logs.
• Keep end-to-end traceability: change request → approval → code/config diff → build/release → deployment → post-deploy validation. ²

For most audit teams, “automated change implementation” is a short phrase that hides a lot of operational detail. CM-3(3) is narrow but demanding: it expects changes to be integrated into the current baseline and then deployed across all applicable systems through an automated mechanism you define and control. That means your organization needs two things that often drift apart in practice: a governed baseline (what “approved configuration” means right now) and a repeatable, tool-driven way to push that baseline everywhere it belongs.

This requirement shows up in federal systems and contractor environments handling federal data because assessors want to reduce configuration drift, reduce manual errors during releases, and tighten traceability. You do not satisfy CM-3(3) with a change policy alone. You satisfy it with evidence that your automation is actually doing the work: baseline updates are generated from approved changes, and the updated baseline is deployed consistently across the installed base. ²

If you need to move quickly, focus on three operator outcomes: (1) define what your baseline artifact is for each platform, (2) make the baseline update path automated and gated, and (3) make rollout measurable using inventory plus deployment telemetry.

What CM-3(3) requires (plain English)

CM-3(3): automated change implementation requirement expects you to:

1. implement changes into the current system baseline, and
2. deploy the updated baseline across the installed base,
3. using an automated mechanism you specify. ¹

In operator terms:

• A change is not “done” when it’s approved. It’s done when it is incorporated into the baseline artifact and rolled out broadly through controlled automation.
• “Installed base” means the population that should receive the baseline (servers, endpoints, containers, network devices, cloud resources, managed SaaS tenant settings where feasible). Your scope must match your system boundary and inventory.
• The control allows flexibility: you define the automation (the “organization-defined parameter”), but you must be consistent and able to produce evidence of repeatable deployment. ¹

Regulatory text

“Implement changes to the current system baseline and deploy the updated baseline across the installed base using {{ insert: param, cm-03.03_odp }}.” ¹

What the operator must do with this text

• Pick and document your automation mechanism (the parameter). Examples: CI/CD pipeline for application and infrastructure; configuration management for OS baseline; MDM for endpoints; network automation for device configs.
• Operationalize baseline updates as part of the same automated path as deployment. If engineers can deploy without updating the baseline artifact, you will fail the intent.
• Demonstrate rollout across the installed base through inventory alignment (what should get the baseline) plus deployment telemetry (what did get it). ²

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is a contractual or program requirement. ²

Operational context (where CM-3(3) “bites”)

• Teams with multiple environments (dev/test/prod) where manual promotion creates drift.
• Organizations with mixed fleets (cloud + on-prem, endpoints + servers, multiple business units).
• Environments with frequent patching or hardening requirements where “baseline” must evolve without breaking coverage.

What you actually need to do (step-by-step)

Use this as a build sheet a CCO/GRC lead can hand to IT, DevOps, and Security Engineering.

1) Define the baseline artifacts (by platform)

Create a simple register that answers: “What is the baseline, as a thing we can deploy?”

• Server OS: CIS-aligned configuration profile, GPO, Ansible role, or baseline image.
• Cloud infrastructure: IaC modules (Terraform/CloudFormation) + policy-as-code.
• Containers: approved base images + Dockerfiles + admission policies.
• Endpoints: MDM configuration profiles + standard software set.
• Network: standard configuration templates + automated push tooling.

Artifact rule: the baseline must be versioned and diffable (Git or equivalent), even if the final deployment is through another tool. This is how you prove what changed. ²

2) Map the automated mechanism (the parameter) to each baseline

Document, per baseline artifact:

• Tooling: CI/CD, config management, orchestration, MDM, network automation.
• Trigger: merge to main, approved change ticket, signed release, scheduled patch window.
• Gates: required approvals, automated tests, security scans, peer review.
• Rollback: prior baseline version and restore method.
• Coverage: which asset classes receive it (tied to inventory).

Keep this mapping short but explicit; auditors look for clear ownership and repeatability.

3) Enforce change-to-baseline traceability

Build a single chain of evidence:

• Change request (ticket) references the baseline repo change (PR/MR ID).
• PR includes the rationale and scope (which systems/controls are impacted).
• Approval is recorded in the system of record (ITSM and/or code review approvals).
• The pipeline run is linked back to the approved change.

If your teams release from a branch without an approved change record, close that gap with policy plus technical guardrails (for example, require a change ID in commit/PR templates and block merges without it).

4) Automate the baseline update and build

The baseline should be produced the same way every time:

• Build pipeline compiles the baseline artifact (image build, config bundle, signed release).
• Baseline version is stamped (tag/release ID).
• Outputs are stored in an artifact repository (image registry, package repo, config store).

This is the “implement changes to the current system baseline” portion, made concrete. ¹

5) Automate deployment across the installed base

You need two capabilities:

• Authoritative inventory of in-scope assets (the installed base).
• Deployment telemetry showing which baseline version is installed where.

Common patterns:

• Progressive rollout (rings/waves) controlled by automation.
• Auto-remediation for drift (configuration management enforcing desired state).
• For immutable infrastructure, replace instances with the new baseline image.

6) Validate and record post-deploy state

Build automated checks that confirm the baseline is active:

• Endpoint compliance state from MDM.
• Configuration management “converged” status.
• Runtime policy checks (for example, admission controller enforcing approved images).
• Spot checks for critical settings tied to the baseline.

Store results centrally and make them reportable by baseline version and asset group.

7) Assign ownership and recurring evidence collection

CM-3(3) fails most often due to “we do it, but can’t prove it.” Set named owners for:

• Baseline artifact owners (platform owners).
• Pipeline owners (DevOps/SRE).
• Inventory owner (ITAM/Cloud ops).
• Control owner (GRC) who runs evidence collection.

Daydream fits cleanly here as the control owner workspace: map CM-3(3) to an accountable owner, define the implementation procedure, and schedule recurring evidence pulls (pipeline runs, deployment reports, inventory snapshots) so you are assessment-ready without a scramble.

Required evidence and artifacts to retain

Keep evidence that an assessor can replay mentally from approval to deployment.

Baseline definition

• Baseline register (by platform) with owners and deployment mechanism.
• Baseline repository links and versioning approach.
• Baseline version history and diffs (PRs/commits).

Change control and approvals

• Change tickets tied to baseline updates.
• Approval records (CAB approvals where used; code review approvals).
• Exception records for emergency changes (with post-implementation review).

Automation and deployment

• CI/CD pipeline definitions (as code) and run logs.
• Artifact repository records (build outputs, image digests, package versions).
• Deployment logs (orchestrator history, config management reports, MDM compliance exports).
• Inventory snapshot showing the installed base in scope and rollout coverage.

Validation

• Automated test results (smoke tests, config compliance checks).
• Post-deploy verification reports and rollback records when applicable.

Common exam/audit questions and hangups

Auditors and assessors tend to fixate on these points:

1. “What is your baseline?” If you answer with a PDF, expect follow-ups about how it becomes deployable.
2. “Show me that the baseline was updated for this change.” They will pick a recent change and ask for end-to-end traceability.
3. “How do you know everything got the updated baseline?” Inventory and rollout evidence must reconcile.
4. “What is the automation mechanism you use?” Your defined parameter must match reality and be consistently used. ¹
5. “How do you prevent manual, out-of-band changes?” Expect scrutiny of break-glass access and drift controls.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails CM-3(3)	Fix
Baseline exists only as documentation	No deployable artifact; no measurable rollout	Convert baseline to versioned config/image/IaC artifacts
Automation exists, but it bypasses approvals	Change implementation is not governed	Add merge gates, ticket linkage, approval checks
“Installed base” is vague	You can’t prove coverage	Define installed base via inventory and scope tags
Manual hotfixes in production become normal	Baseline and deployed state diverge	Require post-facto baseline update and documented exception handling
Evidence is scattered across tools	Assessment becomes a scavenger hunt	Centralize evidence collection (Daydream or equivalent GRC evidence workflows)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific enhancement, so treat the risk as assessment and mission risk rather than case-law-driven. Practically, weak automated change implementation increases:

• Configuration drift and inconsistent hardening.
• Untracked changes that complicate incident response.
• Higher likelihood of outages during releases due to inconsistent deployment steps.

For federal and federal-adjacent programs, the most immediate consequence is usually control assessment findings, delayed ATO, or contractual noncompliance tied to security requirements. ²

Practical 30/60/90-day execution plan

Use this to drive execution without inventing program timelines. Adjust pace to your release cadence and fleet size.

First 30 days (establish the minimum viable control)

• Name the control owner and platform owners; document RACI.
• Define “baseline artifacts” for each major platform and where they live (repos/registries).
• Choose and document the automation mechanism for each baseline (the CM-3(3) parameter). ¹
• Start evidence capture for one high-value slice (for example, server OS baseline or a key application’s CI/CD path).

Next 60 days (make it real across the installed base)

• Tie change tickets to baseline PRs and pipeline runs (traceability).
• Implement automated rollout reporting: baseline version by asset group, derived from inventory + deployment telemetry.
• Add guardrails to reduce out-of-band changes (restricted admin access, drift detection, required post-change baseline updates).

By 90 days (assessment-ready and repeatable)

• Expand from one slice to all in-scope platforms defined in your system boundary.
• Standardize evidence packaging: a monthly export pack with change samples, pipeline logs, deployment coverage, and validation results.
• Run a tabletop assessment: pick recent changes and prove the chain end-to-end without engineering heroics.

Frequently Asked Questions

What counts as “automation” for CM-3(3)?

Automation means a tool-driven, repeatable process that updates the baseline and deploys it broadly (for example, CI/CD, configuration management, imaging, orchestration, MDM). You define the mechanism, but you must show it is consistently used and produces logs. ¹

Do we need to deploy the updated baseline to every system immediately?

CM-3(3) requires deployment across the installed base, but it does not prescribe a rollout pattern. Phased rollouts are fine if your evidence shows complete coverage over your defined rollout process and exceptions are documented.

How do we define “installed base” in a hybrid environment?

Define installed base from an authoritative inventory source and scope tags that match your system boundary. Then report deployment status by that same inventory population so auditors can reconcile “should have” versus “does have.”

We allow emergency changes. Does that break CM-3(3)?

Emergency changes are workable if you still (1) record approval under an emergency process, (2) update the baseline artifact after the fact, and (3) deploy the updated baseline through the standard automated mechanism with evidence.

Is “baseline as code” mandatory?

NIST does not mandate a specific implementation pattern, but versioned, diffable baseline artifacts make CM-3(3) provable. If your baseline lives in tooling that is not code-native (like MDM), exportable configuration versions and deployment logs become your proof set. ²

What evidence should we hand an assessor for a sample change?

Provide the change record, the baseline PR/commit diff, approval evidence, the pipeline/build record producing a versioned baseline, deployment logs showing where it was rolled out, and post-deploy validation/compliance results tied to that baseline version. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5