No SSP, no score: the document that gates your entire CMMC program.

The one requirement with no point value

Requirement 3.12.4 of NIST SP 800-171 asks you to develop, document, and keep current a System Security Plan. It looks like one requirement among 110. It isn't. Under the DoD Assessment Methodology, a missing SSP doesn't subtract points — it means the assessment cannot be completed. No SSP, no assessment; no assessment, no SPRS score. You are not eligible for a number at all.

This is why our free CMMC Calculator treats the SSP as a gate, not a point value. There's no arithmetic to do on a program that can't be assessed. Everything else in your compliance effort — every control, every policy, every remediation sprint — sits downstream of this one document.

What a real SSP actually contains

The reason so many SSPs fail is that they were written to satisfy a checkbox, not to describe a system. A real SSP does five jobs:

It draws the authorization boundary. What's in scope, what's out, and where the line runs. This is the single highest-leverage section, because every downstream control applies to everything inside it.

It addresses each of the 110 requirements individually — how it's implemented in your environment, or an honest statement that it isn't yet. "Implemented via Group Policy X on systems Y" is an SSP entry. "We take security seriously" is not.

It also carries your network diagrams, defines roles and responsibilities (who owns which control, by name or role), and describes the environment itself — the systems, connections, and data flows that make the boundary concrete.

It's a living document — and assessors test it against reality

The SSP isn't a deliverable you finish; it's a description that has to stay true. When a certified assessor arrives, C3PAO assessors anchor their interviews and evidence requests to your SSP. They read what you wrote, then go verify it: pull the configuration, watch the process, ask the named owner. Every mismatch between the document and the environment is a finding waiting to be written up.

• A boundary they can trace. Specific systems, networks, and enclaves — not "our network." If the diagram and the boundary narrative disagree, expect questions.
• Present-tense implementation statements. "We will deploy" is a plan of action, not an implementation. Aspirational language in an SSP tells an assessor exactly where to dig.
• All 110 requirements addressed — including the ones you haven't implemented. An honest "not implemented" with a pointer to your plan beats silence every time.
• Named ownership. Roles and responsibilities that match the org chart, so interviews land on people who actually run the controls.
• A revision history. A document last touched two years ago is evidence that it's not living — and an invitation to test every claim in it.

The failure modes we see over and over

The same patterns show up in almost every SSP that wouldn't survive assessment: a purchased template that was never customized (the vendor's placeholder text is still visible if you know where to look); a boundary described so vaguely — "our network" — that scope can't be validated; controls written aspirationally in future tense; and no revision history, so nobody can say when the document last matched reality.

None of these are exotic problems. They're what happens when the SSP is treated as paperwork instead of as the operating description of your environment. The fix is structural: give the document an owner, a review cadence, and a change process. Our compliance system exists precisely to keep the SSP living instead of decaying, and the free readiness checklist will tell you quickly whether yours has the bones it needs.

If you're staring at a template-shaped document and a real assessment date, start with a gap assessment — the SSP review is where we begin, because it's where the assessor will.