How to complete a NIST 800-171 Basic Assessment when a contract requires it
When a DoD contract includes DFARS 252.204-7019 and 252.204-7020, an offeror must have a current summary score for each relevant covered system posted in SPRS before it can be considered for award. A Basic Assessment is a self-assessment that starts from a current system security plan (SSP) and scores the 110 Rev. 2 requirements using the DoD Assessment Methodology, Version 1.2.1. The organization owns the score and the posting. An implementation partner can help prepare the SSP, map evidence to each requirement and run the scoring worksheet, but a partner cannot sign the score as an independent assessor. The result depends on each system's boundary and implementation status, so the first decision is which systems hold or process CUI and must be scored separately.
Work from the SSP outward. The methodology treats a missing SSP as a reason no assessment can be completed, which is also a finding of noncompliance with DFARS 252.204-7012. For each requirement, the methodology starts at 110 and subtracts a weighted value when the requirement is not implemented, so a score can fall below zero. Requirements not fully implemented score as not implemented, and a plan of action does not change that result. Confirm the weights and the two partial-credit cases (multi-factor authentication limited to remote and privileged users, and encryption that is not FIPS-validated) directly in the methodology document before you finalize the worksheet. Also confirm which remote access, wireless and mobile requirements do not apply because the company does not permit those capabilities, since the methodology does not deduct points for those.
Before posting, check that each SSP's CAGE codes, the assessing organization, the assessment date, the summary score and the expected date for a score of 110 are correct, and that the SP 800-171 version assessed is stated. Ask any consultant to show the evidence behind each score, not only the total. A score that cannot be traced to a system, a requirement and a piece of evidence will not hold up under later review. Your posting obligations continue after the first submission, so set a calendar reminder for the currency window in the contract and review scores when the environment changes.
What are the steps to finish a Basic Assessment?
The sequence turns an existing system security plan into a scored, dated and posted Basic Assessment, with each step producing a record that a later reviewer can trace back to the evidence behind it.
Confirm the system security plan covers each system
Before any scoring, the organization confirms that a current system security plan exists for every system that stores, processes or transmits CUI, and that each plan names the system boundary, its CAGE codes and the services it depends on. The methodology is explicit that a missing SSP means no assessment can be completed, and that absence is itself a finding of noncompliance with DFARS 252.204-7012. Done means each covered system has a dated SSP that the assessor can read before scoring begins.
List the 110 Rev. 2 requirements against the system
Basic Assessments score against the 110 requirements of SP 800-171 Rev. 2, because the CMMC Level 2 rule makes those requirements identical for DoD contractors even though NIST withdrew Rev. 2 in May 2024. The assessor builds a worksheet with one row per requirement, mapping each to the SSP section, the responsible owner and the system where it applies. Done means every requirement has a row and no requirement is left without a named place where its implementation is described.
Judge each requirement as fully implemented or not
For each row, the assessor decides whether the requirement is fully implemented on the covered system, using the SSP and direct evidence such as configuration exports, account listings or logs. A requirement that is only partly done scores as not implemented, and a plan of action does not change that result. Requirements the company does not permit, such as remote access, wireless or mobile device use (3.1.12, 3.1.16, 3.1.18), are recorded as not applicable with the policy that prohibits them. Done means every row carries a yes, no or not-applicable decision and a pointer to its evidence.
Apply the methodology point values
The assessor starts at 110 and subtracts the weighted value for each requirement not implemented: 5 points for the 42 requirements whose absence could lead to significant exploitation or exfiltration of CUI, 3 points for the 14 with a confined effect, and 1 point for the rest. Two requirements earn partial credit (3 points instead of 5): multi-factor authentication (3.5.3) that covers only remote and privileged users, and encryption (3.13.11) that is used but not FIPS-validated. Because the score starts at 110 and subtracts, it can go negative, so the worksheet should show each deduction. Done means every deduction is traceable to a row.
Compute the summary score and the 110 target date
The assessor totals the deductions into a summary score, such as 95 out of 110, and records the date by which the organization expects to reach a score of 110, which the posting requires. The score is only as good as the decisions behind it, so a second reviewer should spot-check the rows that carry the largest deductions. Done means the score, the expected date and the reviewer's sign-off are recorded in the assessment file.
Record the assessment date and assessing organization
The assessment record states the assessment date, the SP 800-171 version assessed (Rev. 2 for a Basic Assessment against the DoD methodology), and the organization that performed the assessment. The organization's leadership should confirm the scope and the result before posting, because the people who sign the posting are accountable for its accuracy. Done means the record names the assessor, the date and the scope in terms that match the SSP.
Prepare the SPRS posting for each system
The posting in the Supplier Performance Risk System carries the version assessed, the assessing organization, each SSP with its CAGE codes, the assessment date, the summary score and the expected date for a score of 110. Each relevant covered system needs its own summary score posted, and offerors must have a current assessment to be considered for award under DFARS 252.204-7019 and 7020. Done means every covered system has a posting that matches its assessment file, and the team has confirmed with the contracting office which currency window applies to the solicitation.
How the DoD Assessment Methodology turns 110 requirements into a score
The DoD Assessment Methodology starts every score at 110, the number of Rev. 2 requirements, and subtracts a weighted value for each requirement you have not fully implemented. The weights come in three tiers. Forty-two listed requirements carry 5 points each, because their absence could lead to significant exploitation or exfiltration of CUI. Fourteen requirements with a confined effect carry 3 points each, and every remaining requirement carries 1 point. Access control requirement 3.1.1 is in the 5-point group and media protection requirement 3.8.2 is in the 3-point group. Because the deductions are weighted, a single missing 5-point requirement can cost more than several missing 1-point requirements combined. Before you score anything, pull the methodology itself and confirm the lists against Version 1.2.1 dated 24 June 2020, since that is the version the scoring rules come from.
Because the subtractions have no floor, a score can go negative. An environment with many gaps in the high-weight requirements can drop below zero, and that result is valid output, not a formula error. Two requirements allow partial credit. If multi-factor authentication under 3.5.3 covers only remote and privileged users, the deduction for that requirement drops from 5 points to 3. The same reduction applies to encryption under 3.13.11 when encryption is used but the modules are not FIPS-validated. Check the actual configuration before you claim either credit. Confirm which accounts the MFA policy covers in your identity provider, and confirm the validation status of each cryptographic module in the system boundary from the vendor's documentation, not from the product marketing page.
A plan of action does not count as implementation. A requirement that is not fully implemented scores as not implemented, whether or not a plan exists for it. The methodology also makes 3.12.2 a special case: if you have no plan of action, that requirement scores as not implemented on its own. Treat your plan of action and milestones as a record of intent, not as credit. Before you finalize the score, walk through each requirement that the plan covers and ask whether the control operates today, with evidence an assessor could examine. Requirements that are open in the plan are deducted in full at their weight, so a plan that lists a 5-point gap as scheduled still costs you 5 points on the day you post.
Which scoring decisions change the number most?
A Basic Assessment score is a sum of deductions, so a handful of judgment calls move the total more than most individual controls do. Each decision below changes points in the DoD Assessment Methodology, and each needs a written basis in the system security plan so an assessor can trace the number back to the system.
MFA covering only some users
Multi-factor authentication under 3.5.3 earns partial credit when it covers only remote and privileged users. The deduction drops from 5 points to 3, but only if that scope is true for the whole system. Check whether MFA applies to on-site standard users, service accounts and every path into the CUI enclave, and record the exact population in the SSP. If the scope is wider, score full credit; if it is narrower, score the requirement as not implemented.
Encryption that is not FIPS-validated
Under 3.13.11, encryption that is used but not FIPS-validated also earns partial credit, at 3 points instead of 5. Many teams assume that any strong cipher qualifies, but the test is validation status of the cryptographic module, not algorithm strength. Confirm the validated module certificate for each product that protects CUI in transit or at rest, and state the module and its use in the SSP. Unvalidated encryption on any CUI path reduces the credit for the whole requirement.
Plans of action score as not implemented
A plan of action does not count as implementation. A requirement that is not fully implemented scores as not implemented, whether or not a plan exists, so a planned fix earns no credit until the control works. A missing plan of action also makes 3.12.2 not implemented. For each open item, record the date the control was verified as working, not the date it was scheduled, and keep the plan of action as supporting detail rather than as a score input.
Capabilities the company does not permit
The methodology does not deduct points for remote access (3.1.12), wireless access (3.1.16) or mobile devices (3.1.18) when the company does not permit those capabilities. This is a real scoring benefit, but it depends on a prohibition that is enforced. Document the policy, the technical blocks such as disabled wireless adapters or denied remote paths, and any exceptions. A prohibition that exists only on paper, or that is quietly violated by staff, will not hold up on review.
DoD CIO adjudicated equivalencies
Requirements the DoD CIO has adjudicated as not applicable or as equally effective through an alternative measure are scored as implemented. Only the adjudications the DoD CIO has issued count, not a contractor's own reasoning that an alternative is comparable. Before relying on one, confirm that the adjudication covers your exact requirement and system configuration, and cite the adjudication in the SSP alongside the alternative safeguard you operate.
What goes into the SPRS posting for each system
The table lists each field the DoD expects in a Basic Assessment posting, what it must show, and where organizations most often make errors. Read it as a checklist to complete for every covered system before you submit, and confirm the current submission steps with your contracting office.
| Posting field | What it must show | Common error to check |
|---|---|---|
| SP 800-171 version assessed | The version used for the assessment, which for DoD Basic Assessments is Rev. 2 with its 110 requirements | Recording Rev. 3 without confirming the version the contract and current DoD guidance require |
| Assessing organization | The organization that performed the self-assessment, identified by name | Leaving the field blank or naming a consultant as if it issued a certification |
| Each SSP and its CAGE codes | One entry per system security plan, linked to the CAGE codes of the facilities covered by that system | Posting one score for several systems, or omitting a CAGE code for a site that handles CUI |
| Assessment date | The date the self-assessment was completed, which starts the three-year currency period | Using the date of a later review or the date the score was entered into the portal |
| Summary score | The total from the DoD Assessment Methodology, for example 95 out of 110, which can be negative | Reporting an optimistic score that counts plans of action as implemented |
| Expected date for a score of 110 | The date the organization expects to implement all remaining requirements and reach 110 | Setting a date that has passed or no owner for the remaining work |
| Currency rule (DFARS 252.204-7019) | An offeror that must implement SP 800-171 needs a current assessment, generally not more than three years old unless the solicitation sets less | Letting the assessment lapse while the posted score still appears valid |
| Submission steps | The current portal steps, account requirements and any contract-specific instructions | Relying on an outdated procedure. Confirm current submission steps with the contracting office |
Who owns the score, the SSP and the posting?
Executive leadership owns the decision to post a score, because the score is a statement the organization makes to the contracting Government. Leaders do not need to score requirements themselves, but they must fund the work, accept the residual risk of any requirement not fully implemented, and make sure someone with authority reviews the score before it goes into SPRS. Leadership also decides whether the organization pursues an enclave, a narrower CUI boundary or a remediation schedule, and those choices change the score more than any scoring exercise does.
- Accepting the posted score: Confirm in writing who approves the summary score and the expected date for a score of 110 before posting.
- Funding remediation: Approve the budget and schedule for closing requirements that score as not implemented.
- Setting the boundary: Decide which systems handle CUI and which are excluded, since the SSP and score cover only the scoped environment.
- Owning contract risk: Understand that the contracting Government relies on the score when it awards work.
- Naming an accountable executive: Assign one officer who answers for the accuracy of the posting.
Check that the approval record names the executive, the date and the SSP version the approval covers.
The compliance lead owns the system security plan, the evidence library and the scoring worksheet. This role decides whether each requirement is fully implemented, partially implemented or not implemented, and records the reason for each decision. The lead also keeps the score current when systems change, which is the part of the work most often neglected after the first posting. Where the organization has no internal security staff, this role can be filled by an outside person, but the organization still signs the scoring decisions.
- Maintaining the SSP: Keep the system security plan current with the system boundary, CAGE codes and the controls actually in place.
- Scoring each requirement: Apply the DoD Assessment Methodology so that each of the 110 requirements has a documented decision and evidence.
- Tracking plans of action: Record open items with dates, owners and milestones, knowing that a plan of action does not count as implementation.
- Triggering updates: Revisit the score when a system, vendor or CUI flow changes.
- Preparing the posting: Assemble the fields for SPRS, including the assessment date and the assessing organization.
Check that every score has evidence behind it, and that no requirement is marked implemented on the strength of a planned control.
An implementation partner can prepare the systems, documents and evidence that support the score. For a Basic Assessment this usually means drafting or reviewing the SSP, configuring controls in the client's own environment, gathering evidence, and helping the compliance lead work through the scoring. A partner works inside the organization's accounts, data centers or networks, and the organization keeps ownership of the controls once the engagement ends. The partner does not sign the assessment, does not post to SPRS, and does not decide the score for the organization unless the written contract explicitly gives it that role.
- Outsourceable work: SSP drafting, control configuration, evidence collection, gap remediation and documentation support.
- Retained by the organization: Final scoring decisions, the SSP approval, the SPRS account and the posting itself.
- Written scope: Name the systems, requirements and deliverables in a fixed-scope agreement before work begins.
- Evidence handover: Deliver the SSP, evidence and configuration records to the organization in a form it can maintain alone.
- No independent assessment: A partner that helped build a control should not be treated as the independent assessor of that control.
Check that the contract states who posts, who signs and who maintains the SSP after the engagement closes.
The Defense Contract Management Agency's Defense Contract Management Agency Defense Industrial Base Cybersecurity Assessment Center (DCMA DIBCAC) performs Government assessments of NIST SP 800-171 implementation. A Basic Assessment is a self-assessment, so the organization completes it without DCMA's involvement. Later Government assessments, at the Medium or High level, are independent of the organization and of any partner that helped prepare it. The assessor tests the claimed score against the SSP and evidence, and its results can override the organization's own posted score. Preparing for those assessments is the organization's responsibility, even when a partner helped build the environment.
- Independent role: The assessor reviews the work and does not prepare the SSP or the score.
- Evidence requests: Expect requests for the SSP, configurations, logs and demonstrations of controls.
- Access: The organization provides access to the scoped environment and the people who run it.
- Results: Government results can change the posted score, so the organization must update SPRS when they do.
- Preparation: Maintain evidence continuously so that the assessed state matches the posted state.
Check the assessment notice for the level, scope and timing, and confirm which people and systems you must make available.
What delays a Basic Assessment or inflates its score gap?
Most Basic Assessments stall or post a lower score for reasons that have little to do with security. The causes below come from the methodology's scoring rules and from the posting requirements, so each one can be checked before the score is calculated.
SSP written after scoring
The DoD Assessment Methodology says a Basic Assessment cannot be completed without a system security plan, and a missing SSP is also a finding of noncompliance with DFARS 252.204-7012. Teams that score requirements first often find the SSP describes a different system than the one they assessed. Write the SSP first, then score each requirement against the controls it actually describes, and confirm the SSP is dated and approved before you start scoring.
Plans of action scored as implemented
A plan of action does not count as implementation. Requirements not fully implemented score as not implemented whether or not a plan exists, and a missing plan of action makes 3.12.2 not implemented. Scoring a planned fix as complete is the most direct way to overstate the score. Mark each requirement as implemented only when the control operates today, and record open items with dates in the plan of action.
Unclear system boundaries and CAGE codes
Each SSP posted in SPRS must carry its own CAGE codes, and the posting must cover each relevant covered system. When the boundary is vague, a team may post one score for a system that includes a second environment, or leave out a contractor-operated enclave entirely. Draw the boundary with an asset inventory, list every system that stores, processes or transmits CUI, and map each system to the CAGE codes that use it before the first score is posted.
Stale evidence behind current answers
A score reflects the state of controls on the assessment date, so evidence collected months earlier may no longer prove a control works. Access reviews, patch records, backup restore tests and audit log samples go stale as staff and systems change. Before scoring, date every artifact, confirm it still matches the running configuration, and replace anything older than the current review cycle. An assessor will ask for the same proof, so keep the evidence index current.
Enclaves that are not described
A CUI enclave that exists only in a diagram, or one that a managed service provider runs without a written description, is hard to score correctly. Requirements such as remote access, wireless and mobile device controls, and external systems depend on how the enclave connects to the rest of the business. Describe every connection, access path and external service provider in the SSP. Where a capability is not permitted, document the prohibition, since the methodology does not deduct points for remote access, wireless or mobile requirements that the company does not allow.
Common questions about completing a Basic Assessment
How long does a NIST 800-171 Basic Assessment take to complete?
No fixed duration is published for a Basic Assessment, and the effort depends mostly on the state of the system security plan (SSP) when you start. An organization with a current SSP, a documented boundary and evidence already gathered for each requirement will spend its time scoring and checking claims. An organization without an SSP cannot finish the assessment at all, because the DoD Assessment Methodology treats a missing SSP as a reason no assessment can be completed. The main drivers are the number of systems in scope, how many of the 110 requirements are not yet fully implemented, how many environments an assessor must sample, and how much of the evidence lives in people's heads rather than in records. Ask any party quoting the work to break its estimate down by system, by requirement family and by evidence collection.
Can an organization complete a Basic Assessment without outside help?
Yes. A Basic Assessment is a self-assessment, so the organization owns the work, the score and the posting. Many organizations do the scoring with internal staff who know the systems, provided they read the DoD Assessment Methodology closely enough to apply its rules correctly, such as the partial credit for multi-factor authentication and encryption and the rule that a plan of action does not count as implementation. Outside help is usually used to prepare the SSP, collect evidence, check that requirements marked as implemented are actually in place, and test the scoring before anyone signs. An implementation partner can prepare systems and evidence, but it does not issue the assessment result. Only the organization decides what it posts, and a qualified independent assessor is needed where a contract or the assessment type requires one.
Does Rev. 2 or Rev. 3 apply to a Basic Assessment today?
For a DoD Basic Assessment, the version that matters today is Rev. 2, with its 110 requirements in 14 families. NIST withdrew Rev. 2 on 14 May 2024, but 32 CFR 170.14(c)(3) makes the CMMC Level 2 requirements identical to Rev. 2, and 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. That deviation cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A FAR overhaul proposed rule published 23 June 2026 would move contractors to Rev. 3 with ODP values published by the DoW CIO, but it was not final as of October 2026. Check the contract's clause and any deviation that applies to it, and record the version you assessed in the posting.
Who signs the SPRS posting for a Basic Assessment?
The organization posts its own score, and the posting must name the organization that performed the assessment. For a Basic Assessment, that is usually the organization itself. The posting includes the SP 800-171 version assessed, the assessing organization, each SSP with its CAGE codes, the assessment date, the summary score (for example 95 out of 110) and the date a score of 110 is expected. An executive or authorized official should review the score before it goes into SPRS, because the figure is a statement to the government that the contracting team relies on when making awards. Consultants can calculate or review the score, but they should not be treated as the party attesting to it. Keep the scoring worksheet, the SSP version and the evidence behind each credited requirement so the posting can be defended.
What happens if our SPRS score drops after we post it?
The posted score must reflect the environment as it is, so a drop in implementation means the posting is no longer accurate and should be updated. Common causes include a new system brought into scope without an SSP, a control removed during a migration, a multi-factor authentication rollout that covers only some users, or a plan of action that never turned into implemented controls. Update the score when you learn of the change rather than waiting for the three-year currency date, and record what changed and why. Inaccurate or unsupported scores are the kind of gap that has led to False Claims Act settlements, so treat a score correction as a compliance task with its own evidence, not as a formality. Ask counsel how a correction interacts with any open contract obligations before you change the figure.
Which requirements cost nothing to score if we do not allow them?
The DoD Assessment Methodology does not deduct points for remote access, wireless or mobile device requirements (3.1.12, 3.1.16 and 3.1.18) when the company does not permit those capabilities. This is the most useful scoring rule for a small environment, but it only applies if the prohibition is real and enforced. Document the policy, configure systems to block the capability, and keep evidence that the restriction holds, such as network settings and device inventory. An assessor will test whether the capability truly cannot be used, and a stated prohibition that is routinely bypassed will not count. Confirm with your contracting officer or assessor how the rule applies to your specific systems before you rely on it.
What engineering evidence should we gather before scoring?
Start with the SSP, since the methodology treats its absence as blocking the whole assessment. Then gather configuration exports for access control, multi-factor authentication settings, encryption settings and logging, plus recent scan results, patch records and the incident response plan. For each requirement you intend to score as implemented, confirm that the control works as described and that a record shows it. For encryption, check whether the modules in use are FIPS-validated, because encryption that is not FIPS-validated reduces the credit for requirement 3.13.11. Where a plan of action exists, record it, but do not score the requirement as implemented unless the control is fully in place. Keep the evidence in a form that another person can reproduce.
How DeployOpen prepares SSPs, evidence and scoring support
DeployOpen works on the Basic Assessment as a preparation partner: we help build the system security plan, the evidence behind each requirement and the scoring worksheet, while your organization owns its controls and its score. Only an independent party can issue an assessment report, so the posted SPRS score always remains your organization's own statement.
How we scope
- The written scope names each system and enclave that handles CUI, with its SSP and CAGE codes.
- Scope covers which of the 110 requirements are in place, partly implemented or not permitted, as agreed before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We draft or update the SSP so each requirement names the implementing control, owner and system boundary.
- We configure or document the technical controls needed for requirements such as MFA scope and FIPS-validated encryption.
- We reconcile each requirement with real system evidence so no point is claimed for a control that does not operate.
How we hand over
- You receive the SSP, the requirement-by-requirement evidence index and the scoring worksheet in editable form.
- Plans of action cover every requirement not fully implemented, with owners and milestones, and do not count as implementation.
- Your team receives a walkthrough so staff can explain and maintain the evidence before anyone outside reviews it.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so scores stay accurate as systems change.
- Retainer work can refresh evidence and the SSP before the three-year currency date or after a significant system change.
- Ask us to confirm which assessment version and posting fields your contract requires before we start scoring.
