Monitor security controls on an ongoing basis
📖 What This Means
This practice requires organizations to continuously monitor their security controls to ensure they are functioning as intended and protecting sensitive data. Think of it like regularly checking your car's brakes to make sure they work properly. Without ongoing monitoring, you might not realize a control has failed until it's too late. For example, if a firewall rule gets changed accidentally, it could leave your network exposed. Another example is monitoring user access logs to spot unauthorized attempts to access sensitive systems. This ongoing vigilance helps catch issues early and maintain a strong security posture.
🎯 Why It Matters
Failing to monitor security controls can lead to undetected vulnerabilities, which attackers can exploit. For instance, in the 2017 Equifax breach, a known vulnerability in a web application went unpatched for months, exposing the personal data of 147 million people. The cost of such breaches includes financial penalties, loss of customer trust, and damage to reputation. From the DoD/CMMC perspective, continuous monitoring is critical because defense contractors handle Controlled Unclassified Information (CUI) that adversaries target. This practice ensures that security controls remain effective over time, reducing the risk of data breaches and compliance failures.
✅ How to Implement
- Enable logging and monitoring services in your cloud environment (e.g., AWS CloudTrail, Azure Monitor, GCP Operations Suite).
- Set up alerts for unusual activity, such as failed login attempts or changes to security configurations.
- Regularly review access logs to ensure only authorized users are accessing sensitive data.
- Conduct periodic vulnerability scans on cloud resources using tools like AWS Inspector or Azure Security Center.
- Automate compliance checks using cloud-native tools like AWS Config or Azure Policy.
- Document and review monitoring processes in your cloud security policy.
- Train staff on how to respond to alerts and escalate incidents.
📋 Evidence Examples
Security Monitoring Policy
SIEM Logs
Vulnerability Scan Reports
Incident Response Records
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 CA.L2-3.12.3 ("Monitor security controls on an ongoing basis"), 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 security assessment program, SSP maintenance process, continuous monitoring capabilities, and penetration testing schedule. Reference specific tools and responsible parties. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"CA.L2-3.12.3 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to monitor security controls on an ongoing basis. 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']."
"CA.L2-3.12.3 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to monitor security controls on an ongoing basis. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"CA.L2-3.12.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
- • Define the assessment boundary (which systems are in scope)
- • Document assessment methodology and tools
- • Identify assessors (internal team, external firm)
- • Ensure this control covers all systems within your defined CUI boundary where monitor security controls on an ongoing basis applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Security Assessment Policy
- 📄 System Security Plan (SSP)
- 📄 Plan of Action & Milestones (POA&M)
- 📄 Assessment reports
- 📄 Evidence artifacts specific to CA.L2-3.12.3
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will review your SSP for completeness, verify POA&M items are being tracked and remediated, and check that assessments are conducted at the required frequency.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have a documented security monitoring policy?
Question 2: Are logs from all critical systems being collected and reviewed?
Question 3: Are alerts configured for critical security events?
Question 4: Are vulnerability scans conducted regularly?
Question 5: Are monitoring processes reviewed and updated annually?
⚠️ Common Mistakes (What Auditors Flag)
1. Incomplete logging
2. Lack of alerts
3. Ignoring scan results
4. No documentation
5. Inadequate training
📚 Parent Policy
This practice is governed by the Assessment, Authorization, and Monitoring Policy