Key takeaways

  • The method used here is the NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1, dated June 24, 2020, which is the version published on the DoD acquisition site that we read.
  • You start at 110, the number of NIST SP 800-171 requirements. For each requirement not met, you subtract its value: 5, 3 or 1. The score can go below zero.
  • The method does not give partial credit in general. If a requirement is 75 percent rolled out, it counts as not implemented.
  • The method's own examples of built-in partial credit are two: MFA (3.5.3) loses 3 points, not 5, if it covers remote and privileged users only; FIPS-validated cryptography (3.13.11) loses 3 points, not 5, if encryption is used but is not FIPS validated.
  • Without a system security plan (3.12.4) the assessment cannot be completed at all, so there is no score. Without a plan of action for gaps, requirement 3.12.2 counts as not implemented.
  • A number alone is not a CMMC status. Read the CMMC conditions separately before you plan around a score.

Which rules this example uses

The Supplier Performance Risk System, SPRS, holds the scores that contractors post under DFARS 252.204-7019 and 252.204-7020. Those scores are produced with the NIST SP 800-171 DoD Assessment Methodology. This example uses Version 1.2.1 of that methodology, dated June 24, 2020, and the 110 requirements of NIST SP 800-171 Revision 2. The company and the gaps below are invented for teaching. The values per requirement come from the methodology's scoring template.

If DoD publishes a newer version of the methodology, use that one. The arithmetic idea stays the same, but values and notes can change.

Step 1: start at 110

The methodology says that if all security requirements are implemented, the contractor gets 110, consistent with the total number of NIST SP 800-171 requirements. For each requirement not met, the associated value is subtracted from 110. That can end below zero.

Step 2: know the three weights

Each requirement in the scoring template carries a value of 5, 3 or 1. Roughly, the 5s are the requirements with the biggest effect on security, such as access limits, audit logs, vulnerability remediation, malicious code protection and multi-factor authentication. The 3s sit in the middle, such as least privilege and periodic risk assessment. The 1s are the supporting items. You do not need to memorize them; the template lists each one.

Step 3: a worked example

Imagine a small machine shop that has finished its system security plan and its self-assessment against the 800-171A objectives. It found ten requirements not fully met:

  • 3.14.1, flaw remediation is not done in a timely way: minus 5.
  • 3.3.5, log review and correlation are not in place: minus 5.
  • 3.8.7, removable media is not controlled: minus 5.
  • 3.5.3, multi-factor authentication covers remote and privileged users but not all users: minus 3 (partial credit, explained below).
  • 3.13.11, files are encrypted but with a module that is not FIPS validated: minus 3 (partial credit, explained below).
  • 3.3.2, actions of individual users cannot always be traced: minus 3.
  • 3.11.1, risk assessments are not periodic: minus 3.
  • 3.2.3, insider threat awareness is missing from training: minus 1.
  • 3.10.5, physical access devices such as keys and badges are not managed: minus 1.
  • 3.1.22, nobody reviews content posted on public systems: minus 1.

The deductions are 5 + 5 + 5 + 3 + 3 + 3 + 3 + 1 + 1 + 1, which is 30. The score is 110 minus 30, so 80.

Where partial credit comes from

The methodology says it is not designed to credit partial implementation, with the exception of requirements where partial scoring is built in. It names multi-factor authentication, 3.5.3, as the example. For 3.5.3, 3 points are subtracted if MFA is implemented only for remote and privileged users, and 5 points are subtracted if it is not implemented for any users. The reasoning in the text is that MFA is typically rolled out first to remote and privileged users, who are fewer and more critical, and then to everyone.

For FIPS-validated encryption, 3.13.11, 3 points are subtracted if encryption is used but is not FIPS validated, and 5 points if no encryption is used. The methodology also says that using an approved algorithm, such as AES, is not enough by itself: the cryptographic module has to be separately validated under FIPS 140.

Where partial credit does not apply

The methodology gives its own warning example. If the first roll-out of multi-factor authentication is only 75 percent complete, and a plan of action is still being carried out, requirement 3.5.3 is considered not implemented, because it has not been fully implemented. A plan of action does not earn points. The exception is a temporary deficiency that appears after implementation, for example a patch that invalidates a module's FIPS validation, which the methodology scores as implemented while the plan of action runs.

What breaks the score entirely

  • No system security plan. Requirement 3.12.4 has no number; the methodology says that without a plan, the assessment cannot be completed because of incomplete information and noncompliance with the clause.
  • No plan of action for the gaps. The methodology says that this causes 3.12.2 to be assessed as not implemented, a 3-point loss on top of the others.

What 80 does and does not tell you

An 80 says that, by your own reading of the evidence, the net weight of unmet requirements is 30 points. It does not say which gaps are dangerous. In the example, three 5‑point items about patching, logging and removable media are the ones attackers use. It also is not a CMMC status. The CMMC rule has its own conditions for a conditional Level 2 status, including a minimum score and a list of requirements that may not be on the plan of action; an 80 would not meet a threshold of 88. Read the separate CMMC article on this site for that part.

Two more cautions. A posted score is a statement to the government, so it should reflect the evidence you can show, not the plan you hope to finish. And the score applies to a defined scope with a system security plan; if the scope changes, redo the sum.

A sensible way to do your own

  • Fix the scope first: which systems, people and locations touch CUI.
  • Score each requirement against its objectives with evidence, not memory.
  • Mark partial states honestly. Only 3.5.3 and 3.13.11 have built-in partial values.
  • Sort your gaps by weight and by the risk they carry, then close the 5s that matter most first.
  • Write the plan of action with real dates, and re-score when items close.

We can run a scoring review against the methodology as scoped, authorized work and give you the gap list with evidence. We do not act as your assessor for a CMMC certification, and we do not guarantee any score or status.

Sources

This article is general information, not legal, contracting or technical advice for your environment. Contract clauses, DoD policy and certification rules are set by the Department of Defense and your contract; confirm what applies to you with your prime, your contracting officer and counsel. Last reviewed .

Next article

Related reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity