What Is a System Security Plan (SSP)?

An assessor opens the System Security Plan for a FedRAMP Moderate system on the first morning of a three-week assessment. The boundary diagram on page 14 shows four AWS services. The assessor pulls the current CloudFormation inventory: seven services, three of which were added over the past eighteen months and process customer PII. The SSP is eighteen months stale on day one. Everything that follows -- control verification, evidence requests, interview questions -- now starts from a position of doubt rather than trust.

Why This Matters Right Now

Two forces are converging. First, FedRAMP 20x mandates OSCAL-native security packages, which means SSPs must be machine-readable, version-controlled, and continuously updated rather than static Word documents that sit in SharePoint until the next annual assessment. Organizations that cannot produce OSCAL-formatted SSPs will find the authorization path significantly harder. Second, CMMC Level 2 assessments are now active across the Defense Industrial Base, and C3PAOs are opening every engagement by comparing the SSP boundary description against what they discover in the environment. The days of a "good enough" SSP that was accurate at initial authorization and never updated are over.

What an SSP Actually Is

A System Security Plan is the foundational document that describes how an information system is protected. It identifies what the system is, where its boundaries lie, who is responsible for it, what data it processes, and how every applicable security control is implemented. If you are pursuing an Authority to Operate (ATO), a FedRAMP authorization, CMMC certification, or any federal compliance effort, the SSP is the document that everything else depends on.

The SSP is not a compliance artifact you produce once and file away. It is the living blueprint of your security posture. Assessors read it before they touch your environment. Authorizing Officials sign off on the residual risk described in it. When the SSP is wrong, everything downstream -- assessments, POA&Ms, authorization decisions -- is built on a false foundation.

The concept is codified in NIST SP 800-18 Rev 1. The logic is straightforward: before you can protect a system, you need to describe it. Before an Authorizing Official can accept the risk of operating it, they need to understand what the system is and what protections are in place.

Who Reads the SSP and Why

The SSP serves multiple audiences, each with different needs:

Authorizing Officials use it to make risk-based authorization decisions.
Security assessors (3PAOs, DIBCACs, internal assessment teams) use it as the basis for their test plans -- they verify that what you documented is what you actually implemented.
System administrators and engineers reference it to understand the security architecture and operational procedures they are responsible for maintaining.
Auditors treat it as the primary evidence of your security program design intent.
Incident responders reference it to understand system boundaries, data flows, and interconnections during an incident.

Which Frameworks Require an SSP?

Nearly every compliance framework that touches information systems requires some form of a system security plan:

Framework	SSP Requirement	Governing Publication
NIST RMF (800-37)	Required for all federal information systems as part of the Implement step	NIST SP 800-18 Rev 1
FedRAMP	Required as the foundational document in the security package	FedRAMP SSP template (or OSCAL-native under 20x)
CMMC Level 2	Required; maps to NIST 800-171 requirement 3.12.4	NIST SP 800-171 Rev 2
FISMA	Required for all federal agencies and contractors operating federal systems	FIPS 200, NIST SP 800-18
DoD RMF (DoDI 8510.01)	Required; registered and maintained in eMASS	DoDI 8510.01
NIST 800-171	Security requirement 3.12.4: "Develop, document, and periodically update system security plans"	NIST SP 800-171 Rev 2
ICD 503	Required for Intelligence Community systems	ICD 503 / CNSSI 1253

The specific name and format varies -- FedRAMP provides a Word template (or OSCAL under 20x), DoD uses eMASS fields, CMMC assessors accept various formats -- but the content requirements are consistent because they trace back to the same NIST control catalog.

What an SSP Contains

A complete SSP covers the following sections. The order and exact headings vary by template, but the content is consistent across frameworks.

System Identification and Description

This is the "what is this system?" section:

System name and unique identifier. For DoD systems, this is the eMASS system identifier. For FedRAMP, this is the Cloud Service Offering (CSO) name registered with the PMO.
System categorization. The FIPS 199 impact level (Low, Moderate, High) for confidentiality, integrity, and availability, along with the rationale for each rating.
Information types. Every type of information the system processes, stores, or transmits, categorized per NIST SP 800-60.
System purpose and function. A plain-language description of what the system does and why it exists.
Operational status. Whether the system is operational, under development, or undergoing a major modification.
System environment. The physical and logical environment -- data center locations, cloud providers, network segments.

Authorization Boundary

