NIST 800-171 compliance checklist for defense contractors

What a defense contractor must have in place for NIST 800-171 compliance

A defense contractor or subcontractor whose contract carries DFARS 252.204-7012 must be able to show a current system security plan, a plan of action and milestones, a posted SPRS score, incident reporting readiness, and compliant cloud and subcontract arrangements. Each item rests on a specific rule: the system security plan on requirement 03.15.02 of SP 800-171 Rev. 3 (or 3.12.4 in Rev. 2), the plan of action on 03.12.02 and 32 CFR 170.21, the SPRS score on DFARS 252.204-7019, the 72-hour reporting window on DFARS 252.204-7012, and the cloud and flow-down duties on paragraphs (b)(2)(ii)(D) and (m) of the same clause. The organization owns these controls. An implementation partner, such as DeployOpen, can prepare systems, documentation and evidence, but only an independent assessor or certification body issues assessment results.

The revision you must meet depends on the contract and on current DoW guidance, so confirm it before you build anything. As of October 2026, DoW Class Deviation 2026-O0025, Revision 3 names SP 800-171 Revision 2 in the revised DFARS 252.204-7012, and a DoW CIO memorandum of 13 July 2026 requires baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A FAR proposed rule would move contractors to Rev. 3 with DoW-published ODP values, but it was not final at that date. Ask the contracting officer which revision and which ODP values apply, and record the answer in the system security plan.

Work backward from the evidence an assessor will ask for. Confirm the CUI boundary first, because the SSP, the SPRS score and the cloud checks all depend on which systems are in scope. Then write the SSP, make sure every requirement that is not fully implemented has an entry in the plan of action and milestones, and calculate the score using the DoD Assessment Methodology. Check that your cloud provider's CUI environment meets FedRAMP Moderate equivalency, that your incident response plan supports reporting within 72 hours, and that the flow-down language appears unaltered in subcontracts. A quote from a consultant should break out each of these items, state what is one-time and what recurs, and name who signs the assessment outcome.

Scope and the system security plan: what to define first

Before any assessment starts, the organization has to decide which systems fall under NIST SP 800-171 and document how they are protected. The cards below cover the scope decisions and the system security plan that every DoD assessment depends on, with the rule behind each item.

Identify CUI-bearing components

NIST limits Rev. 3 to components of nonfederal systems that process, store or transmit CUI, plus components that protect those components. Start by listing where CUI enters, is created, is stored and leaves the environment, including email, file shares, engineering tools and backups. Each system on that list is in scope until the organization documents a reason it is not.

Include protecting components in scope

Scope is not limited to the systems that hold CUI. Directory services, logging servers, firewalls, and administrator workstations can all protect CUI components, and an assessor will expect them inside the boundary. Document each protecting component and its role so the boundary reflects how the environment actually protects CUI.

Draw and maintain the boundary

A boundary diagram shows which components handle CUI, which protect them, and where the connections to systems outside the scope are controlled. Record the external service providers and any cloud services that store or transmit CUI. Confirm with the contracting team which contracts and programs the boundary covers, since a single system may serve several.

Write the system security plan

The SSP is the document a DoD Basic Assessment reviews, and requirement 03.15.02 in Rev. 3 (3.12.4 in Rev. 2) requires one. Describe each requirement, how it is implemented, and who is responsible. Under the DoD Assessment Methodology, an assessment cannot be completed without an SSP, and that absence is itself a finding of noncompliance with DFARS 252.204-7012.

Keep the SSP current

An SSP written once and never revised describes an environment that no longer exists. Update it when the boundary, a system, a provider, or a control changes, and record the date of each revision. Assessors compare the SSP against what they observe, so a stale plan creates findings even when the controls themselves work.

Confirm the assessment method

Ask the contracting officer or prime contractor which assessment applies to the contract and whether an SSP in a particular format is expected. Confirm the assessment date and the level the SSP must support before scoring begins. These answers set how much detail the SSP needs and how it links to the SPRS score.

Incident reporting readiness within 72 hours

This sequence lets a defense contractor move from a suspected cyber incident to a DoD report within the clause's 72-hour window, with the evidence, preserved media and contact records needed to support the report and any follow-up forensic work. It is only as good as the preparation done before an incident occurs.

