Somewhere in the UK right now, a small business owner is staring at a list of security patches and wondering which ones they can safely ignore. The honest answer is: some of them. But working out which ones requires a completely different way of thinking about this problem than most businesses currently use.
A quiet but significant change in how vulnerabilities get communicated
The US Cybersecurity and Infrastructure Security Agency, better known as CISA, recently stopped publishing its weekly vulnerability bulletin. That bulletin had been running for years, listing newly disclosed software flaws and encouraging organisations to review and patch them. The reason it has been dropped is not that vulnerabilities have become less of a problem. It is the opposite. The volume of newly disclosed flaws has grown so large that a flat weekly list has become more noise than useful signal.
CISA is now focusing its communications on vulnerabilities where there is confirmed evidence of real-world exploitation, meaning flaws that attackers are actively using against real targets right now. The shift is from "here is everything that could theoretically be exploited" to "here is what is actually being used against people." That is a meaningful distinction, and it is one that UK small businesses should apply directly to how they manage their own patching.
The scale of the problem makes any blanket approach unworkable
More than 28,000 new security vulnerabilities were publicly disclosed in 2023. That number has grown year on year. No small business, and frankly no large one, can meaningfully respond to every single disclosure. Businesses that try to patch everything the instant it lands often create their own problems: rushed updates that break systems, staff time consumed by an endless treadmill, and genuine risks buried under routine noise.
But the businesses that take the opposite approach and treat patching as something to deal with when something breaks are taking an entirely different kind of risk. Unpatched systems remain one of the most consistent ways attackers get a foothold. As we covered when looking at critical software flaws in business systems, the gap between a flaw being disclosed and it being actively used in attacks has shortened considerably in recent years.
The answer is not more patching or less patching. It is smarter patching.
What risk-based thinking actually looks like in practice
Risk-based vulnerability management means asking a different set of questions rather than simply "has a patch been released?" The three that matter most are:
- Is this vulnerability being actively exploited? A theoretical flaw with no confirmed use in the wild sits in a very different priority bucket from one that criminal groups have been deploying against real targets this week.
- Does the affected software actually run in your business? A critical vulnerability in an application you have never installed is not your problem to address urgently. Knowing what is on your network is a prerequisite for making this call correctly.
- What could actually happen if someone exploited it? A flaw that might let an attacker read one low-sensitivity file is a different conversation from one that could hand them administrative control of your entire system.
This is the logic that CISA has now formalised for its own public communications. It is also the logic that well-designed vulnerability management programmes have been built on for years.
What this means for a business that does not have a dedicated IT security team
For most small businesses, this translates into three practical things.
First, routine patches should be applied consistently. Operating system updates, browser updates, and standard software should not be left to accumulate. Automated patch management handles this without relying on someone to remember, and it takes the routine risk off the table without consuming significant time.
Second, knowing what is actually running on your network matters more than most businesses appreciate. You cannot make informed decisions about risk from software you did not realise was installed. A vulnerability scan maps your real exposure rather than a theoretical one, and surfaces the things that need attention before an attacker finds them first.
Third, when a high-severity vulnerability is confirmed to be under active exploitation, that one genuinely does need fast attention. These are the disclosures that appear in the news, get named, and come with confirmed reports of attacks happening right now. That category is far smaller than the full list of disclosed vulnerabilities, and treating it with appropriate urgency while handling the routine stuff automatically is how the balance works.
The broader lesson from CISA's change
CISA's decision is not a signal that vulnerabilities matter less. It is an acknowledgement that treating every disclosed flaw with identical urgency is not a security strategy, it is a route to paralysis. The organisations that manage this well are not the ones trying to respond to everything at once. They are the ones that know their own systems well enough to understand which vulnerabilities actually apply to them, and have consistent processes for handling the routine work so that genuine alerts do not get lost in background noise.
If your current approach to patching sits somewhere between "we try to do everything" and "we deal with it when something goes wrong," there is a more sustainable middle ground. Start by understanding what is running on your systems, automate the routine patching, and get a clearer picture of where your real exposures are. That is what vulnerability management looks like when it is working properly.