What Is a System Security Plan (SSP)?

A system security plan is the document that describes a system's boundary, the environment it operates in, its connections to other systems, and how each applicable security requirement is implemented. The definition in force for defense contractors is regulatory, not advisory: 32 CFR 170.4 defines the SSP as "the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements" (Cornell LII). The contrarian point, and the one that changes how you write it: the SSP is not evidence you produce for an assessment. It is the thing the assessment is conducted against. 32 CFR 170.17 requires "The name, date, and version of the SSP" to be included in the assessment results submitted to eMASS (Cornell LII), which means your plan is identified by version in a federal record. Every claim in it becomes something someone can test.

This article covers where the SSP obligation comes from, what belongs in one, why the absence of a prescribed format is a trap rather than a freedom, and the boundary between what lives in the plan and what belongs in a plan of action.

Key takeaways

• For NIST SP 800-171 the SSP is itself a numbered requirement, not a byproduct. Revision 2 states it at 3.12.4; Revision 3 restates it as 03.15.02 in a new Planning family.
• There is no prescribed format. NIST says so in a footnote, and that is exactly why so many SSPs fail: freedom of form is not freedom of content.
• The boundary statement is the highest-stakes sentence in the document, because every scoping argument afterwards resolves against it.
• Enduring exceptions belong in the SSP. Temporary deficiencies belong in a plan of action, which runs on a clock: 32 CFR 170.16 and 170.17 both put POA&M closeout at 180 days.
• The SSP is a living document identified by name, date and version in your submitted assessment results, so version discipline is a compliance control in its own right.

Where the obligation comes from

Two instruments create it for a defense contractor, and they say slightly different things.

NIST SP 800-171 makes it a requirement. Revision 2 states requirement 3.12.4 as: "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." Its discussion adds that system security plans "relate security requirements to a set of security controls" and describe at a high level how those controls meet the requirements, "but do not provide detailed, technical descriptions of the design or implementation of the controls".

That last clause is more useful than it looks. An SSP is not a design document. Teams that treat it as one produce a hundred pages nobody can assess.

Revision 3, final since May 2024 (NIST), keeps the requirement but moves it: it is 03.15.02, System Security Plan, in the Planning family, one of the families Revision 3 added. NIST's glossary carries the Revision 3 definition: "A document that describes how an organization meets or plans to meet the security requirements for a system. In particular, the system security plan describes the system boundary, the environment in which the system operates, how the security requirements are satisfied, and the relationships with or connections to other systems" (NIST CSRC).

Which revision you owe is a separate and consequential question, and it is not the one most vendors answer correctly. Note that NIST's own record for Revision 2 now reads "Withdrawn on May 14, 2024. Superseded by SP 800-171 Rev. 3" (NIST), while the CMMC program rule still names Revision 2: 32 CFR 170.2 incorporates by reference "SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Revision 2, February 2020 (includes updates as of January 28, 2021)". That is a real tension and it is worth understanding before you rebuild anything; do not let it change how you structure the plan.

The second instrument is the CMMC program rule, which does not merely reference the SSP but files it. Beyond the eMASS submission requirement above, 32 CFR 170.16 requires that security requirements from an external service provider's Customer Responsibility Matrix "must be documented or referred to in the OSA's System Security Plan" (Cornell LII). If you use a cloud provider or a managed service provider, their responsibility matrix has to land inside your plan, by reference at minimum.

What actually goes in one

Work from the requirement's own list, because an assessor will.

The boundary. Which systems, networks, facilities, people and external services are in scope, and just as importantly which are out and why. This is the sentence the whole document rests on. A boundary written as "our corporate environment" invites the assessor to scope everything you own. A boundary written with named enclaves, named data flows and an explicit exclusion list gives you an argument. The choice between a narrow enclave and a full-scope environment is a strategy question we treat separately from the drafting.

The environment of operation. Where the system physically and logically runs: data centers, cloud regions, remote workers, contractor sites. This is where most CUI-handling surprises surface, and it is usually the section that changes first when the business changes.

Connections and relationships. Interconnections with other systems, and the external service providers you depend on. This is where the Customer Responsibility Matrix material belongs, and where a shared-responsibility claim gets written down rather than assumed.

Implementation, per requirement. For each applicable requirement, what you do, who does it, and where the evidence is. Not the vendor's marketing description of a product. The specific configuration or process, in your environment.

NIST adds one relief that is worth knowing: security plans "need not be single documents; the plans can be a collection of various documents including documents that already exist", and effective plans "make extensive use of references to policies, procedures, and additional documents". An SSP that points at your access control policy is better than an SSP that copies it, because the copy goes stale silently.

No prescribed format is not a freedom

NIST's footnote to 3.12.4 is short and consequential: "There is no prescribed format or specified level of detail for system security plans. However, organizations ensure that the required information in 3.12.4 is conveyed in those plans."

Every template vendor quotes the first sentence. The second is the one that bites. You may structure the plan however you like, and you remain responsible for conveying all of the required information. In practice that means two failure modes we see repeatedly.

The first is the narrative SSP: twelve pages of well-written prose about the security program, from which an assessor cannot determine what is implemented for a specific requirement. It reads well and it is unassessable.

The second is the template SSP: a downloaded document with the vendor's example text lightly edited, describing controls the organization does not operate. That one is worse than nothing, because 32 CFR 170.17 puts its name, date and version into the assessment record. A plan that claims a control you do not run is a documented claim, not a drafting slip.

The structure that survives is boring: one section per requirement, each with an implementation statement, the owner, and a pointer to the evidence. It is tedious to write and it re-keys cleanly if the requirement catalogue is ever renumbered underneath you, which is not a hypothetical given the Revision 2 and Revision 3 situation.

