AI has broken the traditional vulnerability management playbook. The numbers are no longer a trend. They're a structural break. And the GRC programmes still running on the old model are the...
AI has broken the traditional vulnerability management playbook. The numbers are no longer a trend. They’re a structural break. And the GRC programmes still running on the old model are the ones most exposed to it.
Here’s the number that should be on every risk committee agenda right now.
Mandiant’s M-Trends 2026 finds the mean time to exploit a given vulnerability is now an estimated negative seven days, meaning exploitation is routinely occurring before a patch is even released.
Read that again. Negative seven days.
The traditional vulnerability management playbook was built on a simple assumption: you have time. A vulnerability is disclosed. You have days, maybe weeks, to assess it, prioritise it, and patch it before an attacker weaponises it.
That assumption is gone.
By early 2026, AI-assisted exploit development has reduced the average time-to-exploit to under 12 hours with exploits often appearing before patches, detection signatures, or risk assessments.
FIRST forecasts a record 59,000 CVEs in 2026, one every nine minutes.
One vulnerability. Every nine minutes. Exploitable, in some cases, before anyone has had a chance to assess it.
This is not a cybersecurity problem with a GRC footnote. This is a fundamental challenge to how risk programmes are designed, how compliance evidence is structured, and how boards are briefed. GRC leaders who treat this as a technical update to pass to the CISO are missing the governance implication entirely.
The volume problem didn’t arrive alone. It arrived with a complexity problem that makes volume even harder to manage.
AI-generated code produces 2.74x more security vulnerabilities than human-written code, according to CodeRabbit’s 2025 State of AI vs. Human Code Generation report. Georgia Tech’s Vibe Security Radar identified 56 CVEs linked to AI-generated code in the first quarter of 2026 alone.
AI-related CVEs surged 34.6% year-over-year to 2,130 disclosed in 2025 alone with projections suggesting between 2,800 and 3,600 AI CVEs in 2026.
Only 23% of organisations have AI-specific incident response plans, despite 78% having AI in production.
This is the governance gap. AI is already inside your enterprise inside your code, your models, your vendor stack. And most risk programmes have no structured response plan for when it fails.
The old playbook optimised for one thing: patch velocity. Find it, assess it, fix it. That linear model assumes you have enough time between discovery and exploitation to work through the sequence.
You don’t anymore. What’s needed instead is a fundamentally different architecture one that operates across three velocities simultaneously.
Traditional vulnerability programmes run periodic scans. Monthly. Quarterly. Sometimes annually for certain asset classes.
CVE submissions to the NVD increased 263% between 2020 and 2025. The first quarter of 2026 is already running nearly one-third ahead of the same period last year.
Periodic scanning against a surface growing at this rate produces a snapshot of a landscape that has already moved on. GRC programmes need to shift from scheduled discovery to continuous monitoring where the vulnerability inventory is live, not compiled on a cadence that made sense in 2019.
This isn’t an IT architecture decision. It’s a governance decision. What your risk register reflects about your current exposure is a board accountability question.
In 2025, mean time to remediation dropped by approximately 47% across all severity levels showing that the industry is moving toward continuous security validation.
But speed of remediation is only valuable if the right vulnerabilities are being remediated first. With 48,000+ CVEs per year, roughly 133 new vulnerabilities disclosed every single day, manual triage at any meaningful scale is impossible.
AI-powered triage tools now allow organisations to score vulnerabilities not just by CVSS severity, but by exploitability probability, asset criticality, regulatory exposure, and business impact in real time.
For GRC leaders, the governance question is: what is your triage methodology, and can you evidence it to an auditor? A programme that patches randomly or by severity alone, without a documented risk-weighting methodology, will not satisfy the scrutiny now coming from regulators.
Traditional vulnerability management programmes set patch timelines by severity category. Critical: 7 days. High: 30 days. Medium: 90 days. These timelines were reasonable when they were set. They are not reasonable now.
Vulnerability exploitation now drives 20% of breaches, up 34% year-over-year, with edge-device and VPN exploitation rising roughly 8x to 22% of initial-access cases.
GRC programmes need to move from compliance-driven patch timelines to threat-driven SLAs, where the timeline is set by the current exploitability of a vulnerability, not by its CVSS score alone. That requires integrating threat intelligence into patch prioritisation in real time, not as a quarterly review exercise.
For GRC leaders broadly: The compliance evidence challenge is now as significant as the operational one. If an AI finds thousands of vulnerabilities, even a 5% false-positive rate generates hundreds of ghost issues that consume analyst time, dilute attention from real risks, and create compliance-evidence headaches during audits. Your audit trail for vulnerability management needs to demonstrate a structured triage methodology, not just a list of patches applied.
For BFSI organisations: The regulatory implications are direct and named. DORA’s ICT risk management requirements explicitly cover vulnerability management, requiring documented processes, evidence of continuous monitoring, and demonstrable patch timelines. RBI’s IT framework and the CBUAE’s cyber security guidelines carry similar expectations. The CISA Known Exploited Vulnerabilities catalog grew 20% to 1,484 entries in 2025, with 245 added in the year and 24 explicitly tagged as ransomware-exploited. A bank that cannot evidence how it monitors and responds to entries on this catalog has a regulatory exposure, not just a security one.
For Escrow and custody platforms: The risk profile here is specific and acute. Vulnerabilities in the codebase underpinning custody logic, settlement processing, or transaction reconciliation are not just security failures, they are potential integrity failures with direct financial and legal consequences. AI-generated code produces 2.74x more security vulnerabilities than human-written code. Any escrow platform that has accelerated development velocity using AI-assisted coding tools without a corresponding increase in security review rigour has introduced a structural risk into its own codebase that standard vulnerability scanning may not fully surface.
This is the section to forward to your risk committee chair.
Three questions that should be on the agenda, with answers ready:
1. What is our current mean time to patch for actively exploited vulnerabilities and is that timeline still defensible given current exploit development speeds? If the answer is “we use CVSS-based categories set three years ago,” the methodology needs updating before the regulator asks the same question.
2. Do we have a documented, evidenced triage methodology that distinguishes between CVEs by exploitability and business impact not just severity score? FIRST’s lead researcher Éireann Leverett notes: “The difference between preparing for 30,000 vulnerabilities and 100,000 is not merely operational, it’s strategic.” Your board needs to understand which end of that spectrum your programme is designed for.
3. What is our AI-specific vulnerability posture and does our incident response plan cover AI system failures? Only 23% of organisations have AI-specific incident response plans, despite 78% having AI in production. If your board hasn’t been briefed on this gap specifically, Q3 is the time.
The vulnerability management playbook that served GRC programmes for the last decade assumed a world where discovery preceded exploitation, and where volume was manageable by a skilled team working systematically through a queue.
That world ended. The organisations that recognise this earliest and rebuild their risk architecture around the three velocity shifts are the ones that will satisfy regulators, protect operations, and brief boards with the confidence that comes from a programme genuinely designed for 2026, not inherited from 2019.
