Writing an SSP That Survives Scrutiny

Every assessment I have watched go badly went badly in the first hour, and it went badly for the same reason: the assessor could not tell from the System Security Plan what the system actually was. Not what the company intended to build. What was running, that morning, in that office, on those laptops.

The SSP is the one document where being vague costs you more than being wrong. A wrong control description gets a finding. A vague boundary gets the whole assessment paused while somebody works out what they are even looking at.

Two facts that should change how you write it

It is not scored. In the DoD Assessment Methodology, 3.12.4 carries no point value. I wrote about this in SPRS Scoring Explained — it is the one requirement out of 110 that never touches your number. People read that and conclude the SSP is a formality.

It cannot go on a POA&M. Under 32 CFR 170.21, CA.L2-3.12.4 is one of six Level 2 requirements that are never POA&M-eligible. I covered the full list in POA&M: What Belongs on It and What Doesn’t.

Put those together and the reason becomes obvious. The SSP is not scored because it is not one of the things being measured — it is the ruler. It defines the boundary that every other requirement is assessed against. And it cannot be deferred, because there is nothing to defer to. An assessment without an adequate SSP does not fail. It stops, with a finding that the assessment could not be completed due to incomplete information.

That is a worse outcome than failing. Failing tells you what to fix.

What the control actually asks for

NIST SP 800-171 Rev. 2, requirement 3.12.4, in full:

Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

Four things, plus a maintenance obligation. Read it as a checklist and it is short. The trouble is that three of the four are things most small shops have never written down anywhere.

The clause says	Which means, concretely
System boundaries	A named list of every asset in scope, and an explicit statement of what is out and why
System environments of operation	Where the work physically and logically happens — office, home, cloud tenant, shop floor, a laptop in a hotel
How security requirements are implemented	110 short answers describing the mechanism that is running today
Relationships and connections to other systems	Every external service provider, VPN, prime portal, and integration that touches CUI
Periodically update	A stated review interval and evidence you have actually hit it

The boundary section is where most SSPs fail

I have read SSPs that describe the boundary as “the corporate network.” That is not a boundary. It is a gesture at one.

A boundary an assessor can work with is enumerable. Someone can walk the office with your asset list and account for every device on it. The test is not whether the description sounds right; it is whether a stranger could use it to decide, for any given machine, whether that machine is in scope.

Which means the boundary section has to say what is out, and why. The estimating workstation that never sees CUI is out — say so, and say what keeps it out. The personal phone that gets email but not files is out — say so, and say what enforces that. Exclusions you do not document read as omissions, and omissions get scoped back in.

If you have not made the scoping decision yet, make it before you write a word of the SSP. I laid out why that decision drives everything else in CUI Scoping: The Decision That Determines Your Entire CMMC Budget. Writing an SSP for an unscoped environment is writing it twice.

Describe what is, not what should be

This is the single most common defect I see, and it comes from writing the SSP and the policy set at the same time with the same words.

A policy says what the organization requires. An SSP says what the organization does. They are different documents with different tenses, and copying one into the other produces a plan full of sentences like “users shall be required to authenticate using multi-factor authentication.” An assessor reads that and cannot tell whether MFA is on.

Compare:

• Weak: “Multi-factor authentication shall be enforced for all privileged accounts.”
• Usable: “MFA is enforced by a Conditional Access policy in Entra ID named Require MFA — All Users, applied to all 14 accounts in the tenant with no exclusions. Number-matching push through Microsoft Authenticator; hardware keys for the two global administrators. SMS is blocked at the tenant authentication-methods policy.”

The second one is four sentences. It names the mechanism, the scope, the exceptions and the enforcement point. It also tells you exactly what evidence to pull when someone asks — which is most of the work of an assessment done in advance.

One requirement, one entry, four questions

For each of the 110, answer four questions and stop. Discipline here is what keeps the document readable and keeps it current.

• What mechanism implements this? Name the product, the policy, the setting, the physical control. “Entra ID Conditional Access,” not “our identity system.”
• Where does it apply? Which assets, which users, which locations. If it does not cover the whole boundary, say what it misses.
• Who is responsible? A role, and a named person behind the role. Small shops can name people; it is honest and it is faster to verify.
• What proves it? A pointer to the artifact — the export, the screenshot, the ticket queue, the log. Not the artifact itself.

