How to Write an SSP for CMMC Level 2 (Step-by-Step)

Why the SSP Is the Most Important CMMC Document You'll Write

Every CMMC Level 2 assessment starts the same way: the C3PAO team reads your System Security Plan before they interview a single person or test a single system. The SSP is the frame through which assessors interpret everything else. If your SSP says a control is fully implemented but your technical configuration contradicts it, that discrepancy is a finding — and it signals to the assessors that other areas may also be misrepresented.

NIST 800-171 requirement 3.12.4 makes the SSP mandatory. It is not optional documentation that good organizations happen to have. It is a contractual requirement under DFARS 252.204-7012, and its absence — or inadequacy — can block contract award. More practically, a well-written SSP dramatically reduces the friction of your assessment and gives you a fighting chance of passing on the first try.

This guide walks through every section of a CMMC Level 2 SSP, what assessors look for in each one, and the mistakes that cause otherwise-prepared contractors to fail.

Step 1: Define Your System Boundary Before You Write Anything Else

The most consequential decision in SSP authorship is defining the system boundary — exactly which hardware, software, networks, cloud services, and facilities are in scope. Everything else in the document flows from this definition.

A boundary that is too narrow leaves CUI-handling systems unprotected and unassessed. A boundary that is too broad makes your compliance program needlessly complex. Getting it right requires answering three questions:

• Where does CUI enter your organization? (Email, file transfer, government portals, the prime contractor?)
• Where is CUI stored and processed? (On-premises servers, cloud storage, individual workstations, collaboration tools?)
• Where does CUI exit your organization, and to whom?

The answers define your boundary. Every system that touches CUI — even indirectly — is in scope. This includes cloud services like Microsoft 365, Google Workspace, or any SaaS tool your team uses for government work. Failing to include cloud services is the single most common boundary error, and assessors check for it specifically.

Once your boundary is defined, draw a network diagram that shows data flows, trust zones, internet-facing systems, connections to external parties, and any cloud environments. The diagram is part of the SSP and must match what the assessors find when they examine your environment.

Step 2: Write the System Description

The system description is a narrative overview that answers four questions: what is this system, what does it do, what CUI does it process or store, and where is it physically located?

Keep this section factual and specific. Assessors are not looking for marketing language about your cybersecurity posture — they want to understand the environment quickly so they can contextualize everything else they read. A strong system description covers:

• The primary business function the system supports
• The CUI categories present in the environment (reference the NARA CUI Registry categories)
• The types of users who access the system (employees, contractors, service accounts)
• The physical locations of the infrastructure (corporate office, data center, cloud regions)
• The operating systems and major software platforms in use

Do not describe your security controls in this section — that comes later. The system description is about what the system is, not how it is protected.

Step 3: Document User Types and Access Roles

Before you can describe how access is controlled, you need to document who has access and why. This section lists every category of user that interacts with in-scope systems:

• Privileged users — administrators with elevated rights (domain admins, cloud console admins, system administrators)
• Standard users — employees who access CUI in the course of normal work
• Service accounts — non-human accounts used by applications and automated processes
• External users — contractors, vendors, or government personnel with access to your systems

For each user type, describe the access rights they hold and the systems they are authorized to access. This becomes the foundation of your Access Control implementation statements and will be directly examined during the assessment.

Step 4: Write Control Implementation Statements for All 110 Requirements

This is the core of the SSP and where most contractors underinvest. For each of the 110 NIST 800-171 requirements, you need an implementation statement that explains — specifically — how your organization satisfies that requirement.

The difference between a weak statement and a strong one is specificity. Compare these two statements for requirement 3.5.3 (multi-factor authentication):

Weak: "We use multi-factor authentication for all users."

Strong: "Multi-factor authentication is enforced for all user accounts accessing CUI-bearing systems via Microsoft Entra ID Conditional Access policies. Policies require Microsoft Authenticator app approval for all sign-ins to Microsoft 365, the corporate VPN (Cisco Secure Client), and the internal file share. MFA is enforced at the identity provider level and cannot be bypassed. Service accounts are excluded from interactive MFA requirements and instead use certificate-based authentication with 90-day rotation. Configuration is maintained by the IT Administrator and documented in the Entra ID CA Policy inventory (Appendix C)."

The strong statement tells an assessor what they need to examine (the Conditional Access policies), who to interview (the IT Administrator), and what to test (attempt access without MFA). The weak statement tells them nothing and will result in follow-up questions that slow the assessment.

Specific elements every implementation statement should include:

• The specific technical mechanism or tool that implements the requirement
• The scope (what systems, users, or data the control applies to)
• Any exceptions or limitations, and how those exceptions are managed
• Who is responsible for the control
• Where the evidence can be found (policy documents, configuration screenshots, system reports)

Step 5: Handle Unimplemented Controls with a POA&M

If any of the 110 requirements are not yet fully implemented, they must be documented in a Plan of Action and Milestones (POA&M) and referenced in the SSP. The SSP implementation statement for an unimplemented control should state that the requirement is not currently met, with a cross-reference to the corresponding POA&M item.