Detect and triage the suspected incident
The security operations lead or designated incident responder receives an alert from monitoring, a user, a vendor or a subcontractor, then decides whether it may affect covered defense information (CDI). Triage records the time of discovery, the systems and accounts involved, and whether CDI could be present. The output is a dated incident ticket with a yes or no decision on possible CDI involvement. The 72-hour clock in the clause runs from discovery of a cyber incident, so the discovery time must be recorded accurately from the first moment.
Contain and preserve the affected systems
The responder isolates affected hosts and accounts as far as operations allow, while avoiding actions that overwrite logs, memory or disk state. Relevant logs, snapshots and affected images are collected under documented chain of custody. The output is a preservation record listing each affected asset, the collection method and the storage location. Confirm with counsel and your DoD contracting officer which preservation and retention steps the clause requires for malicious software and media, and keep them in the runbook.
Review for evidence of compromise of CDI
Under paragraph (c) of DFARS 252.204-7012, the contractor must review its systems for evidence that covered defense information was compromised. The review covers compromised computers, servers, data and user accounts, and it traces the access path and the data sets reachable from each affected asset. The output is a written compromise assessment that states which CDI, if any, may have been accessed, copied or altered, and which evidence supports that conclusion. Where the review is inconclusive, the record should say so and list what remains unknown.
Assess the cloud provider and subcontractor involvement
If an external cloud service provider stores, processes or transmits CDI, or if a subcontractor handled affected data, the responder requests that provider's incident data and confirms the provider's reporting and forensic support obligations under the clause. The team records which provider and subcontractor contacts were engaged and when. The output is a list of third-party incident records linked to the main incident ticket. Confirm the exact provider and subcontract flow-down terms against the clause text and the signed agreements.
Report to DoD at dibnet.dod.mil within 72 hours
The DFARS clause defines rapidly report as within 72 hours of discovery of a cyber incident, and paragraph (c) directs the contractor to report to DoD through the DIBNet portal at dibnet.dod.mil. A named officer, usually the security lead or a delegated executive, submits the report with the facts gathered so far and an incident identifier. The output is the DIBNet incident report number and the submitted timestamp, both filed with the incident ticket. Reports can be updated as the investigation proceeds, so the initial submission should not wait for a complete analysis.
Supply media and malware for DoD review on request
Once a report is filed, the contractor should be ready to provide preserved images, malicious software samples and access to affected media when DoD requests them, and to support any forensic analysis the clause requires. The team confirms the access, transfer and handling procedures in advance, including who may release data and how it is encrypted in transit. The output is a request log showing what DoD asked for, what was provided and when. Confirm the exact forensic support and media preservation duties against the clause text before relying on this step.
Close the incident and update the POA&M and SSP
After containment and reporting, the team documents root cause, corrective actions and lessons learned. Any new weakness found during the incident is added to the plan of action and milestones, and the system security plan is updated where the incident changed the system boundary or controls. The output is a closed incident record, an updated plan of action and milestones entry for each open weakness, and a revised SSP version number. This closes the loop between incident response and the assessment record that DoD relies on.

Cloud providers and subcontract flow-down checks

Defense contractors often rely on outside parties to host or support covered defense information. The DFARS clause reaches cloud providers and subcontractors, so each external party needs a documented check before CUI moves to it. The cards below cover the cloud requirement, the flow-down rule and the evidence to request.

Cloud service provider standard

If an external cloud service provider stores, processes or transmits covered defense information, DFARS 252.204-7012(b)(2)(ii)(D) requires security requirements equivalent to the FedRAMP Moderate baseline. Your organization owns this obligation even when the provider runs the platform. Confirm the provider's FedRAMP authorization status or equivalent evidence in writing before any CUI is placed in its environment.

Cloud incident reporting and forensics

The same paragraph requires the cloud provider to support the clause's incident reporting and forensic support requirements. Your 72-hour reporting window starts at discovery, so the provider's notification terms must allow you to meet it. Ask the provider how it will preserve logs, images and media, and who will give your team access to them during an investigation.

Provider evidence to request

Ask the provider for its current FedRAMP authorization package or equivalent documentation, the scope of the authorized services, and its incident response contact terms. Check whether the covered services are the ones you actually use, because a provider may be authorized for some products but not others. Keep the evidence in your assessment file with the date you received it.

Confirm equivalence with the contracting officer

