Lesson 9 · Running it · 2 min read
Measuring a CNAPP after rollout: coverage, fix time and noise
Cloud Security Compare editors · Matchups reviewed September 2026 · Editorial assessment
The short version
Four measures show whether a CNAPP is doing its job after purchase: how much of the estate it covers, how long the most important findings take to fix, how many alerts lead to action, and how many fixes are made in code rather than in the console. Record a baseline in the first month and review the same numbers every quarter.
How much of the estate is covered?
Compare the product's inventory with your own list of cloud accounts, subscriptions and projects every month. New accounts are the usual gap: an account created outside the standard process is often the one with the weakest settings. For runtime, track the share of production hosts and clusters with a working sensor. Report both numbers by cloud, since coverage is often uneven across providers.
How long do important findings take to fix?
Pick a definition of important that your team agrees on, for example findings on an attack path to sensitive data, or the product's top priority tier. Measure the median time from first detection to fix for those findings only. A falling number means prioritization and routing are working. Measuring every finding hides the signal, because low-priority findings dominate the count.
How much of the alerting leads to action?
For runtime detections and high-priority findings, sample a set each month and record whether each one led to action, was a known and accepted risk, or was noise. A high share of noise means the rules need tuning or the ranking is off. Vendor figures such as Upwind's claim of 93% noise reduction are the vendor's own measurements; your sample is the one that describes your estate.
Are fixes being made in code?
If you bought the platform partly for code-to-cloud tracing, count how many fixes were made in source through a pull request rather than in the console, and how many repositories are connected. A fix made only in the console is often undone by the next deployment.
What do you do with the numbers?
Review them each quarter with the people who signed off the purchase. If a number stalls, check it against the criterion it maps to: coverage to agentless coverage and runtime, fix time to risk prioritization, fixes in code to code-to-cloud. If the gap is in the product rather than the process, that is the evidence for the next review of the decision, covered in the next lesson.
Who should own each measure?
Give each measure one owner. Coverage usually sits with the cloud platform team, because new accounts and clusters are created there. Fix time belongs to whoever runs vulnerability management. Alert quality belongs to the team that answers runtime alerts, often the SOC. Fixes in code belong to an engineering lead, since that number only moves when developers accept the work. One owner per measure keeps the quarterly review short: each owner explains their number and the one change that would move it.
Related pages
- Writing a CNAPP scoring sheetThe criteria your measures map to
- Reading vendor claimsWhy vendor figures are not your baseline
- Comparison matrixWhere your platform trails
Next lesson: When to re-review a CNAPP decision