NIST 800-171 system security plan: what it must contain

Does a NIST 800-171 system security plan have to exist before an assessment?

Yes. If a DoD contract or CMMC requirement is in front of you, an up-to-date system security plan (SSP) must exist before a DoD Basic Assessment or a CMMC assessment can proceed. Requirement 03.15.02 in SP 800-171 Rev. 3 requires the plan, and 32 CFR 170.24 requires an up-to-date SSP at the time of assessment. Without one, the DoD Assessment Methodology treats the assessment as incomplete, which is also a finding of noncompliance with DFARS 252.204-7012. Treat the SSP as a gating document, not a report you write after the assessment is scheduled.

What the plan says depends on your own environment. It has to reflect your system boundary, the categories of in-scope assets (CUI assets, security protection assets, contractor risk managed assets and specialized assets such as IoT, OT and test equipment, as 32 CFR 170.19(c) lists), each cloud or external service provider and its customer responsibility matrix, and any alternative or not-applicable requirement that a DoD CIO has adjudicated. Your organization owns the plan and must be able to defend every statement in it. An implementation partner can help draft the document and assemble the supporting evidence, but only an independent assessor judges whether the plan and the implementation it describes are sufficient.

Before you commit to a date, confirm three things with your contracting officer and your assessor: which SP 800-171 revision the contract currently names, which assessment you expect, and what format the assessor will accept. NIST publishes a CUI SSP template, and NIST notes that its Rev. 2 guidance sets no prescribed format for the plan, so the format is a decision to agree in writing, not an assumption.

What else the SSP must document for scoping

The SSP is more than a narrative of controls. Under the DoD rules, it must also show which assets are in scope, where the system boundary and external connections sit, how exceptions are handled, and which DoD CIO decisions apply. Each card below is a scoping element an assessor will check, and each one needs an owner to confirm it against the real environment.

Asset categories under 170.19(c)

32 CFR 170.19(c) requires the SSP to show how each in-scope asset category is treated: CUI assets, security protection assets, contractor risk managed assets, and specialized assets such as IoT, OT and test equipment. Each category carries different requirements, so an unclassified asset cannot be left out by default. Confirm that every device in the inventory is assigned to one category and that the SSP explains the reason for each assignment, including the treatment of specialized equipment that cannot host the usual agents.

System boundary and external connections

The DoD Assessment Methodology expects the SSP to describe system boundaries, environments of operation, and relationships with or connections to other systems. Assessors use this description to decide which systems are in scope before they test any requirement. Confirm that the diagram matches live network routes, identity trust relationships, remote access paths and file transfer links, because a connection missing from the SSP is often the first finding raised.

Isolated enduring exceptions with mitigations

An isolated enduring exception is a requirement a specific item cannot meet, such as specialized equipment with a fixed configuration. Under the DoD Assessment Methodology and 32 CFR 170.24, such an exception is assessed as MET when the SSP describes it together with any mitigations. Confirm that each exception names the asset, the requirement, the reason it cannot be met, the compensating controls, and who reviews the exception at each SSP update. Undocumented exceptions are treated as gaps.

Cloud and service provider responsibilities

32 CFR 170.16(c)(2) and (3) require the customer responsibility matrix of any cloud or external service provider that handles CUI to be documented in, or referenced by, the SSP. The matrix shows which controls the provider implements and which remain with the contractor. Confirm that the provider's current matrix is on file, that its version matches the one referenced in the SSP, and that the contractor has evidence for each control it keeps.

DoD CIO adjudications recorded in the SSP

32 CFR 170.24 requires any DoD CIO adjudication of an alternative or not-applicable requirement to be included in the SSP. These decisions change what the assessor tests, so an adjudication held only in email or a contracting file is easy to miss. Confirm that each adjudication is recorded with its date, the requirement it covers, and the conditions attached, and that the SSP is updated when a new one is issued.

How cloud and external providers appear in the SSP

When a cloud service provider stores, processes or transmits CUI for you, the provider's controls become part of the evidence your system security plan (SSP) must support. Under 32 CFR 170.16(c)(2), the customer responsibility matrix for that provider must be documented in your SSP or referenced by it. The matrix shows which requirements the provider implements, which you implement, and which are shared, so an assessor can see who owns each safeguard.

