Writing an SSP and POA&M for NIST 800-171 (Small Contractor Guide)

Every small defense contractor eventually gets told they need a system security plan. Almost nobody gets told where that requirement actually comes from, what has to be in it, or why the document they downloaded from a template site will fail an assessment.

This is the practical version, written for a shop with five people and no security staff. It covers the legal basis, what goes in the plan, how to scope it so the work is survivable, the plan-of-action rules that trip people up, and the specific failures assessors reject.

Where the requirement actually comes from

The chain has three links and the middle one is usually cited wrong.

It starts with DFARS 252.204-7012, paragraph (b)(2)(i), which requires that the covered contractor information system be subject to the security requirements in NIST SP 800-171. Under a class deviation still in effect, that means Revision 2 specifically, not whatever version is current.

Note what that is not. It is not (b)(2)(ii), which covers the implementation deadline, DoD CIO variance requests, and the cloud rule. And it is not (b)(3), where the clause mentions that additional measures “may” be addressed in a system security plan — that is permissive language, not a mandate. Citing (b)(3) as your authority is a common and avoidable error.

The second link is NIST SP 800-171 Rev 2, requirement 3.12.4: “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.”

The third is the CMMC program rule, which states that organizations must have an SSP in place at the time of assessment, and that the absence of an up-to-date one “would result in a finding that an assessment could not be completed.” The same rule bars the SSP requirement from ever appearing on a plan of action.

One version note worth carrying: in Revision 3, NIST withdrew 3.12.4 and moved the SSP into a new Planning family, expanding it considerably and adding a requirement to protect the plan from unauthorized disclosure. Revision 3 does not apply to DoD today. A proposed FAR rule published in June 2026 would apply Rev 3 government-wide, but it is not final.

There is no required format

NIST says so in a footnote to 3.12.4: “There is no prescribed format or specified level of detail for system security plans. However, organizations ensure that the required information in 3.12.4 is conveyed in those plans.”

The discussion section adds that the SSP and plan of action can be separate or combined documents, in any format, and that the plan need not be a single document — it can be a collection of things you already have.

Format is yours. Content is not.

The eight things an assessor checks

NIST SP 800-171A breaks 3.12.4 into eight determination statements. This is your acceptance criteria, and it is worth reading as a checklist rather than prose:

• [a] a system security plan is developed
• [b] the system boundary is described and documented
• [c] the system environment of operation is described and documented
• [d] security requirements identified and approved as non-applicable are identified
• [e] the method of security requirement implementation is described and documented
• [f] the relationship with or connection to other systems is described and documented
• [g] the frequency to update the SSP is defined
• [h] the SSP is updated with the defined frequency

Small shops routinely satisfy [a] through [f] and fail on [d], [g], and [h] — no documented rationale or approver for the requirements marked not applicable, no stated review cadence, and no evidence the cadence was ever met. A signed and dated revision history table fixes two of the three.

A version trap while we are here: the June 2018 edition of SP 800-171A was withdrawn by NIST in May 2024. CMMC still incorporates that withdrawn edition by reference. As a DoD contractor you use the withdrawn document. Do not switch to 800-171A Rev 3.

An SSP outline you can actually follow

1. Cover block — legal name, CAGE codes in scope, UEI, version, effective date, and an approval signature with a date.
2. Revision history table — date, version, author, change summary, approver. This is your evidence for [h].
3. Review cadence statement — one sentence committing to at least annual review and update on significant change. Satisfies [g].
4. System identification — system name and ID, system owner, security officer or affirming official, government point of contact.
5. Purpose and mission — what you do and which contracts drive the handling of controlled information.
6. Information types — the specific CUI categories you handle, mapped to the NARA CUI Registry, and whether any FCI-only environment exists.
7. Boundary — narrative and diagram. State explicitly what is in and what is out, and be prepared to justify why out-of-scope assets cannot touch CUI.
8. Categorized asset inventory — every asset tagged by category, with hardware models, software versions, cloud tenants, and service providers.
9. Network diagram — showing the boundary, in-scope assets, external connections, and where CUI rests and moves. It must match sections 7 and 8 exactly.
10. Environment of operation — physical sites, remote workers, device posture, on-premise versus cloud split.
11. CUI data flow narrative — how it arrives, where it lands, who touches it, how it leaves, how it is destroyed.
12. External providers — for each, what it processes, its FedRAMP status, and the responsibility matrix.
13. Roles and user counts — general, privileged, administrative, externally managed.
14. The 110 requirements — one entry each: status, a narrative describing what you actually do naming the real product and setting, and a pointer to the evidence. For anything marked not applicable, the rationale and the approver.
15. Enduring exceptions — circumstances where full compliance is infeasible, with mitigations. Described properly in the SSP, these are scored as met. This is the highest-leverage paragraph in the document.
16. Appendices — policy index and an evidence artifact index mapping artifact to requirement to location to owner to date.

