Track, review, approve/disapprove, and audit changes to systems
📖 What This Means
This practice requires organizations to have a structured process for managing changes to their systems. This includes tracking every change, reviewing it for potential security impacts, approving or disapproving it based on the review, and auditing the changes to ensure they were implemented correctly. Think of it like a quality control process for system updates—it ensures that changes don't introduce vulnerabilities or disrupt operations. For example, when a software update is proposed, it should be documented, evaluated for risks, approved by a designated team, and then audited to confirm it was applied correctly. Another example is hardware changes, like adding a new server, which must go through the same process to ensure it aligns with security policies.
🎯 Why It Matters
Uncontrolled changes to systems can lead to security vulnerabilities, system outages, or unauthorized access. For instance, a 2021 breach at a major retailer occurred because an unapproved change introduced a vulnerability that hackers exploited, resulting in millions of dollars in losses and reputational damage. From the DoD's perspective, this control is critical because defense contractors handle sensitive government information. Without proper change management, adversaries could exploit unapproved changes to steal classified data or disrupt critical systems. The potential impact includes financial penalties, loss of contracts, and damage to national security.
✅ How to Implement
- 1. Use cloud-native change management tools like AWS Systems Manager Change Manager or Azure Change Tracking.
- 2. Define a change approval workflow in your cloud platform, ensuring it includes security review steps.
- 3. Enable logging for all changes using services like AWS CloudTrail or Azure Activity Log.
- 4. Regularly audit changes by exporting logs and reviewing them for unauthorized modifications.
- 5. Integrate change management with your SIEM (e.g., Splunk or Sentinel) for real-time monitoring.
- 6. Document all changes in a centralized repository, such as a ticketing system like Jira or ServiceNow.
📋 Evidence Examples
Change Control Policy
Change Request Log
CCB Meeting Minutes
Change Audit Report
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For CM.L2-3.4.3 ("Track, review, approve/disapprove, and audit changes to systems"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your configuration management process, including baseline configurations, change control procedures, vulnerability management, and how configuration compliance is monitored and enforced. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"CM.L2-3.4.3 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to track, review, approve/disapprove, and audit changes to systems. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"CM.L2-3.4.3 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to track, review, approve/disapprove, and audit changes to systems. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"CM.L2-3.4.3 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all system types within the CUI boundary requiring baselines
- • Document configuration management tools and CMDB
- • Map change control workflow from request to implementation
- • Ensure this control covers all systems within your defined CUI boundary where track, review, approve/disapprove, and audit changes to systems applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Configuration Management Policy
- 📄 Baseline configuration documents
- 📄 Change management records
- 📄 CMDB/asset inventory
- 📄 Evidence artifacts specific to CM.L2-3.4.3
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will compare actual system configurations against documented baselines, review change tickets for proper approval workflow, and verify vulnerability remediation within SLA.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have a documented change control policy?
Question 2: Are all changes tracked in a centralized log?
Question 3: Is there a Change Control Board (CCB) to review and approve changes?
Question 4: Are changes audited regularly to verify compliance?
Question 5: Are employees trained on change management procedures?
⚠️ Common Mistakes (What Auditors Flag)
1. Incomplete change documentation.
2. Skipping security reviews.
3. Failure to audit changes.
4. Missing training records.
5. Unapproved changes.
📚 Parent Policy
This practice is governed by the Configuration Management Policy