Every defense contractor we have ever talked to has gotten a quote from a CMMC consultant to write their System Security Plan. The numbers we hear range from $8,000 for a small SSP to $45,000+ for a multi-site, multi-enclave shop. Most small contractors do not have that budget, so they put off the SSP, which means they put off the assessment, which means they delay the contract award.
You do not have to hire a consultant to write an SSP for CMMC Level 2. You do have to understand what an SSP actually is, what assessors look for, and where the genuinely hard parts live. This article is the founder-to-founder version of the conversation.
What an SSP actually is
The System Security Plan is the narrative document that describes:
- The system you are protecting (boundary, components, information flows).
- The CUI you handle (categories, where it lives, who touches it).
- How each of the 110 NIST 800-171 Rev 2 controls is implemented in your environment.
- The roles responsible for each control.
- The evidence that backs each implementation statement.
It is not a policy document. Policies are referenced from the SSP, not embedded in it. It is not a list of procedures either. Procedures are also referenced. The SSP is the connective tissue between your control implementations and the documentation that proves them.
The DoD CIO has a template. Use it.
The DoD CIO publishes an SSP template aligned to NIST 800-171. Download it. Yes, the formatting is from 2012. Yes, it is a Word document. Use it anyway. C3PAOs are familiar with this shape and an assessor reading a non-standard SSP is an assessor who is mentally re-mapping while you are presenting. You do not want that.
If you want a more modern shape, every reputable GRC platform (ours included) generates an SSP that matches the DoD CIO template structure but with cleaner typography, hyperlinks, and an automatically maintained control matrix. The shape is the same, the polish is different.
The five sections you must get right
A defensible SSP has five sections that assessors actually read carefully. Get these right and the rest is mechanical fill-in.
1. System identification + boundaries
What is the name of the system you are documenting. What is the authorization boundary. What is in scope, what is out of scope, and where do those scopes touch each other.
This is the single most common failure mode we see. Contractors write "all of our company IT" as the scope, then the assessor asks why the SSP describes a 50-person company's controls when the CUI only flows through 8 people in engineering. The scope is too broad, the controls do not match the reality, and the SSP loses credibility.
Tight scope wins. Document the systems that actually touch CUI. Document the systems that flow data to those systems. Document the air gap or segmentation that keeps everything else out. Be specific about the network boundary, the data boundary, and the identity boundary.
Still on the fence? See it on your data.
30 minutes, live screen-share against your real SSP or POA&M. No slides, no card on file.
Book a demo
2. System description + information flows
A diagram. Two if needed.
Diagram one: the network architecture, with the CUI enclave or environment clearly delineated. Show the firewalls, the segmentation, the identity provider, the storage location.
Diagram two: the information flow. Where does CUI enter the system, where does it transit, where does it rest, where does it leave. Who interacts with it at each stage.
Assessors read these diagrams first. If the diagrams contradict the implementation statements later, you will spend the rest of the assessment in remediation conversation.
3. Control implementation statements
For each of the 110 controls, a paragraph that describes how it is implemented in your environment. Not "we have firewalls", but "Palo Alto NGFW configured per our standard ruleset, managed by our MSP, with weekly rule review documented in the change management log".
Specificity is the difference between an implementation statement and an aspirational statement. Assessors are trained to push back on aspirational language. If the statement does not name the system, the configuration, the responsible party, and the cadence of review, it is aspirational.
The fastest path to good implementation statements: write them in the present tense, name the tool, name the human, and describe the cadence. If you cannot write it that way, the control is probably not actually implemented.
4. Roles and responsibilities
A table of who owns what. Specifically: who is the system owner, who is the information system security officer (ISSO), who is the contracting officer's representative for security, and who is the responsible party for each control family.
For very small shops, the same person owns multiple roles. That is fine. Document it. Do not invent fictional people to pad the table.
5. POA&M references
Every control not fully implemented gets a Plan of Action and Milestones entry. The SSP references the POA&M; the POA&M lives as a separate document but they are read together by the assessor.
A clean SSP / POA&M pair lists the same controls in both documents with consistent status language. A messy pair has controls marked "Implemented" in the SSP and "Other Than Satisfied" in the POA&M. That is an automatic finding.
Realistic time investment
For a small defense contractor (under 50 people, single site, CUI scoped to a clear enclave), the founder-driven SSP build looks like:
| Phase | Time | Who |
|---|---|---|
| Read the standard end-to-end | 10 hours | Founder + IT lead |
| Scope + diagram the system | 8 hours | Founder + IT lead |
| Write control implementation statements | 25 to 35 hours | Founder, IT lead, possibly HR for AT family |
| Internal review + tighten language | 5 hours | Founder + reviewer |
| POA&M build for unimplemented controls | 6 hours | Founder |
| Final formatting + cross-reference check | 4 hours | Founder |
Total: 60 to 70 hours of founder + IT lead time. Spread over four to six weeks. No outside consultant required.
If you have a more complex shop (multi-site, mixed CUI categories, classified work alongside CUI work), the numbers double and we would gently suggest at least a four-hour consulting session to validate scope. Not 40 hours of consulting. Four hours, on scope.
When you actually need a consultant
To be honest about the trade-off:
- Hire a consultant when: you have multiple authorization boundaries (commercial + ITAR + classified), or you are first-time pursuing an assessment for a contract whose award depends on a specific date and you cannot afford to learn on the job.
- Skip the consultant when: you have a clear scope, a competent IT lead, and 60 to 70 hours of founder time available across 6 weeks.
The middle ground that does not work: paying a consultant $25,000 to write the SSP for a system they have never seen, with implementation statements they invented, that you then have to defend in an assessment. We have audited several of those. Half the implementation statements do not match the contractor's actual environment.
How a GRC platform shortens this
A purpose-built CMMC platform does not write the SSP for you. It does:
- Enforce the control coverage so you cannot ship an SSP that is missing a control.
- Generate the standard DoD CIO template structure from your control inputs.
- Cross-link control statements to the policies and evidence that back them, so the assessor's clicks line up with your implementation.
- Auto-build the SSP / POA&M consistency check so the two documents never disagree.
- Recompute SPRS scoring as you implement.
For an estimate of what your SPRS score looks like right now against the 110 Rev 2 controls, try our SPRS calculator. Free, browser-side, no login.
For a Rev 2-aligned SSP template you can fill in offline, our free SSP template is email-gated and downloads instantly. Same shape we use on the platform.
Related reading
- Why Excel fails for CMMC Level 2 — why the spreadsheet path does not scale past the first 30 controls.
- NIST 800-171 Rev 2 vs Rev 3 explained — the revision your SSP should currently target.
