Most organisations have a regular patching schedule, and for the majority of vulnerabilities, that makes sense.
Updates need testing, maintenance windows need planning and nobody wants to cause an outage while trying to fix a security problem.
But what happens when a vulnerability needs fixing before the next scheduled update?
That’s something I think organisations need to be looking at more closely, particularly as AI starts to change how quickly vulnerabilities can be found and analysed. Earlier this year, Anthropic worked with Mozilla to test Claude Opus 4.6 against Firefox. Over two weeks it found 22 vulnerabilities, 14 of which Mozilla rated high severity.
Finding those vulnerabilities is obviously useful. But from an organisation’s point of view, I’m interested in what happens next. If vulnerabilities are being found faster, are we actually in a position to respond any faster when one affects us?
Because finding the vulnerability is only the first part of the job. Someone still needs to work out whether you use the affected software, where it is, whether it is exposed, whether the vulnerability is exploitable in your environment and what could happen if it was exploited. Then you need to decide how urgently to act and whether the patch itself creates an operational problem.
Think about everything that might need patching across a business. Laptops, desktops and server operating systems are the obvious ones, but there are also browsers, third-party applications, firewalls, network appliances, firmware and specialist systems.
Some may be managed internally, some by an MSP and others may not be actively managed at all!
So, when a serious vulnerability is publicised, one of the first questions is actually quite basic: do we know whether it affects us? And if we do, who is responsible for doing something about it?
Emergency patch management: when the normal timetable doesn’t work
The NCSC’s current vulnerability management guidance recommends completing business-as-usual updates to internet-facing services and software within five days.
Where vulnerabilities are being actively exploited, however, the expected response can be considerably faster. In some circumstances, remediation times fall below 24, 48 or 72 hours.
Those timescales become more difficult when responsibility for patching is split between internal teams, an MSP and other suppliers, particularly if it isn’t clear how an urgent vulnerability would be handled.
If a vulnerability affecting your environment was being actively exploited today, what would actually happen?
Would your MSP know you were affected and tell you, or would you need to raise it with them? Could they patch outside the agreed schedule? Who can approve an emergency change and, if the patch couldn’t safely be applied, who decides what happens instead?
Your MSP may be relying on automatic patching of operating systems while third-party applications sit outside the agreement, network equipment belongs to another supplier and specialist systems are managed elsewhere.
That may work perfectly well during routine patching, but what happens when something fails? Or when something urgent happens and you need to know who owns the system, who can make the change and who verifies that the change has been successful?
The NCSC recommends that organisations have a rapid response pathway for actively exploited vulnerabilities and that arrangements with critical suppliers and MSPs support rapid mitigation where internet-facing systems are being exploited.
For me, that’s the conversation worth having with an MSP. Not just how often they patch, but what they cover, how they verify vulnerability remediation, how they deal with something that can’t wait and where responsibility sits when it falls outside the normal process.
Vulnerability management: not every critical vulnerability is equally critical to you
Not every vulnerability warrants an emergency response, even when the severity score is high.
A critical severity score tells you something about the vulnerability, but I’d want to contextualise this before deciding what we do about it.
Do we use the affected technology, where does it sit, can somebody reach it from the internet, is exploitation already happening and, if an attacker gets through it, what can they reach next?
One vulnerability on an exposed service with a route into something important may matter far more than ten sitting on isolated internal systems.
Patching itself isn’t without risk either. Anyone who has managed live systems knows it isn’t simply a case of pressing an update button. Applications need testing, systems have dependencies and sometimes taking something offline creates a bigger operational problem than leaving it running.
There will be occasions when patching immediately isn’t the right answer. You might isolate a system, restrict access or put another mitigating control in place while an update is tested, particularly where applying the patch immediately creates risk in live systems.
What you don’t want is an actively exploited vulnerability sitting there simply because the next maintenance window isn’t until Tuesday.
What should you ask your MSP about patch management?
If your patching is managed by an MSP, I’d be asking a few questions about how this works in practice.
What exactly are you patching for us? How do you know when a new vulnerability affects our environment? What would make you move outside our normal patching schedule and how quickly could you do it?
Who needs to approve it, what happens if the patch can’t be applied and how do you check afterwards that it has installed everywhere it should?
It’s also worth checking what happens after a patch has been deployed, because devices can be offline, deployments can fail and systems can get missed.
You need to know that the vulnerability has actually been fixed across the systems affected, rather than assuming the deployment itself is the end of the job.
The basics of patch management haven’t really changed. The difference AI could make is the speed at which new vulnerabilities are found and potentially exploited, which puts more pressure on how quickly organisations can work out whether they’re affected and respond.
If I were speaking to an MSP about this, I’d want to see the asset inventory, the latest vulnerability scan and what is still waiting to be remediated. I’d also want to know how they check that patches have been successfully applied.
Because when something does need fixing quickly, that’s probably not the time to discover that nobody is quite sure who’s responsible for it.