Enduring exceptions live here; temporary ones do not

This is the distinction that decides where a gap gets written down, and getting it wrong creates work in both directions.

NIST SP 800-171 Revision 2 puts it plainly in its discussion of scope: some systems, including specialized systems such as industrial and process control systems, medical devices and CNC machines, "may have limitations on the application of certain security requirements", and "To accommodate such issues, the system security plan, as reflected in requirement 3.12.4, is used to describe any enduring exceptions to the security requirements. Individual, isolated, or temporary deficiencies are managed though plans of action, as reflected in requirement 3.12.2."

The CMMC rule uses the same split with its own vocabulary. 32 CFR 170.4 defines an enduring exception as "a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible", and adds that for one of those "no operational plan of action is required but the circumstance must be documented within a system security plan". An operational plan of action is the artifact identifying "temporary vulnerabilities and temporary deficiencies ... in implementation of requirements" and documenting how they will be mitigated, corrected or eliminated.

So: a permanent limitation of a specialized system is described in the SSP. A control you have not finished implementing is a plan of action item, and plans of action come with deadlines. Both 32 CFR 170.16 and 170.17 set POA&M closeout at 180 days from the relevant CMMC status date, after which a conditional status expires. The mechanics of what may and may not go on a POA&M are covered in CMMC POA&M rules.

Writing a temporary gap into the SSP as though it were an enduring exception is the version of this mistake we see most, and it is a bad trade: it converts a time-boxed remediation item into a standing claim that your environment cannot meet the requirement at all.

Honest caveats

Templates are not useless. A good one gives you a structure and a reminder of the sections you would otherwise forget, and starting from a blank document wastes a week. What a template cannot do is describe your boundary, and the boundary is the part that determines your assessment.

Nor should the SSP be written by whoever has spare time. The person drafting it needs to be able to say what is actually running, not what the policy says should be running. In our experience the highest-quality plans come from a pairing: someone who knows the environment technically, and someone who knows how an assessor reads a requirement. Either alone produces a document that fails for a predictable reason, and the technical person working alone fails less obviously, which is worse.

One more, against our own interest: if you are early enough that you do not yet know which of your systems touch CUI, an SSP engagement is premature. Scoping comes first. Writing a plan around a boundary you have not established produces a document you will rewrite, and paying a consultancy to write it twice is a poor use of the budget. Start with what CUI you actually receive; FCI versus CUI is the distinction that gates everything downstream, and what CMMC level do I need is the next question after it.

Where Top Floor fits

Our CMMC practice writes system security plans in the structured, one-section-per-requirement form described above, with an explicit boundary statement, the external service provider responsibility matrices referenced where 32 CFR 170.16 requires them, and enduring exceptions separated from plan-of-action items so the two do not contaminate each other.

We also treat the plan as a versioned artifact rather than a deliverable. Because the assessment record carries its name, date and version, we set the update triggers with the client at the start: environment changes, new external service providers, boundary changes, and requirement re-implementations. Where a client is running CMMC alongside other frameworks, compliance as a service keeps the underlying evidence in one place, and how your score is derived from the requirement set is covered in how to calculate your SPRS score.

How to decide this week

Find your current SSP and check three things before anything else. Does it state a boundary you could defend to a stranger? Does it have a version number and a date? Does it describe controls you are actually running today?

If the answer to any of those is no, stop adding content and fix that first. A plan with a clean boundary and honest, thin implementation statements is assessable. A plan with a vague boundary and rich implementation statements is not, however impressive it reads.

Then separate your gap list into permanent limitations and unfinished work. Move the permanent ones into the plan as enduring exceptions with the justification attached. Move the unfinished ones onto a plan of action with owners and dates, and check those dates against the 180-day closeout window.

Finally, decide who owns the version. If nobody owns it, the plan is already drifting from your environment, and the drift is invisible until an assessor finds it.

Frequently asked questions

Is a system security plan required, or just recommended?

Required, in two independent ways for a defense contractor. NIST SP 800-171 makes it a numbered security requirement in its own right, stated at 3.12.4 in Revision 2 and restated as 03.15.02 in Revision 3. Separately, the CMMC program rule at 32 CFR 170.17 requires the name, date and version of the SSP to be included in the assessment results submitted to eMASS, and 32 CFR 170.16 requires external service provider responsibilities to be documented or referred to in it. There is no version of this where the plan is optional paperwork.

How long should an SSP be?

There is no prescribed length, and NIST says so directly: there is "no prescribed format or specified level of detail", provided the required information is conveyed. Length follows the size of the boundary and the number of applicable requirements, not a page target. NIST also allows the plan to be a collection of documents rather than one file, and encourages references to existing policies and procedures, so a shorter core document with disciplined pointers is usually stronger than a long self-contained one that goes stale.

What is the difference between the SSP and a POA&M?

The SSP describes what your system is and how the requirements are implemented, including enduring exceptions where a specialized system genuinely cannot meet a requirement. A plan of action handles temporary deficiencies: things not yet implemented, with a plan and a date. NIST SP 800-171 draws that line explicitly, putting enduring exceptions in the plan and individual, isolated or temporary deficiencies into plans of action. Under CMMC the plan of action also carries a deadline, with closeout required within 180 days of the relevant status date.

Can we use an SSP template?

Yes, for structure. What a template cannot supply is the boundary, the environment description, or the implementation statements, and those are the parts an assessment turns on. The specific risk with templates is leaving example text in place that describes controls you do not operate, because the CMMC assessment record identifies your plan by name, date and version, which makes an inherited claim a documented one. Use the template for section headings, then write every substantive sentence from what your environment actually does.