30/60/90 Days Is the Wrong Metric for AI-Era Vulnerability Remediation

The 30/60/90-day vulnerability remediation SLA has been a fixture in GRC programs for over a decade. Critical vulnerabilities get patched in 30 days. High severity in 60. Medium in 90. The logic was sound when it was built: attackers needed time to find, analyze, and weaponize a disclosed vulnerability. The SLA window was designed to close the gap before exploitation became likely.

That gap is compressing rapidly. And most GRC programs have not caught up.

Key Takeaways

• The 30/60/90-day vulnerability remediation SLA was calibrated for manual attacker timelines that AI has fundamentally shortened

• Mean time to exploit (MTTE) for critical disclosed vulnerabilities is now measured in days or hours, not weeks, for widely targeted software

• SOC 2 Trust Services Criterion CC7.1 monitoring that surfaces issues on a weekly cadence is a structural gap when exploitation windows are hours

• Continuous controls monitoring (CCM) shifts from a maturity aspiration to a minimum viable posture when detection-to-action time is the constraint

• AI gives defenders real tools: faster threat modeling, LLM-assisted remediation triage, and detection logic that can be written and deployed in hours

• GRC programs built around annual audits are measuring control health at the wrong frequency for the current threat environment

How the 30/60/90 Model Was Built

The tiered SLA framework emerged from a reasonable operational premise. Exploitation of disclosed vulnerabilities required a chain of attacker work: find the CVE, understand the affected software, develop a working exploit, identify exposed targets, and execute. That chain took time. The 30/60/90 model was an attempt to outrun the chain.

The model also reflected what teams could actually do. Patch deployment at scale requires testing, change management approval, scheduling maintenance windows, and coordinating across teams. A 30-day window for critical findings was operationally aggressive when most of that work was manual. The 60 and 90-day tiers gave lower-priority findings room to work through the pipeline without creating constant emergencies.

The model was right for its moment. The problem is that the threat side of the equation has changed faster than the response side.

What AI Has Done to Attacker Timelines

AI-assisted tooling has changed the economics of exploit development. Analyzing a Common Vulnerabilities and Exposures (CVE) disclosure, identifying affected software versions, generating proof-of-concept exploit code, and scanning for exposed targets are all tasks that AI can assist with at a speed that manual analysis cannot match.

The mean time to exploit (MTTE) for disclosed vulnerabilities has collapsed. Mandiant's M-Trends 2026 documents a mean TTE of negative seven days and exploitation of high-value vulnerabilities now routinely begins before vendors issue patches. The CISA Known Exploited Vulnerabilities (KEV) catalog provides ongoing tracking of actively exploited CVEs and is worth bookmarking as a reference for prioritization decisions.

The SLA model was calibrated to a different attacker timeline. If exploitation begins within 48 hours of disclosure for a critical finding, a 30-day remediation SLA does not create a window. It concedes one.

What This Means for CC7.1

SOC 2 Trust Services Criterion CC7.1 covers detection procedures for identifying configuration changes and new vulnerabilities that could affect the security of the system. In practice, this is where vulnerability scanning cadence, detection coverage, and SLA documentation should appear.

Most CC7.1 sections document what the team does. Fewer document whether that cadence is calibrated to the actual exploitation timeline for the systems they run.

If your vulnerability scanner runs weekly and your critical remediation SLA is 30 days, your detection-to-triage pipeline was designed around a threat model with more lead time than you currently have. The control may pass an audit. It may not match the window available for the most-targeted classes of vulnerability in your environment.

This is the structural gap most GRC programs have not surfaced: the SLA was set for a different risk environment, it still passes the control test, and no one has reviewed it because audits measure whether the SLA exists, not whether it is still calibrated correctly.

The right question to answer in a CC7.1 section is not "do we have a scanning cadence?" It is: how quickly does a disclosed critical CVE appear in our detection pipeline, and what is the maximum time between disclosure and a remediation action being assigned to an owner? That specificity is evidence. The absence of it is a gap dressed as a control.

Defenders Get Capability Too

The same AI acceleration that compresses attacker timelines also gives defenders leverage, and it is worth being specific about what that looks like in practice.

LLM-assisted threat modeling allows security teams to generate attack surface analysis for a new system component in an afternoon rather than a week. Detection rules that previously required a senior analyst working from scratch can now be drafted, tested against sample log data, and iterated on in hours. Remediation guidance for a specific CVE can include vendor-specific configuration steps, compensating controls, and a rollback procedure generated from the CVE advisory and the organization's system inventory, reducing the time from "we know about this" to "an engineer has what they need to fix it."

The defenders who use AI effectively treat it as a force multiplier on analyst judgment, not a replacement for it. Triage decisions still require a human. Detection logic still needs review before it fires in production. But the bottleneck shifts: from "can we generate the rule?" to "can we make the right call about whether it applies here?"

For GRC programs, the implication is not whether to use AI in detection and response workflows. It is whether the program is structured to deploy and iterate quickly enough to extract the advantage.

What an Engineered Response Looks Like

Adapting to compressed exploitation timelines requires changes to three specific things.

SLA Windows Need a Review Cadence

A 30/60/90-day SLA that was set two or three years ago has not been updated for the current threat model. Build SLA review into the annual risk assessment cycle. The question is not just "do we have SLAs?" It is: "are these windows calibrated to what we know about exploitation timelines for the vulnerability classes relevant to the systems we operate?" An SLA that has never been revisited is not a risk decision. It is a default that became a policy.

CC7.1 Coverage Needs to Specify Cadence and Scope

A monitoring section that says "vulnerability scans are conducted on a regular basis" does not answer the questions that matter: what is the detection latency from disclosure to triage, what percentage of production systems are covered by real-time scanning versus scheduled scans, and how does the team handle zero-day disclosures between scheduled scan windows? Vague coverage language passes the control test. Specific cadence language, tied to the actual exploitation timelines for your environment, is what makes the control defensible.

Continuous Monitoring Is Now the Baseline, Not the Aspiration

GRC programs built around annual audit cycles measure control health at the frequency that works for auditors. That frequency does not match the threat environment for organizations where exploitation windows are hours. Continuous controls monitoring (CCM), where detection state is evaluated on demand rather than once a year, is not a premium capability for high-maturity programs. It is the operating model that makes the other two changes above possible: you cannot compress your response time if you are not continuously aware of your detection state.

The AI advantage is real on both sides of this. Programs that close the gap will be the ones that treat AI as an engineering problem, not an awareness campaign.

Make Your GRC Program Fast Enough to Matter

Evidence collected once a year describes a program at its best. Rippling Automated Compliance generates evidence continuously from the same systems that run your operations. Monitors for CC7.1 are SLA-aware and surface issues as they happen, not at the next scheduled scan or the next audit window. Remediation workflows route findings to owners with context, expected resolution timelines, and in-platform guidance, so the time from detection to action shrinks without adding headcount. When exploitation windows compress, your compliance program already moves at the speed your security team needs.

FAQ