Write Your First SSP Without a Consultant (a Practitioner's Template)

The System Security Plan is the strange center of gravity of NIST 800-171: it’s requirement 3.12.4, it carries zero points in the scoring methodology, and yet without it your assessment cannot be completed at all: the methodology’s own words are that an assessment “could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.”

No SSP means no valid SPRS score, no CMMC assessment, and no defensible position if anyone ever questions your affirmation. It’s also the first artifact a C3PAO will ask for: assessments are, in large part, an audit of your SSP against reality.

The good news: a small contractor’s SSP does not need to be a 200-page monster. It needs to be true, specific, and current. Here’s a lean structure that works.

Before you write: shrink the boundary

The single highest-leverage security decision a small contractor makes is scoping. Every asset that processes, stores, or transmits CUI (or connects to something that does) is in scope, and everything in scope must satisfy all applicable controls.

So before documenting anything:

• Can CUI live in one cloud tenant (e.g., Microsoft 365 GCC/GCC High) instead of scattered across shares and inboxes?
• Can it be confined to specific workstations/VLANs instead of the whole flat network?
• Can you refuse CUI you don’t need? (Primes over-share constantly. Push back.)

A tight enclave can turn “harden 60 machines” into “harden 12.” Write the SSP for the boundary you want, then make reality match.

The lean SSP structure

1. System identification. System name, SSP version and date, owner, your CAGE code(s), the Affirming Official, and the assessment scope type (enterprise or enclave). This is the metadata SPRS asks about: keep it in one obvious place.

2. System description and boundary. One page: what the system is for, what kinds of CUI it handles, and a boundary statement (the part assessors actually read) naming what’s inside (tenant, subnets, device groups, SaaS) and what’s explicitly outside (guest Wi-Fi, personal devices, the ERP that never sees CUI). Include a simple network diagram; a clean draw.io export beats no diagram.

3. Environment inventory. Tables, not prose: locations, hardware classes, OS versions, cloud services (with their FedRAMP/DoD status where relevant), and the security stack (EDR, firewall, MFA, backup). Every named component should reappear somewhere in a control implementation statement.

4. Interconnections. Who/what connects: MSP remote access, prime portals, cloud sync, VPN paths. For each: purpose, direction, protection. (This is 3.1.20 and 3.13.x territory, and assessors love asking about the MSP.)

5. Control implementation: all 110. The heart of it. For each requirement, 2-5 sentences answering three questions: How is it implemented? With what? Who’s responsible?

The pattern that works:

3.5.3: MFA. Microsoft Entra Conditional Access enforces MFA (Authenticator app) for all user and admin accounts on all access to the tenant. VPN access requires MFA via SAML to Entra. Local server logons are restricted to two named admins using hardware keys. Owner: IT Manager. Status: Implemented.

Write “Status: Implemented / Partially implemented / Planned” honestly for each: this is exactly where your SPRS score comes from, and where an assessor will probe. A requirement marked Implemented with no named mechanism is a red flag, not a time-saver.

For requirements that are N/A (the methodology permits exactly five, in narrow cases: no remote access, no wireless, no mobile), say why the condition holds and how you enforce that it stays true.

6. POA&M reference. Don’t bury deficiencies in the SSP. Point to the POA&M as a separate living document with each gap, its weight, owner, milestones, and target date. (The calculator exports a starter POA&M sorted by points at risk.)

7. Maintenance. Who updates the SSP, when (at minimum: after significant changes and annually), and a change log table. An SSP dated three IT generations ago is almost worse than none.

Three failure modes to avoid

1. The copied template nobody edited. Assessors have seen every template. When the SSP says “the organization employs FIPS-validated cryptography” but nobody can name the module or certificate, the whole document loses credibility: including the parts that were true.
2. Policy-speak instead of mechanisms. “Access is granted per the Access Control Policy” answers nothing. Name the tool, the setting, the group, the person.
3. One heroic author. If the SSP lives in one person’s head and they leave, your compliance program leaves with them. Keep it in version control (a Word doc in SharePoint with versioning counts) with a named backup owner.

What “done” looks like

You’re done with v1 when: every one of the 110 requirements has an honest implementation statement; the boundary matches how CUI actually flows; the POA&M lists every “Partially/Planned” item with a date; and your SPRS submission references this exact SSP by name. That’s a package you can defend: to a prime, an assessor, or a DOJ attorney you hopefully never meet.

Not legal advice; adapt to your environment.