When to update your NIST 800-171 SPRS score

Update your NIST SP 800-171 score whenever the values posted in SPRS stop matching the systems, assessment results or affirmations behind them. If your contract requires NIST SP 800-171 and a score is already posted, treat that posting as a claim you must be able to defend at any time, not a one-time filing. The organization owns the score. An assessor or DoD produces the results, but your team is responsible for keeping the posted entries accurate for each covered system and each System Security Plan (SSP) with its CAGE codes.

The trigger depends on three things: your environment, the clauses in your contracts, and your assessment history. A change to the network boundary, the enclave, the hosting provider or the set of systems that handle CUI can make a posted score describe something that no longer exists. A new contract clause, a new assessment or a changed status can also change what must be posted. Start by listing every covered system and the score posted for it, then compare each entry against the current SSP, the most recent assessment record and any affirmation you have entered. Any mismatch is a reason to correct the entry before a contracting officer or DoD finds it.

Ask two questions in writing before you rely on a posting. Which SP 800-171 version and assessment method does each entry reflect, and which clause in your current contracts governs how old that score may be? Confirm both with your contracting officer and your assessor, because the answers depend on the solicitation and on the DFARS and 32 CFR Part 170 requirements in force on the date you work. Record the answers and the person who gave them, so the next update starts from documented facts rather than memory.

What a SPRS posting contains and which fields go stale

A SPRS entry is a set of linked fields, and each one has its own trigger for going out of date. Knowing which field changes with which event tells you when to update the posting and when a score that looks current has stopped being accurate.

Assessed version and scope

The posting records which SP 800-171 version was assessed, which determines the requirement count and numbering the score is measured against. Because the version field is tied to the assessment methodology, a change in the version the contract requires means the existing score may no longer describe the work you are being asked to protect. Confirm the field definitions against DFARS 252.204-7019 and 252.204-7020 before you rely on them.

Assessing organization and date

The posting names the organization that performed the assessment and the assessment date. The date sets the currency clock, so a score posted years ago can fall outside the window a solicitation allows even if nothing in your environment has changed. Record who assessed, when, and whether the assessor was your own team, a consultant or the Government, because each carries different weight in a review.

System security plan and CAGE codes

Each system security plan on the posting is tied to the CAGE codes of the entities it covers. When a new system enters CUI scope, a new SSP and its score must be posted for that system. When a facility or legal entity changes, check that the CAGE codes still match the organizations that actually handle CUI, because a mismatch leaves a covered system without a posted score.

Summary score

The summary score is the requirement-weighted result for each system, shown as a figure such as 95 out of 110. It changes when you remediate a failed requirement, when a POA&M item closes, or when a control is found not to work as described. Any change in the controls that alter the score makes the posted number stale, even if the assessment date looks recent.

Expected completion date for 110

The posting includes the date you expect to reach a score of 110. This is a commitment, not a measurement. If a remediation slips, the date must be revised, and a date that has passed without a score update signals to a reviewer that the plan was not followed. Set the date only after your remediation plan has named owners and dependencies.

Fields that change with controls

Changes to access, encryption, logging or any other requirement can move the summary score in either direction, and a hidden control weakness can push it well below the posted figure. A consultant or assessor that finds a much lower result than the one on file treats the gap as a posting that was never accurate, not as a routine update. Review the posting each time a control in your SSP changes.

How the three-year currency rule shapes the update schedule

Under DFARS 252.204-7019, an offeror that must implement NIST SP 800-171 needs a current assessment before it can be considered for award, and each relevant covered system needs a summary score posted in SPRS. The default currency limit is three years: the assessment must be not more than three years old unless the solicitation sets a shorter period. That makes the assessment date, not the date you posted the score or the date you last looked at it, the clock that matters. Build your update schedule backward from that date for every system that holds CUI, and track each system separately, because one enclave may have been assessed more recently than another.

Age is measured from the assessment date, and a score can remain inside the window while the environment it describes has already changed. A score taken before a cloud migration, a new identity provider, a change to the CUI enclave boundary or a shift in remote access may still show as current in SPRS. Treat any material change to the systems, the boundary or the System Security Plan as a trigger to reassess, even when the calendar says you have time left. Ask whether a change to the boundary or to the SSP counts as a reason for a new assessment under your internal process, and document that decision.

