Monitor system security alerts and advisories and take action
📖 What This Means
This control requires organizations to actively monitor security alerts and advisories related to their systems and take appropriate actions to address any identified threats or vulnerabilities. This means staying informed about potential risks through notifications from software vendors, security organizations, and internal monitoring tools, and then responding promptly to mitigate those risks. For example, if a security advisory warns about a critical vulnerability in a software application your company uses, you should quickly apply the recommended patch or update to protect your systems. Similarly, if your antivirus software detects malware, you should isolate the affected system and clean it immediately. The goal is to maintain the integrity and security of your systems by staying proactive about potential threats.
🎯 Why It Matters
Failing to monitor and act on security alerts can leave your systems exposed to known vulnerabilities, increasing the risk of cyberattacks, data breaches, and operational disruptions. For instance, the Equifax breach in 2017 occurred because the company failed to patch a known vulnerability in their software, leading to the exposure of sensitive data for millions of individuals. The Department of Defense (DoD) emphasizes this control in CMMC to ensure defense contractors maintain a strong security posture and protect Controlled Unclassified Information (CUI). By addressing security alerts promptly, organizations can prevent costly incidents, protect their reputation, and meet compliance requirements.
✅ How to Implement
- Enable security alerts in your cloud provider's dashboard (e.g., AWS CloudWatch, Azure Security Center).
- Subscribe to security advisories from your cloud provider's notification service.
- Configure automated responses to common alerts (e.g., auto-scaling, quarantine).
- Regularly review cloud audit logs for unusual activity.
- Integrate cloud monitoring tools with your Security Information and Event Management (SIEM) system.
📋 Evidence Examples
Security Alert Log
Patch Management Report
Incident Response Playbook
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.L1-3.14.3 ("Monitor system security alerts and advisories and take action"), 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.L1-3.14.3 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to monitor system security alerts and advisories and take action. 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.L1-3.14.3 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to monitor system security alerts and advisories and take action. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"SI.L1-3.14.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 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 system security alerts and advisories and take action 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.L1-3.14.3
- 📄 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 system in place to monitor security alerts?
Question 2: Are alerts reviewed and acted upon daily?
Question 3: Do you have a documented incident response playbook?
Question 4: Are employees trained on responding to security alerts?
Question 5: Are patches applied within 30 days of advisory release?
⚠️ Common Mistakes (What Auditors Flag)
1. Not subscribing to vendor advisories
2. Ignoring low-priority alerts
3. Delaying patch application
4. Lacking documentation
5. Not integrating cloud and on-premise monitoring
📚 Parent Policy
This practice is governed by the System and Information Integrity Policy