Security Ratings in Government Procurement: What Vendors Need to Know
Security ratings requirements are showing up in RFPs with increasing frequency. What the thresholds look like, how agencies use them, and why waiting until RFP time to fix your score is already too late.
A few years ago, a GovTech vendor could reasonably expect that a government agency’s security review would consist of a questionnaire, maybe a SOC 2 report request, and a phone call with someone in IT. That’s changing. Security ratings have become a standard tool in government procurement, and they’re increasingly showing up not as advisory data points but as hard pass/fail gates.
If you sell into federal, state, or local government — or into enterprises that sell into government — understanding how this works is not optional anymore.
How Agencies Are Using Security Ratings
BitSight and SecurityScorecard are the two platforms you’ll encounter most frequently. Both work the same way: they passively collect internet-observable signals about a vendor’s security posture and produce a numeric score. Agencies use these scores at several points in the procurement lifecycle.
Pre-qualification. Some agencies run automated BitSight checks as part of their vendor registration process. Before you ever submit a proposal, your score is already in their system. Vendors below a threshold may be filtered out before they know they’re being evaluated.
RFP language. This is where vendors get surprised most often. The score requirement appears in Section L or Section M of a federal solicitation — evaluation criteria — or buried in the vendor qualification requirements of a state RFP. Language varies but the effect is the same: Vendors must demonstrate a BitSight score of 780 or above at time of proposal submission or The agency reserves the right to disqualify vendors whose security ratings do not meet minimum standards.
Contract performance monitoring. Increasingly, score maintenance is a contract obligation, not just a procurement gate. If your score drops below a threshold after award, you may be required to remediate within a defined window or face contract action.
Incident response evaluation. After a publicized breach, agencies sometimes run ratings checks on their vendor list. This is less formal but happens.
What the Thresholds Look Like
Scores on both platforms run from 250 to 900, roughly analogous to a credit score. Letter grades and numeric ranges vary between platforms, but for government procurement purposes, here’s what you’ll see in practice:
- 780-800+ is the threshold most commonly cited in formal RFP language at the federal and state level. This puts you solidly in “B” territory on the BitSight scale.
- 750 appears frequently in informal qualification guidance and some state and local requirements.
- Below 700 is where deals reliably die. At this level, the conversation has already moved on before you knew it started.
SecurityScorecard uses a letter grade system (A through F), and “A” or “B” requirements are common. An “A” on SecurityScorecard corresponds roughly to a score above 90 on their 0-100 scale.
Why RFP Response Time Is Too Late
This is the thing that catches vendors off guard. Improving your BitSight or SecurityScorecard score isn’t like updating a capability statement. You cannot fix your score in the two weeks before a proposal is due.
The reasons are structural:
Findings have persistence. Even after you fix the underlying issue, the finding stays active in BitSight until their next scan of that service confirms it’s resolved. Depending on the finding type, that can take days to weeks.
Score propagation takes time. Patching cadence scores — which reflect observed patch behavior over time — won’t respond meaningfully to a two-week sprint. BitSight infers your hygiene from historical observation, not just today’s state.
Some findings require investigation before they can be fixed. Compromised system findings — often the highest-weight findings on your report — require you to identify and clean the source before the finding clears. That’s not a same-day task.
The math isn’t linear. Moving from 650 to 780 isn’t the same effort as moving from 720 to 780. The distribution of finding weights means the last 30 points before your threshold can require more work than the first 50.
Realistically, a meaningful score improvement — 50+ points — requires 60 to 90 days of sustained effort with the right prioritization. More if there are significant infrastructure issues. Less if the score is being dragged down by a small number of discrete, fixable findings.
The Timeline That Actually Works
The companies that handle this well aren’t fixing their score when an RFP comes in. They’re maintaining a score above threshold as an ongoing business practice, the same way they maintain their SOC 2.
The practical timeline: if government procurement is part of your business, run your BitSight and SecurityScorecard profiles now, before you have a deadline. Identify the findings. Understand which ones are dragging your score and whether they’re fixable quickly or require sustained effort. Build remediation into your normal engineering cadence.
If you already have a deal on the line, start yesterday. Get your current ratings report, understand what’s actually driving the score, and work the highest-weight findings first. Whether you can get to threshold in time depends entirely on what’s on that report — which is why the first step is always the audit.
If you’re looking at an upcoming RFP and aren’t sure where your score stands or what it would take to move it, that’s a conversation worth having before the solicitation drops.