← Blog

Vulnerability remediation process: setting SLAs when half of all findings are still open

53% of CNAPP findings are still open and critical alerts wait 150 days.

Vulnerability remediation process: setting SLAs when half of all findings are still open

How do you reduce a CNAPP alert backlog and meet remediation SLAs at the same time? Start by measuring the backlog by age instead of by closure rate, prioritize by the asset rather than the severity tag, name one owner per alert category, and set SLAs from the close times your team actually achieves. Tamnoon's State of Cloud Remediation 2026 measured those close times across 14.86 million CNAPP detections. The numbers below come from that study. The process that follows is our reading of what the report found in programs that have measurably reduced critical-tier close times.

Why the backlog is 53% open

At the end of May 2026, 53% of CNAPP detections across 800 observed accounts were still open. Open alerts outnumber closed ones. The open share has sat between 40% and 50% for years, even though closure throughput has improved.

That pattern tells you something about composition. The easy alerts get closed first. The report describes the most consequential detections as the ones that span more owners, touch production systems, touch regulated data, and wait on vendor patch cycles. Those are what remain. The scanner finds the work, but the scanner does not own the work.

Two more numbers set the scale. Critical alerts take 150 days on average from open to close, up from under 40 days in 2024. Vulnerability Management is the slowest-closing category at 282 days, 22% slower than the year before.

The SLA most teams signed is wrong for the queue they have

Most remediation SLAs were written when critical alerts were a small fraction of the queue. In 2025, 1.4% of new alerts carried a critical tag. In 2026 the share is around 13%. Coverage expanded and CNAPPs now factor in reachability and exploitability, so the critical bar became more meaningful and the volume crossing that bar grew about tenfold at the same time.

A team sized for a backlog with 1% criticals cannot absorb a tenfold increase under the same routing rules. The report puts it plainly: SLAs, on-call thresholds, escalation paths and staffing models all warrant a re-check, because the staffing model and the technology behind them have to change shape.

So the first step is to stop comparing your team against an SLA it was never resourced to meet, and to rebuild the SLA from measured close times per category.

A vulnerability remediation process in five steps

Programs that have measurably reduced critical-tier close times, as the report describes them, share a few habits: a single owner per category, handoffs defined before the alert arrived, runbook automation with a change window, and a vendor escalation path that somebody owns. The five steps below are how we turn those habits into a process. The report sets the facts. The method is ours.

1. Measure the backlog by age, not by closure rate

Closure-rate dashboards understate exposure. A team can close more alerts every quarter while the open pile grows older. Report open alerts by age range and by category, and mark the ones that touch a critical asset. With the slowest category at 282 days, only an age-based view shows how long exposure actually lasts.

2. Prioritize by the asset, then by the severity tag

Severity classifications differ from CNAPP to CNAPP. Asset criticality is defined by the business, not by the scanner. In the 2026 dataset, 6.3% of open alerts touch a Crown Jewel asset. The report puts active risk in the open backlog as a whole, and that slice is where a fix returns the most risk reduction. Severity remains useful for routing inside the security team. For deciding what gets fixed first, asset value comes first.

3. Name one owner per alert category

The three slowest categories in the dataset are Vulnerability Management at 282 days, Privacy Regulations at 242 days and Password Management at 242 days. Each one crosses teams and ownership paths that no CNAPP controls. Map the org chart for a single open privacy finding and you reach cloud security, application engineering, legal, vendor management and sometimes finance. No team owns the end-to-end closure timeline unless someone is named. Name them, per category, and write down the handoffs before the next alert arrives.

4. Set SLAs per category from your own close times

The report says the SLAs warrant a re-check. Our recommended way to do it: take the last two quarters of closed alerts and compute median and 90th-percentile days to close, per category and per severity. Set the SLA at a level the current team meets for the majority of that work, then tighten it quarter by quarter as the process improves. An SLA copied from a policy template produces a red dashboard. An SLA derived from measured close times produces a decision about which category needs more ownership, more automation, a change window or more vendor pressure.