A POA&M entry requires: the specific requirement that is not implemented, a description of the gap, the planned remediation steps, the person or team responsible, and a target completion date. Target dates must be realistic — assessors will ask whether your POA&M timeline is achievable and whether you're on track.

One critical point: under the DoD Assessment Methodology, having a POA&M for a control does not give you credit for it in your SPRS score. The control is scored as Not Met until it is fully implemented. The POA&M is required documentation, but it does not change your score until the work is done.

Step 6: Document External Systems and Dependencies

Most environments have dependencies on external systems — cloud providers, managed service providers, SaaS applications, or government portals. Each of these must be documented in the SSP, including:

• What the external system does and what CUI it handles
• The security controls the external provider implements (referenced from their own documentation or SOC 2 reports)
• Whether the provider has a FedRAMP authorization that covers the CUI data types in use
• The contractual agreements (data processing agreements, BAAs, or DFARS flow-down clauses) that govern the relationship

This section is important because assessors will evaluate whether your use of external providers creates gaps in your control coverage. If you store CUI in a cloud service that is not covered by your SSP, that is both a scope omission and a potential unmitigated risk finding.

Step 7: Address All 14 Control Families

A complete CMMC Level 2 SSP covers all 110 requirements across all 14 NIST 800-171 control families. The families and their requirement counts are:

• Access Control (AC) — 22 requirements (the largest family; covers user access, remote access, and least privilege)
• Awareness and Training (AT) — 3 requirements (security awareness training and role-based training documentation)
• Audit and Accountability (AU) — 9 requirements (logging, log protection, and review)
• Configuration Management (CM) — 9 requirements (baselines, change control, and software inventory)
• Identification and Authentication (IA) — 11 requirements (MFA, password requirements, and authenticator management)
• Incident Response (IR) — 3 requirements (incident handling capability, tracking, and reporting)
• Maintenance (MA) — 6 requirements (controlled maintenance and remote maintenance security)
• Media Protection (MP) — 9 requirements (media access, sanitization, and transport)
• Personnel Security (PS) — 2 requirements (screening and termination procedures)
• Physical Protection (PE) — 6 requirements (physical access controls to systems and facilities)
• Risk Assessment (RA) — 3 requirements (risk assessments and vulnerability scanning)
• Security Assessment (CA) — 4 requirements (control assessments, action plans, and SSP maintenance)
• System and Communications Protection (SC) — 16 requirements (network architecture, boundary protection, and encryption)
• System and Information Integrity (SI) — 7 requirements (malware protection, security alerts, and patching)

No control family can be omitted. An SSP that addresses 100 of the 110 requirements is not a complete SSP — the missing 10 are findings before the assessment even starts.

Step 8: Keep the SSP Current

An SSP is a living document, not a one-time deliverable. Every time your environment changes — you adopt a new cloud service, change your network architecture, add a new class of user, or implement a new security control — the SSP must be updated to reflect the change. Requirement 3.12.4 includes maintaining the SSP as a continuous obligation.

Assessors compare the SSP against what they observe. A document that describes last year's environment creates contradictions that undermine your credibility for controls that are actually implemented. Schedule a formal SSP review at least annually and as part of any significant change management process.

Common SSP Mistakes That Fail Assessments

• Using a generic template without customizing it. Templates are useful starting points, but they describe fictional environments. If your SSP reads like it was written for a generic IT shop rather than your specific organization, assessors notice — and they will look more closely for additional disconnects between documentation and reality.
• Writing aspirational statements. The SSP describes current implementation, not planned implementation. If a control is not yet in place, it belongs in the POA&M, not in an implementation statement that implies it is operational.
• Omitting cloud services and SaaS tools. Microsoft 365, Teams, SharePoint, and similar services are among the most common SSP omissions. If your team uses these tools for any work that involves CUI, they are in scope.
• Writing policy-level statements instead of implementation-level statements. "We have an access control policy" is not an implementation statement. "Access to CUI systems requires approval from the employee's manager and IT administrator, is provisioned in Active Directory using the least-privilege role appropriate to the employee's function, and is reviewed quarterly using the report documented in Appendix B" is an implementation statement.
• Not cross-referencing supporting documents. Your SSP should reference your policies, procedures, network diagrams, configuration inventories, and other documentation as appendices or external references. This makes the assessment smoother and demonstrates that the document is grounded in real artifacts.

How RegulatoryForge Helps

RegulatoryForge's SSP Builder walks you through each of the 110 NIST 800-171 requirements with guided prompts that help you write specific, assessor-ready implementation statements. As you complete each section, the platform tracks your coverage across all 14 control families and flags requirements where your statements are too vague to support an assessment. When you're ready, you can export a formatted SSP document ready for C3PAO review.

Not sure what a finished SSP looks like for your environment? Use our free SSP preview generator — enter your company name and system details to see a sample covering 3 control families. No account required.