How to Calculate Your SPRS Score (Negative Is Normal)

A NIST SP 800-171 self-assessment score starts at 110, one point for each security requirement, and subtracts 5, 3, or 1 for every requirement that is not fully implemented. 32 CFR 170.24 sets the weights by consequence: 5 points where a gap "could lead to significant exploitation of the network, or exfiltration of CUI", 3 where the effect is "specific and confined", 1 where it is "limited or indirect". Partial credit exists in exactly two places, both named in the same section and both scoring 3 rather than 5, and everywhere else a requirement is met or it is not. The regulation states plainly that the arithmetic "may result in a negative score". First-pass negative scores are ordinary, because the 5-point requirements are exactly the ones small contractors are least likely to have: multifactor authentication, FIPS-validated cryptography, boundary protection. The number is a starting position. What it is not is a private working note, because submitting it to the Supplier Performance Risk System is a representation to the government.

That last point is the one most guides bury, so this article covers the arithmetic first and then the part with legal consequences attached.

Key takeaways

• Start at 110, one point per security requirement, and subtract 5, 3 or 1 for every requirement that is not fully implemented. The weights are set by consequence in 32 CFR 170.24.
• Partial credit exists in exactly two places, multifactor authentication and FIPS-validated cryptography, and both score 3 rather than 5. Everywhere else a requirement is met or it is not.
• A negative first score is ordinary. The 5-point requirements are exactly the ones small contractors are least likely to have, so the number is a starting position rather than a verdict.
• The score is not a private working note. Submitting it to SPRS, with a senior official's affirmation, is a representation to the government, and the False Claims Act theory does not require a breach.
• Scope first, score second, and assess against the NIST SP 800-171A objectives rather than requirement titles. A score against an undefined boundary is a score of nothing.

The arithmetic, exactly

Take the 110 security requirements of NIST SP 800-171 Rev 2. For each one, decide whether it is fully implemented. Not mostly, not planned, not implemented on some systems. Fully.

For every requirement that is not fully implemented, subtract its point value: 5, 3, or 1, per the weighting in 32 CFR 170.24. The result is your score.

Two mechanics people get wrong. First, partial credit is the exception rather than the rule, so a control implemented on eight of ten in-scope servers scores zero. Second, the weights are not evenly distributed, which is why the score moves in lumps. A handful of 5-point misses does more damage than a long tail of 1-point misses, and that shapes remediation order.

The two places partial credit does exist

Most guides say flatly that there is no partial credit. That is right for 108 of the 110 requirements and wrong for two, and both exceptions sit in the same section of 32 CFR 170.24 that sets the weights.

Multifactor authentication. Three points are subtracted rather than five where MFA is "implemented only for remote and privileged users". Five points are subtracted where MFA "is not implemented for any users". So an organization that has covered remote access and administrators, and has not yet reached the general user population, is 3 points down on that requirement, not 5.

FIPS-validated cryptography. Where encryption "is employed, but is not FIPS-validated", three points are subtracted. Five points are subtracted where no encryption is employed at all. The distinction matters because plenty of environments encrypt CUI with modules that were never submitted for validation, and that is a different position from not encrypting it.

Both carve-outs exist because these two controls are usually deployed in stages rather than switched on estate-wide. Nothing else in the method works this way: for the other 108 requirements the answer is fully implemented or it is not.

The arithmetic also explains the negative results. If you have not deployed multifactor authentication for network access, have not moved to FIPS-validated cryptographic modules, and have gaps in boundary protection and logging, you can be several dozen points down before you reach anything most people would call a weakness. A score below zero is a statement about the weighting, not a verdict on your business.

Two related points are worth separating from the score itself, because they belong to different documents. NIST SP 800-171A breaks each requirement into assessment objectives, and it is the right level to assess against, because "we do access control" is not a finding and "each of these objectives is met, here is the evidence" is. And the conditional-certification threshold that people quote as "80 percent" is a CMMC assessment rule in 32 CFR 170.21, not an SPRS scoring rule. We cover it in CMMC POA&M rules.

What the submission actually commits you to

Under Phase 1, which began November 10, 2025, applicable solicitations require the CMMC level to be met at award, self-assessment results to be recorded in SPRS, and a senior company official to affirm continuing compliance. That affirmation is the part with teeth.

The Department of Justice's Civil Cyber-Fraud Initiative has pursued contractors under the False Claims Act over cybersecurity representations made to the government. The theory is straightforward: you were paid on a contract that required safeguarding, you represented that you met the requirements, and the representation was false. It does not require a breach. It requires a claim for payment and an untrue statement.

This reframes the whole exercise. A score is not a grade you are trying to improve for appearances. It is a number you will have to defend, alongside a System Security Plan that says how each requirement is met, and, if it comes to it, evidence that the implementation described was real on the date you said it. That is why we tell clients to submit the honest number and work the plan, rather than round up and hope the assessment model keeps slipping.

The suspension of CMMC Phases 2 through 4 on July 13, 2026 changed none of this. Phase 1 obligations were not suspended, and what the pause did and did not touch is worth reading if you have been told otherwise.

How to run the assessment so the score means something

Scope first, score second. A score is only meaningful against a defined boundary. If you have not decided which systems store, process, or transmit CUI, you are scoring an undefined thing. Start with what data you actually hold.

Assess against 800-171A objectives, not against requirement titles. The objective-level view is where "we have MFA" resolves into which accounts, which access paths, and what evidence exists.

Write the System Security Plan as you go. The SSP is not the deliverable at the end. It is the artifact that makes the score reproducible, and CA.L2-3.12.4, the system security plan requirement, is one of the requirements that can never be deferred to a plan of action.