Equivalence to FedRAMP Moderate is a judgment that your contracting officer may question, so confirm it with them rather than assuming it. Record the provider, the services in scope and the evidence you relied on. Raise the question early if the provider's authorization differs from the baseline you expected.

Flow-down to operationally critical subcontracts

Paragraph (m) requires the clause to flow down without alteration to subcontracts for operationally critical support or where performance involves covered defense information. Review each subcontract that touches your covered systems, including managed service and IT support agreements. Confirm the subcontract contains the clause text unchanged and set a process to re-check it when subcontracts renew.

Commercial subcontracts included

The flow-down requirement applies to commercial subcontracts as well as traditional defense subcontracts. Vendors that supply commercial software, hosting or support often sign standard terms that omit DoD clauses. Inventory these vendors, identify those with access to covered defense information, and negotiate the clause into their terms or document why it does not apply.

Which revision the checklist must follow in October 2026

Your checklist must follow the revision named in your contract, and as of October 2026 that is most likely Revision 2. NIST SP 800-171 Rev. 3 contains 97 security requirements, while Rev. 2 contains 110, and the two sets are not interchangeable line by line. The DoD Assessment Methodology and CMMC Level 2 both track Rev. 2, and 32 CFR 170.14(c)(3) makes the CMMC Level 2 requirements identical to 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. Build your scope, SSP and SPRS evidence against the 110 Rev. 2 requirements unless your solicitation says otherwise.

The picture is changing. A FAR overhaul proposed rule published 23 June 2026 would require contractors handling CUI to comply with Rev. 3 using organization-defined parameter values published by the DoW CIO. Comments closed 23 July 2026, and the rule was not final as of October 2026. Do not reorganize your checklist around Rev. 3 on the strength of a proposal, but do record which Rev. 3 requirements have no Rev. 2 counterpart, so a later transition does not start from zero. NIST's change analysis spreadsheet is the starting point for that mapping, and the NIST change analysis links from the Rev. 2 to Rev. 3 comparison page.

Before you finalize the checklist, ask your contracting officer three things in writing: which revision and DFARS clause version the current solicitation or contract incorporates, whether any ODP values have been assigned to the contract, and how the proposed FAR rule would apply if it is finalized during performance. Confirm the answers against the contract text itself, not only against a verbal reply. Record the answers in the SSP so the assessor who reviews your SPRS score can trace which revision each requirement was measured against.

Questions contractors ask before they sign off the checklist

Can a contractor be compliant with a POA&M still open?

Only in a limited sense. A plan of action and milestones (POA&M) documents how you will fix gaps, but it does not count as implementation. Under the DoD Assessment Methodology, a requirement that is not fully implemented scores as not implemented whether or not a plan exists, so an open POA&M does not raise the score for the item it covers. Requirement 03.12.02 asks for a POA&M that documents planned remediation and is updated from assessment findings. The rules on which items may stay open, and for how long, come from the DFARS and the CMMC scoring rules in 32 CFR 170.21 and 170.24. Confirm with your contracting officer how an open POA&M affects a specific award, because the solicitation sets the requirements for each offer.

Does a missing system security plan block an assessment?

Yes. A DoD Basic Assessment is a self-assessment based on reviewing the system security plan (SSP), and the DoD Assessment Methodology states that an assessment cannot be completed without one. Missing the SSP is also a finding of noncompliance with DFARS 252.204-7012. The SSP is the document that describes your system boundary, how each requirement is met and who is responsible. Requirement 03.15.02 in Rev. 3 covers it. Before you sign off, check that the SSP names every covered system in scope, reflects current configurations and is dated, since an outdated SSP can fail a review even when it exists.

Do subcontractors need to comply with NIST 800-171, or only the prime?

Subcontractors can be in scope too. DFARS 252.204-7012(m) requires the clause to flow down without alteration to subcontracts for operationally critical support or where performance involves covered defense information, including commercial subcontracts. Your flow-down obligations depend on what the subcontractor does with CUI. Map each subcontract against the clause, record which subcontractors receive covered defense information, and confirm their status in the subcontract terms. Where a subcontractor handles CUI, you should review their SSP and assessment results. The contracting officer can confirm which subcontracts the clause reaches on a specific contract.

Does a cloud provider need FedRAMP for CUI?

