Your System Security Plan is a Level 2 requirement in its own right (NIST SP 800-171 3.12.4), and CA.L2-3.12.4 is one of six requirements that may never be on a POA&M (32 CFR 170.21(a)(2)(iii)). The SSP is not a checkbox exercise. It is the document that describes how your organization implements the 110 security requirements in NIST SP 800-171 Rev. 2, and it has to agree with the evidence behind each one.
This guide breaks down what goes into a CMMC SSP, section by section, so you can build one that reflects your actual security posture rather than a fantasy version of it.
What is a System Security Plan, and why does CMMC require one?
A System Security Plan is a formal document that describes how your organization protects Controlled Unclassified Information (CUI). Under CMMC Level 2, your SSP maps directly to the 110 security requirements in NIST SP 800-171. It is not a policy manual and not a network diagram. Requirement 3.12.4 asks it to describe system boundaries, environments of operation, how the security requirements are implemented, and relationships with or connections to other systems. NIST prescribes no format (NIST SP 800-171 Rev. 2, 3.12.4, footnote 28).
The SSP also carries your scope. Under 32 CFR 170.19, the treatment of CUI Assets, Security Protection Assets, Contractor Risk Managed Assets and Specialized Assets is documented in the SSP, as is the use of any External Service Provider. An assessor reads what your SSP says you do and then asks for the evidence.
Test your SSP against three questions:
- Accuracy: does the SSP describe what you actually do, not what you wish you did?
- Completeness: does every required control have a narrative that addresses the requirement?
- Specificity: are the descriptions specific to your environment, or could they apply to any company on earth?
A vague SSP is hard to check against evidence, for your own team and for anyone who assesses it.
Seven sections that cover what 3.12.4 asks for
NIST SP 800-171 does not prescribe an SSP format. These seven sections are one practical way to convey what 3.12.4 asks for; the first, second, third and fifth map to its four elements.
1. System identification and boundaries
Define what is in scope. Identify your CUI environment by name, describe the types of CUI you handle, map every data flow where CUI moves, and include boundary diagrams that show where your CUI environment begins and ends. Scoping too broadly brings more assets into scope than you need to protect. Define a clear CUI enclave, segment it from your general business network, and document the boundaries precisely.
2. System environment and architecture
Document every component that touches CUI: hardware inventory, software inventory, network topology, and cloud infrastructure. Under 32 CFR 170.19(c)(1), CUI Assets, Security Protection Assets, Contractor Risk Managed Assets and Specialized Assets are each documented in the asset inventory, so the inventory and the SSP need to agree.
3. Security control implementation
This is the heart of your SSP. For each of the 110 NIST 800-171 controls, write a narrative explaining how you implement that control in your specific environment. Per-control narratives are more thorough and easier to check against evidence. Grouped narratives organized by control family are faster to write but create gaps unless you are disciplined about coverage. Every narrative should answer four questions: what do we do, how do we do it, what tools or processes support it, and who is responsible for it?
Not sure how many of the 110 controls you actually meet today? A free 10-question gap check gives you a directional self-assessment (not an official SPRS score) before you write a single narrative.
Run the free gap check →4. Roles and responsibilities
Define who owns what: the system owner, the information system security officer, control owners for each family, and the executive with final authority. If your SSP says everyone is responsible for security, nobody is.
5. Interconnections and information sharing
Document every external system that connects to your CUI environment: cloud service providers and whether you inherit controls from them, third-party managed security services, partners you share CUI with, and external integrations. For each, describe the data exchanged, the protections in place, and any agreements that govern the connection.
6. Incident response and contingency planning
Cross-reference your Incident Response Plan and Business Continuity Plan rather than duplicating them. Describe how those processes integrate with your security posture, including escalation procedures for CUI incidents and recovery objectives for CUI systems. Confirm your specific cyber-incident reporting obligations under your DFARS contract clauses against current DoD guidance.
7. Ongoing monitoring strategy
CMMC is not a point-in-time certification you pass and forget. Describe how you maintain compliance between assessments: how often you review control implementations, what monitoring tools you use, how you track and remediate new vulnerabilities, your process for updating the SSP when the environment changes, and your schedule for internal assessments.
Common SSP mistakes
- Copy-paste from templates without customization. A generic narrative does not describe your implementation. Templates are starting points, not finished products.
- Missing or vague control narratives. Writing that you "implement access controls" is not a narrative. Describing how you configure role-based access with conditional access policies for CUI resources is. Specific narratives are the ones evidence can confirm.
- Not reflecting actual implementation. If your SSP says you enforce MFA everywhere but your VPN still uses single-factor authentication, the evidence will contradict the SSP. Your SSP must describe reality, including POA&Ms for controls not yet fully implemented.
- Ignoring inherited controls. If you use a FedRAMP-authorized cloud provider, some controls are inherited. Your SSP must clearly identify which controls are inherited, which are shared responsibility, and which are fully yours.
How AaaS platforms help you manage the SSP
Writing and maintaining an SSP by hand is real work. For small and mid-size contractors without a dedicated compliance department, keeping the SSP current as the environment changes is the hard part. That is the problem Agent-as-a-Service (AaaS) providers are built to solve, by giving your team operational leverage rather than adding headcount.
- AI-assisted control mapping and narrative drafting. Instead of starting from a blank template, the platform drafts a narrative for every requirement from measured findings where a connected cloud shows them and from your team's attestations where it cannot, and shows the evidence on file behind each determination; a requirement with no evidence is never marked met, and under the default Rev. 2 target it is scored not met. ElasticD3M staff do not review the drafts; your team reviews them, and your Affirming Official makes the decisions.
- Updates on a stated schedule. When a connected cloud's configuration changes, the next re-scan (about every seven days) records the drift it can observe, and the SSP is rebuilt on your tier's cycle. On-prem servers and firewalls are recorded from your evidence.
- Documentation kept current. Instead of a scramble before your assessment, your SSP is rebuilt on a stated cycle and reflects your environment as of its last measurement.
This is not about replacing your compliance team. It is about giving the people responsible for compliance the tools to manage the process efficiently, while the decisions about your security program, and what gets affirmed, stay with your people.
If your SSP is not started, not current, or built on a generic template, a first step is to see where you actually stand. The free gap check gives a free first read, and the $999 CMMC Level 2 Readiness Snapshot maps your posture from your intake and any source you connect.
Source: NIST SP 800-171 Rev. 2, requirement 3.12.4; 32 CFR 170.14, 170.19 and 170.21. This article is general guidance, not legal or compliance advice. Confirm regulatory citations against current NIST and DoD publications.