Writing an SSP for a 40-Person Shop (Without Paying a Consultant Five Figures)

A System Security Plan (SSP) is the document that describes how your company implements each of the 110 security requirements of NIST SP 800-171: what your system boundary is, what environment it runs in, how every requirement is met, and how your systems connect to everything else. It is required by DFARS 252.204-7012 through requirement 3.12.4, and it is the single document every other part of your compliance program hangs off of. Your self-assessment is a review of your SSP. A government assessment is a review of your SSP. A CMMC certification assessment works from your SSP. This article explains what the document must contain, how to structure it so it survives scrutiny, and why a downloaded template on its own will not get you there.

Why this one document outranks the rest

Three structural facts give the SSP its weight.

Without it, you have no score. The DoD Assessment Methodology is explicit: the assessment is based on reviewing the SSP, so if there is no SSP, the finding is that an assessment could not be completed due to incomplete information and noncompliance with DFARS 252.204-7012. Not a low score. No score, and therefore no eligibility under DFARS 252.204-7019.

Assessors work from it, not around it. Under NIST SP 800-171A, an assessor's job is to determine whether each requirement is satisfied as described. Your SSP's implementation statements are the claims being tested. A vague statement gives the assessor nothing to verify, and "we couldn't verify it" resolves to Not Met.

It has already featured in enforcement. In the government's 2025 settlement with a defense contractor over cybersecurity representations, one of the allegations was that for a three-year period the company lacked a consolidated written plan describing system boundaries, operating environment, implementation of requirements, and system interconnections for its covered systems. The absence of the document itself was part of the case.

What an SSP legally must contain

Requirement 3.12.4 specifies four elements. Everything else is formatting.

1. System boundary. Which systems, devices, networks, and locations are inside the plan's scope, and which are excluded and why.
2. Environment of operation. What the system actually is: the shop network, the office VLAN, the M365 or GCC High tenant, the CAD workstations, the CNC controllers that touch technical data.
3. How each security requirement is implemented. The core of the document: a statement for each of the 110 requirements describing how your company meets it, or declaring it not yet implemented (which routes it to your POA&M) or not applicable (with justification).
4. Relationships with, or connections to, other systems. Your MSP's remote-management tooling, cloud services, the prime's portal, anything that touches the boundary.

NIST publishes a free SSP template alongside SP 800-171, and it is a fine skeleton. The reason templates fail is not the skeleton. It is what people put in it, which brings us to the part assessors actually read.

The per-requirement statement: structure that survives assessment

The unit of work in an SSP is the implementation statement, and the standard that statement has to meet is set by NIST SP 800-171A. There, each of the 110 requirements is decomposed into assessment objectives, 320 in total, and an assessor determines each objective individually. Requirement 3.1.1 ("limit system access to authorized users...") is not one question. In 800-171A it is six determinations: are authorized users identified, are processes acting on their behalf identified, are authorized devices identified, and is access actually limited to each of those three sets.

So the statement that survives assessment is written to the objectives, not the heading. A workable structure for each requirement:

• Status: Implemented / Not implemented (POA&M reference) / Not applicable (justification).
• What: the mechanism, named specifically. The actual products, settings, and policies, not categories of them.
• Who: the role responsible for operating and reviewing it.
• Where: which part of the boundary it applies to, if not everywhere.
• Evidence pointer: what artifact demonstrates it, and where that artifact lives.

Here is the difference in practice, using 3.5.3 (multifactor authentication):

Template-grade statement: "The organization uses multifactor authentication to protect accounts."

Assessable statement: "MFA via Microsoft Entra ID is enforced by conditional access policy for all user accounts (network access) and for the two administrator accounts (local and network access). Enrollment is verified monthly by the Quality Manager against the active-user list from onboarding records. Shop-floor machine controllers do not have network accounts and are addressed under 3.1.1. Evidence: conditional access policy export, monthly enrollment report."

The first statement cannot be assessed; it names no scope, no mechanism, no owner. The second one maps to the objectives an assessor must determine, tells them exactly what to examine, and admits its own edge cases instead of hoping nobody asks about the shop floor. Writing 110 of these is the actual labor of an SSP. It is also why the document commonly runs long: at even a paragraph per requirement plus scoping and diagrams, a thorough small-shop SSP lands well north of a hundred pages.

Scope before you write a word

Most of the pain in an SSP is determined before the first implementation statement, when you decide where CUI lives. Two principles do most of the work for a small shop.

Shrink the boundary. Every device inside the boundary is a device you must describe and control across all applicable requirements. If drawings and specs are received, stored, and processed only on a defined set of systems (a CUI enclave: specific workstations, a specific file store or GCC High tenant, a controlled segment of the network) then the SSP describes that enclave, not every PC in the building. The front-office computer that only ever touches QuickBooks is a scoping decision, and the right decision keeps it outside.

Claim inherited controls honestly. If your MSP runs patching or your cloud tenant provides encryption at rest, those are legitimately part of how requirements are met, but "inherited" does not mean "somebody else's problem." The SSP must say who provides the control, and you need the provider's documentation (a shared-responsibility matrix, a contract clause, their attestations) as evidence. An assessor will not accept "our IT guy handles it" as an implementation statement, and neither should you: several requirements, like maintaining the SSP itself and reviewing access, cannot be inherited at all.

