NIST 800-171 implementation plan: where to start

NIST 800-171 implementation plan: where to start when a contract requires it

When a DoD or federal contract requires NIST SP 800-171, start by finding where CUI lives, then set the boundary or enclave that keeps it in scope, write the system security plan (SSP), and fix the requirements that carry the most weight in the DoD Assessment Methodology before anything else. The 5-point requirements come first because the methodology subtracts 5 points for each of 42 requirements whose absence could lead to significant exploitation or exfiltration of CUI, and an SSP is the document an assessor reviews first. Without an SSP, a Basic Assessment cannot be completed and that gap is itself a finding of noncompliance with DFARS 252.204-7012. Work out first which requirements your environment truly needs, because the order of effort depends on the systems you run.

The revision the contract names also shapes the plan. DoD contracting currently points to Revision 2, which has 110 requirements, and the DoW Class Deviation 2026-O0025, Revision 3 names Revision 2 explicitly. Rev. 3 has 97 requirements, and a proposed FAR overhaul would move civilian and defense contracts toward it, but that rule was not final as of October 2026. Confirm with the contracting officer which revision applies, and use NIST's change analysis workbook to map Rev. 2 gaps to their Rev. 3 counterparts so that work carries forward if the requirement changes. Expect Rev. 3 to add organization-defined parameters that someone in your organization must set, since NIST does not assign those values.

Ownership is the point to settle early. Your organization owns its controls and the decisions behind them, including the boundary, the ODP values and the SSP's accuracy. An implementation partner such as DeployOpen can plan and build systems inside your environment, configure the controls, and prepare the evidence an assessor will examine, and it should state that scope in a written, fixed-scope agreement before work begins. Only an independent assessor or the government body that runs the assessment issues results, and the SPRS score your organization submits must match what that assessment shows. Ask any partner to confirm which of these steps it performs and which remain with your staff.

In what order should you implement NIST SP 800-171?

The sequence moves from knowing where CUI lives, to drawing a boundary around it, to documenting the system, so each later step rests on facts the earlier steps established. The output is a System Security Plan and a gap list you can act on.

Locate every place CUI is processed and stored
Start by identifying where CUI enters, is processed, is stored and leaves your organization. Requirement 03.04.11 (Information location) asks you to identify and document the system components that process and store CUI and to record changes to those locations. Involve contract owners, engineering, IT operations and anyone who emails or shares files with the customer, because CUI often sits in places nobody listed. The step is done when you have a data-flow inventory that names each system, repository, mailbox, endpoint and third-party service touching CUI, and an owner for each.
Set the boundary or enclave around CUI
Decide whether to scope the whole organization into NIST SP 800-171 or to isolate CUI in an enclave. An enclave depends on controls such as 03.13.01 (Boundary protection), which asks for managed interfaces and separate subnetworks, and 03.01.03 (Information flow enforcement), which governs how data moves between systems. Enclave design is often the largest cost driver, so compare it against the cost of applying the requirements across the whole estate. The step is done when a boundary diagram shows which assets are in scope, how traffic crosses the boundary, and which systems are deliberately excluded with a stated reason.
Write the system security plan
Document the system security plan (SSP) under requirement 03.15.02, which describes the system boundary, the operational environment, how each requirement is met and the responsible roles. NIST does not prescribe a format, but the plan must convey the information the requirement calls for, and NIST publishes a CUI SSP template you can adapt. The SSP is the document an assessor or contracting officer reads first, so write it from the boundary and inventory you already produced. The step is done when a named owner has approved a version that matches the actual configuration of the systems, and that version is under change control.
Fix the five-point requirements first
Under the DoD Assessment Methodology, a small set of requirements carries a 5-point deduction if it is absent, because gaps there can lead to significant exploitation or exfiltration of CUI. Examples include access control requirement 3.1.1 and media protection requirement 3.8.7 in the Rev. 2 numbering. Address these first so the most damaging gaps close before lower-weight items. Map each one to its Rev. 3 counterpart using NIST's change analysis workbook, since numbering changed. The step is done when each 5-point requirement has an implemented control, a configuration or procedure artifact, and an entry in the SSP.
Assign values for organization-defined parameters
Rev. 3 contains organization-defined parameters (ODPs) that NIST does not fill in. If your federal agency or contract does not specify a value, you must assign one for the requirement to be complete. Examples include session timeouts, review frequencies and retention periods. Ask the contracting agency whether it has set any values, and record your own choices with a rationale where it has not. The step is done when every ODP in your in-scope requirements has a documented value, approved by the accountable owner, and reflected in the system configuration. Confirm the current ODP expectations with the contracting agency, since federal rulemaking on this point is still in progress.
Gap-assess the remaining requirements
Assess every remaining requirement against its determination statements in SP 800-171A Rev. 3, using the examine, interview and test methods the assessment guide describes. Work family by family, recording for each requirement whether it is met, partially met or not met, and the evidence you would show an assessor. If your contract still references Revision 2, use the change analysis to carry Rev. 2 findings forward. The step is done when you have a gap register with an owner, a remediation approach and a target for each open item, and a record of the evidence that already exists. Any scoring or formal assessment is run by the agency or assessor, not by your implementation partner.

