Percentage-based scores make it easier to compare teams, environments, and business units of different sizes without letting scale distort the picture. Raw counts can hide whether a large environment is actually better controlled or merely larger. Percentages support clearer benchmarking, more defensible reporting to leadership, and more consistent prioritisation of remediation efforts.
Why percentage-based scoring tells you more than raw counts
Raw vulnerability counts answer how many findings you have, but not how much of the estate they represent. A team with 50 findings across 10,000 assets is in a very different position from a team with 20 findings across 40 assets. Percentage-based scoring normalises for size, so leaders can compare like with like and avoid rewarding scale or punishing it.
That normalisation matters because security data is often uneven: one business unit may run many more systems, scan more often, or expose more endpoints than another. When you express results as a rate or percentage, the number becomes a control signal rather than just a volume signal. It is easier to see whether remediation is keeping pace, whether control coverage is improving, and whether a large environment is genuinely better managed.
Percentages also improve prioritisation. If two environments have the same raw count, but one has far more total assets, the remediation urgency may differ. A percentage-based view helps teams focus on exposure density, not just incident volume, which is especially useful when comparing cloud estates, product lines, or operational units with different footprints.
What raw counts obscure in real security reporting
Raw counts tend to reward context-free comparison. They can make a mature but large environment look worse than a small environment with weaker control coverage simply because the larger environment has more things to inspect. They can also hide concentration risk in the opposite direction: a small environment with only a few findings can still be highly exposed if those findings affect a large share of critical assets.
For reporting, that distinction changes the story you tell. Leadership usually needs to know whether the organisation is reducing exposure relative to its size, not just whether the absolute backlog is rising or falling. Percentage-based measures support more defensible benchmarking across teams, vendors, and time periods because they keep the denominator visible and make trend lines easier to trust.
That is why percentage scores often work better for comparing vulnerability posture across business units, while raw counts still matter for operational triage. Counts show workload. Percentages show control effectiveness. Used together, they tell you whether the backlog is large because the environment is large, or because the environment is under-controlled.
How to use percentage scores without losing operational detail
The most useful approach is to treat percentage-based scoring as the executive and comparative layer, then keep raw counts for remediation planning. A percentage can tell you that one environment is performing better relative to its size, but the raw count still tells you how many tickets, systems, or exceptions the operations team must actually handle.
CIS Controls v8 is a good example of why this dual view matters, because control programs need both prioritised safeguards and measurable implementation progress. In practice, a percentage score is most useful when it is tied to a defined population, such as assets scanned, systems with a control applied, or findings closed within a time window.
If the metric is not clearly defined, percentages can mislead just as easily as counts. A rate based on “systems scanned” will mean something different from a rate based on “critical assets protected,” so the denominator must match the decision you are trying to support. The best score is the one that is stable enough for benchmarking and precise enough for action.
Risk and Threat Considerations
Security scores can create false confidence if the denominator is weak, inconsistent, or easy to game. A team can improve a raw count by shrinking the scope of what it measures, while still leaving the most important assets exposed. Percentage-based scoring reduces that distortion, but only when the underlying asset inventory and scan coverage are trustworthy.
Failure mechanism: Teams report absolute findings without a consistent denominator, or they compare environments with different sizes and control scopes as though they were equivalent. That distorts prioritisation, hides concentration of exposure, and can make an under-controlled environment look acceptable because the number is small.
Impact: Leadership may misallocate remediation effort, miss weak control coverage in larger estates, or approve risk decisions based on a score that is not actually comparable across groups. In the worst case, the organisation optimises for fewer findings instead of lower exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Vulnerability metrics need consistent measurement and tracking to judge posture fairly. |
| Recommendation — Track vulnerability rates alongside counts to measure remediation progress across comparable asset populations. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight of cybersecurity risk is established and maintained | Comparative scoring supports oversight by making risk posture understandable across business units. |
| Recommendation — Use normalized scores to brief leadership on relative exposure and remediation progress. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Vulnerability scanning data must be interpreted against a defined scope to be actionable. |
| Recommendation — Report vulnerability results with a clear denominator so the findings are comparable across environments. | ||
Practitioner Guidance
What to verify: Before trusting a score, confirm what the denominator represents, whether all teams are using the same measurement scope, and whether excluded assets or unscanned systems are being tracked separately. A percentage is only meaningful when the population behind it is stable and explicit.
Decision rule: Use percentages for comparison, governance, and trend analysis; use raw counts for workload sizing and remediation tracking. If a metric must support both purposes, publish both views together so neither scale nor absolute effort is hidden.
Practitioner takeaway: The best security metric is not the smallest number, it is the one that makes exposure comparable, decision-ready, and hard to game.
Related resources from NHI Mgmt Group
- How should security teams stop help desk based MFA bypass attacks?
- Why do raw vulnerability counts give a misleading picture of risk in AI-accelerated environments?
- What breaks when vulnerability management is based only on CVSS scores?
- What breaks when API security is based only on vulnerability scanning?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
