System Security Plan Template: What a CMMC Level 2 SSP Has to Say

What is a System Security Plan?

A System Security Plan is the written description of the system that holds your Controlled Unclassified Information and how it’s protected. In NIST SP 800-171 Rev 2 it’s requirement 3.12.4: “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.”

That one sentence is the whole spec. Four things: the boundary, the environment, how each requirement is met, and the connections. The CMMC rule at 32 CFR 170.4 defines the SSP the same way, as the document that “describes the security controls in place or planned” for the system.

NIST is clear that format is up to you. A footnote in SP 800-171 Rev 2 says “there is no prescribed format or specified level of detail.” It also says the plan doesn’t have to be one document. It can point to policies, procedures, and other documents you already keep. A 40-page Word file is fine. So is a shorter plan that references your inventory and diagram.

Why does CMMC Level 2 require an SSP?

Because the assessment can’t happen without one. Section 170.24 says you must have an SSP “in place at the time of assessment to describe each information system within the CMMC Assessment Scope.” If it’s missing or out of date, the finding is that “an assessment could not be completed due to incomplete information and noncompliance with 48 CFR 252.204-7012.”

It’s also one of the few requirements you can’t defer. Section 170.21 lists CA.L2-3.12.4, the SSP, among the requirements that can never go on a POA&M. Every other gap can at least be argued about. This one can’t.

The SSP is also where the rest of the rule points. The scoping table in 170.19 says to “document asset treatment in the SSP” for CUI assets, security protection assets, contractor risk managed assets, and specialized assets. If you use a cloud provider or an outside IT provider for in-scope work, that relationship and its customer responsibility matrix belong in the SSP too. And for a C3PAO assessment, the name, date, and version of your SSP get recorded with the results.

That holds whether your contract asks for Level 2 (Self) or Level 2 (C3PAO). As we covered in our Level 2 requirements guide, the July 13, 2026 suspension memo limits new contracts to self-assessments for now. A self-assessment still needs the SSP.

Is there an official SSP template?

Yes. NIST publishes a free CUI SSP template as a Word document. It’s listed under supporting materials on the SP 800-171 Rev 2 page. It has sections for system identification, the system environment, and each requirement, with checkboxes for implemented, planned, or not applicable.

It’s a reasonable starting point. Two notes. First, its requirements section still cites the December 2016 version of 800-171, so check the wording against Rev 2, which is what CMMC scores you against. Second, a template only gives you headings. Nobody fails an assessment for using the wrong headings. They fail because what’s under them isn’t true.

What sections does a usable SSP need?

A usable SSP covers the four things 3.12.4 asks for, plus enough context that an assessor can find the evidence. Here’s the outline we’d work from. No download, because the content has to be yours.

1. System identification. System name, what it’s for, the CUI it handles, and the company and CAGE codes it covers.
2. Roles. Who owns the system, who’s responsible for security, and who administers it. Include how many regular and privileged users there are.
3. Boundary and scope diagram. A network diagram that shows where CUI lives and moves, where the boundary is, and every connection out of it: internet, cloud services, remote access, the plant floor. If you’ve built a CUI enclave, the enclave is your boundary, and the diagram should make that obvious.
4. Environment description. A narrative that matches the diagram: sites, networks, operating systems, servers, cloud tenants, and what each component does.
5. Asset inventory reference. Point to your hardware and software inventory instead of pasting it in. Every in-scope asset gets its CMMC category. The inventory, the diagram, and the SSP have to agree. We built a live one for an insurer in our automated hardware inventory report.
6. External service providers. Each cloud provider and outside IT provider in scope, what they do, and a reference to their customer responsibility matrix.
7. Requirement-by-requirement implementation. All 110 requirements. For each: status (implemented, not implemented, or not applicable with the reason), how it’s met, the system or tool that does it, and where the evidence is.
8. Specialized assets. OT, test equipment, and anything else that can’t be fully secured, with how it’s isolated and managed. For a machine shop that’s often an old CNC controller. More on that on our manufacturing IT page.
9. Links to the POA&M. Every requirement marked not implemented points to its POA&M item and target date.
10. Version history and review. Date, version, who approved it, and when it was last updated.

What's the most common SSP mistake?

Describing intentions instead of configuration. “Users are required to use MFA” is a policy statement. “MFA is enforced by Conditional Access on every account in the tenant, with no exclusions” is a configuration, and it’s one an assessor can check in a few minutes.

The rule backs this up. Under 170.24, a requirement is MET only if its objectives are satisfied “based on evidence,” and that evidence has to be in final form. Drafts, working papers, and “unofficial or unapproved policies” don’t count.

Here’s how the gap usually shows up:

• The SSP says “all laptops are encrypted.” The assessor asks for the encryption report. Three laptops aren’t encrypted. Now the requirement is NOT MET, and the SSP is wrong too.
• The diagram is from two years ago. The new file server isn’t on it. Neither is the vendor’s remote support tool.
• Implementation text is copied from a template. It names tools you don’t own.
• Something planned is marked implemented. Planned work goes on the POA&M with a date. Don’t write it up as done.

The fix is boring. Write each implementation statement from the screen that runs the control, then save that screenshot or export as the evidence. If you can’t point to a setting, don’t call the requirement implemented.

Key takeaways

What this looks like when we do it

We’re not a C3PAO or a Registered Practitioner Organization, and we don’t perform CMMC assessments or sign your affirmation. The SSP is your document, and a senior person at your company stands behind it.

Our part is making the IT sections true. We build the inventory and the network diagram from live data, configure the controls, and pull the evidence from the same tools that run them: MFA status, encryption reports, patch history, the asset list. Then the implementation statements describe settings, not hopes. If we manage in-scope systems, we’re an external service provider in your SSP, and we write our part of it with that in mind. For shops with CUI drawings and a plant floor full of older equipment, our manufacturing IT support page covers how we handle the OT side.

Have an SSP that describes the network you meant to build? Book a call and we’ll walk through it.