Most contractors treat the System Security Plan (SSP) as a formality. Write it once, get it signed off, file it away, move on to the next issue. That assumption is wrong, and it is wrong in a way that costs real money later. The SSP is not paperwork that documents a program. Under our doctrine, it anchors the seventy percent of the program that is documentation, not technology, and it is the single artifact an assessor leans on hardest in a CMMC Level 2 assessment.
The Cybersecurity Maturity Model Certification (CMMC) framework does not grade a contractor on intentions. It grades them on evidence, and the SSP is where much of that evidence gets organized, cross-referenced, and made legible to a stranger who has never set foot in the building.
Get the SSP right and every other artifact in the program has somewhere to attach. Get it wrong and even a well-run technical environment fails.
What Contractors Get Wrong About the System Security Plan (SSP)
The mistake starts with the word “plan.” A plan sounds like something you write in advance and revisit later if things change. A System Security Plan under NIST 800-171 is not that.
It is a live, specific description of the environment as it actually exists today: the system boundaries that define what is in scope, the information systems inside those boundaries, and the security controls implemented, as of a given date, to protect the Controlled Unclassified Information (CUI) and sensitive data those systems touch.
We do not write System Security Plans to the 110 controls in NIST SP 800-171. We write them to the 320 assessment objectives underneath those controls, because that is what a C3PAO actually assesses.
A contractor who treats the SSP as a narrative summary of their security posture, rather than a specific, evidence-backed answer to each objective, is building a document that will not survive contact with an assessor. We laid out what a CMMC Level 2 assessment actually requires in our earlier post on the subject; the SSP is where that requirement gets written down in enough detail to prove.
The security requirements in NIST SP 800-171 were never meant to be read in isolation from the environment they apply to. The NIST 800-171 controls describe what has to be true. The SSP is the only place that says, specifically, how it is true for this contractor’s information systems, this contractor’s CUI boundary, and this contractor’s people.
A generic answer to a specific requirement is not a smaller version of compliance. It is the absence of it.
What Actually Has to Be in One
An SSP that will hold up in front of an assessor covers a specific, non-negotiable set of ground. Not a summary of each area. A specific, current, evidence-backed answer for each one.
System boundaries and information systems. What is in scope, what is explicitly out of scope, and why. This is the single most consequential section in the document, because every other section inherits whatever boundary decision gets made here.
Get it wrong and you are either protecting information that never needed that level of protection, or leaving CUI outside a boundary that was supposed to cover it.
Security controls, control by control. Not “we have access control.” Which access control mechanisms, on which systems, configured how, verified when.
Roles and responsibilities. Who owns each control, who executes it, who reviews it. An SSP that does not name actual people by role is an SSP that will not survive the first interview question about who is actually responsible for a given control.
Incident response plans, and what the SSP has to prove about them. Not the full plan copied into the SSP word for word, but a specific description of how those requirements are met, pointing to the real plan behind it.
Not a generic template referenced once and forgotten. A response plan tied to the actual systems, the actual CUI boundary, and the actual people named earlier in the document.
The Watch Bill Behind the SSP
Under our operating doctrine, the SSP does not stand alone. It is one half of the two governing artifacts we run every engagement against. The Watch Bill is the other half: the assignment of a named owner, executor, and reviewer to every assessment objective, so that “who owes the answer” is settled before an assessor ever asks the question.
A System Security Plan without a Watch Bill behind it tends to describe a program nobody is actually running day to day. The document says a control exists.
Nobody can say, on the spot, who checked it last, who would notice if it broke, or who is accountable for keeping it that way between now and the next recertification cycle. That gap does not usually show up until the assessment, and by then it is expensive to fix on the clock.
Why the Documentation Carries the Program
Roughly seventy percent of CMMC compliance is documentation, not technology. That proportion is not a rough guess. It is the doctrinal observation our whole practice is built on.
That seventy percent describes the whole Logbook, not the SSP alone: the System Security Plan, the policies, the procedures, the evidence locker, the screenshots and change tickets that back all of it up. The SSP is not where most of that seventy percent physically lives. It is the anchor document the rest of the Logbook ties back to, and the one an assessor typically opens first.
A contractor who has spent ninety percent of their CMMC budget on firewalls and endpoint tools and ten percent on the documentation that proves those tools are configured correctly has built an upside-down program, no matter how good the technology stack looks.
This is also where “cmmc documentation” stops being an abstract compliance concept and becomes a specific deliverable with a specific standard. Good CMMC documentation is not a binder that exists to be shown to an assessor once.
It is the operating record, and the risk managed as part of this process is documented inside the CUI boundary, updated as the environment changes, not rewritten from scratch every time a recertification cycle comes around. Contractors who understand this the first time meet the requirements roughly twice as fast as contractors who treat the SSP as a one-time writing exercise and then let it go stale.
The Sections Assessors Actually Read Closely
Not every section of a System Security Plan gets equal scrutiny. In our experience running readiness work ahead of formal CMMC assessments, three sections draw the most follow-up questions, and they are the same three sections most contractors under-invest in.
The access control section, because it is where the gap between “we have a policy” and “we have a configured, verified control” shows up fastest. The roles and responsibilities section, because an assessor testing a control will frequently ask who owns it, and a document with no named owner reads as a document nobody actually operates. And the incident response section, because it is the section most often copied wholesale from a template and never adapted to the contractor’s actual information systems.
None of these are technically difficult to fix. They are simply the sections that get written last, rushed, and treated as boilerplate, which is exactly why they are the sections that fail first.
Who Should Actually Be Writing It
We see a lot of SSPs written by whoever had the most free time that quarter, or by a well-meaning IT lead who has never sat through a CMMC assessment. That is a mistake, and it is one we discussed at length in our post on the difference between an advisor, a consultant, and a C3PAO: the person writing your SSP should understand exactly how a C3PAO reads it, because they are the ones who will eventually have to defend it in the room.
Under our Two-Person Team model, a Certified CMMC Assessor or Professional owns the interpretation of every assessment objective, and a technical writer owns turning that interpretation into a document a stranger can pick up and verify. That pairing exists because the two skills rarely live in the same person, and a document written by only one half of that pairing tends to be either technically accurate and unreadable, or readable and technically wrong.
The Bottom Line on CMMC Documentation
The Department of War, still called the Department of Defense (DoD) by most of the industry, is not grading your System Security Plan on effort. It is grading it against 320 specific assessment objectives, in CMMC assessments run the same way every time, by an assessor who has read hundreds of these documents and knows exactly what a rushed one looks like.
Contractors who understand the SSP as the operating record of their program, not a formality attached to their CMMC certification, spend less over the life of the program and pass more often on the first attempt. Contractors who treat it as paperwork spend more, twice: once to write it badly the first time, and again to rebuild it correctly before the next recertification cycle.
The 70% Logbook principle is not a slogan. It is the most literal, practical piece of advice in this entire doctrine, and it starts with the document most contractors are still treating as an afterthought.
