This post explains how to implement an audit-ready change management process to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.3 within your Compliance Framework — covering workflow design, tooling, evidence collection, small-business scenarios, technical controls, and practical tips to ensure every change is tracked, reviewed, approved or disapproved, and logged for auditors.
What CM.L2-3.4.3 requires (high level)
CM.L2-3.4.3 expects organizations to control changes to systems and software by tracking requests, conducting reviews, recording approvals or disapprovals, and maintaining persistent logs of the entire lifecycle of the change. For a Compliance Framework focused on protecting Controlled Unclassified Information (CUI), this means formalized change requests, an approval workflow with separation of duties, and tamper-evident evidence so an auditor can reconstruct what changed, who approved it, and why.
Implementation steps — practical and actionable
Define policy, roles, and workflows
Start with a written Change Management Policy that maps to CM.L2-3.4.3: define change types (standard, normal, emergency), required ticket fields (change ID, owner, scope, impacted CUI systems, backout/rollback plan, test plan, start/end window), approval roles (approver, CAB member, security reviewer), and SLAs for review/approval. Require at least one security reviewer for changes touching CUI. Create a standard "disapprove" flow documenting reason and actions required before resubmission. For small teams, assign role-based approvals rather than relying on specific individuals.
Implement an auditable workflow in tooling
Use a ticket/ITSM system (Jira, ServiceNow, Freshservice) or a lightweight tracking sheet coupled with git-based controls for code/config. Configure required fields and enforce transitions (e.g., "Proposed" → "Approved" → "Scheduled" → "Executed" → "Closed"). Integrate PR-based approvals for infrastructure-as-code: require pull requests, at least one reviewer, and signed commits. For cloud deployments, gate "apply" operations behind an approved ticket — for example, Terraform remote state + a pull-request approval step or a CI job that only runs when the ticket ID is present in the merge message. Make approval records immutable (audit log) and timestamped.
Technical controls and evidence collection for auditors
Capture and retain the following evidence items for each change: the change ticket with metadata, approval records with user identities and timestamps, code commit hashes and PR IDs, deployment run IDs (CI/CD job IDs), server/config diffs before/after, and logs showing change execution (CloudTrail, auditd, Windows Event, etc.). Centralize logs into a SIEM or secure log store (S3 with versioning and encryption, Elasticsearch with WORM retention) and enable cryptographic integrity checks where practical (signed commits, hash of config artifact stored with ticket). Maintain system clocks via NTP and ensure log timestamps are synchronized for coherent timelines.
Real-world small business scenarios
Scenario A — 12-person company with mixed on-prem/cloud: Use Jira for change tickets, GitHub for application code, and AWS for infrastructure. Policy requires a Jira ticket for every deployment; the CI pipeline requires the ticket ID in commit messages and blocks deploys if the ticket is not in "Approved" state. CloudTrail and AWS Config provide deployment and configuration logs; automation exports relevant CloudTrail events and the CI job log to the Jira ticket as attachments. The CAB is a monthly lightweight meeting for normal changes; emergency changes use a documented emergency approval tag and are reviewed retroactively.
Scenario B — 3-person startup with outsourced managed services: Use a simple change request template in Google Docs or a managed-service portal; require the MSP to attach change artifacts (commit hashes, deployment timestamps) and to store logs in a customer-accessible S3 bucket with restricted access. If using SaaS (e.g., Office365), rely on vendor audit logs and require vendor-signed change attestations. For ultra-small teams, implement "two-eyes" where two distinct identities (employee + MSP engineer) must sign off on changes affecting CUI systems.
Risks and consequences of not implementing CM.L2-3.4.3
Failing to have an auditable change management process increases risk of unauthorized or incorrect changes leading to data exposure, system outages, and loss of CUI integrity. Audit gaps can trigger failed assessments, contractual penalties, and loss of DoD or government business. Operationally, lack of rollback plans and documented approvals increases mean time to recovery (MTTR) after change-induced incidents. From a compliance perspective, missing records or tamperable logs are common findings in NIST/CMMC assessments and are difficult and costly to remediate retroactively.
Compliance tips and best practices
Enforce least privilege on the change management system and the CI/CD pipeline. Automate evidence collection: scripts to export ticket metadata, attach commit hashes and deployment logs, and store an immutable export (PDF/JSON) in a secure evidence repository. Maintain retention consistent with contract and regulatory needs (commonly 1–3 years for many contracts) and document retention policy. Handle emergency changes with a defined expedited approval and mandatory post-facto review that is recorded. Use metrics (change success rate, percent of changes with adequate test/backout plans) and sample them during internal audits to build confidence before an external assessment.
Conclusion
To meet CM.L2-3.4.3 under your Compliance Framework, implement a documented change policy, role-based approval workflows, tool-enforced gates (ITSM + git/CI/CD), and tamper-resistant logging with automated evidence collection. Small businesses can implement lightweight but robust controls—ticket + PR + CI guardrails + cloud audit logs—to create an audit-ready package that shows every change was proposed, reviewed, approved or disapproved, and logged. Start with clear policies, automate what you can, and keep evidence easy to extract for assessors.
