Your maintenance contract states: "Security patches will be applied during monthly maintenance windows." When signed three years ago, that seemed entirely adequate. Back then, there was a grace period of several weeks between vulnerability disclosure and actual attacks starting.
That underlying premise has shifted. Multiple studies now measure the time from disclosure to working exploit code in hours rather than days. A monthly patching schedule can mean remaining defenseless for up to 29 days in the worst-case scenario.
Many organizations push internal operations to work harder without updating contractual language, but this leaves liability boundaries dangerously ambiguous when an incident occurs.
What the reports of shrinking grace periods actually show
These figures come from several industry reports. Because observation scopes and definitions vary across studies, it is best to view them not as absolute metrics, but as the overall direction of change.
- Some analyses report that the average time to attack dropped from roughly 53 days in 2024 to under 24 hours in 2026
- For approximately 40% of known vulnerabilities, exploitation is observed within hours to days of disclosure
- Cases have been documented where functional exploit code was generated within nine hours of disclosure for certain critical vulnerabilities
Conversely, metrics on the defensive side are moving in the opposite direction. Research indicates the median remediation timeline for exploited vulnerabilities reached 43 days, lengthening from 32 days the previous year. Attackers are getting faster, while defenders are getting slower. This widening gap represents the reality today.
Automated differential analysis powered by AI is cited as a driving factor. Once a patch is released, reverse-engineering "what was broken" by examining "what was fixed" becomes possible. Work that once demanded significant manual labor and time has been radically compressed. While the reality that releasing a fix itself provides hints for attacks is not new, the time required to weaponize it has changed completely.
Applying everything within 24 hours is unrealistic
Even so, revising contracts to mandate applying every patch within 24 hours is unrealistic for most SMBs. Validating stability in staging environments, deploying outside business hours, and preparing rollback procedures—increasing velocity demands proportional operational capacity.
A realistic approach is triaging targets. Dividing them into three tiers is sufficient:
| Classification | Target | Target turnaround |
|---|---|---|
| Emergency | Publicly exposed with confirmed active exploitation | Same-day to 72 hours |
| Routine | Publicly exposed without confirmed exploitation, or internal-only | Next scheduled window |
| Planned | Major updates accompanied by feature changes | Separate project schedule |
The crucial factor is to define "Emergency" not by severity scores alone, but along two axes: "external reachability" and "confirmed active exploitation." Even with a high CVSS score, a vulnerability in an admin portal reachable only internally is not an emergency. Conversely, even with a medium score, an issue being actively exploited on internet-facing servers demands emergency treatment.
These two axes allow evaluation without specialized security expertise. Even companies in the stage of evaluating vulnerability assessments for SMBs should define this classification internally.
Four items to define in agreements
When maintenance is outsourced to external vendors, disputes almost always arise after an incident occurs. The following four items should be settled in advance:
- Emergency patch definition. Who evaluates the two axes mentioned above, and how? Does the vendor decide, or does the client make the call upon receiving a report?
- Turnaround time from notification to patch initiation. Express this in explicit hours, not vague phrases like "promptly." Costs diverge sharply depending on whether coverage is during business hours or 24/7/365, making this the primary pricing pivot in estimates
- Handling operational downtime. When an emergency patch risks causing system downtime, do you wait for approval or deploy first and report afterward? If designed to wait for approval, contracts must specify which party assumes liability during the waiting period
- Scope of coverage. How far does maintenance extend: OS, middleware, or application libraries? Many contracts exclude library updates from scope, which is where real vulnerabilities emerge
Verify the fourth point with particular care. Many websites operating with halted updates actually have an active maintenance contract in place, but the contractual scope covers only server infrastructure while omitting application dependencies entirely.
Faster awareness matters more than faster patching
Before trying to speed up patch application, what works best for most companies is improving detection. Do you have a mechanism in place to find out on the same day when a vulnerability is disclosed for a product your company uses?
If this relies on a weekly email check, even if your contract mandates applying patches within 24 hours, the clock only starts three days later. Before debating patching speed, check the following two points.
First, do you maintain an inventory of the products you use? Servers, middleware, frameworks, and key libraries. Without this list, you cannot determine whether a newly disclosed vulnerability affects your organization.
Second, are notifications being sent to an individual's email address? It is all too common for a notification arriving on an employee's day off to go unread by anyone until Monday. Consolidate these alerts into a shared address or a chat channel.
These two measures cost almost nothing. They are worth doing well before renegotiating contracts.
Increasing frequency introduces a different problem
Increasing patching frequency raises the probability of outages caused by updates breaking things. Increasing speed without anticipating this risk comes at the expense of availability.
The countermeasure is to establish rollback readiness in advance: pre-application snapshots, configuration file backups, and documented rollback procedures. Having these three items enables rapid decisions during emergency patching. Conversely, in an architecture where changes cannot be rolled back, debates over "what to do if applying this breaks the system" recur every time, ultimately causing delays.
When considering how to define SLAs in maintenance contracts, give the presence of rollback procedures equal weight alongside patching turnaround times. In practice, whether speed can be promised depends on this.
What to do next
First, check how "security patches" are defined in your company's maintenance contracts. If wording like "monthly" or "promptly" is used, it is a candidate for review. If specified in hours, evaluate whether that timeframe is sufficient using the categories described above.
Next, verify who receives vulnerability advisories. If they are routed to individual addresses, simply switching to a shared inbox will shorten your effective response time.
GleamHub offers consultations on development, AI, and automation covering maintenance structure design, vulnerability response workflows, and assessing existing system architectures. Because viable options depend on your system configuration and current maintenance setup, please consult with us individually. Reach out via Contact Us.
Sources
- N-day is Becoming N-Hour. Patching Faster Won’t Save You. — The Hacker News
- AI-Driven Vulnerability Surge Breaks the Traditional Patching Model — SecurityWeek
- The Collapsing Exploit Window: AI-Speed Vulnerability Weaponization — Cloud Security Alliance
- When exploits move in hours, patching must move faster — N-able
- AI is shrinking the time to patch software vulnerabilities — Axios
