The cloud controls that sink your NIST SP 800-171 self-assessment score
Whatever happens to third-party assessment schedules, the self-assessment obligation is in force now. DFARS 252.204-7019 requires a current NIST SP 800-171 self-assessment score posted in the Supplier Performance Risk System (SPRS) to be considered for award, and 252.204-7020 gives the government access to verify it and pushes the requirement down the subcontract chain. For contractors running workloads in Azure Government or AWS GovCloud, the score-killers are rarely exotic. They are cloud configuration decisions, made reasonably at migration time, that map onto the heaviest deductions in the scoring methodology. Here is how the math works and where cloud environments bleed points.
How does the NIST SP 800-171 scoring methodology work?
You start at 110 and subtract. The scoring methodology codified in 32 CFR 170.24 assigns each of NIST SP 800-171 Rev 2’s 110 requirements a weight: five points for requirements whose absence could lead to significant exploitation of the network or exfiltration of CUI, three points for gaps with a specific and confined effect, and one point for the remaining derived requirements. Unimplemented requirements are subtracted from the maximum, and the score may go negative.
A plan of action and milestones (POA&M) documents how a gap will be closed, but the deduction stands until the requirement is implemented. The methodology credits partial implementation in only two named cases, both covered below, which means the fastest way to read a score is to find the five-point items first.
FIPS-validated encryption is the deduction hiding in your cloud settings
Requirement 3.13.11 calls for FIPS-validated cryptography to protect the confidentiality of CUI, and encrypted is not the same claim as FIPS-validated. The methodology prices the difference exactly: five points off if encryption is not employed, three points off if encryption is employed but not FIPS-validated.
In cloud terms, this lives in configuration detail: whether services are using FIPS-validated cryptographic modules and endpoints, how keys are managed, and where TLS terminates. Both major government cloud platforms document FIPS configuration, and the operational rule is to verify current module validation status against vendor documentation rather than assuming the region implies it. One structural note worth knowing: under the CMMC rule, this encrypted-but-not-FIPS-validated condition is the only gap above one point that may sit on a POA&M at assessment time, which tells you how common the Department expects it to be.
Multifactor authentication has to cover the consoles, and the laptops were the easy part
Requirement 3.5.3 is weighted at five points if multifactor authentication (MFA) is not implemented for any users, and three points if it covers only remote and privileged users. In a cloud estate, the accounts that matter most are the ones an on-premises MFA rollout never saw: the management console, command line and API access, break-glass accounts, and third-party service portals with standing access.
An environment with MFA on every laptop and none on a root account carries the deduction and the actual risk at the same time. The fix is an inventory of authentication paths into the environment, privileged paths first, checked against what the identity platform actually enforces rather than what the policy document says.
The one-point items that quietly add up
The remaining derived requirements deduct one point each, and cloud sprawl manufactures them: every new account or subscription is a fresh chance to skip logging coverage, session controls, or media handling for decommissioned resources. Individually they look ignorable. Ten of them cost more than a missing MFA rollout.
Sweep for them from the asset inventory, not from memory. An inventory-driven pass over accounts, subscriptions, and storage is how the quiet deductions surface, and the inventory is an artifact the requirements expect you to maintain anyway.
What do you do with the score once you have it?
Run the methodology honestly, fix the five-point items first, and post the updated score. The score is not a pass or fail grade; it is a posture statement the government can verify under 252.204-7020, and an accurate lower score with a credible remediation record is a defensible position. An inflated score is not, because it is a representation made to the government.
The working sequence: establish the current score, close the five-point gaps, then the three-point partial cases, then run the one-point sweep from inventory, and update the system security plan so the document matches the environment the score describes. A cloud migration is exactly the kind of change that should trigger this cycle, because the score posted before the migration describes an environment that no longer exists.
If your posted score predates your cloud migration, treat that as the finding. Re-run the methodology against the environment you actually operate, and let the five-point items set the order of work.
VSO helps Defense Industrial Base contractors run the scoring methodology honestly and close the heavy deductions first. If your posted score is older than your architecture, that is the place to start.
FAQ
