144 CMMC
144 CMMC
The structure of a System Security Plan that holds up under review — and the mistakes that get them sent back.
Every contractor pursuing CMMC Level 2 needs a System Security Plan (SSP). Most first drafts get returned for the same handful of reasons. This guide explains what the SSP must contain, what a C3PAO assessor is actually looking for when they pick it up, and the template structure that survives review.
A System Security Plan is the document that describes how your organization implements each of the 110 controls in NIST SP 800-171 Revision 2. It's required by the standard itself (NIST 800-171 control 3.12.4: “Develop, document, and periodically update System Security Plans”) and it's the first document a CMMC Level 2 assessor will ask for.
The SSP is not a policy document. It doesn't say what you intend to do or what your aspirational posture is. It describes the system you actually have today and how each control is genuinely implemented in that system. If you can't say how a control is implemented, the SSP must say so — and you put the fix in your Plan of Action and Milestones (POA&M).
An SSP is also a living document. Networks change, tools change, staff turn over. The plan you submitted last quarter probably needs an update this quarter.
NIST 800-171A (the assessment procedures companion) and the DoD's CMMC assessment guidance both expect the SSP to cover these sections at minimum:
A C3PAO assessor reads dozens of SSPs a year. The ones that pass on first review share several traits.
Weak control description: “Acme implements multifactor authentication for privileged accounts.”
Strong control description: “All privileged accounts (defined as accounts with administrative access to the ACME-DC1 domain controller or the production NAS) require multifactor authentication via Duo Push. Enforcement is configured at the Azure AD conditional access policy named ‘Acme-Admin-MFA’ (last reviewed 2026-04-15). Compliance is logged to Azure AD sign-in logs and reviewed monthly by the IT lead.”
The second version names the tool, the policy, the enforcement point, the scope, and the review cadence. An assessor reading the second version can verify it in five minutes.
The SSP doesn't have to embed every policy document. But every control claim should point to where the proof lives — e.g., “See AcmeIT/Policies/Authentication-Policy-v3.docx” or “See Azure AD conditional access policy Acme-Admin-MFA.” This is exactly what the 144 evidence register is built for: a one-stop list of what your proof is and where it lives, without storing the file itself.
Marking everything “Met” in an SSP is the fastest way to lose credibility with an assessor. Real environments have gaps. The SSP that says “3.13.8 is not currently met — see POA&M item 14 (target completion Q3 2026)” reads as professional. The SSP that claims FIPS-validated cryptography on every endpoint when half the laptops are running consumer Windows reads as either careless or dishonest.
Every section should be dated. The whole document should have a clear version number and last-reviewed date. Assessors will check whether the SSP has been updated since the network or staffing changes that they know about from your interview.
The single fastest disqualifier is an SSP that contradicts what the assessor sees during the on-site or remote inspection. If the SSP says “all endpoints run Crowdstrike Falcon” and the laptop on the desk has Defender, the assessor stops trusting the document.
Here's a section-by-section structure that holds up. You can write this in Word, Google Docs, or any tool that produces a clean PDF.
Describe the system in plain language. Two or three paragraphs. What does it do? Who uses it? What CUI does it handle? Then explicitly state the boundary — the line between systems that are in scope for CMMC and systems that are out of scope (e.g., personal devices, BYOD, separate corporate network without CUI).
List the major hardware, software, and network components. Include a simple network diagram. The diagram doesn't have to be Visio-grade — a clean sketch in any tool works. The point is to show the assessor where data flows.
Describe what kinds of CUI you handle. Be specific: “Engineering drawings under ITAR” vs “Unclassified performance data not marked ITAR” matters. Note where the CUI lives, how it's transmitted, and how it's protected at rest.
This is the bulk of the document — one entry per NIST 800-171 control. For each control:
A consolidated list of the policies, procedures, and configurations referenced throughout the control section. Each item should have a current owner, a last-reviewed date, and a pointer to where it lives in your filing system.
The POA&M is its own document, but the SSP should explicitly reference it and confirm that every Partial or Not Met control is tracked there.
The most common reasons SSPs get sent back:
You can write an SSP by hand. Many small contractors do, and the result is usually a 40-60 page document that takes a few weeks of evenings. Or you can use a tool that generates the SSP from a structured self-assessment.
That's exactly what 144 does: as you walk through each of the 110 controls and mark them Met / Partial / Not Met / N/A in the assessment, the app builds an SSP draft you can print or export. Every control's status and statement are populated automatically, with your org name, point of contact, and logo on the header. You still need to write the specific implementation descriptions — the generic ones won't pass an assessor — but the structure, identification section, family ordering, and POA&M cross-reference are all done for you.
It's $149/month, self-serve, no consultants required. Start with the free SPRS calculator to see your score, then upgrade if you want the SSP, POA&M, and Executive brief generated automatically.
Score all 110 controls, get a branded SSP and POA&M draft, and a prioritized roadmap to close the gaps. $149/month, self-serve.