CMMC Level 2 Practice 3.4.3: Track, review, approve or disapprove, and log changes to organizational systems

CMMC Level 2 assessments frequently expose gaps in “day-to-day” operational discipline, and change control is one of the fastest ways an assessor can tell whether security is managed or improvised. CMMC Level 2 Practice 3.4.3: track, review, approve or disapprove, and log changes to organizational systems requirement is direct: if you change a system that stores, processes, or transmits CUI, you must be able to show that the change was requested, evaluated, authorized (or rejected), implemented, and recorded.

This requirement is mapped to NIST SP 800-171 Rev. 2 control 3.4.3 and is evaluated in the context of your defined CUI scope, your system boundary, and your operational model (on-prem, cloud, hybrid, managed services). ¹ Your objective is not “having a ticketing tool.” Your objective is operational control: reducing unauthorized or risky changes, preventing outages and misconfigurations that weaken security, and producing evidence that stands up under assessment.

The guidance below focuses on what a CCO, compliance lead, or GRC owner needs to operationalize this quickly: scope decisions, minimum viable workflows, evidence packages, and common assessor hangups.

Regulatory text

Requirement (mapped): “Track, review, approve or disapprove, and log changes to organizational systems.” ¹

Operator interpretation: You must implement change control for systems in your CMMC Level 2 scope. That means:

• A change cannot be “informal” (Slack message, hallway conversation) and still count.
• Someone reviews the proposed change for impact and risk.
• An authorized approver explicitly approves or rejects it.
• You keep a durable record (log) that ties request → approval decision → implementation → validation/closure.
  This practice is part of the CMMC Level 2 model implemented under the CMMC Program rule and guidance. ^{2 3}

Plain-English interpretation (what the assessor is testing)

Assessors are testing whether you can prevent and detect unauthorized change and whether your security posture is stable over time. In practice, they want to see:

• Traceability: Can you trace production changes back to a request and an approval?
• Governance: Are approvers defined, and do they have authority for the system?
• Completeness: Does the log include routine changes (patching, config updates) and “security relevant” changes (firewall rules, identity settings)?
• Repeatability: Does the process run the same way across teams and platforms?

A “good enough” implementation is usually a lightweight but consistently followed workflow that covers the whole boundary, not a perfect ITIL program that no one follows.

Who it applies to (entity and operational context)

Applies to: Defense contractors and other federal contractors handling CUI that are pursuing or maintaining CMMC Level 2. ^{2 3}

Operational scope: Apply the control to organizational systems in your CUI environment, which typically includes:

• Endpoints and servers that store/process/transmit CUI
• Network devices (firewalls, switches, routers, VPN concentrators)
• Identity systems (directory services, SSO/IdP, PAM where used)
• Cloud resources (IaaS/PaaS configurations, security groups, IAM policies)
• Security tooling that can change enforcement state (EDR policies, email security rules)

Third-party reality: If a managed service provider or SaaS admin makes changes in your environment, your organization still needs evidence that changes were controlled. Your contract and operating model must support ticketing, approvals, and logging for third-party executed changes.

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

1) Define the change control boundary

• List “in-scope” systems (your CUI boundary) and designate them as change-controlled.
• Define categories: Standard changes (pre-approved, low risk), Normal changes (review/approval required), Emergency changes (expedited with after-the-fact review).
• Document ownership: system owner, technical owner, approver(s).

Deliverable: a one-page “Change Control Scope” section inside your SSP or a supporting standard operating procedure aligned to CMMC L2 / NIST SP 800-171r2 3.4.3. ¹

2) Stand up a minimum viable workflow (ticket-first)

For each in-scope change, require a ticket/change record with:

• Requestor name and role
• System/asset identifier
• Description of change (what, where)
• Reason/business justification
• Risk/impact prompts (security impact, downtime, backout plan)
• Planned implementation time window
• Required testing/validation steps

This can live in Jira/ServiceNow/Azure DevOps or a controlled spreadsheet for very small environments, but you must ensure integrity, retention, and auditability.

3) Implement review and explicit approve/disapprove

• Define reviewers (technical peer review, security review for higher-risk changes).
• Define approvers (system owner, IT manager, ISSO/security lead depending on change type).
• Require an explicit approval status (“Approved” / “Rejected” / “More info required”) captured in the ticket record.

Practical separation-of-duties pattern: the implementer should not be the sole approver for production changes where you can avoid it.

4) Log the change in a durable record and reconcile to system logs

Your “log” is typically the change ticket system plus supporting technical logs:

• Ticket/change record is the authoritative register.
• Technical evidence can include: Git commit IDs, CI/CD pipeline run, configuration snapshots, firewall export diffs, system audit events.

Key point: You must be able to show that changes seen in system audit logs have corresponding approved tickets, at least for a sample set an assessor selects.

5) Control emergency changes without breaking operations

Emergency changes are allowed, but you need guardrails:

• Document emergency criteria (security incident containment, critical outage).
• Require emergency approval by an on-call approver (even if verbal), then retroactive documentation and post-change review.
• Track emergency changes in a dedicated queue so they are easy to audit.

6) Run a recurring change review (operational monitoring)

On a recurring cadence, perform a management review:

• Sample completed changes.
• Confirm approvals exist.
• Confirm validation/backout steps were recorded.
• Identify repeated failures (missing fields, unapproved changes).

