What is an SSP (System Security Plan)?

A System Security Plan (SSP) is a living document that outlines how your organization implements cybersecurity requirements, specifically those outlined in NIST SP 800-171, for handling Controlled Unclassified Information (CUI).  

At its core, the SSP answers these questions:  

• What systems are in scope?  

• Servers  

• Workstations  

• Cloud Providers  

• Etc...   

• What’s the operational (data flow) environment?  

• How does CUI move throughout the environment?  

• How are security controls implemented?  

• Think of the SSP as the architectural blueprint for your cybersecurity house. The foundational document guides your security strategy and proves to the DoD that you’re protecting the data they’ve entrusted to you.  

 

Who Needs an SSP?

Every DoD contractor with DFARS 252.204-7012 in their contracts.  

If you're touching CUI in any form or have the potential to the SSP is not optional. It's not a “nice to have.” It's a non-negotiable compliance requirement under:  

• DFARS 252.204-7012  

• DFARS 252.204-7019  

• DFARS 252.204-7020  

• And critical for CMMC Level 2  

If you’re aiming for CMMC certification, your SSP will be the first document your assessor asks for. If it's missing or weak, your assessment ends there. No SSP = no score = no business with the DoD.  

 

 

 

Why SSPs Matter: More Than a Checkbox 

SSPs have been around longer than most of us have been in the business, tracing their roots back to the Computer Security Act of 1987. This isn’t a new idea; it’s just finally being enforced.  

Here’s why SSPs are mission-critical:  

• They determine if your assessment can even begin.  

• They’re explicitly required by DFARS and the DIBCAC Assessment Methodology.  

• They protect you from False Claims Act violations that cost contractors millions.  

• They help you operationalize your security strategy by mapping your implementation to actual NIST 800-171 controls.  

• They enable SPRS scoring. You can’t score your implementation without a documented plan.  

 

 

Required Contents of an SSP

Straight from NIST SP 800-171, your SSP must document:  

• System boundaries  

• Operational environment  

• Implementation of each security requirement  

• Connections and relationships with other systems  

 

Additionally, robust SSPs typically include:  

• Network diagrams  

• Roles and responsibilities  

• Configuration baselines  

• Shared responsibility matrices (for MSPs and cloud services)  

• Security policies mapped to each control  

• Defined parameters for implementation (e.g., password length, session timeout)  

• Identification of common, hybrid, and system-specific controls  

 

Your SSP must describe how you’re meeting all 110 controls, including 320 Assessment Objectives, not just list that you’ve done them. That’s why five-page SSPs get flagged. There’s simply no way you’ve implemented the full intent of NIST 800-171 in a few pages.  

 

 

How Do You Create an SSP?

Creating an SSP isn't about filling in a template. It's about documenting the real-world implementation of each requirement.  

Here’s how to get started:  

1. Scope your environment. Identify what systems store, process, or transmit CUI.  
2. Describe your systems. Include boundaries, architecture, services, and external connections.  
3. Map to NIST 800-171A. Use the assessment objectives to document how each control is implemented.  
4. Write real implementation descriptions. Explain what was implemented, how it works, and where it lives.  
5. Include diagrams, roles, and responsibilities. Use visuals and RACI charts where appropriate.  
6. Keep it updated. Define how often the SSP will be reviewed — at least annually or whenever there is a significant system or risk change.  

Pro Tip: Your SSP must show how you satisfy each of the 320 assessment objectives in NIST SP 800-171A. That’s the bar your C3PAO assessor will be measuring against.  

 

 

How Often Should You Update an SSP?

Your SSP should be reviewed and updated:  

• At least once every 12 months  

• When significant system changes occur  

• After incidents or new threat discoveries  

This isn’t just best practice, but it’s a requirement under the upcoming NIST SP 800-171 Rev. 3 and the existing SPRS scoring guidance. You're not audit-ready if you haven’t touched your SSP in over a year.  

 

 

SSP vs. POA&M: What’s the Difference?

