What an SSP is, a section-by-section walkthrough mapped to 800-171A objectives, the rejections assessors flag most, and an SSP template outline.
A System Security Plan (SSP) is the document that describes your information system, its boundary, and exactly how you implement each security requirement that applies to it. For defense contractors, that means describing how you meet all 110 requirements of NIST SP 800-171 Rev 2 — the baseline the Department of War (DoW) assesses against for CMMC Level 2. The SSP is not a policy binder and not a marketing document. It is the single artifact a C3PAO assessor reads first, uses to plan the assessment, and checks every piece of evidence against. If your SSP is vague, the assessment goes badly before anyone looks at a firewall rule.
This guide walks the SSP section by section, maps each part to the 320 NIST SP 800-171A assessment objectives an assessor actually scores, shows the rejections that sink otherwise-solid plans, and gives you a realistic sense of how long it takes.
DFARS 252.204-7012 requires contractors handling Controlled Unclassified Information (CUI) to implement NIST 800-171 and maintain a System Security Plan describing that implementation. An SSP does three jobs:
What an SSP is not: a copy of the NIST 800-171 text with "we comply" pasted after each control. That is the single most common failure, and assessors spot it in minutes. An assessor is not asking whether you say you comply — they are asking how, and then verifying it.
A defensible SSP has a predictable structure. Here is what belongs in each section and — critically — how it connects to the 800-171A assessment objectives the assessor will score.
Name the system, its purpose, and its owner. State the categorization (for 800-171, you are protecting CUI). Keep it factual. This section rarely gets scored directly, but a sloppy one signals a sloppy plan.
Draw the boundary. What is in scope, what is out, and where does CUI enter, move, and rest? Include a data flow diagram. This is where scope decisions live, and scope decisions drive everything: a tighter, well-justified boundary (for example, a dedicated CUI enclave) reduces the systems you have to secure and the evidence you have to produce. Assessors challenge boundaries constantly — if you claim a component is out of scope, the SSP must justify why CUI never touches it.
Who owns security? Who administers systems, reviews logs, approves access? Name roles, not just "IT." Several 800-171A objectives ask you to identify the personnel or roles responsible for a given activity — this section is where you answer that in advance.
For each of the 110 requirements, describe your implementation. This is 80% of the document and where assessments are won or lost. For every requirement, 800-171A breaks it into assessment objectives (the discrete things that must all be true for the requirement to be "met"). Your implementation statement should address each objective, not just the headline requirement.
Weak (rejected): "3.1.1 — We limit system access to authorized users. Implemented."
Strong (defensible): "3.1.1 — Access to [system] is limited to authorized users via Active Directory group membership. Accounts are provisioned by [role] only after manager approval logged in [ticketing system]. The authorized-user list is reviewed [ODP-defined frequency] by [role]. Devices are enrolled in [MDM]; unenrolled devices are denied via [conditional access policy]. Evidence: AD group export, access-review records, MDM enrollment report."
The strong version names the mechanism, the responsible role, the frequency, and the evidence. That maps to how 800-171A actually scores: does the assessor have enough to determine each objective is met, and can they find the evidence?
The SSP describes; policies and procedures prescribe; evidence proves. Reference them by name and location so the assessor can trace a claim to a policy to an artifact without a scavenger hunt. Do not paste full policies into the SSP — reference them.
For any requirement not fully met, the SSP notes it and points to your Plan of Action and Milestones. The SSP and POA&M must agree: a requirement cannot be "implemented" in the SSP and "open" in the POA&M. Assessors cross-check these first.
After enough assessments, the same failures recur. Avoid these and you have already beaten most first-time submissions:
Contractors consistently underestimate this. An SSP is not a weekend project — it is a description of your entire security posture. Realistic effort, assuming you have someone who knows the environment:
| System complexity | Requirements to document | Realistic first-draft effort | What drives the time |
|---|---|---|---|
| Small, single enclave (few systems, one cloud) | 110 | ~40–80 hours | Boundary is simple; evidence is centralized |
| Mid-size (on-prem + cloud, multiple teams) | 110 | ~80–160 hours | Boundary complexity; chasing evidence across teams |
| Large / multi-boundary | 110 per boundary | 160+ hours | Multiple systems, more owners, more reconciliation |
These are first-draft ranges for the writing and evidence-gathering, not the remediation to actually close gaps. Add the review-and-revision cycle, and a first SSP commonly spans several weeks of part-time work. The biggest time sink is almost never the writing — it is hunting down evidence and reconciling the boundary with what is actually deployed. Tooling that keeps evidence mapped to requirements collapses that hunt, which is most of the effort.
A template gives you the structure so you are not inventing sections, from the system boundary to an implementation statement and evidence pointer for each requirement. But a template is scaffolding — the value is in the implementation detail you write into it, mapped to the 800-171A objectives. A beautifully formatted SSP full of "we comply" still fails.
What is an SSP? An SSP — System Security Plan — is the document that describes an information system, its boundary, and how it implements each applicable security requirement. For NIST 800-171, it documents how you meet all 110 Rev 2 requirements for protecting CUI. It is required under DFARS 252.204-7012 and is the primary document a CMMC assessor reviews.
What is a System Security Plan used for? Three things: it defines your system boundary and scope, documents your implementation of every applicable control, and serves as the source of truth for your SPRS score and CMMC assessment. Assessors use it to plan the assessment and to check whether your evidence backs up your claims.
Is an SSP required for NIST 800-171 and CMMC? Yes. DFARS 252.204-7012 requires contractors handling CUI to maintain an SSP. Under CMMC Level 2, the SSP is central — an assessor cannot conduct a meaningful assessment without one, and the requirement to document your plan is itself part of 800-171 (requirement 3.12.4 in Rev 2).
How long should an SSP be? Long enough to describe every applicable requirement with real implementation detail, and no longer. For a small single-enclave environment covering all 110 requirements, expect a substantial document — often 40–100+ pages depending on how much you inline versus reference. Length is a byproduct of completeness, not a target; a thin SSP is a red flag, but padding it does not help. If maintaining a document that size by hand sounds painful, that is exactly the case for CMMC compliance software that keeps each implementation statement alongside the control it describes.
What is the difference between an SSP and a POA&M? The SSP describes what you have implemented; the POA&M lists what you have not yet implemented, with a plan and dates to close each gap. They are complementary and must agree with each other. See our POA&M guide for how the two documents work together in a CMMC assessment.
An SSP that reads well to a C3PAO is specific, boundary-honest, mapped to assessment objectives, and backed by evidence you can produce on request. That is a description of how you run security — which is exactly why the ones assembled the night before an assessment fall apart.
Book a demo and we will show you how Compli.ai keeps the SSP implementation statements for all 110 requirements in your own Microsoft 365 tenant, with evidence tagged to requirements and 800-171A objectives and a systems inventory that feeds the SSP's boundary and data-flow sections. For the underlying methodology, start with our NIST 800-171 compliance guide and see how the SSP feeds your SPRS score.