3.4.3 — Control Every Change

The One-Liner

If someone can change production without approval and documentation, your change management is broken.

What It Says

Track, review, approve or disapprove, and log changes to organizational systems.

What It Actually Means

Every change to a CUI system goes through a documented change management process with four steps, all assessed independently:

1. Track. Changes are recorded in a system — ticketing tool, change log, ITSM platform. Nothing happens without a record. The record includes what’s being changed, who requested it, when, and why.

2. Review. Someone with appropriate knowledge evaluates the change before it’s implemented. For CUI systems, this includes a security review — does this change introduce risk or weaken a control?

3. Approve or disapprove. An authorized person formally signs off. For significant changes, this may be a Change Advisory Board (CAB). For routine changes (standard changes), pre-approved categories with documented criteria are acceptable.

4. Log. After implementation, the change is documented: what was done, when, by whom, and what the outcome was. The record is retained.

This applies to everything that alters CUI system state: configuration changes, software updates, hardware modifications, firewall rule changes, cloud service configuration, user account changes — anything.

Emergency changes are still changes. They can bypass the pre-approval step if urgency requires it, but they still must be documented after the fact and reviewed retroactively. “Emergency” is not a permanent loophole.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are changes to the system tracked?	Every change recorded in a ticketing system or change log with description, requester, date
2	Are changes reviewed?	Review evidence — comments, security impact assessment, or CAB minutes — for recent changes
3	Are changes approved or disapproved?	Formal approval recorded — approver name, date, decision — before implementation
4	Are changes logged after implementation?	Post-implementation record: what was done, when, by whom, outcome

---

What to Have Ready on Assessment Day

Documents they’ll review: Configuration management policy; change management procedures; system security plan; change control records (tickets); CAB meeting agendas and minutes; change control audit reports; system audit logs showing changes

People they’ll talk to: Personnel with configuration change control responsibilities; information security personnel; system or network administrators; CAB members

Live demos they’ll ask for: “Show me your last five change tickets.” “Walk me through a recent change from request to completion.” “Show me an emergency change — was it documented after the fact?” “Who approves changes?”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me your change management process. How is a change requested?”
• “Walk me through a recent change ticket — request, review, approval, implementation, log.”
• “Who approves changes? Is there a CAB or designated approver?”
• “How do you handle emergency changes? Show me one.”
• “Are changes documented and tracked in a ticketing system?”
• “Can you show me a change that was disapproved? What happened?”
• “Are changes authorized by management and documented?”

Real-World Example

A defense contractor uses a ticketing system for all change management. A sysadmin needs to add a firewall rule for a new CUI application. They submit a change ticket with: description of the change, affected systems, business justification, rollback plan, and security impact assessment (completed with the IT Security Lead). The IT Security Lead reviews and approves. The CAB meets monthly and reviews all changes implemented since the last meeting — emergency changes are reviewed retroactively. After implementation, the sysadmin updates the ticket with: implementation date, steps performed, verification that the change works, and any issues encountered. The ticket is closed. During the assessment, the assessor reviews five recent change tickets and confirms each has a request, review, approval, implementation record, and post-implementation verification.

---

Where Companies Trip Up

No process. Changes happen ad-hoc — an admin makes a change and tells nobody. The assessor asks “show me your change management process” and it doesn’t exist. At minimum, use a ticketing system and require a ticket for every change.

Emergency bypass without documentation. Emergency changes are made — legitimately — but never documented after the fact. The assessor finds changes in the audit log with no corresponding change ticket. Emergency changes must be documented retroactively within a defined timeframe (48 hours is common).

Rubber stamp approvals. The approval step exists but the approver never actually reviews — they just click “approve” on everything. The assessor will ask the approver about a specific change and check whether they actually evaluated it.

No change log. Changes are approved but there’s no record of what was actually implemented. The ticket says “update firewall rule” but doesn’t record the specific rule that was added. Post-implementation documentation should be specific enough to recreate or reverse the change.

---

How to Talk About This

To a CEO or Board

Every change to our CUI environment goes through documented approval. No surprises, no undocumented changes. We have a complete audit trail of every modification to our systems.

To an Engineering Team

Change management via ticketing system. Workflow: request → security impact assessment → approval (IT Security Lead or CAB) → implement → verify → close. Emergency changes: implement first, document within 48 hours, CAB retroactive review. Standard changes: pre-approved categories with documented criteria. All tickets retained for audit evidence.

---

Connected Requirements

Requirement	Why it matters here
3.4.4 — Check Before You Change	Security impact analysis performed as part of the review step
3.4.5 — Lock Down Change Access	Restricts who can implement changes — the enforcement arm
3.4.1 — Know Your Inventory	Changes update the inventory and may update the baseline
3.3.1 — Log Everything	Configuration changes are auditable events that must be logged

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: CM.L2-3.4.3 | SPRS Weight: 1 point | POA&M Eligible: Yes