Get the boundary drawn, the CUI flow mapped (how technical data arrives, where it is stored, who touches it, how it leaves), and the asset inventory written first. Every implementation statement afterward inherits its scope from this section, which is why a wrong boundary means rewriting the whole document.

Why bare templates fail

Assessors and government reviewers read many SSPs, and template language is instantly recognizable: present-tense claims copied from the requirement text itself ("the organization limits system access to authorized users"), no named systems, no named roles, no scope statements, every requirement miraculously implemented. Three failure modes follow.

The circular statement. Restating the requirement as a claim describes nothing and cannot be verified. It converts directly to Not Met when the assessor asks "how?" and the document has no answer.

The aspirational statement. Templates default to "implemented," and busy people leave the default. Now the SSP claims things that are not true, your self-assessed score inherits the inflation, and you have converted a paperwork gap into a misrepresentation posted to a federal system. The enforcement cases covered in the affirmation article show exactly where that road ends.

The frozen document. A template filled in once, as a project, describes the company as it was that month. The SSP is required to be periodically updated; 3.12.4 says so in its own text. When the assessor finds the SSP describing a file server you decommissioned last year, every other statement in the document becomes suspect.

A template is a table of contents. The product is a truthful, specific, current description of your system, and no download supplies that.

What assessors actually check

Whether it is your own Basic self-assessment, a government Medium or High assessment, or a C3PAO certification assessment, the mechanics are the same, drawn from 800-171A's three assessment methods: examine (documents, configurations, records), interview (the people named as responsible), and test (watch the mechanism work). Practical consequences:

• Your SSP statements are compared against evidence. The statement says enrollment is verified monthly; the assessor asks for the last three monthly reports. Statements you cannot back with artifacts score as Not Met regardless of what is actually configured, because the assessment burden of proof runs through documentation.
• Your people are part of the evidence. The Quality Manager named in the statement will be asked what they do and how. If the SSP and the human disagree, the SSP loses.
• Internal consistency is checked. SSP says implemented, POA&M lists it as open, score assumes it is met: that contradiction is the first thing a reviewer finds, and it undermines the whole document's credibility.

This is also why the widely repeated assessor observation rings true: small contractors fail on documentation and evidence far more often than on technology. The MFA was on. Nobody could show the policy requiring it, the scope it covered, or a record that anyone checked.

The build, in order, for a shop like yours

A realistic sequence for a 10–100 person contractor with a quality manager and an outsourced IT provider, no security team:

1. Map CUI flow and draw the boundary (owner + quality manager + MSP, together; this is a business decision as much as a technical one).
2. Inventory in-scope assets and connections, including the MSP's tooling and cloud tenants.
3. Draft implementation statements family by family, in the structure above, telling the truth about status. The quality manager who already maintains ISO 9001 or AS9100 documentation has exactly the right instincts for this; it is the same discipline pointed at a different standard.
4. Route every "not implemented" to the POA&M with an owner and a date, and compute your score from the honest statuses.
5. Attach evidence per statement as you go, timestamped, so the SSP points at proof instead of promising it.
6. Set the review cadence: statements re-checked when systems change and at least annually, before the affirmation is signed.

On cost: consultant-written SSPs for small contractors routinely quote in the five figures, and the deliverable is a snapshot that begins aging the day it lands. The knowledge a consultant brings is real, and for scoping decisions an experienced outside eye can pay for itself. But the ongoing document, the 110 statements that must stay true, has to live inside your company either way, because your people are the ones who will be interviewed against it and your Affirming Official is the one signing above it.

That maintenance problem is what Valontir is built around: each of the 110 requirements tracked against its 800-171A objectives, implementation statements and evidence held per requirement, and the SSP and POA&M generated from that living record instead of written once and left to rot. When something changes, the documents and the score change with it.

FAQ

Is there an official SSP template? NIST publishes a free SSP template companion to SP 800-171, and the DoD does not mandate any particular format. The four required elements of 3.12.4 are what matter, in any structure.

How long should an SSP be? As long as truthful specificity requires. Small-shop SSPs commonly run 100+ pages once all 110 statements, scoping, diagrams, and inventories are included. Length is a byproduct, not a target.

Can our MSP or consultant write it? They can help draft it, and their controls can be described in it. But the statements must describe your company truthfully, your staff will be interviewed against it, and your senior official affirms it annually. Ownership cannot be outsourced.

Does a POA&M excuse missing statements? No. A plan of action covers a requirement that is honestly marked not implemented. It does not repair an SSP that misdescribes or omits how requirements are met, and the requirement it covers still scores as not met.

Do we need a separate SSP per system? One SSP can cover one defined boundary. If CUI genuinely lives in two disconnected environments, each needs to be described; most small shops engineer their way to a single enclave and a single plan on purpose.

---

Valontir is a compliance workspace for small defense contractors: every 800-171 requirement, every piece of evidence, and your live SPRS score in one place, so your annual affirmation has evidence behind it. Book a demo or request access.

Sources: NIST SP 800-171 Rev. 2 (requirement 3.12.4 and the SSP template under Supplemental Material) · NIST SP 800-171A · DFARS 252.204-7012 · DFARS 252.204-7019 · NIST SP 800-171 DoD Assessment Methodology, v1.2.1 · DOJ: MORSECORP settlement (Mar. 26, 2025)