What is a System Security Plan (SSP)? Everything You Need to Know

If your organization handles Controlled Unclassified Information (CUI) on behalf of a federal agency or the Department of Defense (DoD), you’ll need a System Security Plan (SSP) to meet DFARS 7012 and CMMC Level 2 cybersecurity requirements.

Without an SSP you can’t pass a CMMC Level 2 assessment, and without meeting CMMC Level 2 requirements your organization will not be eligible for any government contracts that require the handing of sensitive information like CUI.

Here’s what you need to know about SSPs and how to get started drafting your own.

What Is a System Security Plan (SSP)?

A system security plan is a formal, living document that provides an overview of the security controls, procedures and policies a DoD contractor has in place to protect  Controlled Unclassified Information (CUI). It outlines how your organization meets the requirements and standards needed for NIST SP 800-171.

Think of it as the "single source of truth" for your security program. Something that an external auditor can review to get a complete picture of how your organization tackles cybersecurity from the roles and responsibilities of people on your team to the security controls you’ve implemented to ensure the safeguarding and protection of CUI.

If you’re working towards CMMC Level 2 (the level required for handling CUI) an SSP is mandatory under NIST 800-171, which requires service organizations to "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.”

During a third-party CMMC assessment the C3PAO will expect to see a fully updated SSP. In fact, without one, you can’t pass the assessment. The C3PAO can also fail your organization if the SSP does not meet the required level of detail or if the SSP doesn’t fully reflect NIST 800-171 requirements.

When Do You Need an SSP?

While good security practice suggests everyone should have one, there are specific triggers that move the SSP from a nice to have to mandatory:

• FISMA: All federal agencies are required by law to maintain SSPs for their information systems.
• DFARS 7012 & CMMC: If you are a defense contractor handling Controlled Unclassified Information (CUI), you are contractually obligated to have an SSP. With the CMMC compliance deadline looming, an SSP is essential to passing your CMMC Level 2 audit.‍
• FedRAMP: For FedRAMP, the SSP is the central document in the authorization package, describing how every required security control is implemented in your cloud service.”

Why SSPs are Important

They Enable Auditors to Move Forward

If you’re preparing for or undergoing a CMMC Level 2 assessment, your System Security Plan (SSP) is one of the primary artifacts assessors rely on. If a control isn’t clearly documented in the SSP or its referenced policies and procedures, for assessment purposes it may be treated as not implemented.

Internal Knowledge Sharing

In many fast-growing startups, the security knowledge can sometimes centralised around a few people in your security team creating a single point of failure. FOr example, if your CTO isn’t around, and they’re the only person who knows how your firewall works, that’s an issue.

The SSP forces you to extract that knowledge from your security leadership and document the who, what, and where of your security posture.

Gap Identification

Writing an SSP is a forcing function. You can't write a narrative for a control you haven't implemented. If the requirement says "Implement FIPS-validated cryptography" and you realize you're using standard AES, the SSP process forces you to identify that gap.

What Should a System Security Plan (SSP) Include?

When it comes to producing an SSP, details matter. A robust SSP should be the operational manual for your security program. It needs to describe how you are meeting NIST SP 800-171 requirements, not just state that you are meeting them.

To comply with NIST SP 800-171, your SSP (and its supporting documentation) is expected to clearly document things like:

• System indentifictaion and boundaries: Defining exactly what is inside your secure perimeter and what is outside.
• Operational environment: describing the hardware, software, and firmware that make up your system.
• Implementation of security requirements: A control-by-control explanation of how you satisfy security mandates.
• Connections: How your system relates to or connects with other external systems.‍
• Roles and responsibilities: Who manages the firewalls? Who approves access requests?.‍
• Configuration baselines: The standard settings for your operating systems and software.‍
• Shared responsibility matrices: Crucial for companies using MSPs or cloud providers (like AWS or Azure), defining which controls they handle vs. which ones you handle.‍
• Security policies: Mapping your high-level policies directly to specific controls.

Here's more detail on the key aspects of an SSP:

System Identification

This is the foundation of your SSP as you can't secure what you can't see. Your SSP must list every single asset that falls within your boundary.

• Hardware: Specific make/model of servers, employee laptops, mobile devices, and networking gear (firewalls, switches).
• Software: Operating systems (versions/builds), installed applications, security agents (EDR, antivirus), and firmware.
• External Services: Every cloud service involved in processing data, including AWS/Azure instances, SaaS tools (Slack, Jira, GitHub), and Managed Service Providers (MSPs).

Why it matters: During an audit, an assessor might pick a random laptop or server from your office and ask to see it on the list. If it’s not there, it’s an unauthorized device, and you have a finding.

Network Architecture

You can't describe a network complexity purely in text. You need high-fidelity topology diagrams that visually represent the environment.

• Authorization Boundary: Clearly draw a line around what is "in scope" vs. "out of scope."
• Ingress/Egress Points: Show exactly where data enters and leaves (Internet gateways, VPNs, MPLS lines).
• Subnets & Segmentation: distinct zones for DMZ, Production, Corporate, and Guest networks.
• Data Flow: For CMMC, you need a dedicated diagram showing the lifecycle of CUI (Controlled Unclassified Information) - where it is received, processed, stored, and transmitted.

The Controls

This is the meat of the document. You must go line-by-line through the framework (e.g., the 110 controls of NIST 800-171) and describe how you satisfy each one.

