What is a System Security Plan (SSP)?

If your 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 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, this guide will demystify the process & list the steps to streamline your efforts.

What is an 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 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 an SSP include?

A comprehensive SSP should include the following components:

• Your Scope: Clearly document where 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.

How to create a SSP (with examples)

Creating an SSP can be a time consuming process, but here is the best way to approach creating the program.

Step 1: Complete a Self Assessment

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.

Step 2: Utilize an SSP Template

After completing a self-assessment, you should download one of the many SSP templates available online, like this one provided by NIST, and start writing the documentation for each control. Then you have the outline for your SSP. You can also utilize solutions like PreVeil’s Compliance Accelerator, which can cut down documentation work by 60%. It includes pre-filled SSP documentation that explains how a customer can meet NIST 800-171/A controls.

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 training or a CMMC consultant, 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.

Step 3: Identify the Controls

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.

Step 4: Address the Controls

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. Whether you’re creating this in-house or you’re using a consultant, knowing exactly how controls can be addressed is helpful, which is why we’ve included an example below.

Example of How a SSP Addresses a Specific Controls: 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.

Example of How a SSP Addresses a Specific Controls: CA.L2-3.12.4

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

The supporting policy might state:

• The organization will ensure that the SSP is updated, at least annually, and whenever necessary procedural updates are required.
• 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.
• 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:

• 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
• Administrators of the SSP will complete the following tasks before being eligible to update the SSP:
  • Complete a full Top-Secret Tier 5 background check that must be fully adjudicated (not Interim)
  • The Acting Authority assigns the resource with the Administrator role
    • The Acting Authority will assign the role of Administrator through the creation of a ticket in the internal company ticket system.
      • That ticket will then be routed to the IT Manager
        • The IT Manager will then update the Roles and Responsibilities matrix to ensure that the new Administrator’s information is correctly reflected
• Once updates are completed for the SSP, the document will go through the document review process:
  • Document is sent via email or shared drive link to the authorized Document Reviewer listed on the Roles and Responsibility matrix.
  • The document reviewer will review the document and then submit it to the Acting Authority with any additional information required.
  • 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.

Frequently asked questions about SSPs

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.