SPRS Score and Software: What Your Score Assumes

The Supplier Performance Risk System, SPRS, is where defense contractors post the results of their cybersecurity self-assessments. A score or a self-assessment status in SPRS is a statement about your CUI environment on a given date, and for Level 2 it is followed by an annual affirmation by a senior official. Most of the work behind that statement is policy and configuration. A large share is also software: what is installed, who allowed it and how you know.

What the score is built from

The DoD Assessment Methodology for NIST SP 800-171 starts from a maximum of 110 points, one per requirement, and subtracts weighted values for requirements that are not implemented. The weights reflect the effect of each requirement on security. CMMC self-assessment results for Level 2 use the same 110 requirements of NIST SP 800-171 Rev 2, as set out in 32 CFR Part 170. The official weights are published in the methodology document, so use that source and not a blog summary when you calculate your own score.

Where software shows up in the assessment

Two practices apply directly. CM.L2-3.4.8 asks you to apply deny-by-exception or allow-by-exception policy to the use of software: block what is not authorized, or permit only what is. CM.L2-3.4.9 asks you to control and monitor user-installed software. When you mark them implemented, you are saying that you have a documented policy that names the model you chose, a list of the software it applies to (blocked or permitted, depending on that model), enforcement that works as written, and control and monitoring of what users install. Most contractors choose allowlisting, and the examples below assume it; with a blocklist, the same questions apply to the list of blocked software. See what assessors look for in allowlisting and user-installed software policy.

Software also touches other practices indirectly: vulnerability scanning, flaw remediation and baseline configuration all depend on knowing what is installed. An inventory that is out of date weakens several answers at once.

Questions an assessor can ask

If the claim is that application control is implemented, expect follow-up questions that your records should answer without a scramble. These examples are phrased for an allowlisting policy:

• Where is the list of approved applications, and who maintains it?
• Who approved this specific application, when and on what basis?
• What happens when a user tries to run something that is not on the list?
• How do you find software that was installed outside the process?
• When was this application last reviewed?

A policy with no approval records does not answer these. The records described in the approved software list are the evidence.

Gaps that quietly overstate a score

With an allowlist, these are the usual gaps.

An allowlist that is not enforced. A spreadsheet of approved tools is documentation, not a control, if users can still run anything.

Exceptions without records. Software installed for a project and never added to the list is the usual source of the gap.

Approvals with no basis. "IT said it was fine" is not a recorded decision. A short review of the vendor and the software's behavior is.

A stale list. Software changes and vendors change; approvals that are years old describe a product that no longer exists in that form.

Accuracy is the point

A self-assessment that claims more than the environment supports is a risk of its own. The Department of Justice has pursued False Claims Act cases against contractors over cybersecurity representations. This article is general information, not legal advice; consult counsel about your position. The practical protection is the same either way: score what you can demonstrate, and keep evidence that lets you demonstrate it.

The schedule can change, the claim does not

Dates for mandatory third-party assessments have been reported to shift, and you should confirm the current position with the Department of Defense and the Cyber AB. Self-assessment results and affirmation are your statement under your own contract, and the NIST SP 800-171 requirements in DFARS 252.204-7012 do not wait for a certification date.

Where DigVel fits

DigVel produces a documented, evidence-backed decision for a specific application: vendor screening, sandbox analysis and a report mapped to NIST SP 800-171 practices. That gives you a record to attach to the approved software list and to cite in your system security plan. See the service overview and the approval workflow. A DigVel report supports your own assessment; it is not a certification or a substitute for one.