• Don't regurgitate the rule: If the control says "Limit system access," do not write "We limit system access."
• Describe the mechanism: Write "Access is limited via Okta SSO (MFA required). Active Directory groups 'Admin' and 'User' control file permissions. New accounts require ticket approval from the Security Manager."
• Shared Responsibility: If you are on AWS, explicitly state which parts Amazon handles (physical security of the datacenter) vs. what you handle (configuring the security groups).

Roles and Responsibilities

You need to move away from "The CTO does everything." The SSP must define specific security roles to ensure separation of duties and continuity.

• Operational Roles: System Administrators, Database Admins, Network Engineers.
• Oversight Roles: Information System Security Manager (ISSM), Security Officer, Audit Lead.
• Responsibilities: Clearly map who is responsible for patching, who reviews the logs, and who authorizes new user accounts. This ensures that if key personnel leave, the security program doesn't collapse.

Interconnections

Your system does not exist in a vacuum. You must document every connection to an external system.

• APIs & Integrations: Connections to Stripe, Salesforce, HubSpot, or banking APIs.
• Vendor Tunnels: Does your MSP have a persistent VPN tunnel into your network for support?

Risk: These are common attack vectors. You need to document the security of these pipes - specifically how they are encrypted (e.g., TLS 1.2+) and authenticated (e.g., mutual TLS, API keys).

Defining Your System Scope

Scope is another key part of your SSP, it needs to clearly document where Controlled Unclassified Information (CUI) is processed, stored, or transmitted within your organization. Including a detailed description of servers, networks, applications, and devices involved in handling CUI, as well as details who can access CUI and under what conditions.

Many organizations choose to create a CUI enclave for their CMMC audits so that the whole company (and every employee and device) doesn’t fall into the audit scope. Without a CUI enclave/boundary, you may have to apply strict CMMC compliance controls to the marketing team's Macs and the HR department's emails.

By defining your scope upfront, you limit the audit to that specific enclave. This can save you hundreds of thousands of dollars in implementation and certification costs.

Objectives and Metrics

Your SSP must also tackle the granular details. You can’t just list that you meet a requirement, you must describe how each NIST 800-171 requirement is being implemented.

Assessors evaluate your organization against the 110 NIST SP 800-171 security requirements, which are broken down into 320 assessment objectives in NIST SP 800-171A. Your SSP and supporting documents should be detailed enough that an assessor can map your implementation to each of those objectives.

How to Create a System Security Plan for CMMC and NIST

Creating an SSP is a big undertaking. Here’s how to approach putting one together for your organization:

1. Gap Analysis

Before you write a single word, you need to audit your security posture. You can run a CMMC gap assessment to see where you stand against the 110 NIST 800-171 controls, helping you to understand where you’re at in terms of implementation and policy development.

Once you’ve found the gaps, you can build a plan to get fixes into place and develop your SSP.

2. Start Documenting

Grab an SSP template document (here’s one from NIST) and begin documenting each control your organization has implemented. Be as detailed as possible, for example:

• Instead of… "We log system events and review them periodically."
• You might say… "System logs are aggregated via Amazon CloudWatch and exported to an S3 Glacier vault with a 365-day retention policy. The Security Analyst reviews the 'Critical Events' dashboard weekly every Monday morning."

With each of your systems, you need to define what was implemented, how it works, where it lives and also include any relevant diagrams and details of who (people and team) are responsible for each part of your system.

Pro Tip: You don’t have to go it alone. A complete SSP can be over 100 pages long. That’s a lot of documentation to put together, especially if you’ve never been through a CMMC audit before. If you work with a CMMC RPO (Registered Provider Organization), their team will be able to help you develop your SSP to ensure it’ll pass the audit.

Workstreet is the only AI-powered RPO and we can help your team automate your CMMC Level 2 compliance and get your organization audit ready fast.

Build Your SSP with Workstreet

The SSP is not just a line item to check off your list. It’s the blueprint of your security program and an essential part of CMMC Level 2 success.

Don't let your SSP stall your progress and put your DoD contracts at risk. If you want to automate the heavy lifting of writing your SSP, Workstreet's CMMC and GRC services can help you build a living, audit-ready security plan in a fraction of the time.

Most SSPs don’t pass audits because they lack detail. Our expert team can ensure your SSP matches the context and detail needed for NIST 800-171A. Get in touch to discuss your SSP and progress towards CMMC here.

SSP Frequently Asked Questions

What’s the Difference Between an SSP and a POAM?

The SSP documents compliant controls that are in place right now. The POAM (Plan of Action and Milestones) documents controls that are missing and your plan/timeline to fix them. You need both to present a complete picture of your compliance posture.

How Detailed Does An SSP Need to Be?

It needs to be detailed enough that a C3PAO can understand every aspect of your system and how it meets NIST 800-171 requirements without the need to speak to your CISO or anyone on your team.

Do I Need an SSP if All My Data is in the Cloud (AWS/Office 365)?

Yes. You operate under a Shared Responsibility Model. AWS secures the cloud (the physical data centers), but you must secure what you put in the cloud (access controls, MFA, data classification). You must document your side of that responsibility in your SSP.

How Often Must the SSP Be Updated?

At least annually, but technically whenever a significant change occurs in your environment (e.g., new OS, new cloud provider, office move). It is a living document and must reflect your security posture in the moment.

Can I Use a Template SSP ?

For structure? Yes. For content? No. An SSP must reflect your specific environment.

Will the C3PAO Read the SSP During a CMMC Assessment?

It is usually the first thing they read. If the SSP is messy, vague, or inaccurate, the assessor will likely pause the assessment before even looking at evidence, assuming the organization is not ready.