Before you plan around the default, check the solicitation for any shorter period, since the contract sets the currency that applies to your award. Then confirm with the contracting officer how assessment dates are counted for your situation, including whether a date is measured from the assessment itself or from the date a score was posted, and how a reassessment on a subset of systems affects the others. Put the answers in writing and file them with the SSP. If the answers are unclear, ask before the proposal is submitted, not after the award decision has been made.

Which situations force a score update, by starting point

A posted score describes specific covered systems. If the system changed, was never built, or was scored against a fictitious or virtual environment, the score no longer describes anything that handles CUI, and it must be corrected. The MORSECORP and Georgia Tech matters both turned on scores that did not match the real environment, which is why this trigger carries the most legal exposure.

Systems added or removed: A new enclave, a retired server or a cloud tenant moved into scope each change which SSPs and CAGE codes the posting must list.
Scores tied to a planned environment: A score for a system that exists only in a design document cannot be posted as current for a covered system.
Changed controls: Turning off or replacing a control that was scored as met lowers the summary score and needs a fresh posting.
Who supplies the input: The organization owns the SSP and the scoring. An implementation partner or assessor may prepare evidence, but the organization certifies what it posts.
What to confirm: Confirm that each SSP and CAGE code matches a system that exists today, and that the score reflects the controls actually operating on it.

Before posting, ask whether any system listed in the SSP can be shown to handle CUI as described.

Why a score for an environment that does not exist creates liability

A posted SPRS score is a statement about covered systems that actually exist, and the United States has treated scores that describe something else as potential False Claims Act exposure. In September 2025, the Department of Justice alleged that Georgia Tech Research Corporation submitted a summary assessment score of 98 in December 2020 that was false because it applied to a fictitious or virtual environment rather than any actual covered system. The government also alleged that submitting a score was a condition of contract award. Georgia Tech agreed to pay $875,000 to resolve the civil litigation, and the allegations were not adjudicated. The lesson for your team is that the scope behind each posted score, meaning the SSP, the CAGE codes and the systems it covers, has to match the environment that processes CUI today.

The MORSECORP matter shows the second half of the problem: a score that was once accurate can become inaccurate and stay posted. According to the Department of Justice's March 2025 announcement, MORSECORP admitted it submitted a score of 104 to DoD in January 2021. A third-party consultant told the company in July 2022 that its score was actually -142. The company did not update its score in DoD's system until June 2023, three months after receiving a Government subpoena. MORSECORP agreed to pay $4.6 million to settle the allegations. Ask who in your organization is responsible for re-checking the score when a consultant, assessor or internal review finds a gap, and how quickly that finding reaches the SPRS record.

Keep a dated record of every score, SSP revision and update decision, including the assessment method, the systems in scope, the person who approved the figure and the reason for any change. Confirm the current posting against the SSP each time the boundary, hosting or CAGE code changes, and treat a consultant's lower figure as a trigger for review rather than a disagreement to settle later. Your counsel and your compliance lead should agree in advance how an incorrect score will be corrected and disclosed. A record like this does not prevent an enforcement action, but it shows the Government that the score was tied to a real environment and was kept accurate.

How to correct a score you find is wrong

This sequence takes a discrepancy from first suspicion to a corrected SPRS posting, with a dated internal record and counsel involved from the start. Each step produces a document you can show an assessor or a contracting officer.

