ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A NIST 800-171 SSP is the document that defines your CUI environment and explains how each requirement is met, and for a defense contractor it is often the first thing an assessor asks to see. A weak plan makes every other part of the assessment harder; a strong one lets the assessor understand your boundary, your controls and your evidence quickly.
This guide explains what the system security plan must contain, how the requirement appears in both Revision 2 and Revision 3 of NIST SP 800-171, which revision applies to you in 2026, how to write implementation statements that hold up and how the plan connects to your plan of action and milestones and your CMMC assessment. Always read the current contract clauses and program rules for your situation.
Free gap assessment
What would your SPRS score be today?
Score all 110 NIST SP 800-171 requirements, free, plus the DFARS duties around them: plans of action, 72-hour incident reporting and flow-down.
Run the free NIST SP 800-171 gap assessment → or View premium report sample
NIST SP 800-171 sets security requirements for protecting controlled unclassified information in nonfederal systems and organizations. The standard expects organizations to document their systems and the way requirements are met in a system security plan. In Revision 2, this is requirement 3.12.4. In Revision 3, published on 14 May 2024, the plan sits in the new Planning family as requirement 03.15.02.
The SSP is both a management document and an evidence document. Internally it tells engineers and managers how the environment is meant to work. Externally it tells assessors what to test. See our overview of NIST SP 800-171 and the basics of controlled unclassified information.
Revision 3 was published in 2024 and supersedes Revision 2, but contract requirements move more slowly. One published comparison reports that CMMC Level 2 and the DFARS 252.204-7012 clause currently still require Revision 2 under a Department of Defense class deviation, and that assessors cannot yet assess against Revision 3. The same source reports that a transition is expected later in the CMMC rollout. Check your contract and the current CMMC rules before choosing a revision.
Write your plan so that it can be updated. Structure implementation statements by control family, keep a crosswalk to the other revision and record which revision the plan targets. Our guide to NIST 800-171 Rev 3 lists the changes, including the additional organization-defined parameters and the new families.
The most common SSP failure is a poorly drawn boundary. List every system, network segment, endpoint, cloud service and person that touches CUI. Include the security protection assets that support them, such as identity systems, log servers and firewalls. Draw data flows showing how CUI arrives, where it is processed and stored and how it leaves.
Decide what is out of scope and justify it. If you use an enclave to limit scope, document its controls and the segregation from the rest of the network. A smaller, well-defined boundary is cheaper to secure and easier to assess, but only if the separation is real and evidenced.
| Plan section | What to include | Why assessors care |
|---|---|---|
| System description | Purpose, users, locations, CUI handled | Shows you understand what you protect |
| Boundary and scope | Assets that process, store or transmit CUI, plus security protection assets | Defines what is assessed |
| Data flows | How CUI enters, moves and leaves | Reveals hidden systems and connections |
| Roles and responsibilities | Owners for each control area | Shows accountability |
| Control implementation statements | How each requirement is met and by whom | Core of the assessment |
| External providers | Cloud and managed service responsibilities | Shared responsibility must be clear |
| POA&M reference | Open gaps, owners and dates | Shows honest status |
For each requirement, write a statement that says what the control is, how it is implemented, which system or team does it and where the evidence lives. Avoid copying the requirement text back as the answer; “we implement access control” is not an implementation statement. A good one reads more like: “Access to the CUI enclave is restricted to named users through role-based groups in the identity system; access requests are approved by the system owner and reviewed quarterly; review records are stored in the compliance repository.”
Be honest about status. If a control is partly implemented or not implemented, say so and reference the plan of action and milestones. Overstating implementation is worse than admitting a gap, because assessors test claims against evidence. See NIST 800-171A for the assessment procedures used to evaluate each requirement.
The plan describes the current state; the plan of action and milestones lists the gaps and how you will close them. The two must agree. When a requirement is marked not implemented in the plan, it must appear in the POA&M with an owner and a date. Contractors in the Department of Defense supply chain also report a self-assessment score; read our guide on the SPRS score to see how scoring works. The score must be consistent with the plan, because inconsistencies are a red flag.
Keep the plan current. Update it when systems change, when a new cloud service is adopted and after every assessment or incident.
If you use a cloud or managed service to handle CUI, your plan must describe which controls the provider implements and which you implement. Gather the provider’s documentation and map it to the requirements. Do not assume that a provider certification covers your responsibilities; assessors expect a clear customer responsibility matrix. The link with CMMC is explained in CMMC compliance. For the differences between this standard and the federal baseline, see NIST 800-171 vs 800-53.
The following sequence works for most contractors.
Effort depends on scope and maturity. Writing the plan usually takes weeks for a small, well-scoped environment and months for a complex one, and the real cost lies in the controls and evidence behind it. See NIST 800-171 compliance cost for budget categories. Shrinking scope with an enclave is often the most effective cost control.
A template supplies the structure: system description, boundary, data flows, roles, requirement-by-requirement implementation statements, external provider responsibilities and POA&M references. The NIST SP 800-171 Toolkit includes editable versions, and our page on NIST 800-171 templates explains what a full set contains.
For the source standard, see the NIST SP 800-171 Revision 3 publication page. A template does not replace knowing your environment; fill each section with facts from your systems and verify them with the people who run them.
Take the requirement to limit system access to authorized users. A weak answer says that access control is in place. A strong one says that user accounts for the CUI enclave are created only after a manager approves a request in the ticketing system, that accounts are assigned to role-based groups defined in the identity platform, that multi-factor authentication is enforced for all users, and that the IT manager reviews group membership quarterly and stores the signed review in the compliance repository. It then names the system owner and the evidence locations. Statements of this kind can be tested by an assessor in minutes, which is exactly why they work. Names, tools and timings in this example are illustrative.
Before an assessment, have someone who did not write the plan read it with the evidence folder open. For a sample of twenty requirements, ask whether they can find the evidence named in the statement within two minutes. Note every broken reference, outdated screenshot or unclear owner, and fix them. Confirm the boundary diagram matches the asset inventory, and confirm that every gap in the plan appears in the POA&M. This simple review finds most of the problems that would otherwise surface in the assessment room.
The plan should be approved by a person with authority over the system and the business risk, often the CIO, CISO or an executive sponsor, and the approval should be dated and recorded. Re-approve after significant changes. Keeping an approval history also shows assessors that management owns the environment and the risk. Store the approved copy where the responsible team can reach it, and control the versions so nobody works from an outdated plan.
Frequent errors include a boundary that omits cloud services, implementation statements copied from the requirement, claims without evidence, a plan that contradicts the POA&M and a document that nobody updates. Another is writing the plan once for the audit and then never using it. Treat it as a living operating document, and review it whenever your environment changes.
A system security plan that describes the CUI environment and how each NIST SP 800-171 requirement is implemented. It is required by the standard and examined during assessments.
Requirement 3.12.4 in Revision 2 and 03.15.02 in Revision 3.
Check your contract and current CMMC rules. One published comparison reports that CMMC Level 2 and DFARS currently require Revision 2.
The SSP describes the current state and how controls are met. The POA&M lists gaps and how and when you will fix them.
When your environment changes and at least annually.
