Chapter 1
How to Structure an SSP for CMMC Level 2
A System Security Plan, called an SSP, is the first thing a CMMC assessor reads. For Level 2, the plan must address the 110 security requirements of NIST SP 800-171 Rev. 2. That mapping is set by the CMMC program rule, 32 CFR Part 170. 32 CFR Part 170
Good structure makes those answers easy to find. Use the eight sections below, in this order.
1. Cover page and version history
Start with a cover page. Name the system, the company, and the date. State that the plan supports CMMC Level 2.
Add a version history table. Record each change with a date and an author. This shows the plan is maintained, not written once and forgotten.
2. System overview and boundary
Describe the system in plain terms. Say what it does and who uses it. List where it operates, including cloud services.
Draw the boundary clearly. The boundary is the line around what is in scope. Everything inside the line must be addressed.
Name the data types the system handles. Call out CUI wherever it lives. CUI stands for Controlled Unclassified Information. It is the data CMMC exists to protect.
3. Roles and responsibilities
List the people behind the plan. Name the system owner and the security lead. Include contact details for each.
Describe what each role does. The owner approves changes. The security lead runs the controls day to day.
Keep this section current. Staff changes fast. An SSP that names people who left looks neglected.
4. System architecture and inventory
Add a short inventory of what is inside the boundary. List servers, services, and major applications. Short lists are fine.
Note which parts handle CUI and which do not. Assessors check that the boundary on paper matches the network in reality.
Name any outside services that touch CUI, like cloud providers or managed IT. Mark what each one does with the data.
5. Control statements for all 110 requirements
This is the heart of the SSP. Address every requirement, grouped by its family. The 110 requirements sit in 14 control families, from access control to system integrity.
For each requirement, write three things. State whether it is implemented. Describe how it works in your environment. Name the evidence that proves it.
Be specific in every statement. "Remote access requires multi-factor authentication through our VPN" beats "access is controlled." Vague lines invite follow-up questions.
Use the same requirement numbers everywhere. Consistent numbering ties the SSP to your evidence folders. The assessor can jump between them without hunting.
6. Evidence map: what the assessor will check
NIST SP 800-171A defines how CUI requirements are assessed. Assessors use three methods: Examine, Interview, and Test. NIST SP 800-171A
Examine means reading documents. The assessor reads your policies, procedures, logs, and settings. Your SSP must name these documents so they can be found.
Interview means talking to people. The assessor asks admins and managers how controls work day to day. Your roles section must name the right people to ask.
Test means trying the controls. The assessor may attempt a login without MFA or check that a disabled account stays disabled. Your statements must describe behavior that holds up live.
Build each control statement with all three in mind. One statement should point to a document, a person, and a working control. That is what an assessor actually verifies.
7. POA&M and open items
No plan is perfect. List what is not yet done. For each gap, give a fix and a date.
POA&M stands for Plan of Action and Milestones. Keep it inside the SSP or attach it as an appendix. Either way, reference it clearly.
Be honest about dates. Assessors respect a real plan. They distrust a page of wishes.
Review the POA&M monthly. Close items as fixes land. A shrinking list shows progress.
8. Diagrams and appendices
Add a network diagram. Show where CUI enters, moves, and rests. Mark the boundary on the drawing.
Attach supporting lists. Include the hardware and software inventory, a contact list, and a short glossary.
Keep appendices tight. They support the plan, not replace it.
PolicyCortex generates evidence for these statements from live Azure systems, so the SSP stays tied to how things actually run.
Sources
- 32 CFR Part 170, Cybersecurity Maturity Model Certification (CMMC) Program
- NIST SP 800-171A, Assessing Security Requirements for Controlled Unclassified Information
- NIST SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Next step
Structure matters, but honest content matters more. Build each statement on proof you can show.