Provider security package: Obtain the provider's current responsibility matrix and the documentation it cites, such as its independent assurance reports or compliance attestations, and confirm they cover the service you use.
Scope of the service: Confirm that the services holding CUI, including backups, logs and support tooling, are named in the matrix rather than only the headline product.
FedRAMP status: Confirm the provider's authorization level and whether it covers the environment in which your CUI resides. Ask for written confirmation rather than relying on marketing pages.
Your responsibilities: List the requirements you still own, such as user access, encryption key choices, configuration and CUI marking, so none are left unassigned.
Incident and reporting duties: Confirm how the provider notifies you of incidents and how that fits your reporting obligations under DFARS 252.204-7012.

Before an assessment, check that the matrix version matches the provider's current service terms and that the SSP cites that version.

What keeping the SSP current costs

This table compares the cost components of keeping a NIST SP 800-171 system security plan current, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Only the FAR January 2025 estimate is used for effort, so confirm rates and hours against your own environment before budgeting.

Cost component	Who is paid or who does the work	One-time or recurring	What drives the cost
Initial SSP drafting	Internal staff, or an implementation partner under a fixed-scope written quote	One-time	Number of system components, boundary complexity, number of external service providers, existing documentation
Scheduled review and update	One information security analyst, internal time; FAR January 2025 estimate of about one hour a month (12 hours a year) at $95 an hour	Recurring	Frequency set in the organization's own review cycle under requirement 03.15.02, and the size of the system
Change-driven updates	Internal analyst time, or partner time if scoped in writing	Recurring, irregular	Frequency of system changes, new connections, new cloud services, staff role changes and new CUI flows
Submission on request	Internal analyst time; FAR January 2025 estimate of about 30 minutes to submit the SSP to the Government on request	Recurring, on request	How often contracting officers or assessors ask for the SSP and how current the document already is
Asset inventory and document control tooling	Software or hosting vendors, plus internal administration	Mostly recurring licensing; setup is one-time	Asset count, need for version history and access controls on the SSP, and whether existing tools can be reused
Assessor time reviewing the SSP	Independent assessor or certification body, paid under its own engagement	Recurring per assessment cycle	Quality and completeness of the SSP, number of in-scope systems, and how many review rounds are needed

How an SSP is drafted and kept current

The sequence below moves from defining what the system is to protecting and maintaining the document, so that the SSP describes the environment an assessor will actually examine. Each step produces an artifact that feeds the next, and the finished plan is the basis for any DoD Basic Assessment or CMMC assessment.

Define the system boundary and inventory components
Start by drawing the boundary of the system that stores, processes or transmits CUI, then list every component inside it: endpoints, servers, cloud tenants, identity services, network devices and the connections that cross the boundary. Assign an owner to each component and record where it sits, including any external services. The output is a bounded system description and a component inventory that the rest of the SSP can reference. The step is complete when someone outside the project can trace every component to a boundary decision and a named owner.
Classify assets by treatment category
Sort each inventoried component into the asset categories the DoD methodology uses: CUI assets, security protection assets, contractor risk managed assets and specialized assets such as IoT, OT and test equipment. The category determines how the SSP describes that asset's safeguards and whether it is in scope for assessment. Record the reasoning for borderline cases, since assessors will ask why an asset was treated as out of scope. The output is a categorized asset register that explains each classification.
Map each requirement to implementation status
Work through every requirement in the revision your contract names, using the assessment procedures in SP 800-171A as the checklist for what evidence exists. For each requirement, state whether it is implemented, partially implemented, planned or not applicable, and describe the safeguard in specific terms: the tool, the setting, the owner and the review cadence. Under Rev. 3, record the value your organization assigned to each organization-defined parameter where no federal value was supplied. The output is a requirement-by-requirement implementation narrative, and the step is complete when every requirement has a status and a description.
Document providers, connections and exceptions
Describe every external service provider and cloud service that touches the system, and document its customer responsibility matrix in the SSP or reference it from there. List each system connection, its purpose and the agreement that governs it. Record isolated enduring exceptions, such as equipment that cannot meet a requirement, together with the mitigations applied, and include any DoD CIO adjudication of an alternative or not-applicable requirement. The output is a provider section, a connection register and an exceptions log, each cross-referenced to the requirement it affects.
Obtain internal review and approval
Route the draft to the people who own the controls: IT operations, security, HR for personnel requirements, facilities for physical controls and a legal or contracts reviewer for flow-down and provider commitments. Each reviewer checks the sections they own against how the system actually runs, and records corrections. A senior accountable officer then signs off on the plan. The output is a reviewed SSP with a revision history and a named approver. The step is complete when the people who run the controls confirm that the written description matches their practice.
Protect the SSP from unauthorized disclosure
Because the SSP describes how the system is defended, it should be classified and access-restricted as sensitive information in its own right. Limit read and write access to personnel with a need to know, store it within the protected environment or a controlled repository, and log changes to it. Decide in advance how copies are shared with the contracting agency or an assessor, and through which protected channel. The output is an access-controlled document with a documented sharing procedure, and the step is complete when access settings have been tested against the list of approved readers.
Schedule reviews and updates
Set the review frequency that your organization defines for requirement 03.15.02 and record it in the SSP itself, then add triggers that force an earlier update, such as a significant system change, a new provider, a changed boundary or a finding from a vulnerability scan or assessment. Assign an owner for each review and track the changes in the revision history. Keeping the plan current is an ongoing cost, and the time it takes depends on how often the environment changes. The output is a maintenance calendar, a change trigger list and a dated revision record, which together show an assessor that the SSP reflects the system at the time of assessment.