If the provider stores, processes or transmits covered defense information, the DFARS requires an external cloud service provider to meet security requirements equivalent to the FedRAMP Moderate baseline, along with the clause's incident reporting and forensic support requirements, under DFARS 252.204-7012(b)(2)(ii)(D). The phrase is equivalent, so the provider does not always need a formal FedRAMP authorization, but you must be able to show that equivalence. Ask the provider for its authorization or equivalence evidence, confirm its incident reporting commitments, and check that these terms appear in your contract with it. Confirm the expected evidence with your contracting officer.

How much effort does the checklist really take?

The effort depends on how much of the environment is already documented and how wide the CUI scope is. The main drivers are the number of covered systems, how many of the 97 Rev. 3 requirements (or 110 Rev. 2 requirements, which DoD contracts still reference) you already meet, the number of organization-defined parameters you must set, and how many subcontractors and cloud providers need review. Most of the work is documentation and evidence collection, not single purchases. Ask any implementer for a written scope that lists systems, requirements and deliverables before you agree on timing. Government effort estimates for implementing SP 800-171 exist in regulatory impact analyses, so check the figures your contracting officer cites rather than relying on general estimates.

Do we need outside help to sign off the checklist?

Not necessarily, but you should separate the roles. Your organization owns its controls and makes the attestation. An implementation partner can prepare systems, configurations, the SSP, the POA&M and evidence. Only an independent assessor, such as a DCMA DIBCAC assessor or a CMMC third-party assessor where that applies, issues assessment results. DeployOpen, for example, plans, implements, hardens and documents self-hosted open-source platforms in your own infrastructure, and prepares evidence for assessments, but it does not issue assessments or certifications. Ask any partner for a fixed-scope written proposal, confirm who performs each step, and verify with your contracting officer which assessments your contract requires.

Who owns each item on the checklist

The contracting organization owns its controls, its system security plan, its plan of action and milestones, its SPRS submission and every reporting decision. Those duties stay with the company even when it hires a partner to help. The contract is between the organization and the federal agency, and NIST places the application and implementation of SP 800-171, and any compliance issues, with that agency. The contractor is therefore the party that must be able to answer for each checklist item.

Controls and their operation: Each of the 97 Rev. 3 requirements, or the 110 Rev. 2 requirements that DoD contracts currently name, must be implemented and run by the company's own staff or contracted service providers.
System security plan: The organization writes, approves and keeps current the SSP, including the boundary and any external service providers.
Plan of action and milestones: The organization records open weaknesses, owners and dates, and updates them as findings change.
SPRS posting: The organization calculates and posts its summary score in SPRS and keeps it accurate.
Reporting and subcontract terms: The organization decides on cyber incident reporting to DoD within the clause's timelines and flows DFARS 252.204-7012 down to covered subcontractors.

Confirm that a named executive owns the score and the SSP, because the contractor carries the consequences of an inaccurate posting.

What usually breaks a NIST 800-171 checklist

Most failed NIST 800-171 assessments do not fail on missing technology. They fail on documents that drift from the real environment, on open items counted as finished work, and on evidence that sits with a provider or subcontractor the contractor never checked. The cards below cover the five breakpoints that come up most and the check that catches each one before an assessor or contracting officer does.

An SSP that does not match the real system

The system security plan is the document every DoD assessment starts from, and a missing SSP means no assessment can be completed. An SSP that describes an older architecture, a retired tool or a different boundary is nearly as damaging, because assessors test the system in front of them against what the plan says. Before any assessment, walk the boundary with the people who run it: confirm each asset that stores, processes or transmits CUI, each connection in and out, and each place the plan names a control. Requirement 03.15.02 is the anchor for this check.

POA&M items counted as completed controls

A plan of action and milestones documents planned remediation. It does not satisfy the requirement it covers. A requirement that is not fully implemented scores as not implemented whether or not a plan exists, so an open item listed on the POA&M still lowers the score. Teams that record a control as "in progress" and then describe it as met in an SPRS posting or an assessment create a finding that is hard to explain. Review every POA&M line against the actual state of the control, and mark an item closed only after evidence shows the requirement is implemented.

A stale SPRS score

The SPRS score is a summary of the assessment on record, and DFARS 252.204-7019 requires a current assessment, not more than 3 years old unless the solicitation sets less, before award. A score posted after a major change in tools, boundary or hosting describes a system that no longer exists. Set a trigger for review whenever the SSP changes, a system joins or leaves the boundary, or a POA&M item closes, and confirm that the posted score still matches the documented state before a new bid or option year.

