If a contractor asks which single document matters most for DFARS and CMMC compliance, the answer is almost always the System Security Plan. It's the control auditors check first, the basis of your SPRS score, and — increasingly — the document the government points to when a compliance representation turns out to be false.
The System Security Plan (SSP) is not paperwork you generate after you're compliant; it is the artifact that defines what "compliant" even means for your environment. NIST SP 800-171 makes the SSP its own requirement — control 3.12.4, mapped in CMMC Level 2 as CA.L2-3.12.4 — and every other control's implementation status is judged against what your SSP says. Get the SSP wrong and everything downstream, from your self-assessment score to your annual affirmation, inherits the error.
What the SSP Actually Has to Contain
Control 3.12.4 requires contractors to "develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems." In practice that means four things your SSP must pin down: the boundary of the system that stores, processes, or transmits Controlled Unclassified Information; the operating environment (on-premises, cloud, hybrid, remote users); how each of the applicable NIST SP 800-171 requirements is implemented in that environment; and the external connections and service providers — managed service providers, cloud platforms, subcontractors — that touch the same information.
There is no mandated format and no prescribed page count. NIST is explicit that the SSP can be a collection of documents rather than one file, and can reference existing policies and procedures instead of restating them. What NIST does not permit is vagueness: the plan has to contain enough detail that someone could implement the environment as described and that an assessor could determine whether reality matches the document.
Why the SSP Is the Linchpin of Everything Else
Under DFARS 252.204-7012, DoD contractors handling covered defense information must implement NIST SP 800-171, and under DFARS 252.204-7019/7020 they must post a summary self-assessment score to the Supplier Performance Risk System (SPRS). That score is calculated directly against the SSP — each unmet requirement subtracts points from a starting 110. If your SSP overstates what you've implemented, your SPRS score is wrong, and the affirmation you submit alongside it is wrong too. (For how that scoring works, see our explainer on the SPRS score and DFARS 7019/7020.)
This is also where the SSP intersects with enforcement. The Department of Justice's Civil Cyber-Fraud Initiative has repeatedly premised False Claims Act settlements not on data breaches but on misrepresentations — contractors certifying implementation their SSP and systems didn't support. An accurate SSP that honestly documents gaps (and pairs them with a Plan of Action and Milestones) is defensible. An SSP that describes controls the contractor never actually deployed is the paper trail an enforcement action is built on.
The Common Failure Mode
The most frequent SSP mistake is not a missing document — it's a stale or aspirational one. Contractors download a template, describe the security program they intend to have, and never reconcile it with what's actually running. Two years later the SSP describes multi-factor authentication that was never fully rolled out and a boundary that no longer reflects where CUI actually lives. Because 3.12.4 requires the SSP to be periodically updated, that drift is itself a control failure — and it makes every representation resting on the SSP unreliable.
Notably, the SSP is one of the controls a contractor cannot defer with a POA&M. Not having a documented, current SSP blocks any conditional compliance status outright; it is a threshold requirement, not a fixable-later gap.
Key Takeaways
- The SSP is a required control, not just documentation. NIST SP 800-171 control 3.12.4 (CMMC CA.L2-3.12.4) demands a current plan describing your boundary, environment, control implementation, and external connections.
- Your SPRS score and your affirmations are only as accurate as your SSP. Because the self-assessment is scored against the plan, an inflated SSP produces a false score — the exact fact pattern DOJ has pursued under the False Claims Act.
- Keep it current, or it becomes a liability. A stale, aspirational SSP is a control failure in its own right and undermines every compliance representation built on it; unlike most controls, a missing SSP can't be papered over with a POA&M.
Start by confirming which framework and level apply to your contracts with Find My Requirements, work through the control-by-control detail on Frameworks, and use our checklists and program-building guide to keep your SSP tied to what's actually running in your environment.
---
This article is educational information about federal procurement and cybersecurity requirements. It is not legal advice, and it does not create an attorney-client relationship.
Primary source: NIST SP 800-171, security requirement 3.12.4 (System Security Plan), implemented for defense contractors through DFARS 252.204-7012 and assessed as CA.L2-3.12.4 under the CMMC Program (NIST SP 800-171).