System Security Plan (SSP) Template: Structure, Sections, and a Free Builder

Most teams start their system security plan from a blank Word document or a template they inherited from a previous ATO package. That works until you realize the template has 40 pages of boilerplate, a control matrix that no longer matches SP 800-53 Rev 5, and a categorization section that quietly contradicts the baseline you actually implemented. An SSP is not a writing exercise. It is the authoritative description of one system: what it is, how it is categorized, where its boundary sits, who is responsible for it, and how each selected control is implemented. This article lays out a system security plan template mapped to NIST SP 800-18 Rev 1, explains what each section has to contain, and shows how FIPS 199 categorization drives the SP 800-53 control baseline so the pieces stay consistent.

The structure here is aligned to SP 800-18 Rev 1 (Guide for Developing Security Plans for Federal Information Systems), with the control catalog and baselines from SP 800-53 Rev 5 and SP 800-53B. NIST does not mandate a single rigid format. As long as the major sections are present and readily identifiable, you can organize the plan to fit your agency or program. The sections below are the ones an assessor or AO will look for regardless of the cover sheet.

What an SSP is for (and what it is not)

SP 800-18 is direct about the purpose: the SSP provides an overview of the security requirements of the system and describes the controls in place or planned for meeting those requirements. It also delineates responsibilities and expected behavior of all individuals who access the system. Three implications follow from that:

One system, one plan. The SSP is scoped to a single defined system with a single authorization boundary. If you cannot draw the boundary, you cannot write the plan.
It is a living document. The plan reflects current state. When the system changes (new components, a re-categorization, a control implementation change), the SSP gets updated and re-approved, not archived.
It is the spine of the assessment package. The SAR assesses the controls the SSP claims. The POA&M tracks the gaps the SAR finds. The authorization decision rests on all three. If the SSP is wrong, everything downstream inherits the error.

Common misconception: The SSP is not a copy of the SP 800-53 control catalog with your logo on it. Restating the control text back to NIST proves nothing. The implementation narrative, in your own words, describing your system, is the part that has value.

NIST SSP template: a section-by-section outline

The table below is a working system security plan template outline, aligned to the SP 800-18 Rev 1 plan elements. The front matter (system identification through laws and policies) is mostly structured fields. The weight of the document is in the control implementation narratives.

#	Section	What it contains
1	System Name / Unique Identifier	The official system name and a persistent identifier that follows the system across its lifecycle and across the package (SSP, SAR, POA&M).
2	System Categorization	The FIPS 199 categorization: impact level (Low / Moderate / High) for confidentiality, integrity, and availability, plus the overall high-water-mark level.
3	System Owner	Name, title, organization, and contact for the official accountable for the system.
4	Authorizing Official	The senior official with authority to authorize operation and accept residual risk.
5	Other Designated Contacts	ISSO/ISSM, system administrators, and other key roles with security responsibilities.
6	Assignment of Security Responsibility	The individual assigned responsibility for the security of the system, with current contact information.
7	System Operational Status	Operational, under development, or undergoing major modification.
8	Information System Type	Major application or general support system (and, in CUI/CMMC contexts, the in-scope environment).
9	General Description / Purpose	One to three paragraphs on the function and purpose of the system, including any factors that raise special security concerns (wireless, mobile, public-facing, etc.).
10	System Environment	Technical description of the environment: hardware, software, hosting model, network topology, data flows.
11	System Interconnections / Information Sharing	Connections to other systems, the nature of the data exchanged, and the agreements governing them.
12	Related Laws, Regulations, Policies	Statutory and policy drivers specific to the system (FISMA, FedRAMP, DFARS/CMMC, agency policy).
13	Minimum Security Controls	The selected SP 800-53 baseline and, for each control, an implementation narrative and status (implemented, partially, planned).
14	Component Inventory	The CM-8 inventory of system components, ideally mapped to the controls each component supports.
15	Completion & Approval Dates	The date the plan was completed and the date it was approved, establishing the document version in effect.

FIPS 199 categorization drives the SP 800-53 baseline

This is the part teams most often get subtly wrong, so it is worth being precise. The categorization in section 2 is not cosmetic. It selects your control baseline.

Under FIPS 199 you rate the potential impact of a loss of confidentiality, integrity, and availability separately, each as Low, Moderate, or High. Low is a limited adverse effect, Moderate is a serious adverse effect, and High is a severe or catastrophic adverse effect. The overall system categorization is set at the high-water mark: the highest of the three. If C is Moderate, I is Low, and A is Low, the system is Moderate. A single High in any one objective makes the whole system High.

FIPS 200 then derives the system impact level from that categorization and ties it to a starting control set, and SP 800-53B defines the three baselines you choose from:

FIPS 199 overall impact	SP 800-53B baseline	Approx. control count
Low	Low baseline	~149 controls
Moderate	Moderate baseline	~287 controls
High	High baseline	~370 controls

The baselines are largely cumulative: the Moderate set builds on the Low set, and the High set builds on the Moderate set, with a handful of control enhancements that differ by level. After you select the baseline, you tailor it: apply scoping considerations, add controls where your risk assessment surfaces a threat the baseline does not cover, and remove or modify controls that genuinely do not apply, documenting and justifying every tailoring decision. Tailoring out a control with no rationale is the fastest way to lose an assessor's confidence in the whole plan.

