The System Security Plan is the first document a C3PAO assessor reads and the last one most contractors think to write. Here's what it is, what must be in it, and why going into a CMMC Level 2 assessment without one is a guaranteed failure.
Before a Certified Third-Party Assessment Organization (C3PAO, an independent firm accredited to conduct CMMC assessments on behalf of DoD) runs a single interview or reviews a single technical control, they read your System Security Plan. It tells them what's in scope, what you claim to have implemented, and where they should focus. Think of it as a job interview where the hiring manager already read your resume, what you wrote before showing up determines the conversation. If your SSP is vague, incomplete, or doesn't exist, the assessment starts badly and usually stays that way.
A System Security Plan (SSP) is a formal document that describes how your organization protects the information systems used to receive, store, process, or transmit Controlled Unclassified Information (CUI). It maps your system boundary, describes your architecture, identifies your authorized users, and, most critically, documents your implementation of all 110 security practices required by NIST SP 800-171 Rev 2 and CMMC Level 2.
The legal basis: DFARS 252.204-7012, the clause in virtually every DoD contract that covers cybersecurity, requires contractors to implement NIST SP 800-171 and to maintain a current SSP. It's not a best practice. It's a contractual obligation.
If you are a defense contractor or subcontractor that handles CUI, technical drawings, contract data, export-controlled information, or any other data marked CUI, you need an SSP. This includes:
If you've ever wondered whether you're in scope, look at your contract. If you see DFARS 252.204-7012 or DFARS 252.204-7021, you need an SSP and you need it to be accurate.
There's a common misconception that the SSP is just a checklist. It's not. A one-page spreadsheet where you check "yes" next to 110 practices is not an SSP, that's a wish list. It will collapse under assessor scrutiny.
An SSP is a narrative document. For each of the 110 practices, it must describe specifically how your organization implements that requirement, the systems involved, the tools in use, the people responsible, and the evidence that can be produced. Vague statements like "we have antivirus" don't pass. "All endpoints are protected by CrowdStrike Falcon, managed centrally by the IT team, with definitions updating every 4 hours and alerts forwarded to our SIEM" is what an assessor needs to see.
NIST SP 800-171 organizes its 110 practices into 14 security domains. Your SSP must address every domain with specific implementation statements. An assessor will test each claim, so if your SSP says it's implemented, you need the evidence to prove it.
The largest domain. Covers who can access what, how accounts are managed, how remote access is secured, and how CUI is kept from flowing to unauthorized destinations. This is also the most common failure area.
Log everything. Retain logs. Review them. Alert when logging fails. Know who did what, when, on which system. If you can't answer an assessor's question about a past event with a log, this domain is your problem.
Every user who touches CUI must receive security awareness training. Role-specific training is required for IT and security staff. Phishing simulation evidence goes a long way here.
Know what's in your environment, lock it down to secure baselines, and control what changes. Asset inventories, hardening standards, and a real change management process are required, not optional.
MFA is not negotiable at CMMC Level 2. Every privileged account and every non-privileged account accessing systems remotely must use MFA. Password policies, account lockout, and session controls also live here.
The remaining 55 practices cover Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity. Each requires documented implementation.
When a C3PAO assessor receives your SSP, they use it as the roadmap for your assessment. Here's the basic process:
One thing assessors look for that most contractors miss: The SSP boundary definition. You must clearly define what is in scope and what is not. If your boundary is vague or drawn too broadly, assessors will expand their testing. If it's drawn in a way that excludes systems that clearly handle CUI, that's an immediate red flag.
The authorization boundary tells the assessor what systems are in scope. Many contractors write "all IT systems", which is either so broad it triggers testing of everything, or inaccurate because their accounting system actually isn't in scope. Be specific. List the systems. Draw the diagram.
For each of the 110 practices, you need to describe what you actually do. "Implemented, we use Active Directory" is not a practice implementation statement. A real statement names the tool, describes the configuration, identifies who manages it, and notes where evidence can be found.
Assessors need to see your architecture. A network diagram that shows your zones, how CUI flows, where the perimeter controls are, and how remote access enters the network is a requirement, not a nice-to-have. An assessor who can't see your network diagram will draw their own conclusions about your network. Those conclusions are usually worse than reality.
This sounds obvious, but it happens constantly. Contractors mark a control implemented because they plan to have it or because they have a partial implementation. If an assessor finds a mismatch between what you claimed and what exists, the finding is more serious than if you'd listed it as planned with a realistic remediation date.
Almost no organization achieves 110 out of 110 practices on the first assessment attempt. That's expected. What assessors want to see is that you know where your gaps are and have a credible plan to close them. A missing POA&M signals that you haven't done the internal assessment work to know your own posture.
Written from scratch, a complete, assessment-ready SSP for a small defense contractor typically takes 40–80 hours, spread across IT staff, management, and whoever is coordinating the compliance effort. That includes drafting implementation statements, gathering evidence, building the boundary diagram, and getting sign-off.
Starting from a well-structured template that already contains all 110 practice rows, the correct section structure, and example implementation language cuts that time significantly. The substantive work, describing your specific environment and controls, still takes time. But you're not spending hours figuring out what the SSP needs to contain or what format assessors expect to see.
Our CMMC Level 2 SSP template includes all 110 NIST SP 800-171 Rev 2 practices organized by domain, implementation status tracking, example implementation language, a boundary definition section, an interconnection table, and a signed authorization block. It's the document structure used in real CMMC assessments.
Get the SSP Template at SecReadyNow →If you've been tracking CMMC requirements, you've heard of the Supplier Performance Risk System (SPRS). Since November 2020, contractors have been required to submit a NIST SP 800-171 self-assessment score to SPRS. That score is derived from, you guessed it, an SSP-level review of your 110 practices. Each practice you cannot demonstrate is assessed a point value deduction from a maximum score of 110.
If your SPRS score doesn't align with your SSP, that's a problem. Contracting officers can see your SPRS score, and auditors can request your SSP. They need to tell the same story.
Ideally, your SSP should be complete and current before you bid on any contract that requires CMMC Level 2. The realistic answer for most small contractors is: start now, because it will surface gaps you didn't know you had, and those gaps take time to close.
The SSP is a living document. It changes when your architecture changes, when new systems come in scope, when personnel change, when you remediate findings. "Complete" is a starting point, not a destination. But you have to start somewhere.
The System Security Plan isn't a bureaucratic checkbox. It's the proof that you know what CUI you handle, what systems it lives on, who can access it, and how you're protecting it. Done well, it becomes an operational security document, something your IT team actually references when making decisions about access, configurations, and architecture.
Done poorly, or not at all, it's the reason you fail an assessment you could have passed.
No spam. Just practical guidance on CMMC compliance and new resources when we publish them.