Photo by Christopher Gower on Unsplash
Most small businesses treat software updates the same way they treat filing cabinet maintenance. Something to do eventually, when things are quiet, probably on a Friday afternoon. For most of the last two decades, that approach was imperfect but survivable. That is no longer the case. The comfortable gap that used to exist between a security vulnerability being made public and attackers actually using it has shrunk so dramatically that for many flaws, that gap is now measured in hours rather than weeks.
What the grace period actually was
Security researchers and IT teams used to work with a reasonable mental model: when a software flaw was published, there was a stretch of time before attackers built working exploits, tested them, and started scanning the internet for vulnerable targets. That window gave businesses time to read the advisory, understand the risk, test the patch in a safe environment, and roll it out without panic.
That model shaped how most small businesses still think about updates today. It is also the reason so many businesses have a policy that amounts to patching when someone gets round to it.
Why that window no longer exists
Two things have changed the picture fundamentally. First, automated scanning tools can probe every internet-connected system on the planet within hours of a CVE number being published. Attackers no longer need a team of researchers studying a vulnerability and hand-crafting an exploit. They point a tool at the internet and let it work.
Second, AI-assisted exploit development has collapsed the time it takes to turn a published vulnerability description into working attack code. What used to require days of skilled reverse engineering can now happen in a fraction of that time. We have already written about how AI is compressing the gap between a discovered flaw and an active attack, and the picture has continued to sharpen since then.
The result is that the grace period businesses relied on is no longer a reliable feature of how security works. In some recent high-profile cases, exploitation began before patches had even reached the public download servers.
Why small businesses feel this differently
A large organisation with a security operations centre watching traffic in real time at least has a chance of catching an exploitation attempt as it happens. Most small businesses have none of that infrastructure. There is no dashboard showing which systems are unpatched, no alert when an automated scanner probes a known vulnerability on a business firewall, and no one watching logs at 2am when the attack actually runs.
This creates a specific problem: you will often not know a system has been compromised until something visibly breaks, or until data shows up somewhere it should not. By then, the attacker has already had time to move. The pattern of attackers being inside before a patch even arrived is not an edge case any more. It is a pattern.
There is also a practical insurance consideration. Cyber insurers increasingly look at patch history when a claim comes in. A known vulnerability that had a patch available and was not applied is the kind of detail that can complicate a claim significantly.
What actually makes a difference
Automated, managed patching
Enabling automatic updates on individual machines is not the same thing as having proper patch management. Real patch management covers operating systems, third-party applications, browser components, and firmware, gives you a central view of what is current and what is not, and applies updates on a schedule that reflects actual risk rather than user convenience. Automated patch management does the heavy lifting without relying on someone to remember to click update.
Knowing what you are actually running
You cannot patch what you do not know is there. Shadow IT, legacy applications, and forgotten internet-facing services are exactly what automated scanners look for. Vulnerability scanning gives you a regular, accurate picture of your exposed surface so you are not discovering it the same moment an attacker does.
Prioritising by actual exposure
Not every patch carries the same urgency. A vulnerability in software that faces the open internet is a different risk level from one in an internal tool that nothing outside your office can reach. Understanding that distinction lets you focus effort on the things that matter most, rather than treating every update as equally optional or equally critical.
The practical takeaway
The shift here did not happen overnight, which is part of why the old mental model has persisted. But the gap between when a flaw is known and when attackers act on it has closed to a point where the Friday afternoon update schedule is a genuine business risk, not just a best practice you have not got round to yet.
The most useful first step is getting a clear, honest picture of what software is running across your business and how current it actually is. If that picture does not currently exist, or if patching depends on someone manually working through a list, that is the conversation worth having before an incident forces it.