Why finding where CUI lives comes before every other control

Requirement 03.04.11 (Information location) asks you to identify and document where CUI is processed and stored, and which system components do that work, before you can credibly claim any other requirement applies. Every later decision depends on that map. You cannot scope access control, encryption, logging or media protection to systems you have not found, and an assessor will test the requirement by comparing your documentation against what is actually running. The same requirement also asks you to record changes to where CUI sits, so the map must be maintained, not produced once for an audit.

The map matters most for the enclave-supporting requirements. Boundary protection through managed interfaces and separate subnetworks (03.13.01), information flow enforcement (03.01.03) and documenting CUI processing and storage locations (03.04.11) work together. If CUI can reach a system outside the enclave through email, file sync, a backup job or a support tool, the boundary is only as narrow as the least-documented path. Start by listing every workflow that touches CUI, including contract intake, engineering tickets, shared drives and vendor portals, then decide which of those can be moved inside a dedicated enclave. A narrow enclave generally reduces the number of systems that must meet every requirement, which lowers both the work to implement and the work to keep evidence current. Treat this as a design choice you document, not a conclusion an assessor will accept on your behalf.

Confirm the boundary before you build around it. Ask your contracting officer which contract or agreement defines the CUI in scope and whether any agency-specific requirements change what counts as the enclave. Then walk the proposed boundary with your independent assessor, since assessment methods depend on how the boundary is drawn. DeployOpen can help prepare the network diagrams, data flow records and enclave configuration evidence, but the decision on scope and the assessment belong to you and to the assessor.

Which requirements carry the most weight in a DoD Basic Assessment?

A DoD Basic Assessment turns each NIST SP 800-171 requirement into points, so the requirements you implement first decide how much of your score you recover. The cards below cover the scoring tiers, the system security plan that must exist before any score can be recorded, and the checks to make before you rely on a figure.

The 5-point requirements

The DoD Assessment Methodology deducts 5 points for each of 42 listed requirements whose absence could lead to significant exploitation or exfiltration of CUI. Examples include 3.1.1 and 3.8.7. Start your implementation here because one gap in these areas can wipe out a large share of the score in a single step. Check each one against your own environment, not just against a policy document.

The 3-point requirements

Fourteen requirements carry 3 points because their absence has a confined effect. An example is 3.8.2. These gaps still reduce your score and can block an award, but they usually affect a narrower set of systems than the 5-point group. Schedule them after the high-weight controls, and document any compensating measure you rely on so the assessor can follow your reasoning.

The 1-point requirements

Every remaining requirement is worth 1 point. Each one still counts toward the total, and a stack of small gaps can lower the score as much as a single major one. Treat these as a tracked backlog with named owners and dates, and review them in the same cycle as your system security plan so that the score you report matches the system you operate.

The SSP comes first

A Basic Assessment is a self-assessment based on reviewing your system security plan. The methodology states that without an SSP, the assessment cannot be completed, and that missing SSP is itself a finding of noncompliance with DFARS 252.204-7012. Write the plan before you score, even if it describes gaps you have not yet fixed. Ask your team to confirm who owns each section and when it was last reviewed.

Confirm the methodology version

