What is a System Security Plan (SSP)?

If your defense organization processes Controlled Unclassified Information (CUI), it is essential to develop a System Security Plan (SSP) that aligns with NIST 800-171 standards. A SSP outlines the specific policies and procedures your organization employs to meet these regulatory requirements. More than just an internal document, your SSP must also be comprehensible and convincing to external auditors.

This blog serves as a comprehensive guide to crafting a robust SSP capable of withstanding auditor scrutiny. While creating a CMMC-compliant SSP can seem daunting and time-intensive, this guide will demystify the process and provide practical steps to streamline your efforts.

Quick Guide to Get Started with CMMC

What is a CMMC System Security Plan (SSP)?

A System Security Plan (SSP) is a document that outlines a defense contractor’s cybersecurity strategy for protecting Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). The SSP provides a detailed account of how security controls from NIST SP 800-171 are  implemented, monitored, and enforced through policies, technology, or a combination of both. It also defines the roles and responsibilities of security personnel, ensuring the proper handling and protection of FCI or CUI.

For contractors pursuing CMMC Level 2 compliance, developing an SSP is not optional—it is a mandatory requirement. Since November 2016, NIST 800-171 has stipulated that organizations must:

In the CMMC process, an Authorized Third-Party Assessment Organization (C3PAO) will typically review the SSP as a prerequisite for conducting the Level 2 assessment. If the C3PAO determines that the SSP lacks sufficient detail or does not adequately address the NIST 800-171 requirements, they may deem the organization not ready for assessment. In such cases, contractors will need to revise and strengthen their SSP before the evaluation can proceed.

What Should a System Security Plan (SSP) Include?

A comprehensive SSP should include the following key components:

• Your Scope:
  Clearly document where Controlled Unclassified Information (CUI) is processed, stored, or transmitted within the system. Specify who has access to this information and under what conditions.
• In-Scope Systems:
  Provide a detailed description of system boundaries, system interconnections, and key components within the system environment. This includes servers, networks, applications, and any devices involved in handling CUI.
• Objectives and Metrics:
  Describe how each NIST 800-171 security requirement is being implemented. Include measurable metrics or mechanisms to monitor, assess, and improve the effectiveness of security controls over time.

The more detailed and precise your SSP is, the better. Thorough documentation ensures that your processes are clear and verifiable not only for your team but also for future assessors. It also helps identify gaps, demonstrate compliance, and facilitate continuous improvement.

What is an example of a SSP?

For CMMC Level 2, your SSP needs to go through the 110 controls of NIST 800-171 one by one and explain how you’ll satisfy each and every one of them. Each control can be satisfied by technology, policy or a combination of both.

If a control can be met by technology, the IT team can simply state that the control is met by a technology solution. If, however, the control is met by a training or an incident response plan, then explaining the process of how the organization meets those requirements becomes much more complex. Many contractors will turn to a certified consultant to assist in this process who is better able to provide an overview of the security controls used by the organization.

Example for control AC L1-3.22

This control states:

The policy could state:

• No CUI or FCI will be posted on our public-facing websites
• There are three roles that can post information on the company’s public facing website: Admin, Power user, Author
• The Compliance Officer will review all materials before they are posted to the website
• If FCI or CUI is accidentally posted (spillage), we will follow the procedure referenced in our Incident Response Plan – See Incident Response Plan (Document 21)

In addition, the organization will need to demonstrate that they have absorbed the lessons of this control and made it part of their standard behavior.

CA.L2-3.12.4 provides a slightly more detailed example. The control states that contractors must:

The supporting policy might state:

1. The organization will ensure that the SSP is updated, at least annually, and whenever necessary procedural updates are required.
2. The organization will only allow those resources with full background checks to act as Administrators. Those Administrators will be the only authorized resources to update the SSP.
3. The Acting Authority for the organization (i.e., the CEO, CISO, CTO, etc.) will finalize the SSP and the SSP will not be active until the finalization, via signature, of the Acting Authority.

