Develop and implement plans of action designed to correct deficiencies and reduce vulnerabilities
π What This Means
This practice requires organizations to create and execute Plans of Action and Milestones (POA&Ms) to address identified security weaknesses and reduce vulnerabilities. Essentially, when a security assessment or vulnerability scan reveals issues, you need a structured plan to fix them. This plan should outline what needs to be done, who is responsible, and when it will be completed. For example, if a server is found to have outdated software, the POA&M would detail the steps to update it, assign the task to the IT team, and set a deadline. This ensures that vulnerabilities are not just identified but actively resolved, maintaining a strong security posture.
π― Why It Matters
Failing to address vulnerabilities can lead to data breaches, system compromises, and regulatory penalties. For instance, the Equifax breach in 2017 was caused by an unpatched vulnerability, resulting in the exposure of 147 million records and costing the company over $1.4 billion. From the DoD/CMMC perspective, this control is critical because it ensures that defense contractors continuously improve their security measures, reducing the risk of sensitive defense information being compromised. Itβs not just about finding problems but ensuring they are systematically fixed to protect Controlled Unclassified Information (CUI).
β How to Implement
- Identify vulnerabilities using cloud-native tools like AWS Inspector, Azure Security Center, or GCP Security Command Center.
- Create a POA&M document in your cloudβs project management tool (e.g., Jira, Trello) or spreadsheet.
- Assign remediation tasks to specific team members with clear deadlines.
- Use cloud automation tools (e.g., AWS Systems Manager, Azure Automation) to apply patches or updates.
- Monitor progress through dashboards in your cloud providerβs security console.
- Conduct follow-up scans to verify issues are resolved.
- Document all actions in your POA&M and update your security policies as needed.
π Evidence Examples
POA&M Document
Vulnerability Scan Report
Remediation Records
Security Policy Update
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.2 ("Develop and implement plans of action designed to correct deficiencies and reduce vulnerabilities"), 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.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to develop and implement plans of action designed to correct deficiencies and reduc.... 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.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to develop and implement plans of action designed to correct deficiencies and reduc.... 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.2 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 develop and implement plans of action designed to correct deficiencies and reduce vulnerabilities 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.2
- π 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: Have you conducted a recent vulnerability scan?
Question 2: Have you documented identified vulnerabilities in a POA&M?
Question 3: Have you assigned remediation tasks to specific team members?
Question 4: Have you verified that vulnerabilities have been mitigated?
Question 5: Is your POA&M updated and maintained for audits?
β οΈ Common Mistakes (What Auditors Flag)
1. Incomplete POA&M documentation
2. Failure to prioritize vulnerabilities
3. Lack of follow-up scans
4. Unassigned or unclear responsibilities
5. Outdated security policies
π Parent Policy
This practice is governed by the Assessment, Authorization, and Monitoring Policy