If you’re a defense contractor and have a DFARS 7012 clause in your contract, and handle CUI then you will need a System Security Plan (SSP) to comply with  the NIST 800-171 requirements. Your  System Security Plan (SSP) will spell out the policies and procedures your organization has adopted for that compliance. Importantly, this documentation cannot just make sense to you – it also has to make sense to a potential outside auditor.

This blog will provide a helpful guide for how to create a sufficiently robust SSP that can meet the scrutiny of auditors. Creating a CMMC SSP can be challenging and time consuming, but the process doesn’t need to be opaque.

What is a CMMC System Security Plan (SSP)?

In essence, an SSP describes the cybersecurity program that a defense contractor has in place to protect CUI. The SSP needs to go through each NIST 800-171 control and include how the control 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.

Creating a SSP is not optional. It has been required by NIST 800-171 since November 2016. NIST 800-171 control security requirement 3.12.4 states that organizations must:

“develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationship with or connections to other systems.”


An SSP is also required in order to achieve DFARS 7012, DFARS 7019, and soon-to-be CMMC compliance. DFARS 7012 requires NIST 800-171 compliance and DFARS 7019 requires contractors to submit their NIST 800-171 self assessment scores in the SPRS database. This score can only be accurately calculated and submitted if a contractor has a SSP in place.

What information should an SSP include?

For defense contractors handling CUI, an SSP must include the following key components:

  • Document where CUI is “processed, stored, or transmitted by the system” and who has access to the information.
  • Clearly detail the system boundaries, system interconnections, and key devices found in the system environment.   
  • Provide a thorough description of how all of the security requirements are being implemented or planned to be implemented. 

The more detailed your SSP is, the better! The details will help ensure that your processes are clear not just to you but to any future assessors. 

What is an example of an SSP?

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:

Control information posted or processed on publicly accessible information systems.

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:

Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

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 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 CMMC SSP compliance documentation package for organizations that have deployed our Email and File Sharing platform for protection of CUI.

PreVeil’s package provides you with a SSP template for all NIST 800-171 controls which PreVeil meets as well as policy templates for all 14 NIST families. PreVeil also provides 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 template to how their environment works, the CRM saves contractors hundreds of hours of prep and consultant time. PreVeil’s template helps contractors know who is responsible for meeting the control whether it is their organization, PreVeil or AWS – for example. And the PreVeil SSP template provides a POA&M for the controls left unmet by our existing package.

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.


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.


Frequently Asked Questions about SSPs

Is an SSP Mandatory?

Yes, an SSP is mandatory. According to NIST 800-171 control 3.12.4, “The absence of a system secuirty plan would result in a finding htat ‘an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204.7012”

How many pages long is an SSP?

A typical SSP along with its supporting documentation ranges from 80-120 pages.

How often should I update my organization’s SSP?

An organization should ensure that the SSP is updated, at least annually, and whenever necessary procedural updates are required.