If you’re preparing for CMMC Level 2 or 3 certification, you are required to create a System Security Plan (SSP) — a detailed document that explains how your company’s information systems (like your network, hardware, and software) are set up to protect Controlled Unclassified Information (CUI).
In this blog post, we’ll break down everything you need to know about writing an SSP, helping you avoid common pitfalls while making the documentation process simpler for auditors, ultimately improving your chances of passing CMMC audits.
What is a System Security Plan (SSP) for CMMC?
A System Security Plan is a document that describes how your company’s systems are built and how you protect sensitive data like Controlled Unclassified Information (CUI). Think of it like a blueprint of your digital organization, showing what you have, how it works, and how you keep CUI safe.
For CMMC Level 2 and above, having an SSP is mandatory. In fact, the proposed CMMC rule references the system security plan requirements on the Federal Register:
“Currently, to comply with DFARS clause 252.204-7012, contractors are required to develop a System Security Plan (SSP) [7]detailing the policies and procedures their organization has in place to comply with NIST SP 800-171. The SSP serves as a foundational document for the required NIST SP 800-171 self-assessment. Self-assessment scores, as referenced in DFARS clause 252.204-7020, must be submitted in the DoD’s Supplier Performance Risk System (SPRS).[8] The highest score is 110, meaning all 110 NIST SP 800-171 security requirements have been fully implemented. If a contractor’s SPRS score is less than 110, indicating security gaps exist, then the contractor must create a Plan of Action (POA) [9] identifying security tasks that still need to be accomplished. In essence, an SSP describes the cybersecurity plan the contractor has in place to protect CUI. The SSP needs to go through each NIST SP 800-171 security requirement and explain how the requirement is implemented, monitored, and enforced. This can be through policy, technology, or a combination of both. The SSP will also outline the roles and responsibilities of security personnel to ensure that CUI is appropriately protected.”
What This Means
No SSP, no certification. Simply put, if you fail to meet Level 2 or Level 3 compliance requirements, your organization won’t achieve CMMC Level 2 or Level 3 certification and will lose any opportunity to bid on or renew US Department of Defense (DoD) contracts.
Beyond compliance, an SSP is extremely helpful for understanding your systems, identifying weak spots, and making continuous security improvements. Even if you’re currently at CMMC Level 1, where an SSP isn’t required, it’s still an incredibly useful document to identify gaps in your existing program and achieve a higher cybersecurity maturity.
Which organizations need an SSP for CMMC?
Companies registered in the US defense industrial base (DIB) that handle CUI will soon be required to meet the standards of the DoD’s Cybersecurity Maturity Model Certification (CMMC) Level 2, which requires having a detailed SSP in place. The applicability of PL-2 (appropriate control for System Security Plan) is determined by the scope of NIST SP 800-53 Revision 5, which is designed for:
Federal agencies: All federal agencies are required to implement the controls specified in NIST SP 800-53 to protect their information systems.
Organizations operating on behalf of federal agencies: This includes contractors, subcontractors, and service providers managing or processing federal information.
How to Get Started with Your System Security Plan
1. Always start with resources from the DoD
A great starting point is to download the CUI SSP Template. While it’s not mandatory to use their exact template, it helps ensure you don’t miss anything important. At a quick glance, here’s what you’ll need to include in your SSP:
- System Overview: The document must give a high-level description of your system. What does it do? How does your system store, handle, and process CUI?
- Users: The SSP must outline the number of end users and privileged users.
- General Description of Information: The SSP must document the CUI information types processed, stored, or transmitted by the system.
- System Environment: The SSP must include detailed topology narrative and diagrams that clearly depict the system boundaries, system interconnections, and key devices.
- Security Controls: You need to go through each security control required by NIST SP 800-171 and explain how your organization is implementing it.
- Updates: The SSP is a living document. You must record all changes and updates to your systems that deal with CUI, specifying who made the change and details associated with the change.
2. Create Diagrams to Show What’s Happening
A picture is worth a thousand words, right? Your SSP should include detailed diagrams to help auditors (and your own team) visualize how your systems are set up.
Network Diagrams: Show how your network is structured and how different parts of it connect.
Data Flow Diagrams: Show how CUI moves through your system—who’s handling it, how it flows from one system to another, and what security is in place at each step.
These diagrams must be accurate. You can use simple tools like Visio or even PowerPoint to map things out. A good starting point for creating an SSP is to utilize tools that are CMMC compliant such as PreVeil. PreVeil offers a Compliance Accelerator with pre-filled CMMC documentation, including an SSP, a customer responsibility matrix (CRM), and a Plan of Action and Milestones (POA&M).
3. Explain How Each Control Is Implemented
For each control specified in NIST SP 800-171, your SSP must provide a detailed explanation of how the control is implemented. Auditors will use the SSP to understand the systems involved and verify that controls are correctly implemented. Thus, our team recommends the following:
- Control Descriptions: For each control, explain how you implemented it and why. Don’t just copy and paste the control; describe how it works in your environment.
- Cross-reference Documents: Ensure the SSP references relevant policies, procedures, and the POAM. This cross-referencing will assist auditors in verifying compliance in an effective manner.
- Document Rationale: For each control, provide a rationale that explains how and why the control was implemented. This helps auditors understand the thought process behind each security measure.
- Avoid marking controls as “Not Applicable”: Auditors prefer to see controls marked as “implemented” or “planned to be implemented.” Even if a control doesn’t directly apply to your environment (e.g., Wi-Fi security), explain how it would be handled if applicable.
Let’s visualize the above with a clearer example. For instance, if the control involves access restriction, you should describe the following:
- Who has access to that component? For example, keep an access control list and maintain a documented process and procedure describing how the list is maintained.
- Who requested access? For example, require tickets from authorized requesters.
- How do you control access? For example, passwords, two-factor authentication, etc.?
- What’s your process for adding or removing users?
- How do you monitor and log access activities?
- What training or awareness programs are in place to ensure users understand access control policies?
Have you read?
How to Prepare for a CMMC Assessment with a C3PAO
10 Red Flags to Consider When Vetting a CMMC Consultant
CMMC Compliance: Be ready to achieve DoD cybersecurity certification
4. Create a Plan of Action (POAM) for Gaps
No system is perfect, and that’s okay. If there are areas where you haven’t fully implemented some applicable controls, you’ll need a CMMC Plan of Action and Milestones (POAM). For CMMC Level 2, out of the 110 security practices required by NIST SP 800-171, only some controls can be listed in a Plan of Action and Milestones (POA&M). Note that for those specific controls, if they are not fully implemented at the time of the assessment, an organization can still proceed with a POAM, provided they plan to address these gaps within a specific timeframe, usually 180 days.
NIST offers a great template for documenting POAMs, which we strongly suggest linking in your SSP document. The POAM shows that even if you’re not fully compliant right now, you have a plan to get there by answering the following:
- What specific steps are required to close the compliance gap? Provide a detailed action plan outlining the necessary corrective measures.
- Who is responsible for implementing these steps? Clearly identify the individual or team accountable for carrying out the remediation.
- What is the timeline for completing each action? Include a realistic schedule with deadlines for each step, ensuring timely resolution.
Organizations with open items in a POAM must have all of them resolved within 180 days from the CMMC audit in order to pass.
5. Keep the SSP Up to Date
Once you’ve created your SSP, your job is not done. Your SSP is a living document, which means it needs to be updated as your systems evolve. Every time you make a change—whether it’s adding new software or tweaking your network setup—you’ll need to reflect that in your SSP.
Whenever your organization introduces a new process or tool, establishes a new user role, or makes any significant changes to your IT environment, it’s crucial to assess whether these changes impact your SSP. Additionally, updates to your SSP—and possibly your security controls—are necessary when new cyber threats or risks are identified.
If your SSP does not accurately reflect the current operational state of your environment, your organization risks being non-compliant with contracts and could potentially face legal consequences, including prosecution under the False Claims Act.
6. Handle the SSP with Care
Your SSP contains a lot of sensitive information about your systems and security. It’s not something you want floating around the office, and it can only be shared with authorized users. We suggest that you:
- Limit Access: Only share the SSP with people that meet your “need to know” requirement.
- Sign Non-Disclosure Agreements (NDAs): If you need to share the SSP with third parties (like auditors or consultants), make sure they sign an NDA and assess their own information security posture.
Overall, creating an SSP might seem like a daunting task, but if you take it step by step, it is manageable. Start by understanding your systems, involve the right people, and use templates like those provided by the DoD to guide you. And remember, your SSP is a living document—it needs regular updates to stay relevant.
If you need help with drafting your first System Security Plan, an expert CMMC implementor from EXTEND Resources can certainly help.
How EXTEND Resources Helps Organizations Create SSPs for CMMC
EXTEND Resources is an industry leader in integrated risk management for information security and data privacy. We help organizations prevent, mitigate, and overcome the risk of loss associated with security and data privacy incidents. When you choose EXTEND for CMMC support, you can expect:
- CMMC Certified Professionals and Registered Practitioners: An expert guide can assess your readiness, lead or assist with your CMMC program implementation, and prepare your organization for certification.
- Streamlined CMMC Compliance: We leverage rapid assessment tools, efficient processes, and a library of policy templates that can be tailored to your organization.
- Expert CMMC Assessment Support: Our internal audit validates your assessment readiness, and the EXTEND team can support you throughout the certification assessment.
- Reduced time and costs: Significantly reduce the time and costs your organization might otherwise incur in trying to understand, implement, and document an effective CMMC program on its own.
- Improved Cybersecurity Maturity: Our team helps you grow beyond CMMC compliance.
Working with EXTEND allows you to identify and address gaps in your cybersecurity program and enhance your organization’s overall cybersecurity maturity.
Contact our team today to get help with your System Security Plan.