Monitor organizational systems
📖 What This Means
This practice requires organizations to continuously monitor their systems to detect and respond to potential security threats. It involves setting up tools and processes to track system activities, identify unusual patterns, and alert the security team when something suspicious happens. Think of it as having a security camera for your IT systems. For example, if an employee’s account suddenly starts accessing sensitive files at odd hours, monitoring tools should flag this activity. Another example is detecting malware attempting to spread across the network. The goal is to catch issues early before they escalate into major incidents.
🎯 Why It Matters
Failing to monitor systems leaves organizations blind to potential cyberattacks. According to IBM’s Cost of a Data Breach Report, it takes an average of 277 days to identify and contain a breach, costing millions of dollars. For instance, the SolarWinds breach went undetected for months, compromising sensitive government and corporate data. CMMC emphasizes this control because the DoD relies on contractors to protect Controlled Unclassified Information (CUI). Continuous monitoring ensures quick detection of threats, minimizing damage and maintaining trust with the DoD.
✅ How to Implement
- Enable logging in your cloud provider (e.g., AWS CloudTrail, Azure Monitor, GCP Operations Suite).
- Configure alerts for unusual activities like failed logins, unauthorized access attempts, or configuration changes.
- Integrate cloud logs with a Security Information and Event Management (SIEM) tool like Splunk or Elastic Stack.
- Set up automated reports for daily/weekly review by the security team.
- Regularly review and update monitoring rules to adapt to new threats.
📋 Evidence Examples
Monitoring Policy
SIEM Configuration Screenshots
Alert Logs
Incident Response Reports
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 SI.L2-3.14.6 ("Monitor organizational 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 system and information integrity controls, including patch management process, antivirus/EDR deployment, email gateway protection, SIEM monitoring, and application security measures. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"SI.L2-3.14.6 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to monitor organizational 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']."
"SI.L2-3.14.6 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to monitor organizational systems. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"SI.L2-3.14.6 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 systems requiring patch management within the CUI boundary
- • Document EDR/AV coverage across endpoints and servers
- • Specify SIEM monitoring coverage and alert rules
- • Ensure this control covers all systems within your defined CUI boundary where monitor organizational systems applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 System and Information Integrity Policy
- 📄 Patch management reports
- 📄 AV/EDR deployment records
- 📄 SIEM alert configuration
- 📄 Evidence artifacts specific to SI.L2-3.14.6
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify patch management SLAs are met, check AV/EDR deployment coverage (should be 100%), review SIEM alert rules and response times, and test that email gateway blocks malicious content.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have a documented monitoring policy?
Question 2: Are logs from all critical systems being collected?
Question 3: Are alerts configured for suspicious activities?
Question 4: Are logs reviewed regularly?
Question 5: Is staff trained to respond to alerts?
⚠️ Common Mistakes (What Auditors Flag)
1. Incomplete log collection
2. No alerts for suspicious activities
3. Infrequent log reviews
4. Untrained staff
5. No integration between cloud and on-premise tools
📚 Parent Policy
This practice is governed by the System and Information Integrity Policy