What is a CMMC System Security Plan?
A CMMC System Security Plan (SSP) is a required compliance document that explains how a defense contractor meets the cybersecurity practices in NIST SP 800-171. It outlines system boundaries, controls, and policies, and serves as the foundation for CMMC assessments at Levels 2 and 3.
Contractors seeking Cybersecurity Maturity Model Certification (CMMC 2.0) must develop and maintain an SSP that accurately documents how security practices are implemented. It is a living document, updated as systems change, and provides assessors with proof of due diligence.
The SSP supports national supply chain security across the Defense Industrial Base (DIB).
“The SSP is one of the main pillars of CMMC compliance,” says Elliott Harnagel, Product and Compliance Strategist at Strike Graph. “It is impossible to be compliant without one, as not having a documented plan will result in an automatic fail on any assessment. More importantly, the plan acts as the source of truth, where you explain in detail how you comply with each of the 110 controls required for CMMC Level 2. If you don’t have a strong plan, you run the risk of non-compliance or losing contracts.”
Harnagel emphasizes that for your SSP to be credible during an assessment, it must truthfully describe how your system implements the required controls. “The point isn't to make your company look good — it’s to state what you are actually doing,” he says. “Overstating your controls in the SSP will set you up for failure when it comes to your C3PAO audit.”
Assessors will compare your SSP with what they observe in an on-site review.
“CMMC assessors are investigators of your data security practices,” says Michael Greenman, Senior Manager of Cloud Solutions at Deltek. “They are looking at policies and procedures to confirm what they are seeing.”
Difference between SSPs and security policies
A security policy is a high-level document setting your organization’s rules and governance. In contrast, an SSP details how you apply those rules and how your systems meet CMMC requirements. It provides the DoD with evidence that you can protect Controlled Unclassified Information (CUI) and Federal Contract Information (FCI).
“While security policies outline how your organization treats a certain process or handles a given area of operations, like incident response or change management, the SSP addresses how your organization protects CUI across all of the systems that store or transmit it,” explains Harnagel. “In the SSP, organizations must specifically outline how they comply with each of the 110 controls required in NIST 800-171.”
Why the NIST template is only a starting point
The NIST SSP Template is a good starting point for an SSP as it provides a structure for documenting an organization’s cybersecurity program. However, the template does not provide the necessary content to pass a CMMC or NIST 800-171 assessment. As part of the CMMC process, your organization must supply the details, evidence, and operational context.
“The NIST SSP template is an excellent starting point, but it has its limitations, one of the biggest of which is that filling it out is an entirely manual process,” says Harnagel. “Using an SSP that auto-generates some of the necessary information, like Strike Graph's SSP module, can help reduce the documentation burden of outlining compliance with all 110 controls significantly.”
If you still decide to go the manual route, Strike Graph also offers a more helpful version of the NIST template as part of its CMMC SSP Starter Kit, detailed below. This upgraded CMMC SSP template provides the assessment objectives for each control, plus guidance for each control implementation description.
Steps to create your CMMC SSP
To make an effective CMMC SSP, get a template or software to structure it. Research and fill out each applicable section and control, and compile supporting documentation and control implementation evidence.
These 10 steps will help keep your SSP on target:
- Research your level.
Decide your CMMC level. Note that only CMMC Level 2 (the most common) and CMMC Level 3 (for a few major contractors only) require an SSP:
● Level 1 = basic safeguarding (FAR 52.204-21)
● Level 2 = full NIST 800-171 implementation (110 controls)
● Level 3 = full NIST 800 171 plus selected NIST SP 800-172 controls
- Gather reference documents.
● Guides: CMMC Level 2 Assessment Guide or CMMC Level 3 Assessment Guide.
● Assessment procedures: NIST SP 800-171A, Rev. 2. Note that this remains in effect for CMMC, although NIST has published Rev. 3.
● An SSP template: You can use the online NIST SSP form or the enhanced CMMC SSP template from Strike Graph.
● Contracts: Any customer/contract clauses specifying how to handle CUI.
● NIST SP 800-53 and NIST Cybersecurity Framework (NIST CSF): Helpful references for control design and risk program structure. While CMMC Level 2 maps to NIST SP 800-171 (not 800-53 or CSF), many organizations use 800-53 and CSF to inform policies and governance and to maintain cross-framework alignment.
● FedRAMP and FISMA: If you rely on cloud services, reference your provider’s FedRAMP authorization and shared responsibility matrix in the SSP. FedRAMP/FISMA artifacts can support inherited controls, but do not replace CMMC evidence.
- Define the system boundary.
Describe what systems and associated data are within your scope for protecting CUI and FCI.
● Inventory the assets:
- Hardware (servers, endpoints, network devices)
- Applicable software applications (monitoring, authentication, and security tools; Web application frameworks; databases, etc.)
- Cloud services (cloud infrastructure, storage services, managed databases, etc.)
- External connections (third-party APIs, email providers, payment gateways, etc.)
● Diagram the network. Show your CUI’s path.
● Segregate if possible. Narrowing the CUI boundaries lessens the SSP scope and complexity.
- Map and describe the system’s environment.
● Type up the system description, covering purpose, functions, and operating environment.
● Name responsible parties (system owner, Information System Security Officer (ISSO), administrators).
● Document the authorization boundary, with diagrams showing data flows and trust relationships.
● List all external systems, including from partners, vendors, and cloud services, and provide their trust levels.
- Address each CMMC/NIST 800-171 control.
● State the control.
● Describe implementation.
- How the control is met in your system.
- Tools and procedures for enforcing the control.
● List the responsible party for ensuring compliance.
● Reference evidence, such as policies and system screenshots.
● Note gaps. If a control is not fully implemented, flag this in Plan of Action & Milestones (POA&M).
● Perform an internal self-assessment. Collect evidence that demonstrates the control is implemented and operating as intended, such as configuration screenshots, log samples, and training completion records. This documentation backs your SSP and demonstrates you are ready when assessors request verification during a CMMC assessment.
Greenman says each of the 110 controls NIST SP 800-171 (and all 325 assessment objectives) should be mapped to evidence and clearly assigned in a shared responsibility matrix so assessors can verify exactly which part is responsible for each control.
- Create required supporting documentation.
● Supporting documentation across all 14 NIST 800-171 control families. Assessors expect each family referenced in the SSP to include at least one formal policy, plan, or procedure.
● Incident response plan. CMMC assessors expect proof that the plan is tested and updated.
● Configuration management plan. Shows processes for preventing changes without authorization.
● Dedicated access control policy. Assessors expect to see a dedicated policy as access control is one of the most heavily weighted families in NIST 800-171.
● Media protection and sanitization methods. This protects CUI. Auditors may request a demonstration of sanitization processes.
● Your continuous monitoring process. This shows how you watch over your program.
● Business Continuity & Disaster Recovery (BC/DR) Plan: Demonstrates resilience objectives, restoration priorities, and test results that support contingency-related controls.
● Risk register: Central log of risks, owners, mitigation plans, and status; link risk entries to the relevant controls in the SSP.
● Third-party compliance reports (as applicable): ISO 27001, FedRAMP, SOC 2 or others. These can corroborate inherited or shared controls (e.g., cloud, datacenter), but they do not substitute for CMMC-specific evidence.
● CJIS requirements (if you process CJIS data): Note scope and any state/local CJIS obligations; include the applicable policies and agreements.
- Develop the POA&M. This is critical for interim remediation. For every one of the gaps, you’ll have:
● An action item: What must be done to close it
● Milestone/date: When it will be completed
● Resources required: Budget, tools, staffing
- Compile and draft the SSP. Use a clear, auditable structure. Some organizations start with the NIST SSP form, which covers system identification, environment, and control-by-control implementation details. To make the SSP easier to review, many teams also add a cover page, table of contents, and other content. A complete SSP will typically include:
● Cover page and table of contents: Shows ownership and contact info and provides navigation.
● System identification: Defines what system the SSP applies to (name, owner, purpose, CMMC target level).
● Roles and responsibilities: Includes Information System Owner; System Administrator; Security Officer/ISSO; Incident Response Lead.
● System boundary description and diagrams: A narrative description of the boundary, logical diagram, and data flow diagram to show scope.
● Control-by-control implementation descriptions: Include control ID/name; implementation summary; responsible role; supporting document; and status.
● Supporting policies/procedures: List of each supporting document—for example, Access Control Policy, Incident Response Plan.
● POA&M: It’s not part of the NIST form, but assessors expect it alongside the SSP to show how you are closing gaps.
- Review and approve.
● Internal review: Security, IT, and compliance personnel
● Leadership signoff: System owner or designated authorizing official
● Legal review (optional): Ensure that the plan does not commit to practices your organization cannot sustain.
- Circle back regularly.
● Update the SSP with each system adjustment: Update whenever system boundaries, controls, or configurations change.
● Annual review: Even if nothing changes, confirm and re-attest to accuracy.
● Post-incident updates: Revise to reflect new controls or process changes after a security event.
Download the Steps to Create Your CMMC SSP
Key sections of the CMMC System Security Plan
Each organization’s SSP may look a bit different, but the key sections are generally standard. The official NIST SSP form has three main sections: System Identification, System Environment, and Requirements. Organizations often add a cover page, introduction, a Plan of Action & Milestones (POA&M), and appendices.
The added items can make the SSP more convenient during CMMC assessments. Here are descriptions of all the sections:
- Cover page and administrative information (optional addition). Companies often include this section for clarity. It includes:
- Title
- Version number and date
- Author/owner
- Approval signatures
- SSP confidentiality notice
- Revision history
- Table of contents
- Introduction (optional addition). This is usually less than one page and explains the organization’s SSP in broad terms:
- Purpose of SSP and what it covers
- Relevance to CMMC Levels 2/3
- Organization’s commitment to protection of CUI and FCI
- System identification (NIST Section 1.0): This first part of the NIST form spells out the basic details of the system:
- System name and unique identifier
- System owner and responsible organization (name, title, contact)
- CMMC target level (for example, Level 2 or 3)
- System purpose and scope
- Roles of users and number of each type (end users, admins, etc.)
- General description of the information handled (CUI and FCI)
- System environment (NIST Section 2.0): This section describes the system boundary and operating environment. It explains what is inside and outside of the CUI environment. It includes:
- System description: Functions, users, and business processes supported
- Authorization boundary: Narrative description of in-scope networks, devices, and services
- System components: List of hardware, software, and cloud services
- External connections: Vendors, partners, and government systems
- Network diagrams: Logical and physical diagrams showing CUI flows and boundaries
- Requirements (NIST Section 3.0): This is the core of the SSP and typically the longest section. It documents how each of the 110 NIST SP 800-171 requirements is implemented and provides the evidence that assessors will review. For each control, include:
- Control ID
- Control statement
- Implementation description (how your organization meets the requirement)
- Responsible party
- Evidence references (policy name, procedure ID, screenshots, logs)
- Gap status (if applicable, for POA&M tracking)
- Supporting documentation. Assessors typically expect your SSP to reference or link to key organizational documents, such as:
- Access Control Policy
- Incident Response Plan
- Configuration/Change Management Policy
- System and Communications Protection Policy
- Training and Awareness Policy
- Media sanitization procedures
- POA&M. This is not part of the NIST form, but it’s required under DFARS/CMMC and usually submitted alongside the SSP. It tracks gaps and remediation progress. It includes:
- A list of unimplemented or partially implemented controls, with a risk rating and priority level for each item
- Corrective actions, with assigned owners and timelines
- Target completion dates, with tracking to demonstrate progress
- Assigned responsibility
- Appendices (optional but common): Organizations often include appendices for supporting material such as:
- Glossary and acronyms
- Full asset inventory
- Additional diagrams
- Copies or excerpts of key configurations
- Evidence list cross-referenced to controls
CMMC SSP template with guidance
Strike Graph offers a free CMMC SSP template that includes both guidance for filling out each control implementation description and the official NIST Assessment Objectives — neither of which are provided in the NIST template.
Unlike Strike Graph’s software, the template is still a manual process, but it’s an upgrade from the version NIST provides. Download it on its own, or get it as part of the CMMC SSP starter kit detailed below.
Download the guided CMMC SSP template
Examples of a CMMC System Security Plan
These CMMC SSP examples show how two fictional companies might approach an SSP. One is for a small defense contractor, Acme Engineering. The other is for a large, matrixed company, Titan Defense Systems.
Each example shows completed portions of the SSP, so you can see how system data, controls, and evidence might be documented.
Download the CMMC SSP example for a large contractor
Download the CMMC SSP example for a small contractor (page 12)
Strike Graph’s CMMC SSP starter kit
This CMMC SSP starter kit compiles several resources into one convenient download. It gives you a head start on creating an effective system security plan.
The starter kit includes:
- Our enhanced CMMC SSP template: containing guidance for each control implementation description, as well as the Assessment Objectives.
- CMMC SSP examples: for two fictional defense contractors
- Quick-reference checklists: a one-pager of SSP steps and a best practices tip sheet
Download the CMMC SSP Starter Kit
Best practices for creating your CMMC SSP
A strong SSP provides a structured, detailed, and realistic overview of an organization’s cybersecurity posture. Best practices include defining system scope early, documenting control implementation in detail, providing evidence, and keeping the plan current through regular reviews and updates.
Here’s a deeper look at best practices:
- Start with a structured template — but know that software can help when you’re ready. Begin with the NIST SSP template or the Strike Graph guided SSP template so you don’t miss key sections. Be aware that compliance software can later automate much of this work.
- Clarify scope early. Define clear system boundaries that identify what systems, networks, applications, and assets are within your scope. Be precise about what is in scope versus out of scope for your environment. Use diagrams or inventories to show how components interact.
Some contractors may elect to implement a secure CUI enclave — a dedicated, isolated environment where Controlled Unclassified Information can be stored, transmitted, and processed — to reduce the overall scope of their CMMC assessment.
Greenman says that approach is a good plan for part of the solution, but if the data contained in the CUI enclave is needed for other systems and applications, those connections will come into scope or not have to that data, limiting the capabilities.
- Be specific in control descriptions. Explain how each NIST SP 800-171 control is implemented, covering what is implemented, how it’s implemented, who is responsible for implementation, and where it applies (which systems, sites, or environments). Avoid vague language, such as “We use…” or “We have...” Instead, provide specific details on how each control is implemented.
- Stay consistent. Ensure that your SSP follows the same structure for each control section and aligns with other compliance artifacts, including policies and procedures, POA&M, and diagrams and inventories. Avoid excessive technical jargon that auditors may not understand.
- Ensure credible evidence. Reference supporting artifacts, including policies, procedures, training records, and technical configurations that add credibility and make it easier for assessors to verify compliance.
Anchor every control to tangible artifacts and show where third parties are involved. “Show exactly what controls are inherited and shared versus what you are solely responsible for,” Greenman says.
- Collaborate well across departments. Work closely with IT, compliance, legal, and operations teams to ensure buy-in and accountability across your organization. Where appropriate, note relevant staff credentials. These include CMMC RP (Registered Practitioner) for advisory support, CISA (Certified Information Systems Auditor) for audit discipline, or CCSK (Certificate of Cloud Security Knowledge) for cloud control implementation. Credentials don’t replace controls, but they improve execution and review quality.
- Include a Plan of Action and Milestones (POA&M). Transparently document controls that are not fully implemented in the POA&M, with mitigation strategies, timelines, and responsible parties.
- Keep your SSP current. The plan is a living document that requires updates whenever systems, policies, or technologies change. Review quarterly or annually and make changes.
Stale documents are a red flag in any cybersecurity assessment, says Greenman. “SSPs often get written and forgotten.”
- Clarify shared responsibility. Contractors must document all cloud and third-party services — including any Managed Security Service Providers (MSSPs) —and assign who implements, monitors, and evidences each control. Where useful, include a brief crosswalk showing how vendor attestations (e.g., ISO 27001, SOC 2, FedRAMP) support inherited portions of your NIST 800-171 controls.
- Get ready for software. If the manual process becomes too burdensome, use compliance software to streamline documentation, automate evidence collection, and track controls efficiently — speeding up readiness for assessment.
Streamline CMMC compliance with Strike Graph
Managing a CMMC SSP manually can be slow and error-prone. Strike Graph’s AI-native compliance management platform helps you move beyond spreadsheets and static templates by automating control mapping, evidence collection, and progress tracking.
With everything in one platform, teams can:
- Complete CMMC self-assessments more efficiently
- Manage POA&Ms and remediation steps in real time
- Maintain an up-to-date, assessor-ready CMMC SSP without duplicate effort
Strike Graph makes the SSP easily updatable, helping contractors achieve CMMC compliance faster with less manual work.
Schedule a Strike Graph demo today.
CMMC System Security Plan FAQs
Does my organization need a System Security Plan?
Yes. If your organization is a defense contractor pursuing CMMC Level 2 or 3, an SSP is required. Companies must maintain SSPs that document security practices and demonstrate compliance.
How often should a System Security Plan be updated?
An SSP should keep evolving. DOD assessors expect at least an annual review, and more often if system boundaries, policies, or technologies change.
Also, update the SSP to reflect the emerging CMMC landscape and schedule an annual review with responsible parties.
What’s the difference between an SSP and POA&M?
An SSP explains how your organization meets required security controls, while a POA&M documents gaps and timelines for fixing them. A POA&M is part of an SSP and shows how your company plans to achieve full compliance.
How is a System Security Plan assessed?
During a CMMC assessment, the SSP is reviewed to determine whether required controls are in place. Assessors check scope, control implementation, consistency, risk handling, and evidence. Their process includes pre-assessment review, control validation, boundary confirmation, continuous monitoring, and final scoring.
What documentation is required to support the CMMC SSP?
You will need to append credible evidence to your CMMC SSP. Assessors typically expect to see policy and procedure documents, system diagrams, inventories, and control implementation proof. This may include screenshots, training records, logs, or other documents. Most will also include a POA&M to track remediation.
Who completes the CMMC SSP?
The contractor or subcontractor seeking assessment — called the Organization Seeking Assessment (OSA) — is responsible for completing the SSP. Typical contributors include IT and security staff, compliance officers, executives, and system owners.
Can I use a CMMC SSP from another company?
No. Do not copy another company’s SSP. An SSP should be unique to your organization—your systems, networks, data flows, policies, and controls. If it does not reflect your architecture, tools, and processes, assessors will certainly flag it. There are also legal and ethical risks, since SSPs contain sensitive security details.
How to maintain a System Security Plan?
Assign ownership for updates to keep the SSP aligned with changes in systems, policies, or contracts. Version control ensures changes are documented, and supporting documents and evidence stay organized.
What if some of my company’s controls are not fully implemented yet?
It’s common to find gaps. Document them in the SSP, track them in a POA&M with remediation steps, prioritize high-risk items, and show progress. Note: CMMC only allows limited POA&M use for certain controls with strict timelines. High-priority gaps must be closed quickly.
How does my SSP relate to Supplier Performance Risk System (SPRS) scoring?
Most defense contractors must submit a NIST SP 800-171 self-assessment score to SPRS. The SSP provides the foundation for that score, documenting how each control is implemented and identifying gaps. Keeping your SSP detailed and accurate ensures your SPRS score is reliable and consistent with auditor findings.
How do SOC 2, ISO 27001, NIST SP 800-53, and NIST CSF relate to my CMMC SSP?
They’re complementary, not substitutes. CMMC Level 2 evidence must map to NIST SP 800-171 controls. Reports like SOC 2 and ISO 27001, and programs built on NIST SP 800-53 or NIST CSF, can support portions of your control environment (especially for inherited vendor controls) and strengthen policies and governance. In the SSP, reference these artifacts where they apply, but still provide CMMC-specific implementation details and evidence.
Can I leverage FedRAMP and FISMA in my SSP?
Yes. FedRAMP authorizations and FISMA-related documentation from cloud providers can substantiate inherited controls (e.g., infrastructure, platform services). Include the provider’s FedRAMP ATO reference, shared-responsibility matrix, and any customer implementation guidance, then show your side of the configuration and monitoring (screenshots, logs). These artifacts support but don’t replace CMMC evidence.
Do I need a risk register and a BC/DR plan in the SSP?
While not always filed inside the SSP, both are expected references. A risk register links open risks and mitigations to specific controls and POA&M items. A Business Continuity & Disaster Recovery (BC/DR) Plan shows how you keep critical functions running and recover systems, including test results. Reference both from the SSP and keep them current.
Should we use an MSSP for CMMC?
If you have limited staff or 24×7 requirements, an MSSP can operate and monitor controls (e.g., EDR, SIEM, vulnerability management). In the SSP, document who does what, how alerts/escalations work, and where evidence (tickets, logs, reports) is stored. MSSP activity must still produce final-form artifacts mapped to the relevant controls.