Confirm the discrepancy against the actual systems
Start by checking the posted score against the systems it describes. Walk the boundary of each covered system with the people who run it, and compare what the SSP says is in place with what is configured, deployed and operated today. Your internal compliance lead or security engineers own this check, and an outside consultant may help with it. The output is a discrepancy log that records each requirement in question, the evidence you examined, and whether the SSP or the posting is wrong. The step is done when every disputed requirement has a documented answer backed by evidence rather than memory.
Update the system security plan to match reality
Once the facts are confirmed, revise the system security plan for each affected covered system so it describes the environment as it actually exists. Include the system boundary, the implementation status of each requirement, and any planned work tracked in a plan of action and milestones. Check that the CAGE codes tied to each SSP still match the entities in scope. The owner is the organization's security lead, and the output is a versioned SSP with a revision history. The step is done when the SSP and the discrepancy log agree on every requirement.
Rescore the affected requirements
Rescore the requirements in the discrepancy log using the NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1 (24 June 2020). Apply the method's scoring rules to each requirement, recalculate the summary score for each covered system, and record the working for every change. The output is a rescoring worksheet that lists each requirement, its old and new value, the evidence behind it, and the resulting summary score. Your own team or an independent assessor can prepare this worksheet, but an independent assessor, not the implementation partner, issues any assessment result. The step is done when the recalculated scores reconcile with the updated SSP.
Brief legal counsel before the update
Brief legal counsel before or alongside the SPRS change, not after it. Give counsel the discrepancy log, the original posting, the rescoring worksheet, and the timeline of when the organization first knew the posted score was wrong. Counsel decides how the correction is described, whether any contract obligations or disclosure duties apply, and how the record should be preserved. The reason for this order is that the MORSECORP and Georgia Tech settlements turned on how scores were submitted and when they were corrected. The output is a privileged memo or a documented instruction from counsel, and the step is done when counsel has signed off on the wording of the update.
Post the corrected score in SPRS for each system
Update the SPRS posting for each relevant covered system, using the rescoring worksheet as the source for every figure. A Basic Assessment posting carries the SP 800-171 version assessed, the assessing organization, each SSP with its CAGE codes, the assessment date, the summary score, and the date a score of 110 is expected. Enter each system separately and confirm that the entries match the revised SSPs. The output is a set of SPRS entries with the submission record saved. The step is done when each covered system shows the corrected score and the posting is no longer inconsistent with the SSP.
Record the change date and reason
Write an internal memo that records when the discrepancy was found, who confirmed it, what the old and new scores are, the reason for the change, and the date the SPRS entry was made. Attach the discrepancy log, the rescoring worksheet, the revised SSP version and the SPRS confirmation. Store these records where the organization keeps its contract and compliance evidence, and keep them available for a contracting officer or auditor. The output is a dated correction memo, and the step is done when a reviewer who was not involved can follow the entire chain from discovery to posting without asking anyone a question.
Plan the follow-up with an independent assessor
Decide with counsel and your assessor whether the correction calls for a new assessment before the next scheduled review. Note that DCMA DIBCAC Medium or High assessment results take precedence over other assessments under the current deviation clause, and that DoD posts those summary scores to SPRS after a 14 business day rebuttal window. Ask the independent assessor to state in writing whether the corrected posting is one they would accept. The output is a follow-up plan with named owners and the assessor's written position, and the step is done when the plan is filed with the correction memo.

What to verify before you post or update a score

Before any score reaches SPRS, the compliance lead should confirm that the record describes a real environment and can be defended if assessed. The six checks below cover scope, identity, dates, open work, evidence and outside findings, and each one has a named owner inside the organization.

SSP matches systems in scope

Confirm that each system security plan describes a system that exists today and that it covers every system that stores, processes or transmits CUI. Compare the SSP boundary diagram and asset list against the current network, cloud accounts and enclave inventory. Illustrative example: an SSP that still lists a retired file server while omitting a newly added collaboration tool would produce a score for the wrong environment. The system owner signs off, and the executive who attests to the score checks the result.

CAGE codes tied to covered systems

Each posted SSP is associated with the CAGE codes of the organizations it covers, including any subsidiary or site. Confirm that every code in the posting matches the legal entity and location that operate the system, and that no code is attached to a system it does not describe. Mismatches are easy to miss when an acquisition or reorganization changes ownership. The contracts or compliance lead signs off after checking the entity records.

Assessment date and version recorded

Record the date of the assessment, the assessor, and the SP 800-171 version used. A posting must show the version assessed, and the date determines how long the score stays current under the three-year rule. Check that the version in the posting matches the version named in the solicitation or the current contracting instruction, because the answer can change while the rules are in transition. The compliance lead signs off on the date and version.