Practitioner tip: Re-derive the baseline from the categorization every time the categorization changes. The most common SSP inconsistency is a Moderate-baseline control set sitting under a categorization section that was bumped to High after a data type was added. The two have to agree.

What a good control implementation narrative looks like

Section 13 is where SSPs live or die. A narrative is not the control statement copied from SP 800-53. It is a description of how this system satisfies the control. A usable narrative answers four questions:

What is implemented? The actual mechanism, technology, or process, named.
Who is responsible? The role or component that owns it (and whether it is a common, hybrid, or system-specific control).
How does it work here? Configuration, frequency, scope. Concrete enough to be assessable.
What is the status? Implemented, partially implemented, or planned, with a pointer to the POA&M if it is not fully in place.

Compare these two takes on AC-2 (Account Management):

Weak: "The organization creates, enables, modifies, disables, and removes accounts in accordance with organization-defined policy, procedures, prerequisites, and criteria." (That is essentially the control text. It tells an assessor nothing about your system.)
Usable: "Accounts are provisioned in Okta on receipt of an approved access request ticket. The ISSO reviews all privileged accounts quarterly and standard accounts semi-annually; reviews are recorded in the GRC ticket queue. Accounts are disabled automatically after 30 days of inactivity and on the HR off-boarding trigger. AC-2 is implemented; the automated inactivity disable for service accounts is tracked in POA&M item AC-2-01."

The component inventory (CM-8) belongs in the SSP

CM-8 requires a documented inventory of system components that accurately reflects the system. In a strong SSP that inventory is not a detached spreadsheet, it is part of the plan and it ties back to the controls. Each component (host, container image, appliance, SaaS dependency) should carry enough detail to support the boundary description and to map to the controls it helps satisfy. A control mapping column turns the inventory from an asset list into evidence: it shows an assessor that AC-2 actually runs on the identity provider you listed, that SC-7 maps to the boundary devices you enumerated, and so on. Importing component data from an SBOM (CycloneDX or SPDX) or a CSV export keeps the inventory current without retyping it.

A structured builder instead of a blank template

A blank Word template gives you a shape and nothing else. It will not stop you from selecting a Moderate baseline under a High categorization, will not keep your component inventory in sync, and will not carry your control statuses into a SAR or a POA&M. The free SSP builder structures the SP 800-18 sections as fields, computes the SP 800-53 Rev 5 baseline from your FIPS 199 categorization, and keeps the CM-8 inventory mapped to controls. It runs entirely in your browser. Nothing about your system leaves your device, and no account is required.

riskposture.tools/app/ssp · Categorization & Baseline

FIPS 199 Categorization

ConfidentialityModerate

IntegrityModerate

AvailabilityLow

Overall (high-water mark)MODERATE

Selected SP 800-53 Rev 5 Baseline

Moderate

~287 controls selected

Implemented241

Partially33

Planned (→ POA&M)13

When the categorization changes, the baseline re-derives. When you finalize, the Draft/Final lifecycle locks the version so the SSP that the SAR assessed is the SSP on record. Pro adds save/import/export (JSON and CSV), print/PDF reports, and a roll-up across the rest of the suite, but the full SSP structure, categorization logic, and inventory are free and stay on your machine.

Putting it together

A defensible SSP is internally consistent before it is anything else. The categorization in section 2 selects the baseline in section 13. The boundary in section 10 matches the inventory in section 14. The control narratives describe your system, not the catalog, and the not-yet-implemented ones point at real POA&M items. Get those alignments right and the document does its job: it lets an AO understand and accept the risk of one specific system. A blank template hands you a shape. A structured builder keeps the shape consistent as the system changes underneath it.

Frequently asked questions

What NIST standard is an SSP based on?

The SSP structure is aligned to NIST SP 800-18 Rev 1 (Guide for Developing Security Plans for Federal Information Systems), with the control catalog and baselines from SP 800-53 Rev 5 and SP 800-53B. NIST does not mandate a single rigid format. As long as the major sections are present and readily identifiable, you can organize the plan to fit your agency or program.

How does FIPS 199 categorization determine the SP 800-53 baseline?

Under FIPS 199 you rate the potential impact of a loss of confidentiality, integrity, and availability separately, each as Low, Moderate, or High. The overall system categorization is set at the high-water mark, the highest of the three, so a single High in any one objective makes the whole system High. FIPS 200 then derives the impact level and ties it to a starting control set, and SP 800-53B defines the three baselines: Low (about 149 controls), Moderate (about 287 controls), and High (about 370 controls).

Is an SSP just a copy of the SP 800-53 control catalog?

No. The SSP is not a copy of the SP 800-53 control catalog with your logo on it. Restating the control text back to NIST proves nothing. The implementation narrative, in your own words, describing your system, is the part that has value. A usable narrative answers four questions: what is implemented, who is responsible, how it works here, and what its status is.

Does the CM-8 component inventory belong in the SSP?

Yes. CM-8 requires a documented inventory of system components that accurately reflects the system, and in a strong SSP that inventory is part of the plan rather than a detached spreadsheet. A control mapping column turns the inventory into evidence by showing which controls each component helps satisfy. Importing component data from an SBOM (CycloneDX or SPDX) or a CSV export keeps the inventory current without retyping it.