An SSP should describe reality, not fiction

Most of the system security plans (SSPs) we're shown were written from a template. They're long, well formatted and confident. Every requirement reads as implemented. And when you walk the environment, a good part of what the document describes isn't there, or works differently, or is run by someone the plan never mentions.

That isn't a paperwork problem. It's the single most important document in your CMMC Level 2 readiness, and it's describing a company that doesn't exist.

The SSP is the one document you can't defer

Under the CMMC rule, you can reach a conditional Level 2 status with some gaps still open, provided they're listed on a plan of action and milestones (POA&M, itself NIST SP 800-171 requirement 3.12.2), your score is at least 80% of the maximum, and each open item is one of the lowest-weighted (1-point) requirements. Those items must then be closed and confirmed within 180 days. (32 CFR 170.21)

But the rule names a short list of requirements that may never be placed on a POA&M, and the system security plan (NIST SP 800-171 requirement 3.12.4, written CA.L2-3.12.4 in CMMC terms) is one of them. (32 CFR 170.21(a)(2)(iii)) You can't promise to write it later. It has to exist, and it has to be right, when you assess.

What "describing reality" looks like

A useful SSP answers plain questions with specifics:

• Where is the boundary? Which users, systems, locations and cloud services handle CUI, and which don't.
• How is each requirement met today? Not "the organization ensures…", but the setting, process or tool that actually does it, and where the evidence lives.
• Who does it? Your staff, your MSP or a cloud provider. If an external provider handles CUI or security protection data, the rule expects that relationship to be documented in your SSP. (32 CFR 170.19)
• What isn't done yet? Gaps belong in the POA&M with an owner, a milestone and a date. They don't belong hidden in optimistic prose.

Why template SSPs fail

Templates aren't the enemy; a good structure saves time. The problem is filling one in from the desk instead of from the environment. Three patterns come up again and again:

1. Aspirational language. Controls described as they would work once a project finishes.
2. Missing providers. The MSP, the cloud tenant and the security platform do half the work, but the plan reads as if the company does everything itself.
3. No link to evidence. Each statement should point to something you can show. If it can't, it's a claim, not a control.

Every one of these undermines the annual affirmation your senior official enters in SPRS, which states that your organization continues to meet the requirements. (DoD CIO, 32 CFR 170.4)

Keep it current, or it drifts back to fiction

An SSP written accurately in March can be wrong by September. People leave, systems change, providers swap tools. The plan has to be maintained alongside the POA&M, and reviewed against evidence on a schedule, so that each annual affirmation rests on something true.

That ongoing ownership is what the Fractional CMMC Program Lead provides. If you don't yet have an accurate starting point, the SSP & POA&M Buildout writes the plan from your assessed environment, and never describes a control the evidence doesn't support.

Sources

1. 32 CFR 170.21: Plan of Action and Milestones requirements (checked Nov 3, 2026)
2. 32 CFR 170.19: CMMC scoping (checked Nov 3, 2026)
3. 32 CFR 170.4: Acronyms and definitions (checked Nov 3, 2026)
4. NIST SP 800-171 Rev. 2: Protecting CUI in Nonfederal Systems and Organizations (checked Nov 3, 2026)
5. DoD CIO: About CMMC (checked Nov 2, 2026)

General information, not legal advice. Your contracts decide which requirements apply to you.