The authorization boundary defines exactly what is in scope for the security assessment and authorization. Everything inside the boundary is your responsibility to protect and document. Everything outside is either inherited (someone else's responsibility) or out of scope.

The boundary description includes:

Boundary diagram. A visual representation showing all components, networks, and connections. This is one of the most scrutinized artifacts in the entire package.
Hardware inventory. Servers, workstations, network devices, storage systems.
Software inventory. Operating systems, applications, middleware, databases, and security tools.
Network architecture. Subnets, VLANs, firewalls, load balancers, DNS, and routing.
Cloud components. Specific cloud services and the shared responsibility delineation with the provider.

Getting the boundary right is critical. An overly broad boundary increases the number of controls you must implement. An overly narrow boundary creates gaps that assessors will find -- or worse, that attackers will exploit.

System Interconnections

Every external system that connects to yours must be documented:

Interconnection name and identifier
Organization owning the external system
Type of connection (dedicated circuit, VPN, API, internet-facing)
Data exchanged and its sensitivity level
Security controls at the boundary (encryption, access controls, monitoring)
Interconnection Security Agreement (ISA) or Memorandum of Understanding (MOU) reference

For DoD systems, each interconnection must be documented in eMASS. For FedRAMP systems, interconnections define the external attack surface that assessors will probe.

User Roles and Access

The SSP documents every category of user who interacts with the system:

Privileged users (system administrators, database administrators, security administrators)
Non-privileged users (general users, application users)
External users (contractors, partners, other agencies)
Service accounts and automated processes

For each role: what access they have, how they authenticate, how access is provisioned and revoked, and how many individuals hold the role.

Control Implementation Statements

This is the largest section and receives the most assessment scrutiny. For every applicable security control, you document:

How the control is implemented. Not a restatement of the control text -- a specific description of what your system does. "We use multi-factor authentication" is insufficient. "All administrative access to production systems requires authentication via SSO with a FIDO2 hardware token as the second factor; sessions expire after 15 minutes of inactivity" is what assessors need.
Who is responsible. System owner, organization, cloud provider, or shared.
Implementation status. Implemented, partially implemented, planned, or not applicable (with justification).
For gaps: The POA&M entry tracking remediation.

Continuous Monitoring Strategy

How the security posture is monitored ongoing: vulnerability scanning frequency, configuration baseline compliance, log collection and review, POA&M management processes, annual assessment scope, and incident detection capabilities.

Who Writes the SSP?

The Information System Security Officer (ISSO) is typically the primary author. The ISSO has the deepest knowledge of how controls are actually implemented day-to-day.

For DoD systems, the Information System Security Manager (ISSM) oversees the ISSO and is responsible for quality and accuracy. The ISSM reviews and approves before the document reaches the Authorizing Official.

An SSP is never written by one person alone:

Role	Contribution
System Owner	System purpose, mission, and operational context
System Administrator	Technical architecture, configurations, procedures
Network Engineer	Network diagrams, firewall rules, segmentation
Database Administrator	Data handling, encryption at rest, backup procedures
Security Engineer	Security tool configs (SIEM, EDR, scanner), monitoring
Privacy Officer	PII handling, privacy impact assessment inputs
Authorizing Official	Reviews and accepts residual risk

For smaller defense contractors without a dedicated ISSO, the author may be an IT manager or external consultant. Regardless of title, the writer must understand both the control requirements and the actual implementation.

Common SSP Mistakes

Copying Control Text Instead of Describing Implementation

The single most common mistake. The SSP asks "how is AC-2 implemented?" and the author writes "The organization manages information system accounts." That is the control requirement restated, not your implementation. Assessors flag this immediately because it provides zero evidence that you did anything.

Boundary Diagrams That Do Not Match Reality

Boundary diagrams are created during initial documentation and never updated. When an assessor finds components, connections, or data flows not represented in the diagram, credibility erodes rapidly. Every cloud service, API integration, third-party tool, and network path must appear on the diagram -- including the ones added last quarter.

Ignoring Inherited Controls

Many organizations document inherited controls as if they implemented them locally. If your cloud provider manages physical security (PE family), your SSP should state these are inherited, reference the provider's authorization, and describe any customer responsibilities that remain. Over-claiming implementation is a finding.

Writing the SSP After Building the System

The SSP should develop alongside the system. When written retrospectively, control implementations are described aspirationally rather than accurately. The reverse-engineering process is also slower and more expensive than documenting as you go.

Treating It as a One-Time Deliverable

An SSP accurate at initial authorization and inaccurate six months later is a compliance liability. Significant changes -- new components, architectural modifications, new interconnections -- must be reflected before or at the time of the change.

Vague or Inconsistent Terminology

Using different terms for the same component across sections creates confusion. If you call your identity provider "Okta" in the boundary diagram, "the SSO system" in access control, and "the authentication service" in the audit section, assessors will question whether these are one system or three.

Maintaining the SSP as a Living Document

Triggers for Updates

The SSP must be updated when:

Architecture changes (new servers, services, cloud components added or removed)
Boundary changes (components moved in or out of scope)
New interconnections established
Control implementations modified, added, or removed
Key personnel changes (ISSO, ISSM, System Owner)
Security tools replaced or significantly reconfigured
Assessment findings that result in control changes
Periodic review (at minimum annually)

The Documentation-Reality Gap

Systems change faster than documents. Engineers deploy new services on a timeline measured in days; SSP updates happen on a timeline measured in months. This gap is the root cause of most assessment findings -- a new component added without updating the boundary diagram, or a control described in its prior configuration.

Here is the contrarian truth that most compliance consultants will not say: an SSP generated from live system data is more accurate on day 90 than a manually written SSP is on day 1. The manual SSP begins decaying the moment the author saves the file. The generated SSP reflects whatever the system actually is right now. This is not about laziness -- it is about acknowledging that documentation written by humans about dynamic systems is structurally incapable of staying current without automation.

Key Takeaways

The SSP is the document everything else depends on -- assessments, POA&Ms, and authorization decisions all reference it

Boundary diagrams are the single most scrutinized artifact; if they do not match reality, assessor trust collapses immediately

Control implementation statements must describe what YOUR system does, not restate the control requirement text

The SSP must be updated at the time of change, not at the next annual review -- FedRAMP 20x and CMMC both enforce this

OSCAL-native SSPs are now the path forward for FedRAMP; organizations still using Word templates will face increasing friction

An SSP generated from live system data stays accurate; a manually written SSP begins decaying on day one

Frequently Asked Questions

How long should an SSP be?

Length depends on system complexity and the applicable control baseline. A FedRAMP Moderate SSP for a complex cloud system can exceed 300 pages. A CMMC Level 2 SSP for a small contractor with a well-scoped enclave might be 60-80 pages. Length is not the goal -- completeness and accuracy are. An assessor would rather read 80 pages of specific, verifiable implementation statements than 300 pages of vague, generic text.

Can I use the same SSP for multiple frameworks?

Yes, if structured correctly. Since NIST 800-53, NIST 800-171, FedRAMP, and CMMC all share common control foundations, a single SSP can serve multiple authorization efforts. The key is mapping each control implementation to the specific identifiers required by each framework. A multi-framework approach eliminates redundant documentation while satisfying each framework's specific format requirements.

What is the difference between an SSP and a SAR?

The SSP describes how the system IS protected (your documentation of implementation). The Security Assessment Report (SAR) describes how well those protections WORK (the assessor's independent verification). The SSP is your claim; the SAR is the evidence that your claim holds up under testing. They are complementary documents -- the SAR references the SSP throughout and identifies where reality diverges from documentation.

Who signs off on the SSP?

The Authorizing Official (AO) provides the final authorization decision based on the SSP (among other documents). However, the ISSO or ISSM typically signs as the responsible party for accuracy of the technical content. For FedRAMP, an agency AO authorizes (the JAB was retired in 2024). For DoD RMF, the designated AO (often at the component or service level) signs. The signature represents acceptance of the residual risk documented in the SSP -- it is not a rubber stamp.

How does FedRAMP 20x change SSP requirements?

FedRAMP 20x moves from Word-template SSPs to OSCAL-native machine-readable packages -- structured data (JSON or XML) rather than narrative documents. The content requirements remain similar, but the format enables automated validation, continuous updates, and machine-readable PMO consumption. Organizations must invest in tooling that produces valid OSCAL output.

How Advisedly Helps

Advisedly generates and maintains your SSP from live system data. Control implementation narratives are drafted from your actual assessed control status, scanner findings, configuration baselines, and evidence artifacts -- ready for your team to review and approve. Boundary diagrams auto-populate from your current asset inventory. When control status or evidence changes, the SSP narratives regenerate automatically -- no manual re-drafting, no version drift, no assessment surprises. With crosswalk coverage across 500+ frameworks, a single control implementation carries through to your SSP requirements across RMF, FedRAMP, CMMC, and every other standard you are assessed against. Contact begin@advisedly.ai to see how a living SSP works in practice.