That last one is the difference between an SSP that survives an assessment and one that triggers a two-week scramble. The plan should be a map to your evidence, not a substitute for it.

External service providers are part of your system

“Relationships with or connections to other systems” is the phrase that carries the most weight for a small contractor, because a small contractor’s system is mostly other people’s systems.

Your productivity tenant. Your managed service provider. Your backup vendor. Your ERP host. Your prime’s supplier portal. Every one of those is a relationship the SSP has to describe, and for each you need three things on paper: what CUI it touches, what agreement covers it, and what the provider is responsible for versus what you are.

The shared-responsibility split is the part people skip. If your MSP patches servers and you patch laptops, the SSP has to say that, because otherwise both of you will assume the other one has 3.14.1 covered. I have seen exactly that gap sit undiscovered for two years.

The appendices do the real work

Keep the narrative body short and push the volatile material into appendices you can regenerate. Five of them earn their place:

• Asset inventory — every in-scope device with owner, OS, location and asset category. Export it from the source of truth rather than typing it.
• CUI data flow — how CUI enters, where it lands, who touches it, how it leaves, how it is destroyed. One page, and it can be hand-drawn.
• Network diagram — segments, boundary devices, egress points. It has to match the asset inventory.
• External service providers — the table described above.
• Roles and responsibilities — including who your Affirming Official is, because that name has personal exposure attached to it.

Appendices change monthly. The body should change annually. Structuring it that way is what makes “periodically update” achievable rather than aspirational.

Length is not the measure

I have seen 300-page SSPs that could not answer a basic question about the boundary and 40-page SSPs that were airtight. The long ones are usually long because they contain the policy text, the control text from NIST, and a paragraph of restatement for each requirement — three copies of the standard and no description of the system.

Do not quote the requirement back. The assessor has the standard. What they do not have is your environment.

Keeping it true

An SSP goes stale faster than anything else in the compliance file, because it describes a moving target. The controls that break it are ordinary business events: you hire someone, you adopt a tool, you switch MSPs, you let one person work from a second office.

The cheapest fix is a trigger list rather than a calendar. Review the SSP on any of these, in addition to the annual pass:

• A new system, SaaS application or cloud tenant enters the environment
• An external service provider is added, changed or dropped
• The physical footprint changes — new site, new home worker, a closed office
• A control implementation changes, including a vendor changing it for you
• An incident, because the response will expose something the plan got wrong

Date every revision and keep the prior versions. “Periodically update” is assessed by evidence of updates, and a document with one date on it from three years ago answers that question badly.

The test I run before I call one done

Hand the SSP to someone technical who has never seen the environment. Give them no verbal briefing. Ask them four questions:

• Which machines are in scope, and which are not?
• Where does CUI live right now?
• Who do I ask about account provisioning?
• Show me where you would look to prove MFA is on.

If they can answer all four from the document alone, it will survive an assessment. If they have to ask you anything, the assessor will have to ask you the same thing — and every question an assessor has to ask is a question that gets written down.

One more thing about right now

With CMMC Phase 2 suspended since 13 July 2026, third-party certification is not currently being required as a condition of award. That has convinced some people that documentation can wait. It cannot, and the reason is not CMMC.

DFARS 252.204-7012 is untouched. Self-assessment and SPRS submission are untouched. The score you post to SPRS is a representation to the Government, and the SSP is the document you would produce to justify it. That obligation exists today, suspension or no suspension. I worked through what is and is not still in force in Is CMMC Cancelled?

The SSP is also the only compliance artifact that pays for itself regardless. It is the document that tells a new hire how the place works, tells your MSP what you expect of them, and tells you, honestly, how much of the 110 you have actually done. Write it for that. It will pass an assessment as a side effect.

---

Where to go next

• Not sure where you stand? The CMMC readiness quiz takes about five minutes.
• Our CMMC guide for small contractors walks through scoping and scoring from the beginning.
• Want the SSP structure, the appendix templates and the control-entry format as a starting point? That is what our CMMC packets are.