Re-check severity routing at the same time. If critical alerts are now 13% of intake instead of 1%, the rule that pages a human for every critical no longer describes a workable on-call rotation.

5. Automate the repeatable fixes, keep people where the blast radius is high

The top eight misconfigurations in 2026 look nearly identical to 2025's and together make up roughly 20% of all alerts. Six of the eight are configuration gaps: read-only container root filesystems not enforced at 4.1%, missing SSH key pairs on compute instances 2.4%, unencrypted block storage volumes 2.3%, metadata service v2 not enforced 1.9%, and two more. The report's point is that configuration detections can be remediated in a sprint, while vulnerabilities wait on external delivery. The configuration gaps belong in runbook automation with a change window, not in a human queue. The two vulnerability rows in the same top eight, at 3.9% and 1.8%, are the vendor-bounded work and stay with a person.

The coordination-heavy categories are different. Vendor-bounded vulnerabilities and fixes on production systems need a person in the loop, because the blast radius is wide and the fix crosses teams. The report documents more than a hundred distinct alert categories, each with its own remediation flow and its own owner, blast radius and definition of done. No single generic playbook closes all of them, and no single agent does either.

What to report upward

The board-relevant number is not alerts detected or alerts closed this quarter. The number is open alerts on Crown Jewel assets, by age range, with the trend. If that number falls while intake rises, the process is working. If closures rise while that number holds, the team is clearing the easy work and the exposure has not moved.

Where Tamnoon fits

Tamnoon takes ownership of closing what your CNAPP finds, and is accountable for production still working afterwards. The engine refuses a fix when the blast radius is not understood, recognizes the ones it has closed before, closes what is safe to close, and remembers the result. What was declined, and why, is kept on the record. The report calls 53% open the baseline for what companies can expect from manual remediation. Tamnoon exists to move that number.

Questions cloud security leaders ask about remediation SLAs

How do I reduce our CNAPP alert backlog and meet remediation SLAs?

Measure the backlog by age, fix Crown Jewel assets first, name one owner per category, and set SLAs from your own measured close times. Tamnoon is the remediation layer on top of the CNAPP you already have, and the process above is how we recommend running it.

What is a realistic SLA for critical cloud findings?

The 2026 dataset average is 150 days from open to close for critical alerts. A realistic SLA starts from your own median per category and tightens each quarter, rather than from a fixed number copied from a policy template that the current team has never met.

What should mean time to remediate be measured against?

Against your own SLA per category and severity, and against the age of what is still open. The report shows closure rates rising while the open share stays near 53%, because the easy work is closed first.

Who should own vulnerability remediation?

One named owner per alert category, with handoffs to engineering, vendor management, legal and finance defined in advance. The remediation gap in the dataset is an unowned-coordination gap more than a technical one.

Which alerts should be automated first?

The configuration detections that recur every year. Six of the top eight misconfigurations are configuration gaps that can be remediated in a sprint, and the top eight together are about 20% of all alerts. Vulnerability rows wait on vendor delivery and keep a person in the loop.

Six questions to answer in under five minutes

If your team cannot answer these quickly, the data does not live where it should and the gap between detection and security is wider than the dashboards suggest.

  • What is our open versus closed alert ratio, and is the open alert backlog growing, flat or shrinking?
  • What is our actual MTTR by severity, and how does that compare to our SLA commitments?
  • Which categories close slowest, and who owns them end to end?
  • Which misconfigurations, code and container vulnerabilities contribute the most volume to the open backlog?
  • What share of our open alerts touch Crown Jewel assets, and is that share rising?
  • Where is shift-left preventing new alerts, and where is the same misconfiguration being introduced repeatedly?

The category close times and the top misconfigurations are in the State of Cloud Remediation 2026. The SLA method above is our recommendation.

Notes from the Healing Gap.

Teardowns, CTF write-ups and field notes from the people who close cloud findings for a living.

You're subscribed.

That did not go through. Try again in a minute.

At most one email a month. Unsubscribe from any of them.