The system security plan is the single most important document in a NIST SP 800-171 program. It is where you state your boundary, describe your environment, and explain how each requirement is met. Every assessment, from a self-assessment to a CMMC certification assessment, is a test of what the plan says.
It is also the document most often written once, for an assessment, and then left to go stale. This article covers what the plan has to contain, a structure that works for both writers and assessors, the details specific to 800-171 that assessors look for, and how to keep it true after the assessment ends. It uses Rev. 2 numbering. Check which revision your contract cites.
Why the plan carries so much weight
Requirement 3.12.4 in Rev. 2 asks you to develop, document, and periodically update a system security plan. On its face, that is one requirement out of
In practice the other 109 are assessed against it.
An assessor starts with the plan. They read your boundary to know what to sample, your implementation descriptions to know what to test, and your references to know which policies and records to request. A plan that is vague makes the assessment slower and less predictable. A plan that is missing ends it: the DoD Assessment Methodology treats a missing plan as preventing an assessment from being completed.
The plan also travels. When you post a score in DoD's Supplier Performance Risk System, the entry identifies the plan that was assessed. Primes and customers may ask to see parts of it. It should be written to be read by outsiders.
What the plan must describe
Requirement 3.12.4 names four things. A plan that covers them is complete in substance, whatever template it uses.
System boundaries. What is in scope and what is not, and where the edge lies.
System environments of operation. Where the system runs: offices, data centers, cloud services, remote work, and the conditions in each.
How security requirements are implemented. For each requirement, how it is met, or why it is not yet met.
Relationships with or connections to other systems. What the system exchanges data with, and how.
Rev. 3 expands the plan requirement and moves it into the new Planning family. If you are preparing for Rev. 3, read its plan requirement in full, since it asks for more content than Rev. 2's four items.
A structure that works
Templates exist, including NIST-provided ones, and the format matters less than the content. This structure works well because it lets an assessor move from the general to the specific without hunting.
System identification. Name, owner, the roles responsible for security, and the contracts the plan supports.
Scope and boundary. A plain-language description of what is in scope and why, with the asset categories you used.
Environment. Locations, hosting, remote access, and how users connect.
Diagrams. A network diagram showing the boundary and every connection across it, and a data flow diagram showing how CUI enters, moves, and leaves.
Asset inventory. By reference, if it lives in another system, with the date of the version used.
Interconnections and external services. Each cloud provider, managed service provider, and connected system, with what it does and what it is responsible for.
Requirement-by-requirement implementation. All 110 requirements, each with status, description, responsible role, and references to evidence.
Not applicable justifications. For any requirement marked not applicable, the fact that makes it so.
Plan of action reference. A pointer to the plan of action covering every requirement not fully implemented.
Approval and change history. Who approved the plan, when, and what changed in each version.
Section 7 is the bulk of the work. How to write those descriptions so they can be tested is covered in our guide to writing control implementation statements. The guidance there is written for 800-53 controls, and it applies unchanged to 800-171 requirements.
The 800-171 details assessors look for
Some descriptions draw closer scrutiny under 800-171 than in other frameworks. Write these carefully.
The boundary, if you use an enclave. How CUI is kept inside, what prevents it leaving, and how users move between the enclave and the rest of the business. Your scoping work feeds this directly; see scoping where CUI lives.
Cryptography. For 3.13.11, which cryptographic modules protect CUI, and the validation certificate for each. "Encrypted with AES-256" does not answer the question.
Multi-factor authentication coverage. For 3.5.3, which access paths use MFA, including local access to privileged accounts, and how service and emergency accounts are handled.
External service providers. Which requirements each provider meets on your behalf, the evidence you hold for that, and which parts stay with you. A responsibility matrix, referenced from the plan, is the clearest form.
Contractor risk managed and specialized assets. If you use these CMMC categories, the plan should say which assets fall into them and how they are managed.
Logging coverage. Which components send audit records, where they go, and how long they are kept.
Describing the present, not the target
The plan describes the system as it is on the day it is signed. That sounds obvious and is the most common error in practice.
If a requirement is partially implemented, say which parts are in place and which are not, and reference the plan of action item. If it is planned, say so. A plan that describes the target state as current creates two problems at once. An assessor will find the gap and record it, and will then have reason to doubt the rest of the document. Where a score is posted on the basis of that plan, the gap between the plan and reality becomes a question of accuracy, not only of security.
Keeping the plan accurate
Requirement 3.12.4 says "periodically update." Treat that as two triggers.
On change. Update the plan when something it describes changes: a new cloud service, a new office, a new provider, a change of tooling, or a change to the boundary. Add "does this change the system security plan?" to your change management and procurement steps.
On a schedule. Review the whole plan at a defined interval, even if nothing seems to have changed, and record the review. Things change without tickets.
Version the plan. Keep each approved version, with the date and approver. An assessor or a prime may need to know what the plan said on a specific date, and your SPRS entry identifies the plan you scored. If you are moving toward Rev. 3, note that its plan requirement asks for defined review frequencies. Our article on Rev. 2 and Rev. 3 differences covers the wider changes.
Common plan failures
Template text left in. Placeholder language or another company's system name is the fastest way to lose an assessor's confidence.
Requirements restated as implementation. "We limit system access to authorized users" is the requirement, not a description of how.
Diagrams that do not match. If the diagram shows a connection the narrative omits, or the reverse, expect questions about both.
No owners. Every requirement needs a responsible role.
Values that disagree. A session timeout of 15 minutes in the plan and 30 in the configuration is a finding.
Our NIST 800-171 framework page lists the requirements the plan must cover.
How TrustLynce helps
TrustLynce versions the policies and procedures your plan references, with approval and acceptance tracking, so the plan and the documents behind it stay in step. Evidence for each requirement is collected on a schedule from connected systems. See policy management.