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, and it is the only one with no point value. Under the DoD Assessment Methodology, a missing SSP means the assessment cannot be completed, and without a completed assessment you have no SPRS score to post.
Our free CMMC Calculator follows the same rule and treats the SSP as a precondition with no point value, since there's no arithmetic to do on a program that can't be assessed. The controls, policies, and remediation sprints in the rest of your program all build on this one document.
What a real SSP contains
Many SSPs fail because they were written to check a box and never described the actual system. A real SSP does five jobs.
First, it draws the authorization boundary: what's in scope, what's out, and where the line runs. No section affects more of the assessment, because every control applies to everything inside that line.
Second, it addresses each of the 110 requirements individually, saying how the requirement is implemented in your environment or stating honestly 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.
A living document that assessors test against reality
An SSP has to stay true for as long as the system runs. C3PAO assessors build their interviews and evidence requests around it: they read what you wrote, then verify it by pulling the configuration, watching the process, and asking the named owner. Any mismatch between the document and the environment is a likely finding. Here is what they expect to see.
- A boundary they can trace, naming specific systems, networks, and enclaves instead of "our network." If the diagram and the boundary narrative disagree, expect questions.
- Implementation statements in the present tense. "We will deploy" belongs in a plan of action, and future-tense wording 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 owners, with roles and responsibilities that match the org chart, so interviews reach the people who actually run the controls.
- A revision history. A document last edited two years ago suggests nobody maintains it, and it invites the assessor to test every claim in it.
The failures we see over and over
Almost every SSP that wouldn't survive assessment has some mix of the same problems: 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 in the future tense; and no revision history, so nobody can say when the document last matched reality.
These problems are common, and they come from treating the SSP as paperwork when it should be the working description of your environment. Fix them by giving the document an owner, a review cadence, and a change process. Our compliance system is built to keep the SSP current, and the free readiness checklist will tell you quickly whether yours has the basic structure it needs.
If you have a template-shaped document and a real assessment date, start with a gap assessment. We begin with the SSP review because the assessor will too.
Would your SSP survive an assessor reading it line by line?
A practitioner will read your SSP the way a C3PAO will, starting with the boundary and then checking implementation statements against reality, and give you a prioritized fix list. Or email rj@indirectit.com directly.