Surviving CERT-In's 12-Hour SLA Without Mythos
This blog is a summary of talk held by Qualys titled Surviving CERT-In's 12-Hour SLA Without Mythos on 1st July 2026.
Picture this: your security team closes 40,000 more vulnerability tickets this year than last year. On paper, that's a win. The charts trend the right way, the quarterly review goes smoothly, everyone claps.
Except attackers didn't get 40,000 fewer ways in. If anything, they got more.
That's not a rhetorical setup. It's what the numbers actually show. Research analyzing over a billion resolved vulnerability records tracked against the US government's Known Exploited Vulnerabilities (KEV) catalog, spanning more than 10,000 organizations from 2022 to 2025, found that the sheer volume of vulnerabilities closed grew 6.5x, from 73 million in 2022 to 473 million in 2025. Risk didn't shrink to match it. The share of critical vulnerabilities still sitting open a week after discovery actually rose, from 56% to 63%.1
Read that twice. Teams are working harder than ever and losing ground.
Closing Tickets Isn't the Same as Closing Risk
Here's the quiet lie most vulnerability management programs run on: a closed ticket means the problem is gone. It usually doesn't. A patch can get deployed and still leave the underlying attack path wide open. A "critical" CVE score can flag a system nobody could actually exploit, while a "medium" sits ignored on the one server an attacker cares about most.
CVSS tells you how bad a flaw could theoretically be. It says nothing about whether anyone can actually reach it, whether it sits in front of your crown-jewel systems, or whether a threat actor is using it right now. Independent research on the CISA KEV catalog has found that around 12% of confirmed, actively exploited vulnerabilities carry a CVSS score below 7.0, the threshold many organizations use to decide what even gets triaged.2 Treat every finding the same way and you end up busy instead of safe, which is exactly what the 6.5x number above shows happening industry-wide.
There's a second, quieter problem underneath this one: most teams don't actually know what they're protecting in the first place. You can't triage what you can't see. Before prioritization, before remediation, before any of the rest of this, there's a visibility problem that has to get solved first.
You Can't Protect What You Can't See
Most enterprises don't have a clean asset list. Not really. There's a cloud instance a product team spun up without a ticket. An old on-prem box nobody remembers provisioning. A contractor's laptop still sitting on the VPN six months after the contract ended. A shadow AI tool someone installed to "just try it out" that's now quietly connected to internal data.
Real visibility means pulling from everywhere at once, not from a single scanner running a monthly sweep. A serious inventory has to account for:
- Applications and cloud repositories, including the ones spun up outside formal change control
- OT/IoT devices, often invisible to traditional IT scanning
- Internet-facing systems and cloud services, the stuff attackers find first
- On-prem and known IT assets, the traditional core, still worth getting right
- Identity, meaning users, service accounts, and the access tied to each
- Third-party and vendor-connected assets, risk you don't own but still inherit
- Containers and ephemeral workloads, assets that might exist for hours, not months
- Unknown or rogue assets, the ones nobody registered at all
Getting the full picture usually means combining several detection methods too: native agents and scanners, integration with whatever configuration management database the business already runs on, external attack surface scanning to see what the outside world can see, passive sensors to catch unmanaged devices that active scanning misses, and signal pulled from whatever other security tools are already watching pieces of the estate.
None of this matters without business context, though. A raw asset list just tells you what exists. What actually drives prioritization is layering in:
- Business role and criticality: is this system tied to revenue, customer data, or core operations?
- Technical debt: is it running something end-of-life or end-of-support?
- Missing controls: does it have the security tooling it should, or has something quietly been skipped?
Here's what that looks like in practice. Take a single cloud instance running a payment gateway application. As a bare vulnerability finding, it's one line in a spreadsheet, forgettable. Add context and it stops being forgettable fast: this is a Tier 1 critical system tied directly to revenue, it's running an unsupported, end-of-life web server, it has unauthorized remote-access software installed, it has no endpoint detection deployed, and its remote desktop port is exposed to the open internet. That's not a ticket anymore. That's the thing that should be keeping your CISO up at night, and now you actually know it exists.
A mature program also needs to extend that same visibility beyond traditional IT, into a few areas that get overlooked constantly:
- Software supply chain transparency: knowing what's actually inside the software you run and ship, continuously, not just at audit time
- AI system governance: discovering every AI model and workload in use, including shadow AI nobody approved, and testing those systems against adversarial manipulation the same way you'd test any other application
- Application and API security: covering the full lifecycle from code to production, not just the perimeter
- Configuration drift detection: catching the moment a hardened system quietly slides out of its secure baseline
- Identity attack path mapping: finding directory misconfigurations, stale accounts, and privilege escalation chains before someone else does
- Data residency: for regulated markets, knowing exactly where your logs and incident data physically live, and whether that satisfies local law (more on why this specifically matters in India further down)
That's the actual job of prioritization: not ranking CVEs by severity, but ranking exposures, real ones, on real systems, tied to real business consequences.
Risk Is Just Money Wearing a Disguise
Security teams love talking about severity. Boards don't care about severity. They care about money, and honestly, they're right to.
There's a simple way to think about this:
Risk = Time exposed × Severity × What's actually at stake
The variable almost nobody tracks is time, specifically, how long a known, exploitable flaw sits open before someone actually closes it. Call it your window of exposure. It's one of the better predictors of whether your program is working, and most companies have no real idea what theirs is.
Where it lands makes a real difference. Programs built around verified, closed-loop remediation, where a fix isn't considered done until it's re-tested and confirmed, report average exposure windows around 18 days. The typical enterprise, running a standard ticket-and-hope process, sits closer to 67 days.1
Every extra day in that gap isn't just a metric problem. It's a bill waiting to arrive. India recorded the highest average cost of a data breach anywhere in the world in 2025, at ₹22 crore (INR 220 million), a 13% jump from the year before.3 Incidents where shadow AI played a role cost an additional ₹1.79 crore on average, and it was among the top three cost drivers identified in the same research.3 Every day you shave off that exposure window is, quite literally, rupees taken off the table.
If you want your CFO to actually listen in the next budget meeting, stop leading with vulnerability counts. Lead with what an open exposure is costing the business, per day, in currency they recognize. This is the shift a lot of security leaders still haven't made: moving from talking about attack surface to talking about risk surface, measuring cyber risk the same way the rest of the business measures everything else, in terms of probable loss, and reporting it in language a board can act on without a translator.
Prove It's Actually Fixed
Good programs don't stop at "we patched it." They run something closer to a four-step loop:
- Pick what matters, using business criticality and real threat activity, not a raw severity score alone
- Check if it's actually exploitable, by running safe, controlled exploit checks against the real environment, not a lab. The answer should be binary: exploitable here, with these controls, or not
- Weigh the fix carefully, because a bad patch causing an outage is its own kind of risk. Mature programs score patches for reliability, built from a large historical base of prior deployments, before pushing anything out at scale
- Prove the door is shut, by re-testing after remediation and generating real evidence, ideally something tamper-proof, that the exploit path is genuinely closed
That last step is the one almost everyone skips. A closed ticket says a task got done. A verified fix says the risk is gone. Those aren't the same claim, and only one of them should let you sleep at night. The service-level agreement that actually matters isn't "ticket closed." It's "exploit path confirmed closed," and very few programs measure against that bar today.
Manual Remediation Doesn't Scale Anymore
Once you know what to fix, "how" becomes the bottleneck. Most organizations still route every fix through a human decision, and there simply aren't enough hours in the week for that anymore at the volume modern estates generate. A smarter approach maps each exposure to whichever action actually fits, automatically:
- Patch it, across Windows, macOS, Linux, and third-party apps, with zero-touch automation for the low-risk cases and a reliability check before anything ships broadly
- Remove it, uninstalling bloatware or unused software that's quietly widening the attack surface, based on actual usage and dependency data rather than guesswork
- Mitigate it, reducing exposure when no patch exists yet, or when patching carries too much operational risk to push immediately
- Script around it, using pre-built scripts for the messy, recurring cases, or custom ones built for first-party applications that don't fit a standard playbook
- Isolate it, as a genuine last resort, containing a high-risk device from the rest of the network while it gets patched remotely
None of this replaces judgment. It replaces the assumption that every single fix needs a person to manually decide, ticket, assign, chase, and confirm by hand, an assumption that simply doesn't hold up against a 6.5x increase in remediation volume.
AI Is Changing Both Sides of This Fight
It's worth being honest about where AI actually fits into all this, because it cuts both ways.
On the defensive side, mature platforms are increasingly running a mix of AI models rather than betting on one: lightweight, efficient models handling high-volume routine automation, and larger reasoning-focused models brought in for genuinely complex analysis, where cost matters less than getting the right answer. There's also a growing pattern of security vendors partnering directly with AI research labs on distinctly offensive-adjacent use cases, applied defensively: vulnerability research, zero-day discovery, exploit development, malware reverse engineering, and red teaming. Essentially, the same capabilities attackers are developing get pointed inward first, before someone else points them at you.
That same shift is reaching further left into the development pipeline too. AI-assisted static code analysis is increasingly feeding straight into vulnerability management: findings from source code get imported automatically, runtime context gets applied to prioritize what actually matters, and the resulting list gets patched in order of real risk rather than however the code scanner happened to sort it.
The uncomfortable flip side is that attackers are using the same category of tools to move faster too: faster reconnaissance, faster exploit development, more convincing social engineering. This isn't a distant concern either. In May 2026, India's insurance regulator directed every insurer in the country to submit a formal action-taken report on their AI cyber readiness, specifically citing the risk of frontier AI systems being used to accelerate attacks.4 AI hasn't changed what good security fundamentals look like. It's just made the cost of skipping them higher, and the timeline for getting caught shorter.
The Part Most Programs Are Missing: Regulators Want Exactly the Same Thing
This is where it stops being optional.
On July 25, 2025, India's national cybersecurity agency, CERT-In, released a sweeping new set of Comprehensive Cyber Security Audit Policy Guidelines, and they read like someone took everything above and wrote it into law.5 Every organization, public or private, that owns or runs digital systems now has to undergo a full cybersecurity audit of its ICT systems at least once a year. Not a checkbox review. A real one.
A few details matter more than the rest:
- You must maintain a live inventory of every authorized asset, hardware and software both, with proper patch management behind it. Legacy systems can no longer be waved away as "out of scope." They have to be documented, with a formal, signed-off risk exception if they're staying as they are.
- Every finding needs two scores, not one: traditional severity, plus a real-world likelihood-of-exploitation score, mapped back to standard weakness and vulnerability identifiers.6 That's the same "don't just trust the CVSS number" logic good remediation programs already run on, now written into a compliance requirement.
- Audit reports must translate technical findings into business risk for top management. Dashboards and jargon aren't good enough anymore. Risk has to be understandable, and quantifiable, to people who don't read CVE identifiers for a living.
- Senior management now has to review audit scopes, approve remediation actions, and own the security posture directly. There's no more delegating that accountability quietly down to an engineer's backlog.7
- Scope now spans the entire digital estate: IT systems, operational technology, cloud, APIs, databases, source code, and incident response, across development, staging, and production environments alike.
- Software, and increasingly AI, bill-of-materials audits are part of the picture too, checking for transparency and traceability across the supply chain, not just the application layer.
- Non-compliance carries real teeth. Auditors who repeatedly miss things can be suspended from CERT-In's approved list, and organizations remain on the hook under the older, still fully active 2022 Directions running alongside this: 6-hour incident reporting and 180-day log retention.8
Read between the lines and the message is blunt: if you don't already know your assets, understand your real exposure, and can translate it into terms a non-technical executive would sign their name to, you are not audit-ready. You're improvising under a legal deadline, with a compliance officer explaining to the board why they're about to personally attest to risk nobody actually measured.
Organizations that already run mature vulnerability management, with full asset visibility, validated exposure data, and business-risk framing baked into every report, walk into this kind of audit with most of the hard work already done. Everyone else is building the plane while it's already being inspected mid-flight.
And CERT-In isn't the only regulator with a clock running. Indian security leaders answer to a stack, not a single body:
| Regulator | What it actually requires |
|---|---|
| CERT-In | 6-hour incident reporting and 180-day log retention under the 2022 Directions, plus the 2025 audit guidelines above8 |
| DPDP Act | Rules notified in November 2025, with core obligations phasing in through May 2027, carrying its own breach-notification duties9 |
| RBI | IT governance directions for banks and NBFCs requiring a 6-hour initial report plus a 21-day root cause analysis, filed through its Centralised Information Management System10 |
| SEBI | A cyber resilience framework built around anticipate, withstand, contain, recover, and evolve, with mandatory vulnerability assessment and penetration testing11 |
| IRDAI | An AI cyber-readiness action-taken report required from every insurer, due May 20264 |
| NCIIPC | Incident reporting duties for operators of designated critical information infrastructure, layered on top of CERT-In's national reporting clock12 |
The good news, if there is one: every requirement in that stack, asset visibility, exploitability context, business-risk framing, proof of remediation, is exactly what a well-run vulnerability management program produces anyway. Build it for the business case, and you've basically built it for the regulators too. Treat compliance and good security as two separate projects, and you'll end up doing the work twice.
The Basics Still Matter, Even With AI in the Mix
As attackers lean harder on AI to speed things up, the fundamentals don't change. They just get less optional.
- Assume you'll get breached. Build for rapid detection, containment, and recovery, backed by continuous monitoring, network segmentation, solid telemetry, and breach simulations run often enough that they're not a surprise when it's real.
- Trust nothing by default. Strong identity security, micro-segmentation, and conditional access policies that actually monitor sessions in real time, not just at the login screen.
- Layer your defenses. Infrastructure, applications, identities, cloud environments, AI systems, and data loss prevention all need protecting, tied together with integrated monitoring instead of running as disconnected silos.
- Never stop watching. Always-on attack surface monitoring, automated vulnerability scanning, cloud posture assessments, and, critically, immediate validation that a fix actually worked, not just that it was deployed.
Where This Actually Leaves You
Stop measuring your security program by how many tickets it closes. Start measuring it by how few days a real, exploitable risk sits open, what that number is costing you in rupees rather than reputation, and whether you could hand a regulator your asset list tomorrow without flinching.
The regulators just made all three of those mandatory. You might as well get ahead of it.