Questions buyers ask about the SSP

Is a system security plan template enough to meet the requirement?

A template gives you structure, but it does not meet the requirement by itself. NIST publishes a CUI SSP template, and NIST's Rev. 2 page says there is no prescribed format, but the plan must still convey the information requirement 3.12.4 asks for. Rev. 3 carries that obligation into 03.15.02. The plan has to describe your system: its components, the information types it handles, its operating environment and external connections, how each security requirement is implemented, and the people who hold system roles. The DoD Assessment Methodology expects the same content, including system boundaries and relationships with other systems. A template filled with generic statements will not show an assessor how your environment works. Use the template as an outline, then document the system your engineers run today.

Can an implementation partner write the SSP for us?

A partner can draft the SSP and prepare the evidence behind it, but your organization owns the plan and must confirm that every statement matches the live system. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue reports or certifications. A draft is only as accurate as the input your engineers provide, so plan time for them to review each section. Define the scope in writing before work starts: which systems and enclaves are covered, which requirements the SSP must document, how many review rounds are included, and who approves the final version. Ask how the plan will be version controlled, how changes will be tracked after handover, and who keeps the plan current once the engagement ends.

Can a POA&M cover a missing SSP?

No. Under 32 CFR 170.21, the SSP requirement (CA.L2-3.12.4) cannot be placed on a plan of action and milestones for Conditional status. The DoD Assessment Methodology also states that an assessment cannot be completed without an SSP, and treats the absence of one as a finding of noncompliance with DFARS 252.204-7012. A plan of action and milestones can track gaps in other requirements, but it cannot stand in for the plan itself. If you do not have a current SSP, the practical step is to write one before any assessment or score submission, then use the plan of action and milestones only for the specific requirement gaps the SSP reveals.

How often must we update the SSP?

Requirement 03.15.02 requires you to review and update the SSP at an organization-defined frequency, so you choose the interval and write it down in your policy. Calendar reviews are only part of the answer. Update the plan when the system boundary changes, when you add a connection or cloud provider, after a significant incident, and when personnel in system roles change. On cost, the FAR CUI proposed rule of January 2025 estimated that maintaining an SSP takes one information security analyst about one hour a month, or 12 hours a year, at $95 an hour, and that submitting the SSP on request takes about 30 minutes. Those are government estimates. Your own effort depends on how often the environment changes and how many systems the plan covers.

Does Rev. 2 or Rev. 3 govern current DoD work?

For current DoD work, plan around Rev. 2. DoW Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly. It cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. The proposed FAR overhaul published 23 June 2026 would require Rev. 3 with ODP values published by the DoW CIO. Comments closed 23 July 2026, and the rule was not final as of October 2026. Write one SSP that maps to the 110 Rev. 2 requirements and that also covers 03.15.02 in Rev. 3, then confirm the governing revision with your contracting officer in writing.

What must our team supply before an SSP can be written?

Gather the following before drafting starts, so the writers are documenting the system rather than guessing at it:

A current asset inventory with component names, locations, owners and the boundary they sit inside
The CUI types the system handles, with data flow diagrams showing where they move and where they are stored
Network diagrams, external connections and any interconnection agreements
Documentation from each cloud or external service provider, including the customer responsibility matrix
Names and roles of people holding system roles, plus the policies and procedures they follow
Current evidence of implementation, such as configuration baselines, scan results, MFA settings and training records
Treatment of each asset category under 32 CFR 170.19(c): CUI assets, security protection assets, contractor risk managed assets and specialized assets