Open POA&M items reflected accurately

Every open plan of action and milestones item should lower the summary score for the requirement it addresses, and the expected completion date for reaching a score of 110 should be realistic and documented. Check that items marked as closed have evidence of closure, and that no open item has been quietly dropped to raise the number. The security lead owns the POA&M register, and the compliance lead reconciles it against the score.

Score traceable to evidence

For each requirement scored as met, keep a pointer to the evidence that supports it, such as a configuration export, a policy approval record, a scan report or a training log. Partial credit should be explainable line by line. Ask whether an assessor could repeat the score from the evidence alone. Requirements that the organization claims are not applicable should have a documented reason. The control owner for each family provides the evidence, and the compliance lead reviews a sample before posting.

Government and consultant findings reviewed

Before posting, review any finding from a consultant, internal audit, prior assessment or Government review, and decide whether the current score already reflects it. A finding that lowers the score must be carried into the posting, and the reasoning for any disagreement should be written down. Treat a much lower outside result as a reason to stop and verify, not as a number to discard. Legal counsel and the executive attesting to the score should review disputed findings together.

Which score source wins when results disagree

This table compares the four sources that can drive a score posting in SPRS: the organization's own Basic Assessment, a third-party consultant review, a DCMA DIBCAC Medium or High assessment, and CMMC affirmations. Read each row for who produces the result and whether it overrides the others. Confirm current precedence rules in the deviation before relying on them.

Source	What it is and who produces it	When it applies	Takes precedence?
Organization's own Basic Assessment	Self-assessment scored with the DoD Assessment Methodology, produced by the organization and posted to SPRS with its summary score and expected 110 date	Required to post a current score for each covered system before award consideration under DFARS 252.204-7019	No, it is superseded by a DCMA Medium or High result for the same environment
Third-party consultant review	Independent reassessment or gap review performed by an outside consultant; it informs the organization's score but does not itself post to SPRS	Useful when the organization doubts its score or the system security plan describes an environment that differs from reality	No, an organization must still correct its own posting if a consultant finds a lower score
DCMA DIBCAC Medium or High assessment	Government assessment conducted by DCMA, with DoD posting the summary score to SPRS after a 14 business day rebuttal window	Applies when DoD schedules a Medium or High assessment for the contractor or covered environment	Yes, under clause 252.240-7997 (FEB 2026) it takes precedence over other assessments; confirm current rules in the deviation
CMMC Conditional status affirmation	Affirmation by the senior official that the organization has achieved Conditional status, entered in SPRS under 32 CFR 170.22(a)(3)	Applies after an assessment achieves Conditional status with a POA&M in place	Status is verified by DoD in SPRS, but a DCMA Medium or High result still governs the score
CMMC Final status affirmation	Affirmation by the senior official that Final status was achieved, entered in SPRS and verified by DoD	Applies after Final status is achieved, then annually after the Final status date	Current only while no compliance changes have occurred and the affirmation is not older than 1 year under DFARS 252.204-7021
Annual and POA&M closeout affirmations	Yearly continuous compliance affirmation and an affirmation after a POA&M closeout assessment, both entered in SPRS	Due annually after the Final status date and after closing a POA&M	Keeps the status current; a lapsed or inaccurate affirmation can make the status non-current

Questions buyers ask about SPRS score updates

How often must an SPRS score be updated?

An SPRS score must be kept current whenever the facts behind it change, and a posted assessment is only considered current for three years under the codified DFARS 252.204-7019 rule, unless the solicitation sets a shorter period. Between assessments, the number to watch is the date of the last assessment and whether your environment still matches the system security plan it was based on. Confirm the current assessment window in the solicitation, since contracting officers can set a shorter period. The three-year limit is a ceiling, not a schedule, so a score can become inaccurate long before it expires.

Does one control change require a new SPRS score?

Not every change requires a new posting, but any change that makes the posted score wrong does. A single change, such as moving CUI to a new system or disabling a control that was previously implemented, can alter the summary score for the covered system it touches. Treat each change as a question: does it affect the system security plan, the CAGE codes listed, or the controls that were scored? Document the decision either way, because the record of why a change did or did not trigger an update is what an assessor or contracting officer will ask to see. Confirm the threshold with your contracting officer and your assessor before you rely on a judgment call.

