Authoring a System Security Plan (SSP) for NIST 800-171

The System Security Plan (SSP) is the central document in any NIST 800-171 or CMMC engagement. It is required by NIST SP 800-171 r2 control 3.12.4, it is the first artifact a C3PAO assessor asks for, and it is the document that fundamentally determines whether the other 109 controls can be evaluated coherently. A well-authored SSP makes a Level 2 assessment a structured conversation. A weak SSP turns every control into a discovery exercise.

This post is a practical guide to writing one. What sections need to exist, how to handle the control narratives, and the discipline that keeps the document defensible over time.

What the SSP is for

The SSP describes how the organization’s information system implements the security requirements in NIST SP 800-171. It is not a policy document, not a procedure manual, and not a marketing artifact. It is a technical and procedural description of the system as it exists, control by control, in enough detail that an outside reviewer can verify the implementation.

NIST does not publish a mandatory template. CISA, NIST, and the DoD have offered formats over the years. The most commonly referenced is the NIST SP 800-171 SSP template provided alongside the publication. The format is flexible; what matters is that each of the 110 practices is addressed and the description matches what the system actually does.

SSP structure that works

A defensible SSP typically contains the following sections.

1. System identification and characterization

What the system is, what it does, and who owns it:

• System name and unique identifier.
• System owner (named individual, role and contact).
• Authorizing official (often the same person at smaller contractors).
• System security officer.
• Information system contact / point of escalation.
• Operational status (operational, under development, undergoing major modification).
• Information system type (general support system, major application).

2. System description and architecture

This is where the CUI boundary gets documented:

• Logical architecture diagram showing components in scope.
• Network diagram showing internal and external connections, with CUI flows highlighted.
• Asset inventory with categorization (CUI Asset, Security Protection Asset, CRMA, Specialized, Out-of-Scope) per the CMMC scoping guidance.
• Description of major system components: cloud tenants (M365, GCC High, Azure), on-premises systems, endpoint platforms, identity systems.
• System interconnections to external systems with the nature of each.

The scoping decisions described here are the foundation for control evaluation.

3. Information types

The categories of CUI handled by the system, drawn from the CUI Registry. Examples: Controlled Technical Information (CTI), Covered Defense Information per DFARS 7012 definition, Critical Infrastructure Information, Export Controlled (ITAR/EAR). Each category should be tied to the specific contracts or business processes that generate or receive it.

4. Security control implementation

The bulk of the document. One section per family, each control addressed in turn. For each of the 110 NIST 800-171 r2 controls:

• Control identifier and text (verbatim from NIST SP 800-171 r2).
• Implementation status: Implemented, Partially Implemented, Planned, Alternative Implementation, Not Applicable.
• Implementation narrative: a specific description of how the control is implemented in this system. Name the technology, name the policy, name the procedure.
• Responsible party.
• Evidence pointers: which artifact (configuration export, policy document, audit log) demonstrates the implementation. Either inline reference or pointer into an evidence library.

5. Plan of Action and Milestones reference

The SSP references the POA&M but does not duplicate it. Controls marked Partially Implemented or Planned in the SSP should have a corresponding open POA&M item. See POA&M Management Under CMMC for the discipline that keeps the two documents aligned.

6. Roles and responsibilities

A matrix showing which roles are responsible for which control families. This is a quick reference an assessor uses to identify interview targets.

7. SSP revision history

Date, version, author, summary of change. The revision history is itself an audit artifact. An SSP that has not been revised in 18 months in a system that has changed during that time is a credibility problem.

Writing the control narratives

The control narratives are where most SSPs fail. The two most common failure modes are restating the control as the implementation and writing aspirational language.

Restating the control

Example of weak narrative for 3.5.3 (MFA):

“The organization uses multi-factor authentication for local and network access to privileged accounts.”

This restates the control text. It does not describe an implementation. A stronger example:

“MFA is enforced via Entra ID Conditional Access policy CA-001 (‘Require MFA — All Users’) applied to all licensed users in the tenant. The policy requires Microsoft Authenticator or a FIDO2 security key as the second factor; SMS is excluded.”

This version names specific technologies, policies, and procedures rather than simply repeating requirements.

Aspirational language

Narratives written in the future tense, or using “should” / “will” / “is intended to” describe a desired state, not an implemented one. Either the control is implemented or it is not. If it is not, mark it Planned and put it on the POA&M.

Evidence linkage

Each control narrative should reference the artifact that an assessor would examine to verify the implementation. The evidence library is typically organized by control identifier:

• EV-AC-3.1.1 — Entra ID user list export and group memberships demonstrating authorized-user scope.
• EV-AU-3.3.1 — Microsoft Sentinel data retention configuration and sample log query result.
• EV-CM-3.4.1 — Intune configuration profile exports demonstrating baseline configuration enforcement.
• EV-IA-3.5.3 — Conditional Access policy CA-001 export and sign-in log sample.
• EV-SC-3.13.11 — FIPS validation reference for the encryption modules in use (Microsoft 365 service-side encryption per FIPS 140-2 / 140-3 certificate listings).

The evidence library lives in a controlled repository. Version-controlled where possible, with access logged. SharePoint with audit logging is workable; a generic shared drive is not.

SSP discipline over time

The SSP is a living document. Configuration changes that affect control implementations should trigger SSP updates. Practical discipline:

• SSP review on a quarterly cadence at minimum, even where no significant change has occurred. The review itself is recorded in revision history.
• Change management procedures that flag SSP impact. A Conditional Access policy change should ask “does this affect the IA family narratives” before approval.
• Annual signed approval by the authorizing official. The signature attests that the SSP reflects current state.
• SSP and POA&M reviewed together. A control marked Implemented in the SSP that appears as an open POA&M item is a contradiction. So is a closed POA&M item where the SSP still describes a Partially Implemented state.

Relationship to the 110 controls

The SSP addresses every one of the 110 NIST SP 800-171 r2 practices, which map 1:1 to CMMC Level 2 practices. Many of the technical controls (Conditional Access, MFA, device compliance) are documented in narratives that reference the underlying configuration.

What to do next

• Audit the current SSP for restated-control and aspirational-language patterns. Rewrite any narrative that does not name a specific technology, policy, or procedure.
• Confirm every Partially Implemented or Planned control has a corresponding POA&M item, and vice versa.
• Build the evidence library if it does not exist. Organize by control identifier; document where each artifact lives.
• Schedule the quarterly SSP review and the annual authorizing-official sign-off. These dates are visible to an assessor.