While the SSP documents how your organization currently meets the requirements of NIST 800-171, the POA&M (Plan of Action and Milestones) outlines how you plan to address any gaps or unmet requirements. Think of the SSP as your current state — your actual security architecture and processes — while the POA&M is your to-do list for remediation.   

However, under CMMC Level 2, POA&Ms are effectively obsolete because CMMC is pass/fail — you can't pass by promising to fix things later. That’s why your SSP must fully and accurately reflect your implemented controls, not your intentions.  

The one caveat here is that 1-Point controls can grant you a conditional pass, but you have to remediate before you formally receive a certification.   

 

 

Ready to Build a Real SSP — Not Just a Template?

Ask any C3PAO or cybersecurity expert who’s been through a CMMC Level 2 assessment: a detailed, well-structured SSP is the #1 indicator of success.  

Most SSPs fail because they’re generic, incomplete, or written without the context of NIST 800-171A. That’s why we built Commander — the platform designed by the Summit 7 team specifically to help DoD contractors generate, manage, and maintain audit-ready System Security Plans.  

Whether you’re:  

• Starting from scratch,  
• Updating a stale, underwhelming SSP,  
• Or trying to pass a CMMC Level 2 assessment…  

Commander gives you the structure, logic, and automation you need — built by people who’ve worked with assessors.  

 

 

Frequently Asked Questions

Is there a required format for a System Security Plan?  

No. NIST has not published a required or standardized format for SSPs. However, DFARS and CMMC assessors expect a clear, detailed document that explains exactly how your controls are implemented. The community standard has become an SSP structured around the 800-171A assessment criteria, even though NIST hasn’t made that official.  

 

What happens if I don’t have a complete SSP?  

Without a valid, complete SSP:  

• You can’t be assessed for CMMC  

• You can’t submit a valid SPRS score  

• You may violate the False Claims Act enforcement (yes, companies are already getting fined)  

• You won’t win or renew DoD contracts  

 

Can one SSP cover multiple systems or locations?  

Yes, but with caution. A single SSP can cover multiple systems or locations only if they share the same security posture, policies, and control implementations. If your corporate headquarters and production facility have different configurations or access controls, document them as separate systems or segmented sections within a larger SSP. Otherwise, your plan may be vague and flagged during an assessment.  

 

What’s the difference between an SSP and a POA&M?  

An SSP describes how you’ve implemented your cybersecurity requirements. A POA&M (Plan of Action & Milestones) lists the gaps — the things you haven’t done yet and how/when you plan to fix them.  

With CMMC, POA&Ms are mainly off the table. For CMMC Level 2, you must have fully implemented and documented controls — no “we’re working on it” allowed. That’s why the SSP is critical: it’s the document that proves full implementation.  

 

Who should write the SSP — IT, consultants, or someone else?  

Creating an SSP is a cross-functional team effort. IT and security teams will do most of the technical heavy lifting, but operations, HR, and leadership must also contribute. You need someone who understands how your business functions, how systems interact, and who’s responsible for what. Many organizations hire consultants or MSSPs to assist, but internal accountability is key.  

 

What tools can help me build or manage an SSP?  

Several tools can help you build or maintain an SSP:  

• Microsoft Compliance Manager (for M365 GCC/GCC High environments)  
• Governance, Risk, and Compliance (GRC) platforms  
• SSP templates tailored to NIST 800-171A  
• Shared Responsibility Matrix (SRM) tools from providers like Summit 7  

Remember: the tool doesn’t make your SSP compliant — your implementation does. Choose tools that help you map control ownership, evidence, and documentation.  

 

Is the SSP confidential? Do I need to share it?  

Your SSP is considered sensitive but unclassified (not CUI). It should be protected internally (not stored on public drives or emailed freely), but you must be prepared to share it:  

• With DoD contract officers  
• During a DIBCAC High/Medium assessment  
• During a CMMC certification by a C3PAO  

If your SSP contains sensitive corporate IP, mark it appropriately and follow proper CUI handling practices. 

 

---