The associated procedures documented within the SSP could then state:

1. The SSP will be updated every year, or as needed. To ensure this, the Administrator of the SSP will complete the Version History of the SSP to include:
   -The date the SSP was updated
   -Updates made to the SSP
   -Administrator responsible for the updates
   -Updated version number of the SSP
2. Administrators of the SSP will complete the following tasks before being eligible to update the SSP:
   a. Complete a full Top-Secret Tier 5 background check that must be fully adjudicated (not Interim)
   b. The Acting Authority assigns the resource with the Administrator role
   i. The Acting Authority will assign the role of Administrator through the creation of a ticket in the internal company ticket system.
   ii. That ticket will then be routed to the IT Manager
   iii. The IT Manager will then update the Roles and Responsibilities matrix to ensure that the new Administrator’s information is correctly reflected
3. Once updates are completed for the SSP, the document will go through the document review process:
   a. Document is sent via email or shared drive link to the authorized Document Reviewer listed on the Roles and Responsibility matrix.
   b. The document reviewer will review the document and then submit it to the Acting Authority with any additional information required.
   c. The Acting Authority will review the document and ask any questions or gain any additional clarification from the Administrator before ensuring that the document is signed and then disseminated to all stakeholders.

And this control is not unique in its complexity. Many of the NIST 800-171 controls require this level of detail in order to fulfill the requirements of building an accurate SSP and creating an SSP that could pass an audit.

How is a SSP Assessed?

The effectiveness of a System Security Plan (SSP) is evaluated by assessing its alignment with the security requirements outlined in NIST 800-171. Assessors for CMMC Level 2 will examine whether the plan thoroughly addresses potential risks and implements appropriate security controls across key areas, including access control, data protection, system hardening, incident response, and vulnerability management. This evaluation involves a combination of document reviews, system testing, and interviews with system administrators to validate the SSP’s accuracy and practical effectiveness.

How to create a CMMC SSP

As you see above, creating an SSP can be a time consuming process. What can you do to reduce the burden?

1. Self-assess first.

The best way to get started in creating your organization’s SSP is to start with a self-assessment against the 110 NIST 800-171A requirements. This exercise will force you to review each control and take an inventory of what you have in terms of policy, technology. From there you can see the gaps of which controls you need to work on or which ones you already meet.

2. Use a template

After completing a self-assessment, you should download one of the many SSP templates available online and start writing the documentation for each control. Then you have the outline for your SSP.

The disadvantage of attempting to create an SSP in-house is that there are many nuances to writing up the processes and creating the robust documentation you will need. Indeed, trying to do it on their own is where many contractors fail. A typical SSP along with its supporting documentation ranges from 80-120 pages. Without the help of a trained consultant or expert, your SSP policies and procedures will likely not align because you are not implementing the processes you claimed to. As a result, your SSP won’t pass an audit.

How PreVeil can help

PreVeil can reduce the need for expensive external consultants. We offer a Compliance Accelerator with pre-filled CMMC documentation, including an SSP, a customer responsibility matrix (CRM) and Plan of Action and Milestones (POA&M) for the controls that PreVeil doesn’t meet.

While PreVeil’s template still requires contractors to customize the SSP to how their environment works, the CRM saves contractors hundreds of hours of prep and consultant time. PreVeil’s documentation helps contractors know who is responsible for meeting the control- whether it is their organization, PreVeil or AWS – for example. And the Compliance Accelerator includes a POA&M for the controls that still need to be met.

PreVeil can also assist contractors in finding a compliance expert who understands the CMMC landscape and can help their business work through their compliance questions. With PreVeil, customers have a partner, not just a solution.

Conclusion

If you’re a defense contractor, you must create a SSP in order to continue working with the Department of Defense (DoD). If you don’t already have a robust SSP that can stand up to an audit, then you’re already in breach of compliance.

Reach out to one of our compliance experts for a free 15 minute compliance consult or learn more about how to get a copy of PreVeil’s SSP.