System Security Plan: What is It, Who Needs One, and Why?

If your organization handles sensitive data—especially controlled unclassified information (CUI) belonging to the US government—you probably need a System Security Plan (SSP) to comply with cybersecurity regulations. For example:

• Defense suppliers, institutions of higher education (IHEs), and many others in the US government supply chain are currently mandated to comply with the NIST 800-171 standard to protect CUI, which mandates an SSP.
• All US government agencies and their contractors must comply with NIST 800-53, “Recommended Security Controls for Federal Information Systems and Organizations,” which requires an SSP.
• If your business participates in US Department of Defense (DoD) contracts, the Defense Federal Acquisition Regulation Supplement (DFARS) clause in your contract requires you to have an SSP.
• Firms in the US defense industrial base (DIB) that handle CUI will soon be required to comply with the DoD’s Cybersecurity Maturity Model Certification (CMMC) at Level 2, which calls for an SSP.
• The Federal Information Security Management Act (FISMA) requires all US government agencies and their third-party partners to create an SSP to support the implementation of security controls.
• Any cloud service provider (CSP) seeking a FedRAMP Authority to Operate (ATO) must provide an SSP during the application process.

What is a System Security Plan?

An SSP is a comprehensive, dynamic document that outlines the security controls that an organization has in place to protect its IT systems and ensure the confidentiality, integrity, and availability of CUI and other sensitive data. It is a foundational element of a robust cybersecurity program and a primary prerequisite for achieving compliance.

NIST defines an SSP as: “A formal document that provides an overview of the security requirements for an information security program and describes the security controls in place or planned for meeting those requirements.”

An SSP’s purpose is to give auditors and other stakeholders evaluating your cybersecurity posture a readable overview of your security requirements and the controls you have in place or planned to meet the requirements. It usually includes specifics about the system boundaries (aka scope), system components, network configurations, physical and logical access controls, connections to other systems, contingency procedures, and incident response plans.

Other information found in many SSPs includes:

• Security standards and frameworks that the business complies or aligns with
• Roles and responsibilities of security team members
• References to applicable policies and procedures
• Data flow diagrams and other diagrams showing how systems communicate
• Goals and strategies for the cybersecurity program, such as working toward a zero-trust architecture or implementing a defense-in-depth strategy

What are the benefits of having an SSP?

Besides enabling many organizations to achieve or maintain cybersecurity compliance, an SSP offers many other benefits and advantages, such as:

• Laying the groundwork for risk assessment and risk management
• Helping companies identify potential cybersecurity risks
• Enabling businesses to prioritize and allocate resources to mitigate cybersecurity risks
• Ensuring firms meet contractual obligations for protecting stakeholder data

Most importantly, an effective SSP is a vital control that helps organizations to better protect their systems and data from malicious intrusion, exfiltration, and other attacks.

How do we create an SSP?

Creating and maintaining an SSP is a complex process that can require significant expertise. Here are some of the most important initial steps in developing an SSP:

• Define your SSP scope.
  This is one of the most challenging aspects of creating an SSP. What systems, data, and other physical and virtual assets will be covered by the cybersecurity framework(s) you need to comply with? For example, if you need to comply with NIST 800-171 to protect CUI, what systems store, process, and/or transmit CUI? Where does CUI flow across your organization? What staff or roles, including remote employees and vendors, handle CUI?
• Gather all your current documentation.
  As input for your SSP you’ll need all the documentation, policies, procedures, etc., that describes the current security posture for the “in-scope” portion of your IT environment. You should also confirm with your security/IT team that everything is updated to the current operational state. If you need additional documentation for your SSP, you may need to conduct interviews and other research.
• Identify in-scope security controls.
  What controls do you currently have in place to support compliance? What policies and procedures (e.g., your incident response plan and/or disaster recovery plan) relate to your compliance posture? Vulnerability management, patch management, configuration management, security awareness training, and access controls all factor into the SSP.
• Establish cybersecurity objectives and metrics.
  Along with your SSP scope and in-scope controls, you need to document objectives and metrics for your cybersecurity program. This will help ensure an ongoing best-practice implementation that addresses all critical areas, so no compliance requirements are overlooked. Defining metrics to measure and report on performance and progress toward objectives is key.
• Document how you manage vendor risk.
  Many cybersecurity frameworks that require an SSP, such as CMMC Level 2 or FISMA, also require organizations to establish and document controls to evaluate, monitor, and reduce cyber risk and compliance associated with third-party systems and third-party access to systems. This entails ongoing due diligence such as processing self-report questionnaires, reviewing security policies, or conducting on-site audits for highest-risk vendors.
