How to Write a System Security Plan: The Owner’s Guide to the One Document That Gates Everything

Updated July 2026: With CMMC third-party audits suspended since July 13, the SSP didn’t get less important — it became the foundation under the score your company self-reports and the affirmation a senior official signs every year. And one rule got a lot more visible: per the DoD Assessment Methodology, no SSP means no valid SPRS score at all. This guide reflects the current rules.

Here’s the System Security Plan in one sentence: it’s the document that describes, truthfully and specifically, how your company actually protects CUI — system by system, requirement by requirement, with names attached.

And here’s why it deserves twenty minutes of your attention as an owner or COO, even though you’ll never write most of it yourself:

1. It’s a gate, not a chapter. The DoD Assessment Methodology treats a missing SSP as “assessment could not be completed.” No SSP, no valid score, no defensible SPRS entry — the entire rest of your compliance program hangs off this document existing and being current.
2. It’s what your signature points at. When your Affirming Official attests to your SPRS score every year, the SSP is the primary document that either backs that signature up or exposes it. A government-led assessment starts by asking for it. A prime’s supplier review asks for it. If the DOJ ever asks questions, it’s Exhibit A — for you or against you.
3. It’s the institutional memory of your security program. People leave, MSPs change, and “how does our VPN actually work?” shouldn’t live in one person’s head.

SSP stands for System Security Plan. CUI is Controlled Unclassified Information — sensitive government data like technical drawings and specifications. A POA&M is a Plan of Action and Milestones — your tracked list of gaps and fix dates.

First, What an SSP Is Not

Three misconceptions to clear before anyone writes a word:

• It’s not a policy binder. Policies say what you intend; the SSP describes what is. “We require strong passwords” is policy. “Domain policy enforces 14-character passwords; here’s where that’s configured” is SSP.
• It’s not a wish list. The SSP describes today’s reality. Future plans, half-done projects, and known gaps belong in the POA&M — the SSP just points to them honestly.
• It’s not a template you fill in once. A copy-paste SSP describing a generic company is worse than useless: it’s a document with your affirmation’s weight behind it describing an environment you don’t run. Any reviewer who’s seen ten SSPs spots boilerplate in ninety seconds.

The Anatomy: What Goes In It

Six parts, in the order a reader needs them:

1. Who and what. System name, owner, your company info, dates. One page.

2. What this system does. Plain-language description: what the system is for, what kinds of CUI it handles, roughly how many users and of what types. Another page.

3. The boundary — the most important section you’ll personally review. A precise statement of what’s in scope: which workstations, servers, cloud services, network segments, and locations handle CUI — and, just as deliberately, what’s excluded and why. The boundary determines what all 110 requirements apply to, which makes it the single biggest driver of your compliance cost. A tight, defensible boundary (like a contained enclave) means a shorter SSP, fewer systems to secure, and a cheaper program forever. If you review nothing else in the draft, review this.

4. The control implementations — the bulk of the document. For each NIST SP 800-171 requirement: how it’s implemented, with what technology, following what process, owned by whom. More on writing these below, because this is where SSPs are won or lost.

5. Roles and connections. Who’s responsible for what (system owner, security lead, admins, your MSP), and every external connection — other systems, cloud services, partners — with the data flows between them.

6. Diagrams. At minimum: a network/boundary diagram showing what’s inside the line, and a data-flow diagram showing how CUI moves. Reviewers reach for the pictures first; a good diagram answers half their questions before they read a word.

The One Writing Skill That Matters

The control descriptions are where a real SSP separates from a template, and the difference is one thing: specificity.

Bad (template-speak):

“Access to the system is controlled through authentication mechanisms.”

Good (your actual environment):

“Users authenticate to the Windows domain using Active Directory credentials. Domain policy requires 14-character passwords with complexity requirements. Multi-factor authentication using Microsoft Authenticator is required for all remote access through our Cisco AnyConnect VPN and for all Microsoft 365 access.”

The second version names the technology, the configuration, and the scope of coverage — a reader could go verify it. That’s the test for every description: could someone check this claim against your actual environment? If a sentence would be equally true of any company on earth, it’s boilerplate and it fails.

Five questions each description should answer: What technology implements this? How is it configured? What process supports it? Who owns it? How do we know it keeps working?

And honesty about gaps is a feature, not a confession. The right way to handle a partial implementation:

“MFA is implemented for remote VPN access and Microsoft 365. MFA for local privileged access is scheduled for implementation by [date] as documented in POA&M item 7.”

