Develop, document, and periodically update system security plans
📖 What This Means
This practice requires organizations to create, maintain, and regularly update a System Security Plan (SSP). An SSP is a comprehensive document that outlines how your organization implements its security controls to protect sensitive information. It serves as a roadmap for your security posture, detailing the policies, procedures, and technologies in place. For example, if your organization handles Controlled Unclassified Information (CUI), the SSP would describe how access is restricted and monitored. Regularly updating the SSP ensures it reflects current security measures and any changes in the environment, such as new software or hardware. Think of it as a living document that evolves with your organization's security needs.
🎯 Why It Matters
Without a documented and updated SSP, organizations risk having gaps in their security controls, leaving them vulnerable to cyberattacks. For instance, a defense contractor without an SSP might fail to properly secure CUI, leading to a data breach like the 2020 SolarWinds incident, which exposed sensitive government data. The Department of Defense (DoD) emphasizes this practice because it ensures contractors have a clear, consistent approach to protecting CUI. A well-maintained SSP not only helps prevent breaches but also demonstrates compliance during audits, avoiding costly penalties or loss of contracts.
✅ How to Implement
- 1. Identify all cloud assets and services (e.g., AWS S3 buckets, Azure Virtual Machines).
- 2. Document the security controls applied to each asset (e.g., encryption, access policies).
- 3. Use cloud-native tools like AWS CloudTrail or Azure Monitor to track changes and ensure controls are active.
- 4. Integrate the SSP with your cloud provider's security documentation.
- 5. Schedule quarterly reviews to update the SSP with any new cloud services or changes.
- 6. Use tools like Terraform to automate and document infrastructure-as-code configurations.
- 7. Ensure SSP aligns with cloud compliance frameworks (e.g., FedRAMP, SOC 2).
📋 Evidence Examples
System Security Plan (SSP) Document
Inventory of Systems and Assets
Vulnerability Scan Reports
Training Records
Change Management Logs
📝 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.4 ("Develop, document, and periodically update system security plans"), 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.4 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to develop, document, and periodically update system security plans. 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.4 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to develop, document, and periodically update system security plans. 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.4 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, document, and periodically update system security plans 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.4
- 📄 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 System Security Plan (SSP)?
Question 2: Does the SSP cover all systems and assets?
Question 3: Is the SSP updated quarterly?
Question 4: Does the SSP include vulnerability scan results?
Question 5: Are employees trained on SSP procedures?
⚠️ Common Mistakes (What Auditors Flag)
1. Incomplete SSP coverage.
2. Outdated SSP.
3. Missing vulnerability scan results.
4. No employee training records.
5. Inconsistent formatting.
📚 Parent Policy
This practice is governed by the Assessment, Authorization, and Monitoring Policy