What is a System Security Plan (SSP)?
A System Security Plan (SSP) is a comprehensive, living document that explains how your organization protects Controlled Unclassified Information (CUI) within a specific system. It describes what NIST 800-171 security controls are in place, how they are implemented, and who is responsible for maintaining them.
For organizations seeking CMMC compliance, a System Security Plan is required under control CA.L2-3.12.4. It connects each required practice to real-world implementation and provides clear evidence that controls are operating as intended.
What Should a System Security Plan (SSP) Include?
A well-structured System Security Plan should include the following sections:
This is the foundational section of a System Security Plan. It provides essential administrative and descriptive information about the system, allowing stakeholders to clearly understand what system is being documented and who is responsible for it. This typically includes the system name, unique identifier, version, date, the type of information processed (such as CUI categories), and the System Owner responsible for the system.
This section defines the roles and duties assigned to individuals or groups involved in the operation, security, and management of the information system. It ensures accountability and clarity by specifying who is responsible for what aspects of system security — including the System Owner, Information System Security Officer (ISSO), and any third-party administrators or managed service providers.
Here, organizations provide a high-level overview of the information system — what it does, who it serves, and its key components. This section helps assessors and stakeholders quickly understand the system's purpose, scope, and operational context without needing to read the entire document.
This section describes the individual elements — both physical and logical — that make up the information system. That includes hardware (workstations, servers, network devices), software (operating systems, applications, security tools), and external connections (cloud services, VPNs, third-party integrations). The goal is to give a clear picture of the system's architecture and attack surface.
This is the core of the System Security Plan. For each of the 110 NIST 800-171 controls, you'll document whether the control is fully implemented, partially implemented, planned, or not applicable — and describe how it is implemented in your specific environment. Vague answers like "we use antivirus" won't cut it; assessors expect to see specific tools, configurations, policies, and responsible parties named.
If your system connects to or shares data with other systems — including cloud platforms, contractor networks, or government systems — those connections must be documented here along with the security agreements governing them.
Reference the policies that govern the system and its users. These don't need to be reproduced in full, but the SSP should clearly point to where they live and confirm they are current.
Does Your Organization Need a System Security Plan?
The short answer: if your organization handles Controlled Unclassified Information (CUI) and does business with the Department of Defense, yes — you need an SSP.
More specifically, you need an SSP if:
- You are a prime contractor or subcontractor in the Defense Industrial Base (DIB)
- Your contracts include DFARS clause 252.204-7012
- You are pursuing or maintaining CMMC Level 1 or Level 2 certification
- You store, process, or transmit CUI in any form — including email, cloud storage, or on-premises servers
Even if you believe your system is simple, the requirement still applies. An SSP documents your environment, and every environment is different. There is no "too small" exemption.
Why is a System Security Plan Important?
Beyond being a compliance requirement, the SSP serves several critical functions for your organization:
It is your primary evidence document during an assessment. When a C3PAO (Certified Third-Party Assessment Organization) comes in to evaluate your CMMC compliance, the SSP is one of the first things they'll ask for. Gaps or vague descriptions in your SSP signal gaps in your security program.
It forces organizational clarity. Writing an SSP requires you to actually inventory your systems, identify where CUI lives, and assign ownership to every control. Many organizations discover gaps they didn't know existed during this process — which is far better than discovering them during an assessment.
It enables continuous compliance. An SSP isn't a one-time exercise. Because it's a living document, it creates a baseline against which you can track changes, plan remediation through a POAM, and demonstrate that your security posture is actively maintained.
It builds trust with government customers. Contracting officers and program managers increasingly want to see evidence of a mature security program. A well-maintained SSP demonstrates that your organization takes cybersecurity seriously.
How to Create a System Security Plan
Creating an SSP for the first time can feel overwhelming, but breaking it into stages makes it manageable.
- Define the System BoundaryBefore you write a single word, you need to know what you're documenting. Identify every asset — hardware, software, users, and data flows — that touches CUI. This is your system boundary. Getting this right is critical; too narrow and you'll leave gaps, too broad and you'll create unnecessary compliance burden.
- Inventory Your Assets and Data FlowsDocument all hardware, software, and network components within the boundary. Map where CUI enters, moves through, is stored, and exits the system. This feeds directly into the System Components section and helps you understand which controls are most critical.
- Assign Roles and OwnershipIdentify who owns the system, who manages it day-to-day, and who is accountable for security. Every control will ultimately need a named owner, so establish this framework early.
- Document Each Security ControlWork through all 110 NIST 800-171 controls one by one. For each, describe the specific tools, configurations, and processes your organization uses to satisfy it. Be precise — "We use MFA" is not sufficient. Describe which MFA solution, which accounts it covers, and how exceptions are handled.
- Address Gaps with a POAMIf some controls are partially implemented or not yet in place, document them in a Plan of Action and Milestones (POAM) rather than leaving them blank in the SSP. The POAM is the companion document to the SSP that tracks your remediation roadmap.
- Review, Approve, and Establish a Review CadenceHave the document reviewed by your System Owner and security lead before finalizing. Then establish a recurring review schedule — at minimum annually, and any time a significant change occurs.
Automating System Security Plan Creation with ASCERA
Creating and maintaining an SSP manually is one of the most time-consuming aspects of CMMC compliance — and one of the most error-prone.
The typical manual approach involves a combination of Word documents, spreadsheets, and shared drives. Different team members own different sections. Version control is a constant headache. When your environment changes — a new cloud tool, a staff change, a policy update — the SSP often doesn't get updated in time. By the time your assessment rolls around, the document may no longer reflect your actual environment, which is a serious liability.
ASCERA was built to solve this problem. Rather than treating the SSP as a static document you dust off before an audit, ASCERA makes it a continuously maintained, living record of your compliance program.
With ASCERA, you can:
- Build your SSP directly within the platform, with guided prompts for every required section so nothing gets missed
- Link controls to real evidence — screenshots, configurations, and logs — so assessors can verify implementation, not just read about it
- Automatically flag when the SSP is out of sync with your current environment through Continuous Monitoring (ConMon)
- Generate formatted SSP exports ready for assessment submission, without reformatting a Word document from scratch
- Assign and track ownership of controls across your team, so accountability doesn't fall through the cracks
The result is an SSP that's always current, always evidenced, and always audit-ready.
Ready to see how ASCERA can automate your SSP and keep your compliance program continuously up to date?
Schedule a Free DemoSystem Security Plan FAQs
An SSP should be reviewed at least annually and updated any time a significant change occurs — such as adding new systems, changing vendors, modifying network architecture, or updating policies. CMMC assessors will look for evidence that the SSP reflects your current environment, not just how things looked when it was first written.
Generally, no. An SSP is scoped to a specific system boundary. If your organization has multiple distinct systems that process CUI, each may require its own SSP. That said, if systems share the same boundary, architecture, and controls, they may be documented together — but this should be carefully evaluated with your C3PAO or CMMC consultant.
The SSP documents what controls are in place and how they are implemented. The POAM (Plan of Action and Milestones) documents what controls are not yet fully implemented and your plan to remediate them. They are companion documents — the SSP shows where you are, the POAM shows where you're going.
During a CMMC assessment, a C3PAO will review your SSP alongside interviews, observations, and evidence artifacts. They'll verify that the SSP accurately describes your environment, that controls are implemented as described, and that documentation is current. Inconsistencies between the SSP and what they observe in your environment are a common finding.
A template can be a useful starting point, but it should not be treated as a fill-in-the-blank exercise. Assessors can quickly spot generic, boilerplate SSPs that don't reflect a real environment. Any template must be thoroughly customized to describe your specific systems, tools, policies, and people.
There is no required page count, but most SSPs for small-to-mid-sized DIB organizations range from 50 to 150+ pages depending on the complexity of the system and the level of detail provided for each control. Completeness and accuracy matter far more than length.
The System Owner typically leads SSP development, often with input from IT, security, and operations staff. Some organizations work with an RPO (Registered Provider Organization) or CMMC consultant to assist. What matters most is that the people writing it have firsthand knowledge of how the system actually works — not just how it's supposed to work on paper.