Record evidence with the score. A configuration export, a policy version, a ticket, a screenshot with a date. Three years later, the score is only as defensible as the evidence behind it.

Re-score when the environment changes, not annually by calendar. A migration, an acquisition, or a new site can move a score more than a year of drift.

Five scoring mistakes that inflate a score

Every one of these produces a number that is too high, which is the direction that carries the risk.

Awarding partial credit where the method does not offer it. A requirement implemented on most of the in-scope systems scores zero. Outside the two named cases above, there is no proportional credit in the method, and averaging across an estate is the single most common way an untrue score gets produced.

Scoring the company rather than the boundary. If the assessment boundary is not defined, the answers drift toward the best-managed part of the environment. Scope first, then score, and write the boundary down so the next person scores the same thing.

Counting documented as implemented. A written policy is evidence that a requirement is understood, not that it operates. The requirement is met when the control is running and someone can show it running.

Counting multifactor authentication too generously. This one is worth naming on its own because it is the highest-weighted item most organizations get wrong, and because it is where the two deduction levels are easiest to confuse. MFA on the VPN but not on cloud administrative consoles leaves privileged access uncovered, and that is not the case 32 CFR 170.24 gives relief for: the relief is for MFA "implemented only for remote and privileged users", which is remote plus administrators. Get that far and the deduction is 3. Fall short of it and the deduction is 5. Either way the requirement is not fully implemented, and recording it as met is the mistake.

Carrying an old assessment date. A score submitted two years ago describes an environment that no longer exists. Migrations, acquisitions, and new sites all move the number, and an affirmation of continuing compliance against a stale assessment is exactly the representation you do not want to have to defend.

If any of these describes your current score, the correction is cheaper now than later, and correcting it is a normal and documentable act rather than an admission.

The remediation order the weighting implies

Work the 5-point requirements first, because they move the number most and because they are the controls that actually reduce the risk of CUI exfiltration. Multifactor authentication, cryptographic protection of CUI, and boundary protection are the usual suspects.

Then take the 3-point items. Then the long 1-point tail, which is where documentation, review cadence, and process requirements cluster.

There is one deliberate exception to scoring-order remediation. A handful of requirements can never sit on a plan of action under 32 CFR 170.21 regardless of point value, including the system security plan itself. Those come first whatever they score, because leaving them open forecloses options later.

When you should not be paying anyone for this

If you have capable IT staff and a small environment, the self-assessment is genuinely doable in-house. It is tedious rather than esoteric: 110 requirements, an objective list published by NIST, and honest answers. Buying a scoring exercise you could run yourself is a poor first purchase.

Where outside help earns its fee is scoping, the objective-level judgment calls, and the System Security Plan, because those are the places where being wrong is expensive and where experience compounds. If a firm's proposal is a scoring spreadsheet and a template SSP with your name in the header, you are buying a document rather than a determination.

And if your score is already accurate and your gaps are known, what you need is engineering, not assessment. We have seen organizations assess three times before implementing anything.

Where Top Floor fits

Our CMMC work is objective-level: we assess against 800-171A, write findings a system administrator can act on, and leave you with an SSP that describes what is actually true. Where a program needs standing ownership rather than a project, that runs through audit and assurance alongside whatever commercial frameworks you carry.

We are not a C3PAO and do not perform certification assessments, which is deliberate. The conflict-of-interest rules in the program mean the firm that helps you prepare is not the firm that certifies you.

How to decide this week

Pull your current SPRS score and the date it was submitted. If nobody can name both, that is the first task.

Take the five highest-weighted requirements you know you do not meet and cost them out as engineering work, not as compliance work. MFA and encryption are projects with owners and dates.

Then answer one question honestly, in writing, for your senior official: is the affirmation on file still true today? Everything else in this article is downstream of that answer.

Frequently asked questions

Is a negative SPRS score bad?

It is common, and on a first pass it is close to expected. The scoring method starts at 110 and subtracts 5, 3, or 1 for each requirement not fully implemented, and 32 CFR 170.24 states explicitly that this may produce a negative score. Because the 5-point requirements include multifactor authentication, FIPS-validated cryptography, and boundary protection, an organization that has not yet done that engineering work can be deeply negative while running a competent business. What matters is that the number is accurate and that a plan sits behind it.

How is the SPRS score calculated?

Start at 110, one point for each NIST SP 800-171 Rev 2 security requirement. For every requirement not fully implemented, subtract its weight: 5 points where the gap could lead to significant exploitation of the network or exfiltration of CUI, 3 where the effect is specific and confined, and 1 where it is limited or indirect. Partial credit exists in only two cases, both set out in 32 CFR 170.24 alongside the weights: multifactor authentication implemented only for remote and privileged users costs 3 rather than 5, and encryption that is employed but is not FIPS-validated costs 3 rather than 5. For every other requirement, one met on most systems still scores zero.

Do I still have to submit an SPRS score after the CMMC Phase 2 suspension?

Yes. The July 13, 2026 suspension paused Phases 2 through 4, not Phase 1. Since November 10, 2025 applicable solicitations have required the CMMC level to be met at award, with self-assessment results recorded in SPRS and a senior official affirmation of continuing compliance. Those obligations were untouched by the memo.

What happens if my SPRS score is wrong?

Treat it as a legal exposure rather than a data-quality problem. The score and the affirmation behind it are representations to the government, and the Department of Justice's Civil Cyber-Fraud Initiative has pursued contractors under the False Claims Act over cybersecurity representations. Correcting an inaccurate score and documenting when and why it changed is far cheaper than defending it later, and a compliance pause is the least costly moment to do it.