That sentence does three things at once: keeps the SSP truthful, keeps the gap tracked, and keeps your affirmation defensible. An SSP that admits its gaps and points to the plan is stronger than one that claims perfection — because the truthful one survives scrutiny.

Who Writes It, and How Long It Takes

Realistic division of labor:

• Your IT lead or MSP drafts the technical implementation descriptions — they’re the only ones who know the actual configurations
• A compliance-literate reviewer (internal, or a firm like ours) maps descriptions to requirements, catches template-speak, and flags claims that won’t survive verification
• You (or your COO) review the boundary, confirm the roles section names real accountable people, and read enough of the implementations to sign the affirmation with a straight face

Effort: for a small contained environment, a first SSP is typically 2–4 focused weeks alongside normal work; complex or scattered environments take longer — which is itself an argument for shrinking the boundary first. Length: small environments land around 30–60 pages, mid-size 60–100. Length should track complexity, not ambition — a clear 50-page SSP beats a padded 150-page one every time.

Structure: organize it requirement-by-requirement within each control family — a short family overview, then each requirement number with its specific implementation underneath. It’s the format every reviewer (government assessor, prime, future auditor) expects, it maps cleanly to your score, and it makes updates surgical. Pure narrative reads nicer but makes verification a scavenger hunt; don’t make the person scrutinizing your compliance work for it.

Tools: Word or Google Docs is genuinely fine for most small contractors — use consistent headings and a change log. Compliance platforms earn their keep when you’re juggling evidence links and version control across a bigger environment. Fancy tooling doesn’t fix boilerplate; specificity does.

The Six Ways SSPs Go Wrong

1. Boilerplate. Generic descriptions that fit any company. Fails the “could someone verify this?” test on every page.
2. Aspirational writing. Describing the environment you’re building instead of the one you have. Current state in the SSP; future state in the POA&M.
3. A fuzzy boundary. If a reviewer can’t tell what’s in scope, they can’t evaluate anything — and neither can you price your program.
4. No diagrams. Text-only SSPs make every reader reconstruct your network in their head. Two diagrams, minimum.
5. The rotting SSP. Written once, never touched, describing an environment three migrations ago — while someone affirms annually that it’s accurate. Review at least yearly and after any significant change: new systems, office moves, cloud migrations, a new MSP, an incident.
6. Wrong altitude. Too thin to verify, or so bloated the real content drowns. Every section should either describe an implementation or define scope; cut anything that does neither.

Keeping It Alive

The SSP is a living document with a paper trail:

• Version it. Number the versions, log what changed and when, archive old copies. The change history is itself evidence that your program is maintained rather than performed.
• Calendar the review. Annual at minimum, tied to the same calendar entry as your affirmation — reviewing the SSP before signing is exactly the sequence that makes the signature safe.
• Approve it on the record. The system owner reviews and dates each approved version. When someone asks “who stands behind this document?”, the answer should be written down.

Key Takeaways

The SSP is the gate document of your entire compliance program: without a current one, no valid SPRS score exists, and with a bad one, every annual affirmation is signed against fiction. It describes your actual environment — boundary, implementations, owners, connections — with the specificity that lets a reader verify every claim.

Have IT draft, have a compliance-literate reviewer pressure-test for boilerplate, and personally own the boundary review. Handle gaps honestly with POA&M references rather than optimistic prose — a truthful SSP with known gaps beats a perfect-sounding one that can’t survive a look. Then keep it versioned, reviewed annually before the affirmation, and updated when the environment changes.

It’s not paperwork for an assessor who may never come. It’s the document your company’s signature points at every year.

Related Articles:

• POA&M Best Practices for CMMC
• How to Define Your CMMC Level 2 Assessment Boundary
• How to Calculate Your SPRS Score
• CMMC Scope Reduction: Cutting Compliance Costs by 40%+
• CMMC Phase 2 Is Suspended. Your Compliance Obligations Are Not.

Official Sources: NIST SP 800-171 Revision 2, NIST SP 800-18 (Guide for Developing Security Plans), the NIST SP 800-171 DoD Assessment Methodology (v1.2.1), and DoD CMMC Level 2 scoping guidance.

Every Greypike Roadmap includes the SSP framework built from your actual environment — and our Managed Compliance program keeps it current so the annual affirmation never gets signed against a stale document. Fixed fees, published pricing — or take this guide and the templates in NIST SP 800-18 and build it yourself; the specificity test works either way.