Scoping: the decision that determines how much work this is

Handling only Federal Contract Information puts you at CMMC Level 1 and fifteen requirements. Handling Controlled Unclassified Information puts you at Level 2 and all 110. That distinction is worth getting right before anything else.

Within a Level 2 scope, the CMMC rule sorts assets into five categories:

• CUI Assets — process, store, or transmit CUI. Assessed against all Level 2 requirements.
• Security Protection Assets — provide security functions for the scope. Assessed against the requirements relevant to what they do.
• Contractor Risk Managed Assets — can but are not intended to handle CUI, because of policy and practice. The assessor reviews your SSP; if the documentation is sufficient, no further assessment. If it raises questions, a limited check.
• Specialized Assets — can handle CUI but cannot be fully secured: IoT, operational technology, government furnished equipment, restricted systems, test equipment. SSP review only, not assessed against other requirements.
• Out-of-Scope Assets — physically or logically separated, or inherently unable to handle CUI. Not assessed, but you must be prepared to justify the inability.

The first four all require an asset inventory, SSP treatment, and a network diagram.

Service providers scope in on a simple test: does it touch CUI, or does it touch security protection data such as logs, configuration and vulnerability status, or credentials granting access to the environment? Either one pulls the provider into scope — which is how your managed service provider ends up inside your boundary. Your payroll platform, touching neither, stays out. A cloud provider handling CUI must meet FedRAMP Moderate requirements or an equivalency assessed under DoD policy.

The rule never uses the word “enclave,” but the mechanics reward one. A narrower boundary means fewer CUI Assets, more out-of-scope assets, and far less to write and evidence. The cost is a separation you must be able to demonstrate. For a five-person firm, a hardened enclave is usually the difference between achievable and not.

Plans of action: two different documents with the same nickname

The CMMC rule defines two distinct artifacts and the difference is worth real money.

An operational plan of action — the thing requirement 3.12.2 asks for — identifies temporary vulnerabilities and deficiencies. The rule states it “does not identify a timeline for remediation and is not the same as a POA&M.” A temporary deficiency properly captured in one is scored MET.

A POA&M is the assessment-driven instrument. A requirement on one is still scored NOT MET, whether it appears on a POA&M or not.

The POA&M rules, precisely

At Level 1, a POA&M is not permitted at any time. Full stop.

At Level 2, Conditional status requires all three of the following:

1. Your score divided by the total number of requirements is at least 0.8 — which works out to 88 of 110.
2. Nothing on the POA&M is worth more than 1 point, with one exception: 3.13.11 may be included if encryption is employed but not FIPS validated, at a value of 3.
3. None of six specific requirements appears on it, ever: 3.1.20 external connections, 3.1.22 control of public information, 3.12.4 the system security plan, 3.10.3 escort visitors, 3.10.4 physical access logs, and 3.10.5 manage physical access.

Read condition two carefully. Everything worth five points and everything worth three points is ineligible, save the encryption exception. Only one-point requirements can be deferred.

Then the clock. Closeout must be confirmed by a closeout assessment within 180 days of the Conditional status date. Miss it and the Conditional status expires. If that happens mid-performance, standard contractual remedies apply and you become ineligible for additional awards requiring that status until you achieve a new one.

Two timing details people get wrong: the 180 days runs from the Conditional status date, not from closeout. And a successful closeout does not reset your date — the Conditional date remains the status date, so your three-year reassessment clock started on day zero.

What goes in the POA&M

The regulatory definition calls for tasks to be accomplished, resources required, milestones, and scheduled completion dates. NIST’s own template uses eight columns: weaknesses; responsible office; resource estimate (funded, unfunded, or reallocation); scheduled completion date; milestones with interim dates; changes to milestones; how the weakness was identified; and status.

For CMMC use, add the requirement identifier, the specific assessment objectives scored not met, the point value (to prove eligibility), the Conditional status date and the day-180 deadline, and a reference to the closeout evidence.

Practical notes: every milestone needs an actual date — “Q3” is not one. An unfunded remediation with a completion date inside 180 days is a red flag an assessor will probe. And “changes to milestones” is the column that proves this is a living document rather than something generated once.

What assessors actually reject