The scoring weights described here come from the DoD Assessment Methodology, Version 1.2.1, dated 24 June 2020. DoD guidance on how contracts reference NIST SP 800-171 has changed recently, so confirm with your contracting officer which methodology and which revision govern your contract before you submit a score. Record the version you used in your SSP so the basis for every point is traceable.

How to set ODP values and plan for the move from Rev. 2 to Rev. 3

Rev. 3 introduced organization-defined parameters, which are blanks inside a requirement that someone must fill with a specific value, such as a time period, a frequency or a list of events. NIST does not assign these values. If the federal agency you contract with does not specify them, your organization must assign them, and the requirement is not complete until you do. The OSCAL catalog defines 88 ODPs across 50 of the 97 requirements, so this is not a minor edit.

Start with the agency's position: Ask the contracting officer or program office in writing whether it has specified any values. Record the answer, because it determines which ODPs are yours to decide.
Pull the list from the catalog: Export the ODP list from the NIST OSCAL catalog so every parameter has an identifier you can track in the SSP.
Record each value with a rationale: Note the value, who approved it and the reason, such as an alignment with your existing log retention or patching cycle.
Check the assessment procedure: SP 800-171A includes checks that confirm each ODP is defined, so a blank value can fail an assessment even when the control is running.

Check that every ODP has a documented value, an owner and a date, and that the SSP and the assessment procedure refer to the same values.

How much effort does keeping the SSP current take?

The system security plan (SSP) is the document that describes how your system meets the requirements, and requirement 03.15.02 in SP 800-171 Rev. 3 asks you to develop, document and maintain it. NIST sets no prescribed format or level of detail for the plan, so the effort depends on how much of your environment you describe and how often you update it. NIST publishes a CUI SSP template on its CSRC page for Rev. 2 that you can adapt. Before you estimate upkeep, decide which systems fall inside the boundary, because every component you add to the plan adds something to maintain.

The most concrete public estimate comes from the FAR CUI proposed rule published in January 2025. The Government estimated that maintaining an SSP takes one information security analyst about one hour a month (12 hours a year) at $95 an hour, and that submitting the SSP to the Government on request takes about 30 minutes. Treat these as the Government's assumptions for a rule, not a measure of your organization's effort. A large environment with frequent changes, several enclaves or many external service providers will likely need more time, and a small system with few changes may need less.

Use the Government's figures as a starting point for questions to ask yourself and any partner you consider. Who owns the SSP, and who updates it after a change to the boundary, a new service or a remediated finding? How often do you review it against the requirements and the organization-defined parameter values you have assigned? Ask any implementation partner to state in writing which SSP maintenance tasks are in their scope, how many hours they expect for the first version and for each annual review, and what they will hand over so your team can keep the document current afterward. Confirm the current figures and any final rule language with the contracting agency, because the Government's estimate is tied to a proposed rule.

What must be in place before you can show the plan works

Before any gap closure can be shown to a contracting officer or assessor, the compliance lead needs a small set of artifacts that are current and agree with each other. The five checks below connect the CUI inventory, the boundary, the system security plan, the organization-defined parameter values and the per-requirement gap register.

Current CUI inventory

Confirm that you can list every repository, mailbox, endpoint, backup and external service where CUI is processed or stored, with an owner for each. Requirement 03.04.11 expects you to identify and document those locations and to record changes to them. To confirm the inventory, pick three CUI documents at random and trace each one to its storage location, its backup copy and every system that has touched it. Any location you cannot name is a gap.

Documented boundary diagram

Confirm that one diagram shows where CUI enters, moves through and leaves your environment, including every managed interface and separate subnetwork that separates the CUI enclave from the rest of the network. Requirement 03.13.01 and information flow enforcement under 03.01.03 both depend on this picture being accurate. Ask an engineer who did not draw the diagram to walk the traffic paths and mark anything the diagram does not show.

SSP that conveys 3.12.4

Confirm that the system security plan describes the system, its boundary, the requirements and how each one is implemented, and the plan of action for requirements not yet met. NIST does not prescribe a format for the plan, but it must convey what requirement 3.12.4 asks for. NIST publishes a CUI SSP template you can use as a starting point. Check that every statement in the plan matches what the system does today, because an assessor will test those statements against the environment.

