Short answer: A System Security Plan (SSP) is the foundational document that describes your in-scope systems, the boundary around your CUI, and how each of the 110 NIST 800-171 controls is implemented in your environment. For a small contractor it's typically 40–120 pages and structured by control family. Without an SSP, you have nothing to self-assess against and no C3PAO will start an engagement.
What an SSP is for
The SSP is the single source of truth that defines what's in scope for CMMC, who is responsible, and how each control is implemented or inherited from a cloud provider. It anchors your SPRS score, your POA&M, and the C3PAO assessment plan. Treat it as a living document — update it whenever your boundary, tooling, or vendors change.
Section-by-section outline
- System identification — name, CAGE codes, locations, points of contact
- System purpose & operating environment — what the system does, who uses it
- System boundary — diagram + narrative defining what is in / out of scope
- Data flow — how CUI enters, moves, and exits the boundary
- Interconnections — every external system the boundary touches, with the type of data
- Shared responsibility — which controls are inherited (e.g. AWS GovCloud) vs implemented by you
- Control narratives — one per the 110 controls, organized by family
- Roles & responsibilities — named owners for each control family
- Plan maintenance — change-control procedure for the SSP itself
- Appendices — network diagram, asset inventory, software list, POA&M reference
The boundary diagram
Every C3PAO will ask for this in the first 5 minutes. It must show: every host, network segment, and SaaS app that stores, processes, or transmits CUI; the inbound and outbound connections; and the trust boundary line. Use a clear visual style — Visio, Lucidchart, or draw.io are all fine. Label each component with its asset ID from your inventory.
Writing control narratives
Every control narrative needs four parts:
- What the control requires (paraphrase the NIST statement, do not copy verbatim)
- How you implement it (named tool, configuration, person responsible)
- Where the evidence lives (file path, ticket queue, vendor portal)
- Inheritance if applicable (e.g. "Encryption in transit inherited from AWS GovCloud per CRM v3.2 row 14")
Common SSP errors
- Copy-pasting NIST control text without describing implementation
- Boundary diagram missing SaaS apps (Microsoft 365, GitHub, Jira)
- No data flow showing how CUI enters the system
- Shared responsibility claims with no CRM citation
- Outdated screenshots / configurations from before the last network change
- Owner = "IT department" instead of named individuals
- NIST 800-171 controls explained
- SPRS score explained
- GCC High vs GovCloud
- How to choose a C3PAO
- Writing a CMMC POA&M
- CUI marking guide
Frequently asked questions
- How long should my SSP be?
- Length is a symptom, not a goal. A small contractor with a single GovCloud enclave usually lands at 50–80 pages. Anything under 30 is probably too thin; anything over 200 usually means uncontrolled scope.
- Can I reuse a template?
- Yes — the DoD CIO publishes a template, and several free community templates exist. But every control narrative must reflect your actual implementation, not template placeholder text.
- How often do I update it?
- On every material change (new SaaS app in scope, vendor swap, network segmentation change) and at minimum annually. Version-control the document and log changes in section 9.
- Who writes the SSP?
- Usually a security or IT lead with input from each control-family owner. Outside consultants can draft it, but the named owners inside your company must understand and sign off — the C3PAO will interview them.
- NIST 800-171: All 110 Controls in Plain EnglishControls · 12 min read
- How to Write a CMMC POA&M That a C3PAO Will AcceptPOA&M · 8 min read
- SPRS Score Explained: How DoD Sees Your NIST 800-171 PostureSPRS & Scoring · 8 min read
- CMMC vs ISO 27001: Why ISO Doesn't Get You DoD ComplianceFrameworks · 7 min read