CM.L2-3.4.3 requires organizations to track, review, approve, and audit changes to system and configuration baselines; this post gives practical, technical guidance for small businesses to meet that requirement using version control, Infrastructure-as-Code (IaC), CI/CD, and simple change management processes that produce auditable evidence.
\n\nAt a practical level the control expects you to (1) define configuration baselines, (2) ensure any change to those baselines is recorded in a controlled process, (3) require review and formal approval before the change is applied, and (4) keep auditable logs and artifacts that demonstrate who changed what, when, why, and how to revert. For Compliance Framework purposes, that means your configuration items (software, OS images, IaC templates, network settings, device profiles) must live under a versioned system and be tied to an approval workflow with corresponding audit logs retained per your retention policy.
\n\nStart by inventorying configuration artefacts and selecting a single source of truth: put application config, IaC (Terraform, CloudFormation, ARM), Ansible playbooks, and container manifests into a version control system such as Git (GitHub/GitLab/Bitbucket). Create a baseline branch (for example, main or prod) and protect it with branch protection rules: require pull requests (PRs), at least one or two approvers, passing CI checks, and signed commits. Require every change to reference a change ticket (JIRA/Trello/GitHub Issues) and include a succinct description and rollback plan in the PR template so an auditor can trace intent and approval from ticket -> PR -> merge -> deployment.
\n\nConfigure your tooling to produce verifiable evidence automatically. Example controls: enable branch protection to reject direct pushes to prod; enable enforced code review and require 2 approvals for configuration changes; enable commit signing (GPG/SSH) and require verified commits. For IaC, store state in a remote backend with locking (Terraform remote state in an S3 bucket + DynamoDB lock for AWS, or Terraform Cloud), enable versioning on the state S3 bucket, and restrict who can access state with IAM. Use CI pipelines that run static checks and policy-as-code (Conftest/OPA/Sentinel) and fail on policy violations; keep pipeline logs and artifacts (built images, hashes) in an artifact registry like ECR/GCR/Harbor which retains immutable tags or signed images (not mutable latest tags). Example Git workflow: feature branch -> PR referencing CHG-123 -> automated tests + policy checks -> 2 approvals -> merge to main -> CD pipeline deploys to staging and tags release (git tag -a v1.2.0 -m \"Baseline v1.2.0 / CHG-123\").
\n\nImplement drift detection to ensure deployed state matches checked-in baselines: run periodic checks with AWS Config/Azure Policy or open-source tools (InSpec, Chef Automate, Puppet, or Kubernetes Gatekeeper + OPA). Configure CloudTrail or equivalent to log API activity and ship logs to an immutable, access-controlled storage location (for example, S3 with object lock or an append-only log in your SIEM). Maintain logs for the retention window defined in your policy (commonly 1–3 years depending on contract), and produce change reports that show diffs between baseline versions to demonstrate review and approval during audits.
\n\nImagine a small software company that handles CUI for a DoD subcontractor. They use GitHub with protected branches, GitHub Actions for CI, Terraform for infra, and an S3 backend for Terraform state. A developer opens a PR to change an RDS parameter; the PR must reference the JIRA change ticket, include a test plan, and pass automated checks (security lint, terraform fmt, plan). Two team leads review and approve, CI creates an artifact and tags the release. The deployment pipeline requires an approval gate that pulls the ticket ID and approver list from the PR; after deployment, CloudTrail and pipeline logs are exported to a secure S3 bucket and an automated weekly report shows all changes applied that week. For auditors, the company can present the PR, ticket, merge commit, signed artifact hash, state diff, and CloudTrail log — all linked and timestamped.
\n\nMap your artifacts to the control: list PRs, change tickets, branch protection settings, CI logs, artifact hashes, state files, and drift reports in your compliance binder. Standardize commit messages and PR templates to include required metadata (ticket ID, reason, roll-back plan, approvers). Automate evidence collection: produce a daily/weekly \"change register\" that pulls metadata from Git, CI, and ticket systems via their APIs and stores a signed PDF or CSV in your evidence repository. Use role-based access controls and separation of duties (developers cannot approve their own production merges). Periodically (quarterly) review baselines and approval thresholds and record those reviews in the configuration management plan.
\n\nWithout version control and configuration change controls, small businesses face high risk: unauthorized or unreviewed changes can introduce vulnerabilities or misconfigurations that expose CUI, lead to outages, or break contractual compliance. Lacking auditable trails results in failed assessments, loss of contracts, and costly remediation. Even simple mistakes—like a developer pushing credentials to production or a drifted security group—become difficult to investigate or roll back without baselines and signed artifacts.
\n\nIn summary, meeting CM.L2-3.4.3 is achievable for small organizations by placing configuration artifacts under version control, enforcing PR-based workflows with approvals and CI gates, using IaC with remote state and locking, enabling drift detection and audit logging, and automating evidence collection. These steps make change processes auditable, repeatable, and resilient while producing the concrete artifacts auditors require under the Compliance Framework.
", "plain_text": "CM.L2-3.4.3 requires organizations to track, review, approve, and audit changes to system and configuration baselines; this post gives practical, technical guidance for small businesses to meet that requirement using version control, Infrastructure-as-Code (IaC), CI/CD, and simple change management processes that produce auditable evidence.\n\nWhat CM.L2-3.4.3 means in practice\nAt a practical level the control expects you to (1) define configuration baselines, (2) ensure any change to those baselines is recorded in a controlled process, (3) require review and formal approval before the change is applied, and (4) keep auditable logs and artifacts that demonstrate who changed what, when, why, and how to revert. For Compliance Framework purposes, that means your configuration items (software, OS images, IaC templates, network settings, device profiles) must live under a versioned system and be tied to an approval workflow with corresponding audit logs retained per your retention policy.\n\nImplementation plan — step-by-step practical advice\nStart by inventorying configuration artefacts and selecting a single source of truth: put application config, IaC (Terraform, CloudFormation, ARM), Ansible playbooks, and container manifests into a version control system such as Git (GitHub/GitLab/Bitbucket). Create a baseline branch (for example, main or prod) and protect it with branch protection rules: require pull requests (PRs), at least one or two approvers, passing CI checks, and signed commits. Require every change to reference a change ticket (JIRA/Trello/GitHub Issues) and include a succinct description and rollback plan in the PR template so an auditor can trace intent and approval from ticket -> PR -> merge -> deployment.\n\nTechnical controls and examples\nConfigure your tooling to produce verifiable evidence automatically. Example controls: enable branch protection to reject direct pushes to prod; enable enforced code review and require 2 approvals for configuration changes; enable commit signing (GPG/SSH) and require verified commits. For IaC, store state in a remote backend with locking (Terraform remote state in an S3 bucket + DynamoDB lock for AWS, or Terraform Cloud), enable versioning on the state S3 bucket, and restrict who can access state with IAM. Use CI pipelines that run static checks and policy-as-code (Conftest/OPA/Sentinel) and fail on policy violations; keep pipeline logs and artifacts (built images, hashes) in an artifact registry like ECR/GCR/Harbor which retains immutable tags or signed images (not mutable latest tags). Example Git workflow: feature branch -> PR referencing CHG-123 -> automated tests + policy checks -> 2 approvals -> merge to main -> CD pipeline deploys to staging and tags release (git tag -a v1.2.0 -m \"Baseline v1.2.0 / CHG-123\").\n\nConfiguration drift detection and auditing\nImplement drift detection to ensure deployed state matches checked-in baselines: run periodic checks with AWS Config/Azure Policy or open-source tools (InSpec, Chef Automate, Puppet, or Kubernetes Gatekeeper + OPA). Configure CloudTrail or equivalent to log API activity and ship logs to an immutable, access-controlled storage location (for example, S3 with object lock or an append-only log in your SIEM). Maintain logs for the retention window defined in your policy (commonly 1–3 years depending on contract), and produce change reports that show diffs between baseline versions to demonstrate review and approval during audits.\n\nSmall-business scenario: 5-person devops team\nImagine a small software company that handles CUI for a DoD subcontractor. They use GitHub with protected branches, GitHub Actions for CI, Terraform for infra, and an S3 backend for Terraform state. A developer opens a PR to change an RDS parameter; the PR must reference the JIRA change ticket, include a test plan, and pass automated checks (security lint, terraform fmt, plan). Two team leads review and approve, CI creates an artifact and tags the release. The deployment pipeline requires an approval gate that pulls the ticket ID and approver list from the PR; after deployment, CloudTrail and pipeline logs are exported to a secure S3 bucket and an automated weekly report shows all changes applied that week. For auditors, the company can present the PR, ticket, merge commit, signed artifact hash, state diff, and CloudTrail log — all linked and timestamped.\n\nCompliance tips, best practices, and evidence collection\nMap your artifacts to the control: list PRs, change tickets, branch protection settings, CI logs, artifact hashes, state files, and drift reports in your compliance binder. Standardize commit messages and PR templates to include required metadata (ticket ID, reason, roll-back plan, approvers). Automate evidence collection: produce a daily/weekly \"change register\" that pulls metadata from Git, CI, and ticket systems via their APIs and stores a signed PDF or CSV in your evidence repository. Use role-based access controls and separation of duties (developers cannot approve their own production merges). Periodically (quarterly) review baselines and approval thresholds and record those reviews in the configuration management plan.\n\nRisk of not implementing CM.L2-3.4.3\nWithout version control and configuration change controls, small businesses face high risk: unauthorized or unreviewed changes can introduce vulnerabilities or misconfigurations that expose CUI, lead to outages, or break contractual compliance. Lacking auditable trails results in failed assessments, loss of contracts, and costly remediation. Even simple mistakes—like a developer pushing credentials to production or a drifted security group—become difficult to investigate or roll back without baselines and signed artifacts.\n\nIn summary, meeting CM.L2-3.4.3 is achievable for small organizations by placing configuration artifacts under version control, enforcing PR-based workflows with approvals and CI gates, using IaC with remote state and locking, enabling drift detection and audit logging, and automating evidence collection. These steps make change processes auditable, repeatable, and resilient while producing the concrete artifacts auditors require under the Compliance Framework." }, "metadata": { "description": "Practical steps, tools, and small-business examples to track, review, approve, and audit configuration changes to meet NIST SP 800-171 Rev.2 / CMMC 2.0 CM.L2-3.4.3.", "permalink": "/how-to-use-version-control-and-configuration-management-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-cml2-343-requirements.json", "categories": [], "tags": [] } }