Writing a CMMC System Security Plan (SSP) That Survives Assessment

The System Security Plan is the one document a CMMC assessment cannot proceed without. Not figuratively: the scoring rule in 32 CFR 170.24(c)(2) says the absence of an up-to-date SSP at assessment time results in a finding that the assessment “could not be completed due to incomplete information.” The same logic has applied to SPRS self-assessments since the DoD Assessment Methodology. And CA.L2-3.12.4 sits on the short list of requirements that can never ride a POA&M. There is no partial credit for a missing SSP and no deferring it. It is the entry ticket.

Which raises the practical question this post answers: what does an SSP that survives assessment actually contain, and where do they fail?

What 3.12.4 requires, in the assessor’s terms

The requirement itself: “Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.” NIST is explicit that no format or level of detail is prescribed, which sounds liberating until you read 800-171A, where 3.12.4 decomposes into eight determination objectives, [a] through [h]: a plan exists; the boundary is described; the environment of operation is described; requirements marked non-applicable are identified as such by an authorized authority; the method of implementation is described for each requirement; relationships and connections to other systems are described; an update frequency is defined; and the plan is actually updated on that frequency.

Every objective must be met for the requirement to be met, and in a Level 2 certification assessment the C3PAO works from 800-171A directly (32 CFR 170.17). One not-met objective fails the whole requirement. Objectives [g] and [h] are the quiet killers: plenty of shops have an SSP; fewer can show a defined review cadence with dated evidence that it happened.

Why the SSP anchors everything else

Three regulatory hooks make the SSP the spine of the assessment record. The assessment record itself must capture the SSP’s name, date, and version. If you use a cloud provider for CUI, the customer responsibility matrix must be documented or referenced in the SSP. If you use an external service provider at all, that use gets documented in the SSP too (all in 170.17(c)). Assessors read the SSP first and test your environment against what it claims. That is also exactly why the most dangerous SSP is a beautiful one that describes an environment you do not have.

How SSPs actually fail

Assessor commentary from the first year of the phased rollout is remarkably consistent. A-LIGN’s Mike Gallagher describes organizations walking through their CUI flow in conversation and having it not match the SSP. Prescient Security’s Sammy Chowdhury says assessors immediately spot templated, boilerplate, AI-generated SSPs, and reports roughly a third of organizations failing readiness on that class of problem. Insight Assurance’s Adam Glover flags Security Protection Assets, the identity provider, the scanner, the MDM, the ticketing system, left out of asset categorization entirely. Add the perennials: aspirational statements written in future tense, policy language pasted where implementation detail belongs, and an SPRS score that does not match what the document supports.

Notice what is not on that list: nobody fails for formatting. They fail for describing an imaginary environment, for skipping the boundary and asset work, and for writing “we will” where an assessor needs “we do, and here is the record.”

The pattern that survives

Write one implementation statement per requirement, and make each statement answer the 800-171A objective letters for that requirement, in present tense, describing current state. Name the mechanism (what enforces it), the owner (who runs it), and the record (what evidence it produces, referenced by document ID or system name rather than pasted in). Keep the boundary section honest and diagrammed: what is in scope, the five asset categories from the Level 2 scoping guide, and every connection to other systems. Document your ESP and CSP relationships with a real shared-responsibility breakdown, because 170.17 requires it and assessors have learned to look. Define a review cadence you will actually keep, then keep it, with dated review records.

Two coherence checks before anyone external sees it. First, SPRS: DFARS 252.204-7019 requires a Basic Assessment score on file not more than three years old, and your posted score, your POA&M, and your SSP need to tell one consistent story. Second, POA&M eligibility: under 170.21, certification with a POA&M requires scoring at least 88 of 110, only 1-point requirements are deferrable (with a narrow FIPS exception), six requirements are never deferrable, and the closeout window is 180 days. An SSP that quietly leans on ineligible POA&M items fails the coherence test before the assessor arrives.

The Mac-specific paragraph your SSP needs

If your fleet is Apple-first, the environment-of-operation section should say so in the same breath it names the management plane: Apple Business Manager with supervised Automated Device Enrollment, the MDM that enforces configuration, FileVault with escrowed recovery keys for CUI at rest, and your baseline source (for most Mac shops, mSCP-derived profiles). Then be precise where Mac shops are usually vague: the FIPS claim. Name the corecrypto module and CMVP certificate numbers for the macOS versions you pin, because SC.L2-3.13.11’s scoring turns on validation, not on FileVault being switched on. The FIPS deep-dive covers exactly how to write that claim chain.

A sane order of operations

Scope and categorize assets first, because the boundary determines everything downstream. Fill your asset inventory and shared responsibility matrix before writing implementation statements; the statements get dramatically easier once those exist. Write per-requirement statements against the 171A objectives. Log every gap you find as a POA&M item with an owner and a date instead of softening the SSP language to hide it. Then put the SSP on a review cadence and generate the dated records that objectives [g] and [h] will be assessed against.

Educational content, not legal or assessment advice. Regulatory citations were verified against eCFR, NIST, and DoD sources in July 2026.