This is where many teams create “recurring evidence capture,” which directly supports assessment readiness and maps cleanly to the practice intent. ¹

7) Make it work for cloud and infrastructure-as-code (IaC)

If your environment uses Terraform/CloudFormation/Ansible:

• Treat pull requests as the review gate.
• Require approvals in the repo (CODEOWNERS or branch protections).
• Log deployment runs (CI/CD artifacts) and tie them to the ticket ID.

Assessors accept modern change control when it is traceable and enforced.

Required evidence and artifacts to retain (what “good” looks like)

Maintain an evidence set that can be produced quickly:

Policy / procedure

• Change Management Policy or SOP referencing the requirement and scope (CUI boundary) ¹
• Defined change types (standard/normal/emergency) and approval authority matrix

Operational records

• Change tickets with approve/disapprove status and timestamps
• Review notes (security impact, testing performed)
• Emergency change records and post-implementation reviews

Technical corroboration

• Git commits/PR approvals tied to ticket IDs
• CI/CD logs showing deployments tied to approved work items
• System audit logs or configuration baselines showing changes occurred as recorded

Management oversight

• Periodic change review minutes or checklist results
• Exceptions register (when process wasn’t followed) with remediation actions

If you use Daydream to map requirements to controls, treat 3.4.3 as a control with a defined operating cadence and automate recurring evidence capture from ticketing and source control where possible. This reduces last-minute evidence scrambles and supports consistent assessor narratives. ³

Common exam/audit questions and hangups

Assessors often probe the same pressure points:

• “Show me three recent firewall or IAM changes and the approvals.”
• “How do you prevent untracked changes made directly in the cloud console?”
• “Who can approve production changes, and how is that enforced?”
• “How do you handle emergency patching? Show the after-action review.”
• “How do you know changes were actually implemented as approved?”

Hangup: teams show a policy, but the tickets don’t match it. The control fails on operation, not design.

Frequent implementation mistakes (and how to avoid them)

1. Only tracking ‘big’ changes.
   Fix: define “security-relevant” changes and include routine config changes that affect access control, network paths, logging, and encryption.

2. Approvals exist, but not explicit approve/disapprove.
   Fix: require a discrete status field or approval workflow step; “Looks good” comments without a recorded decision cause assessor friction.

3. No linkage between tickets and technical changes.
   Fix: enforce ticket IDs in commit messages, PR titles, deployment annotations, or change descriptions.

4. Emergency changes become a loophole.
   Fix: require post-change documentation and a short review step; track emergency volume as an operational metric for management attention.

5. Third party admins operate outside your workflow.
   Fix: contractually require they open/participate in your change tickets, provide logs, and follow your approval gates for in-scope systems.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. Practically, the risk is assessment failure or a conditional outcome if you cannot demonstrate traceable approvals and logs for in-scope changes under the CMMC Program expectations. ^{2 3}

Operationally, weak change control increases the likelihood of misconfigurations and unauthorized changes that can lead to CUI exposure. This practice is one of the fastest ways to demonstrate you run your environment with discipline.

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Confirm CUI boundary and list in-scope systems.
• Publish a short Change Control SOP and approval matrix.
• Require tickets for all in-scope changes; start with network, identity, and server changes.
• Configure ticket fields: system, risk/impact, backout plan, approval decision.

Days 31–60 (enforce and connect to technical evidence)

• Enforce repo protections (PR approvals) for IaC and code-based changes.
• Require ticket ID linkage to commits/PRs/deployments.
• Build an evidence folder template: policy, approval matrix, ticket exports, sample technical logs.
• Implement emergency change path with post-change review.

Days 61–90 (operate, measure, and harden)

• Run a recurring sample-based change review and document results.
• Add guardrails for console changes in cloud (role-based access, logging, and detective review).
• Expand scope beyond “critical” systems to all in-scope assets.
• Use Daydream (or your GRC system) to schedule recurring evidence pulls and keep an assessor-ready evidence pack aligned to CMMC L2 / NIST SP 800-171r2 3.4.3. ¹

Frequently Asked Questions

Do we need a formal CAB (Change Advisory Board) to pass 3.4.3?

No specific structure is mandated. You do need documented review and explicit approval/disapproval with logs that show it happened consistently for in-scope systems. ¹

Are patches and routine updates “changes” that must be logged?

Yes, if they change the configuration or behavior of in-scope systems. Many teams treat routine patching as a “standard change” with pre-approval, but they still log execution and results.

What counts as “organizational systems” for this control?

Treat systems within your CUI boundary as in scope, including endpoints, servers, network devices, identity services, and cloud configurations that support CUI processing. ¹

Can GitHub pull requests replace change tickets?

They can cover review and approval for code/IaC changes if enforced and traceable, but you still need a durable log that ties the change to the affected system and implementation record. Many organizations link PRs to a ticket for clean audit trails.

How do we handle emergency security fixes without breaking the process?

Define emergency criteria, require expedited approval by an authorized approver, then document the change and run a post-implementation review. Keep emergency changes in a distinct queue so you can show control under pressure.

Our MSP makes firewall changes. How do we show compliance?

Require the MSP to submit changes through your ticketing workflow (or provide records that map to it), obtain your approvals, and provide implementation logs. If they cannot support that, treat it as a contract and control gap.

Footnotes

1. NIST SP 800-171 Rev. 2

2. 32 CFR Part 170

3. DoD CMMC Program Guidance