ODP values with named owners

Confirm that every organization-defined parameter has a documented value and a named owner who approved it. NIST does not assign these values, and when the federal agency does not specify them, the nonfederal organization must set them to complete the requirement. Ask the contracting agency whether it has published values, then record your own choice for every parameter it has not. A value without an owner tends to drift, so review the list whenever a requirement changes.

Per-requirement gap register

Confirm that you have one register row for each requirement, showing its current status, the evidence that supports the status, the responsible owner and the target date. Use the NIST change analysis workbook if you are moving from Rev. 2, because it maps each older requirement to its Rev. 3 counterpart. Review the register on a fixed schedule and make sure every open row points to a plan of action. A register that marks everything as met without evidence will not survive assessment.

Who owns each step: your team, the partner and the assessor

This table compares who owns each step of a NIST SP 800-171 implementation: your organization, an implementation partner such as DeployOpen, and the independent assessor. Read each row as a step in the plan, and use the columns to see who decides, who builds and who certifies or reports. The main takeaway is that the partner can prepare systems and evidence, but the scoring decisions, the SSP and the organization-defined parameter values stay with your organization, and only an independent assessor or certification body issues a report or certificate.

Plan step	Your organization	Implementation partner	Independent assessor
Locate CUI and document its location (03.04.11)	Owns the CUI inventory, data flows and decisions on where CUI may be processed and stored	Helps map systems and collects discovery evidence for the location record	Examines the documented location and tests it against actual systems
Set the boundary or enclave (03.13.01, 03.01.03)	Decides scope, which systems handle CUI and which are excluded	Designs and configures segmentation, managed interfaces and information flow controls	Tests whether boundary protection and flow enforcement operate as described
Write the system security plan (03.15.02)	Owns the SSP, approves it and keeps it current	Drafts technical sections and supplies configuration and architecture evidence	Reviews the SSP against requirements and interviews staff on how it is followed
Fix the 5-point requirements first	Sets priorities, risk acceptance and remediation dates	Implements technical fixes such as access, logging and encryption settings	Checks that each fix is in place and that evidence is retained
Assign organization-defined parameter values	Assigns ODP values unless the federal agency specifies them, and records the rationale	Recommends values based on configured systems and tooling limits	Confirms each ODP value is defined, since the assessment checks this
Plan the Rev. 3 change analysis	Decides the target revision and owns the gap decisions	Runs the requirement-by-requirement gap work using NIST's change analysis workbook	Assesses against the revision the contract names, which the organization must confirm
Produce scores and reports	Owns the score submitted to SPRS and the accuracy of the attestation	Prepares calculations and evidence packs for review	Issues any independent report or certificate, which the partner cannot issue

Common questions about starting NIST SP 800-171 implementation

How long does a NIST SP 800-171 implementation plan take to complete?

The length depends on scope, not on a fixed template. The biggest drivers are how many systems and locations handle CUI, whether CUI can be confined to an enclave, how much of the environment is already documented, and how many of the 97 Rev. 3 requirements need new technical work versus written policy. Organizations with a clear CUI data map and a defined boundary usually move faster because the system security plan and the technical fixes can run in parallel. No duration is set by the standard itself, so ask any provider for a written scope and milestone plan before accepting a timeline. The DeployOpen approach is fixed-scope: scope, deliverables and timelines are agreed in writing before work starts.

Can our own team implement NIST SP 800-171 without an outside partner?

Yes, an organization can implement the requirements with its own staff, and nothing in NIST SP 800-171 requires an outside firm. The organization owns its controls and remains responsible for them. Outside help is typically used to prepare systems, configure logging, encryption and access controls, document the boundary and build the evidence, so internal staff can keep running operations. Independent assessment is a separate step: a DoD Basic Assessment is a self-assessment, while higher-level assessments are carried out by DCMA DIBCAC, and only independent auditors or certification bodies issue reports or certificates. Ask whether a partner prepares evidence or issues any formal attestation, because a partner does neither of the second.

What does the work need from our staff and business owners?