Anchored in the rule text rather than folklore:

• Draft anything. The rule states all evidence must be final, and names working papers, drafts, and unofficial or unapproved policies as unacceptable. An unsigned policy is not a policy.
• One missed objective kills the requirement. Every assessment objective must be met or not applicable for the requirement to score as met.
• A missing or stale SSP ends the assessment. Not a deduction — a stop.
• Copy-pasted control language. Restating the requirement back at the assessor fails [e], which asks for the method of implementation. Name the product, the setting, and the person.
• Policy mistaken for implementation. The assessment methods are examine, interview, and test. A document satisfies only the first.
• Inherited controls with no responsibility matrix. Using a FedRAMP-authorized cloud provider does not make you compliant. The rule’s preamble is explicit: you are not responsible for the provider’s compliance, but you must document in your SSP how you meet the requirements the provider’s customer responsibility matrix assigns to you. Buying GCC High does not implement multifactor authentication for you.
• Requirements true for most assets but not all. The most common real-world failure is not a missing control; it is a control that holds on eight of ten machines.
• Not-applicable determinations with no rationale and no approver. Fails [d] specifically.

What this costs a five-person shop

The CMMC final rule’s regulatory analysis puts a Level 2 self-assessment and affirmation for a small entity at roughly $34,277 initially and about $37,196 over three years, representing something like 140 hours split between a company principal and an outside specialist. Level 1 runs about $5,977 a year, roughly 24 hours.

Here is the caveat that makes those numbers honest: the rule explicitly states there are no engineering costs included, because it assumes you have already implemented the requirements. Those figures are assessment and paperwork only. They exclude buying GCC High, FIPS-validated encryption, multifactor authentication, log retention, vulnerability scanning, a managed provider, or any remediation labor at all. Anyone quoting $34,277 as “the cost of CMMC Level 2” is quoting DoD accurately and misleading you.

Why the SSP is the document that creates legal exposure

Your SPRS score is computed from what your SSP asserts. The assessment methodology says the self-assessment is based on a review of the system security plan. A government assessment then validates whether requirements were implemented as described in that plan.

So the chain runs: the SSP asserts implementation, the score is computed from those assertions, the score is posted, and the score is a representation relied on for award and reaffirmed annually by a named official. A verification that reality does not match the plan invalidates the score and impeaches the affirmation at the same time. Assessment evidence must be retained for six years — the same artifacts that prove compliance are the ones that get subpoenaed.

The June 2026 LOGZONE settlement — $507,144, with a DCMA assessment scoring the company at −170 — was not a case about having no SSP. It was about a gap between what was represented and what existed.

Which points to advice that runs against what a lot of consultants sell: an honest low score backed by a plan the SSP actually supports is a far safer place to stand than a flattering number your documentation cannot defend.

Key takeaways

• The SSP requirement flows from DFARS 252.204-7012(b)(2)(i) into NIST SP 800-171 Rev 2 requirement 3.12.4 — not from (b)(2)(ii) or (b)(3).
• Revision 2 applies to DoD. Revision 3 is proposed government-wide but not final.
• There is no required format, but eight specific determination statements must be satisfied.
• Scoping decides the size of the job. Asset categorization and a defensible boundary are the leverage.
• An operational plan of action scores MET; a POA&M does not.
• Level 2 Conditional status requires a score of at least 88 of 110, only one-point items deferred, and six named requirements never on the list.
• The 180-day closeout clock runs from the Conditional status date and closeout does not reset it.
• DoD’s published cost estimates exclude all remediation and engineering.

Frequently asked questions

Can I use a downloaded SSP template? As a skeleton, yes — NIST publishes one. Two warnings: its requirement text is built on the December 2016 version of the standard and must be replaced with Rev 2 wording, and a template only structures the document. The narrative describing what you actually do is the part being assessed, and it cannot be borrowed.

Do I need a separate SSP for each contract? Not necessarily. The SSP describes an information system, not a contract. One well-scoped plan covering the environment where CUI lives usually serves multiple contracts. What matters is that the plan accurately describes the system in the assessment scope.

My cloud provider is FedRAMP authorized. Am I covered? No. You inherit the provider’s controls, not compliance. Their customer responsibility matrix assigns specific requirements to you, and your SSP has to document how you meet each one. Skipping that is one of the most common assessment failures.

If you need help scoping a boundary or building an SSP that will hold up, Veteran Forge Strategies works with small federal contractors on NIST 800-171 documentation and remediation. Related: NIST 800-171 for small contractors and DFARS cybersecurity requirements.