The CMMC System Security Plan, without hosting your network data

NIST SP 800-171 Revision 2 requirement 3.12.4 states it in one sentence: "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." Four content elements, and each one is structural rather than boilerplate:

The accompanying NIST discussion is deliberately flexible about form. It notes that "there is no prescribed format or specified level of detail for system security plans" and that "security plans need not be single documents; the plans can be a collection of various documents including documents that already exist." What matters is substance: the plan must "contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans." Federal agencies may treat submitted system security plans as critical inputs to the risk decision of letting a nonfederal system process, store, or transmit CUI at all.

In the CMMC scoring methodology at 32 CFR 170.24, every Level 2 requirement carries a point value of 1, 3, or 5, except one. The System Security Plan, CA.L2-3.12.4, has no point value at all: if the organization cannot produce an up-to-date SSP, the assessment "could not be completed due to incomplete information." You do not lose points for a missing SSP; you lose the assessment.

The POA&M rules reinforce that status. 32 CFR 170.21 lists six requirements that may never appear on a Plan of Action and Milestones, and the SSP is one of them. There is no "we will write the SSP later" path: it must exist, and be current, before an official assessment can conclude. For how POA&M limits work overall, see CMMC Level 1 vs Level 2.

Take the four required content elements together and the finished document is a targeting package: which systems hold CUI, where their boundaries sit, what the environment looks like, which defenses exist for each requirement and where they are weak, and every connection into and out of the environment. That is exactly the information an attacker wants and exactly the information a contractor should be most reluctant to copy into third-party platforms.

Compliance tooling usually asks you to do just that: fill hosted forms with real system names, network detail, and connection inventories so the tool can render your SSP. Every copy of that data in someone else's SaaS platform expands your attack surface and becomes part of your vendor-risk story with primes and assessors.

The flexibility NIST built into 3.12.4 makes a different pattern possible. Because there is no prescribed format, an SSP can be drafted as a structured skeleton in which every system, vendor, and connection is an alias: "File Server A," "Cloud Provider 1," "External Connection 2." The hosted draft carries the structure that takes real effort to build: the four content elements, per-family implementation narratives for the 110 requirements, and consistent terminology across the binder. The sensitive substitutions happen in your exported copy, in your own environment, guided by a local completion worksheet that lists exactly what to fill in:

This is how the CMMC System Security Plan document in Security Binder works. The hosted skeleton supports, but does not constitute, the system security plan CA.L2-3.12.4 requires: it becomes that plan only after you complete it locally with real system identifiers, network detail, and connection specifics. Security Binder never hosts that detail, by design. The same drafting model applies to the companion CMMC POA&M document, and you can see what alias-based, watermarked exports look like on the samples page.