The work draws on several roles at once. Contract and program owners confirm which contracts and agreements bring CUI into scope. IT and platform engineers configure identity, logging, encryption, backups and network boundaries. Security staff write and maintain the policies, procedures and the system security plan. HR and facilities cover screening, access removal and physical protection. Leadership approves the boundary and the risk decisions. Expect that engineers will be needed for technical change windows and that business owners must confirm where CUI actually travels, because requirement 03.04.11 requires the organization to identify and document CUI locations. Confirm named owners for each family before the work starts.

Should we start from NIST SP 800-171 Rev. 2 or Rev. 3?

Start from the version your contract names, then plan for the other. NIST withdrew Rev. 2 on 14 May 2024, but the DoD's CMMC Level 2 requirements are identical to Rev. 2, and a DoW class deviation dated 3 September 2026 has contracting officers name Rev. 2 explicitly while a July 2026 DoW CIO memorandum requires baseline compliance with Rev. 2. A FAR proposed rule would move civilian contracts to Rev. 3 with ODP values published by the DoW CIO, but it was not final as of October 2026. NIST's change analysis workbook maps each Rev. 2 requirement to its Rev. 3 counterpart, so a Rev. 2 gap assessment can be reused for Rev. 3. Confirm the version in your contract, and ask any provider how it will track the change.

How much effort does keeping the system security plan up to date take?

The only Government estimate supplied for this is from the January 2025 FAR CUI proposed rule, which estimated that maintaining an SSP takes one information security analyst about one hour a month, or 12 hours a year, at $95 an hour. The same estimate put submitting an SSP to the Government on request at about 30 minutes. Those figures reflect the proposed rule's assumptions, not your environment. Real upkeep grows with the number of systems in the boundary, the rate of change, and how often the plan is reviewed after configuration or personnel changes. Ask how the provider will keep the SSP current after handover.

Which parts of the plan should we set first?

Work in a fixed order: find where CUI lives, set the boundary or enclave, write the SSP, then fix the requirements that carry the most weight. Under the DoD Assessment Methodology, 42 requirements subtract 5 points each if their absence could lead to significant exploitation or exfiltration of CUI, so those are the first technical targets. Organization-defined parameters must also be set, because NIST does not assign their values and the organization must assign them where a federal agency has not. Documenting the plan in writing before buying tools prevents rework.

What should we ask a provider for in a written scope?

Ask for a list of systems in the boundary, the requirements covered, the deliverables for each phase, and who performs each task. Confirm which artifacts you will own at the end, including the SSP, configuration baselines, logging and encryption settings, and runbooks. Ask what is excluded, such as ODP value decisions, remediation of the physical environment, or upkeep after handover, and what the provider needs from your staff in weeks. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and prepares evidence for assessment, but it does not issue assessment results, which only an independent assessor can do.

How DeployOpen scopes and prepares the implementation

DeployOpen works under a fixed-scope written agreement. Before any work starts, the scope, deliverables and timeline are agreed in writing, and a quote follows from that scope. For a NIST SP 800-171 engagement, the scope usually starts with the decisions covered above: where CUI is processed and stored, which systems fall inside the boundary or enclave, and which requirement owners in the organization will sign off on each part. Ask any provider to write those boundaries into the agreement, because a vague scope is the most common reason implementation work runs over.

Within that scope, DeployOpen prepares systems in the organization's own environment, whether that is its cloud accounts, data centers or an isolated network. The work typically covers configuration of the enclave and its boundary controls, logging and access settings, and the documentation needed for the system security plan, drafted against the organization's actual systems rather than a generic template. Evidence is gathered as the controls are built, so the organization can show how each requirement is met. At handover, the organization receives the configuration records, procedures, SSP and evidence set, and should confirm it can maintain them without DeployOpen. The organization still owns its controls, decides its ODP values and makes the final risk decisions.

DeployOpen does not issue assessments, attestations or certifications. A DoD Basic Assessment, a DCMA DIBCAC assessment or any independent review is performed and reported by the body that the contract or agency names, and only that body can state a result. Hiring DeployOpen does not guarantee a score, a pass or a contract award. Before you engage any provider, confirm which assessment your contract requires, who will perform it, and what the implementation partner is responsible for delivering, so that the assessor's findings can be traced back to documented work.

NIST 800-171 implementation plan: where to start