Must we post a lower score a consultant found?

Yes. If a qualified party finds that the posted score overstates your compliance, the score in the Supplier Performance Risk System should be corrected, and the MORSECORP settlement shows what happens when that correction is delayed. MORSECORP said it was told by a third-party consultant in July 2022 that its score was far lower than the 104 it had submitted, and it did not update DoD's system until June 2023, after receiving a Government subpoena. The Justice Department announced a $4.6 million settlement in March 2025. Treat any independent finding as a trigger for a documented review, and confirm with counsel how quickly the correction must be made.

Does an annual affirmation change the SPRS score?

An annual affirmation confirms continued compliance but does not replace an assessment score. Under 32 CFR 170.22(a)(3), affirmations are entered in SPRS when a Conditional or Final status is achieved and annually after the Final status date, and DoD verifies that submission. Under DFARS 252.204-7021, a status counts as current only if there have been no changes in compliance since the status date and a corresponding affirmation of continuous compliance, not older than one year, is in place. If your environment has changed since the last affirmation, the affirmation itself may be inaccurate, so review the change record before signing. Confirm with your assessor which status applies to your contract.

Can our own team update the SPRS score without an outside assessor?

Your organization posts and affirms its own information, but the results that count are not produced by you or by your consultant. Basic Assessments are scored under the DoD Assessment Methodology, and DCMA DIBCAC Medium and High assessments produce results that take precedence over other assessments. Under the 2026 deviation clause, DoD posts Medium or High summary scores to SPRS after offering the contractor 14 business days for rebuttal. Your own team can run an internal review and prepare the posting, but confirm with the contracting officer which assessment type applies before you post.

What can an implementation partner prepare before an update?

An implementation partner can prepare the systems and evidence that an update depends on, but it cannot issue the score or the affirmation. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. In practice, that can include reconciling the system security plan with the current environment, collecting configuration and logging evidence for each changed control, and documenting the change record that explains whether a posting needs to change. Your organization still owns the controls and the posting, and an independent assessor or DoD produces the results. Ask any partner to put this split in writing in the scope.

Who issues the results that count for an SPRS score?

Only DoD and its assessors produce the results that count, and independent assessors issue the findings your organization relies on. Basic Assessments are self-assessments scored under the DoD Assessment Methodology and posted by the organization, while DCMA DIBCAC performs Medium and High assessments whose summary scores DoD posts to SPRS. The organization owns its score, its system security plan and its affirmations, and DeployOpen does not issue audit reports, attestations or certifications. Before relying on any score, confirm which assessment type the solicitation requires and who will produce the result.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, documentation and evidence behind a NIST SP 800-171 score before it is updated in SPRS. We plan and implement self-hosted open-source platforms inside your own infrastructure, and we do not issue assessment results or affirmations, which remain the organization's responsibility and the job of independent assessors.

How we scope

Engagements are fixed-scope, with the systems, environments and SSPs in scope agreed in writing before work starts.
We confirm which covered systems and enclaves each posted score actually describes before any change is made.
The written scope states which requirements are being prepared, which evidence is produced and who owns each follow-up action.

How we build

We implement and configure the open-source platforms in your cloud accounts, data centers or air-gapped networks, so the environment matches the documentation.
We test each claimed control against the SP 800-171A determination statements and record where the system falls short.
We close the gaps in scope, then rerun the checks so any corrected score rests on evidence you can show an assessor.

How we hand over

We deliver an updated system security plan, a plan of action and milestones, and an evidence index mapped to each requirement.
We document the configuration baselines, the scoring worksheet and the reasoning behind every changed score.
We walk your compliance and security staff through the evidence so they can answer assessor questions without us present.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which covers changes after a posted score.
A retainer can keep the SSP and evidence current as systems change, so the three-year currency window stays visible to you.
Ask us to confirm in the written scope how re-verification, annual affirmation evidence and assessor support are handled.

When to update your NIST 800-171 SPRS score