Ask your partner to confirm this list in writing before work begins, and name a single internal owner who can answer questions quickly.

Where do cloud responsibilities and exceptions go in the SSP?

They go in the SSP itself, and the rules are specific. Under 32 CFR 170.16(c)(2) and (3), the customer responsibility matrix of a cloud or external service provider used for CUI must be documented in, or referenced by, your SSP. Under 32 CFR 170.24, any DoD CIO adjudication of an alternative or not-applicable requirement must be included in the SSP. The DoD Assessment Methodology and 32 CFR 170.24 also treat isolated, enduring exceptions, such as specialized equipment that cannot meet a requirement, as implemented when they are described in the SSP along with any mitigations. Document each exception with the reason it exists, the compensating controls and the review date. Confirm with your provider that its matrix is current, because the SSP can only reference what the provider has documented.

What must be in place before the SSP can support an assessment

An SSP is only as credible as the system it describes. The six items below are the inputs an assessor will test the plan against, and each one can be checked before an assessment begins. Gaps in any of them usually surface as contradictions between the SSP and the evidence.

Defined and current system boundary

The boundary states which people, devices, applications, networks and cloud services store, process or transmit CUI, and which are excluded. Confirm the boundary matches the current network diagram and data flows, not the design from the original contract. Check that a change to a system, tenant or connection triggers a boundary review and an SSP update before the change goes live.

Complete asset inventory

The SSP must show how each in-scope asset category is treated: CUI assets, security protection assets, contractor risk managed assets and specialized assets such as IoT, OT and test equipment. Ask whether the inventory is generated from discovery tools or maintained by hand, and whether it reconciles with the boundary. An asset that is missing from the inventory is an asset the SSP cannot describe.

Documented implementation status per requirement

Each requirement needs a stated status (implemented, planned, alternative, or not applicable) and a description of how it is met in this system. Check that every status is backed by a named control owner and an artifact that can be produced on request. Generic statements such as "managed by IT" do not give an assessor anything to test.

Provider responsibility matrices on file

Where a cloud or external service provider handles CUI, the customer responsibility matrix must be documented in the SSP or referenced from it. Confirm which controls the provider implements, which the organization implements, and which are shared. Keep the provider's current matrix in the records, and check that it still matches the service tier actually in use.

Adjudication records for exceptions

Isolated enduring exceptions, such as specialized equipment that cannot meet a requirement, must be described in the SSP with any mitigations. Any DoD CIO adjudication of an alternative or not-applicable requirement must also be included. Check that each exception names the requirement, the reason, the compensating measures and the decision record, and that no exception appears in the SSP without a matching record.

Controlled SSP location with access restrictions

The SSP itself describes security weaknesses, so it must be protected from unauthorized disclosure, which 03.15.02 requires. Confirm where the controlled copy is stored, who can read or edit it, how versions are tracked, and whether it is kept inside the CUI boundary. Test the access list against current personnel, and confirm that the plan can be produced to the government quickly without circulating it by email.

How DeployOpen prepares the SSP and its evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the system security plan describes systems that actually exist and produce evidence. We prepare the SSP and its supporting artifacts; your organization owns its controls and an independent assessor or certification body issues any report or certificate.

How we scope

We agree a written scope that names the CUI systems, their components and their boundary before work starts.
Scope covers the operating environment, connections to other systems and any cloud or external service providers in the data flow.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.

How we build

We document how each requirement of 03.15.02 is implemented, planned or covered by a described safeguard in your environment.
We record the people holding system roles and map identified threats to the safeguards that address them.
Security testing of applications, cloud and infrastructure can be run to check that documented safeguards behave as described.

How we hand over

You receive the SSP with its supporting artifacts, such as component inventories, network diagrams and configuration baselines.
We record how each asset category is treated and how any isolated exceptions are described with their mitigations.
We set out a review and update procedure with an owner and a schedule your organization confirms and approves.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so the SSP tracks changes to the system.
We can help confirm that the SSP is current before an assessment, while the assessor decides what the evidence proves.
Ask us to confirm the review frequency, ownership and change triggers for your SSP in the written scope.

NIST 800-171 system security plan