What 214 Security Teams Reveal About Vulnerability Backlogs

The Vulnerability Backlog Report 2026 describes a verification problem, not simply a volume problem. In ProjectDiscovery’s survey of 214 security practitioners and leaders, 44% said their teams close or deprioritize findings without full verification because they lack time.

The survey also found that 74% saw their backlog grow over the previous year. These results apply to the surveyed group, not every security organization. Still, they give defenders a useful way to examine where verification capacity is being lost.

• 214Security practitioners and leaders surveyedSource: ProjectDiscovery Vulnerability Backlog Report 2026
• 44%Close or deprioritize some findings without full verificationSource: ProjectDiscovery Vulnerability Backlog Report 2026
• 74%Say their backlog grew over the previous yearSource: ProjectDiscovery Vulnerability Backlog Report 2026
• 72%Worry real vulnerabilities sit unnoticed in the backlogSource: ProjectDiscovery Vulnerability Backlog Report 2026

What the Vulnerability Backlog Report 2026 Measured

ProjectDiscovery commissioned a third-party panel survey between October 20 and 28, 2026. The sample included 100 CISOs or security leaders, 49 security engineering respondents, 28 vulnerability management practitioners, and 17 AppSec or product security practitioners.

The remaining respondents worked in pentesting, red teaming, or other cybersecurity roles. ProjectDiscovery rounded percentages to the nearest whole number. The report does not provide margins of error, sampling weights, regional composition, or response-rate details.

That methodology limits broad conclusions. The data describes reported practices and perceptions among 214 respondents. It does not independently measure how many findings were exploitable or whether any particular workflow caused a better security outcome.

Verification Is Where Volume Becomes Risk

The report found that 86% of respondents said at least one in ten findings proved unreal or not exploitable after triage. Another 38% said more than one-quarter met that description.

Noise alone is not the central finding. Among teams that close or deprioritize findings without full verification, 57% said at least three-quarters of the findings they do triage turn out to be real.

This combination creates a difficult queue. Teams expect some false positives, yet the findings they investigate often prove genuine. A severity label cannot resolve that uncertainty by itself because severity and environmental exploitability answer different questions.

Our threat, vulnerability, and risk explainer separates those concepts. For a backlog owner, verification should connect the technical finding to exposure, reachability, asset importance, and compensating controls.

More Finding Sources Create Reconciliation Work

Seventy-one percent of respondents received findings from at least three sources. The average was slightly above three, while 78% received findings from AI testing tools or agents.

ProjectDiscovery found that teams with at least five sources were nearly twice as likely to close findings without full verification. The reported rates were 63% for teams with five or more sources and 35% for teams with one or two.

• Five or more finding sources63 % closing findings withoSurveyed teams
• One or two finding sources35 % closing findings withoSurveyed teams

Source ProjectDiscovery Vulnerability Backlog Report 2026

The survey shows an association, not proof that extra scanners cause skipped verification. Larger or more complex teams may use more sources and face other constraints. However, each additional queue can introduce duplicate records, different labels, and separate ownership.

Defenders can test this problem directly. Measure duplicate rates across sources, time from intake to ownership, and the share of findings that never reach a verification decision. A common record should preserve source evidence without treating one scanner as the only truth.

Company Size Changes the Scale of the Queue

Backlog scale rose sharply among larger organizations in the survey. Sixty-one percent of respondents at organizations with more than 5,000 employees reported at least 1,000 untriaged findings. About one-quarter reported more than 10,000.

Among organizations with 200 to 5,000 employees, 34% reported at least 1,000 untriaged findings, while 5% reported more than 10,000. The comparison describes company-size groups in this sample rather than a universal benchmark.

Large inventories also complicate ownership. Our attack vector and attack surface guide explains why an exposed path and the full set of assets are different. Backlog work needs both the finding and the asset context.

Time Since Zero Tracks How Teams Feel

The report’s strongest perception split concerned how recently a team cleared its backlog. Only 9% of teams that reached zero in the previous month described their backlog negatively.

That share rose to 21% among teams that reached zero in the previous year and 33% when zero was more than a year ago. Among teams that had never reached zero, 60% described the backlog negatively.

This does not prove that reaching zero improves security. It shows a relationship between recent clearance and how respondents described their workload. A zero count can also hide premature closure unless the organization defines what verified, accepted, and remediated mean.

AI Adds Findings and Triage Capacity

Forty-six percent said AI generated more findings to triage, while 36% said it helped them triage faster. Respondents in the second group were less likely to describe their backlog negatively, at 14% compared with 33% among others.

Again, the survey cannot establish causation. Teams with stronger processes may be more likely to deploy useful automation. The safer operational conclusion is to evaluate automation by decision quality, coverage, and auditability rather than ticket throughput alone.

Fifty-six percent agreed that attackers using AI could reach backlog issues before their teams. That is a respondent perception, not evidence that a specific backlog item was exploited.

What Defenders Should Measure Next

A defender-focused reading of the report starts with verification capacity. Count findings entering each source, the proportion deduplicated, the proportion verified, median decision time, and the age of findings without an owner.

• Map every finding source and accountable owner.
• Measure duplicates before combining queue totals.
• Track time from intake to a verified decision.
• Separate verified false positives from administrative closure.
• Record asset exposure and business context with each decision.
• Review findings that age without evidence or ownership.

Half of respondents said additional headcount would not solve the backlog. That result should not be read as evidence that staffing never matters. It suggests teams should inspect workflow fragmentation, duplicate intake, missing context, and verification effort alongside staffing.

The report’s most defensible lesson is narrow: discovery volume and verification capacity are not the same. A team can add sources and produce more findings while reducing the share it can confidently accept, dismiss, or prioritize.

Method Note

This story uses ProjectDiscovery’s report and public report page. The company surveyed 214 security practitioners and leaders through a third-party panel from October 20 through October 28, 2026. Percentages were rounded to whole numbers.

We treated the survey as vendor-produced research and preserved its limitations. We did not use the report’s secondary news references, present associations as causes, or generalize its percentages to all organizations.

The supplied Brandefense Blackhole count used an overly broad keyword and was not relevant to vulnerability-backlog verification. It was therefore excluded rather than presented as supporting evidence.

For program design, the vulnerability management lifecycle guide provides a broader control sequence for discovery, prioritization, remediation, and review.