• Document plans for continuous improvement.
  An SSP should describe how an organization will monitor and maintain compliance, as well as how it plans to improve its current cybersecurity posture. This includes procedures for risk assessment, vulnerability assessment, threat modeling, internal audits, and other evaluations aiming to identify overlooked or evolving compliance or security gaps. It might also include longer-term, proactive goals like implementing a governance, risk, and compliance (GRC) solution or security information and event management (SIEM) solution. Part of any review process should be to apply the findings to updating the SSP.
• Don’t hesitate to use an SSP template.
  NIST, the DoD, and others recommend flowing your SSP into a template to confirm it is complete, accurate, and properly organized. There is no one “official” or required SSP template. While some organizations have the necessary expertise in-house to populate an SSP template, many engage a third-party for added experience and objectivity. This approach can save time and money while reducing compliance and audit risk.

System Security Plan FAQ

Does my organization “really” need an SSP?

If you can’t show stakeholders a robust SSP, you are conceding your inability to protect CUI and other sensitive data. Can you afford not to meet market requirements?

Especially if you want to do business with the US government, an SSP is now a must.

An SSP has been required for participation in DoD contracts since December 31, 2017. The DoD’s compliance assessment guidance directs auditors to review an organization’s SSP as the first step in validating compliance prior to contract award. No SSP means no DoD contract award or renewal.

Does creating an SSP require an internal audit?

An up-to-date self-assessment or internal audit against your compliance requirements is important for identifying applicable controls and identifying how they operate—as well as illuminating any compliance gaps.

A self-assessment will also help you inventory policies, procedures, and relevant assets you need to reference in your SSP.

What information should be in an SSP?

Many of the cybersecurity frameworks that require an SSP, such as NIST 800-171 and CMMC, focus on protecting CUI. In that case, your SSP should also focus on CUI. Some of the information your SSP should communicate to auditors and other stakeholders includes:

• All the different types of CUI your organization handles
• What you do with each type of CUI
• When, where, and how you store, process, and/or transmit CUI
• All the procedures and other controls you have in place or planned to safeguard CUI
• Any gaps in your compliance posture, along with Plans of Action & Milestones (POA&Ms) to close those gaps
• A high-level view of your CUI environment/scope. This could be your whole IT environment, or more likely a subset of it.

How many pages long is an SSP?

SSPs and supporting documentation usually range from 80 to 150 pages up to 500 pages.

The amount of detailed required to support a compliance audit is one reason why building an SSP, even from a template, can be a time-consuming process.

How often should we update our SSP?

An SSP must be reviewed and updated frequently or continuously to support compliance and help demonstrate robust cybersecurity. The update frequency can vary depending on industry, risk levels, data under protection, rate of changes to the security controls, and other factors.

Anytime your business adds a new process or tool, creates a new user role, or otherwise materially changes your IT environment, you need to check whether it impacts your SSP. You also need to update your SSP—and possibly your controls—in response to newly identified cyber threats or other risks.

If your SSP fails to reflect the true operational state of your environment, your company could be noncompliant with contracts and/or could face prosecution under the False Claims Act.

How is an SSP different from a security policy?

An SSP is a comprehensive document that describes an organization’s cybersecurity controls to protect CUI and other sensitive data. Its purpose is to give auditors and other stakeholders a readable overview of a company’s security requirements and the controls in place or planned to meet the requirements. An SSP includes a wide range of specifics about scope, components, configurations, assets, and more.

A security policy document, in contrast, outlines an organization’s high-level approach to security, including its security strategy in relation to business goals.

In short, a security policy describes the “what” and “why” of a company’s security program while an SSP describes the “how.”

Does our SSP need to identify specific cyber threats?

An SSP can optionally identify the specific types of cyber threats that an organization seeks to guard against.

Threats nearly all organizations face include ransomware and other malware attacks; unauthorized access to networks, systems, and data; data exfiltration; and insider threats. Depending on your industry and what data your hold, some businesses are more likely than others to face certain threats, like denial of service (DoS) attacks and advanced persistent threats.

What’s next?

Every supplier that needs an SSP must ensure it is compliant with regulations, accurate, and useful to auditors, clients, and other stakeholders. A common question is, where do we begin?

The main advantage of working with a specialist consultant is you can rest assured your SSP will meet all contract and compliance requirements. Pivot Point Security is a leading consulting firm with extensive experience helping organizations of all sizes achieve compliance and certification against leading cybersecurity frameworks like NIST 800-53, NIST 800-171, ISO 27001, FedRAMP, HITRUST, and more.

To get started on producing a compliant SSP that meets all your business and technical requirements, contact Pivot Point Security.