Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - CM.L2-3.4.3 – Track, review, approve, or disapprove, and log changes to organizational systems.
Understanding the Requirement
This control requires that every configuration and operational change to your information systems be recorded, reviewed, and explicitly approved or rejected before being applied to production, and that the change activity is logged for later review. It combines four objectives: tracking proposed changes, reviewing them for security and business impact, making an explicit approval decision, and maintaining an audit trail of the change and its implementation. For organizations following NIST SP 800-171 REV.2 / CMMC 2.0 Level 2, this typically means formalizing a change control process, assigning decision-makers, and ensuring your systems produce and retain suitable logs.
Technical Implementation
- Document a formal change request process: Use a standard change request form that captures requester, description, reason, affected systems, rollback plan, test plan, scheduled window, and risk assessment. Require completed forms before any non-emergency change is scheduled.
- Establish a change control board (CCB): Define membership (IT lead, security officer, and a business owner) and a cadence (weekly or biweekly). The CCB reviews requests, evaluates security and availability impacts, and records approval or disapproval decisions in the change ticket.
- Use staging and test validation: Mandate that changes are tested in a staging or lab environment that mirrors production. Require test results and rollback verification be attached to the change ticket before approving deployment to production.
- Enforce logging and audit trails: Configure system and application logging to capture who made the change, what was changed, timestamps, and change-related outputs. Centralize logs (SIEM, log server, or cloud logging) and retain them per policy (e.g., 90–365 days depending on risk and contract requirements).
- Implement approval enforcement controls: Use technical controls when possible—require change tickets linked to automation tools (patch management, configuration management databases, or orchestration scripts) so automated deployments check for an approval flag before executing.
- Define emergency change handling: Create a documented emergency change procedure that records the reason, temporary approvals, expedited testing, and a post-event retrospective to convert the emergency change into a regular reviewed item afterward.
Example in a Small or Medium Business
A 40-person engineering firm maintains a mixed environment of workstations and a small set of Linux and Windows servers hosting internal applications. The IT manager implements a simple change control process using a shared ticketing system: every proposed system update or configuration change requires a filled change request form. The change control board meets every other Friday and includes the IT manager, a security lead (part-time CISO), and one operations manager. When Alice, a system administrator, wants to roll out Windows security updates to 35 laptops, she fills the form with scope, test results from a 3-workstation pilot, scheduled downtime, and rollback steps. The CCB reviews the submission, flags one compatibility concern, and approves the change for the next maintenance window after Alice adjusts the pilot patch list. The deployment runs via the patch management tool that verifies the ticket ID and approval before installing. All change metadata and system logs are forwarded to the central log server; when one machine fails to update, the team uses the logs and the documented rollback to restore the device and updates the ticket with the resolution and lessons learned.
Summary
By combining a written change request process, a cross-functional change control board, stage-based testing, enforced approvals, centralized logging, and an emergency change workflow, SMBs can meet CM.L2-3.4.3. These policy and technical controls prevent unauthorized or risky changes, provide accountability through recorded approvals and logs, and ensure you can quickly troubleshoot or roll back problematic deployments—protecting both security and business continuity.