Cloud and subcontractor evidence missing

The contractor answers for every system that stores or processes covered defense information, including external cloud providers and subcontractors. DFARS 252.204-7012 requires an external cloud service provider holding CUI to meet security requirements equivalent to the FedRAMP Moderate baseline, and it requires the clause to flow down without alteration to subcontracts whose performance involves covered defense information. Gather the provider's FedRAMP authorization or equivalent documentation, the responsibility matrix, and each subcontractor's signed flow-down before assessment, and record in the SSP which controls the provider covers.

Incident plans untested against the 72-hour window

DFARS 252.204-7012 requires a contractor to rapidly report a cyber incident within 72 hours of discovery, review for evidence of compromise of covered defense information, and report to DoD at dibnet.dod.mil. A written incident plan that no one has exercised often stalls on who declares an incident, who holds the DoD medium assurance certificate needed to report, and how forensic images are preserved. Run a tabletop exercise that starts the 72-hour clock from a simulated detection and records each hand-off, then fix any step that took longer than the team expected.

Confirm the rules and build the evidence before the assessment

Start by confirming which rules govern your contract, because the answer decides which requirement set you are measured against. NIST withdrew SP 800-171 Rev. 2 on 14 May 2024, yet the CMMC Level 2 rule in 32 CFR Part 170 keeps the 110 Rev. 2 requirements, and DoW Class Deviation 2026-O0025, Revision 3 has contracting officers name Revision 2 explicitly. Ask the contracting officer in writing which revision and which DFARS 252.204-7012 text apply, and check the status of the proposed FAR overhaul rule, which would move contractors to Rev. 3 with DoW-published ODP values. Record the answers and the dates you checked them, because the rules have changed several times in 2026. Next, define scope using NIST's own applicability language. Under NIST's purpose and applicability text, Rev. 3 reaches only the components of nonfederal systems that process, store or transmit CUI, or that protect those components. Draw the boundary around those components, list every system and service inside it, and document each exclusion with a reason. Then draft the system security plan, since a DoD Basic Assessment cannot be completed without one. Write it so an assessor can trace each requirement to a named control, owner and piece of evidence. Plans of action and milestones record the gaps you have not closed. Each entry needs a remediation owner and a target date, and it does not raise your score because a plan exists. Keep these items current as findings change. Before you post a score in SPRS, test incident reporting, because a 72-hour clock starts at discovery. Run a tabletop exercise that confirms who reviews logs for evidence of compromise, who reports to DoD at dibnet.dod.mil, and how malware and media are preserved. Confirm that your cloud provider meets the FedRAMP Moderate equivalent requirement and supports incident and forensic obligations, and that subcontracts carry the clause without alteration. Treat every item above as something to verify on the official sources linked in this topic, and do not rely on this summary alone when you sign a score or a contract.

How DeployOpen prepares NIST 800-171 systems and evidence

DeployOpen plans, implements and documents the technical and operational side of a NIST SP 800-171 program inside your own infrastructure. We prepare systems, controls and evidence for your assessment, while your organization owns its controls and an independent assessor or certification body issues any report or certificate.

How we scope

Scope is agreed in writing before work starts, covering which systems store, process or transmit CUI and which protect them.
The written scope names the systems, the SSP content we will draft, and the requirements we will prepare evidence for.
Engagements are fixed-scope, and ongoing support is available as a retainer once the initial work is complete.

How we build

We implement and harden the in-scope platforms inside your cloud accounts, data centers or air-gapped networks.
We configure access control, logging, encryption and boundary protections against the Rev. 3 requirements your scope selects.
We run security testing on in-scope systems and record findings for plan of action and milestones tracking.

How we hand over

You receive the system security plan, configuration baselines, network diagrams and a requirement-by-requirement evidence map.
Evidence is organized so an assessor can trace each requirement to logs, settings and records you can retain and reproduce.
Open plan of action items are documented with owners and milestones so your team can keep them current after handover.

How we support

Retainers cover patching, upgrades, backups and periodic re-testing of in-scope systems after handover.
We update the system security plan and evidence when systems change, so your SPRS score reflects current state.
Before an assessment, we can help your team confirm readiness, but the assessor, not DeployOpen, decides the outcome.