How should IT teams handle emergency patches for critical vulnerabilities?
· 5 min read
Treat an emergency patch as an emergency change: triage the risk fast, agree the fast path in advance, test as far as the clock allows and keep a remediation plan.
In brief
When a critical vulnerability lands, the safest approach is to treat the patch as an emergency change rather than a reason to abandon change control. Start by deciding whether it really is an emergency. Ask whether you run the affected software anywhere, including shadow IT and supplier managed systems, whether those systems are reachable from the internet, whether the flaw is being exploited in the wild, and whether exploitation could be automated and give an attacker control. The UK National Cyber Security Centre recommends this kind of triage. If most answers are yes, use the emergency path. If not, patch through normal change, sooner than usual if you wish. Agree the emergency path before you need it: who can declare and authorise an emergency change out of hours, what minimum evidence is needed, how it links to your incident process and what is recorded afterwards. John Sansbury, in The Journey to Service Excellence, argues that emergency changes are for genuine threats such as security issues, never a cover for poor planning, and that they still need testing and a remediation plan. Testing can be compressed rather than skipped: patch less critical systems first, move through your usual update rings quickly, and mitigate at the firewall or by disabling the vulnerable component if you cannot patch safely yet. Afterwards, check for compromise, record the change and review what slowed you down, so the next emergency goes more smoothly. The article includes a worked example and the common mistakes to avoid.
Treat an emergency patch as an emergency change, not as a break from change control: decide fast, test as much as the clock allows, have a remediation plan, and record it all. The teams that cope best are not the ones that drop everything and hope; they agreed the rules for a fast path before the vulnerability arrived.
This question comes up every time a critical vulnerability lands, and it came up again this week after the PHP security issues. Answers range from rehearsed protocols to patching at once and waiting to see what breaks. Here is a practical middle path.
Decide whether it really is an emergency
Most new vulnerabilities do not justify an emergency change. A handful of questions sort them quickly:
1. Do we run the affected software at all, including on shadow IT, developer kit and supplier-managed systems? 2. Is the affected system reachable from the internet? 3. Is the vulnerability being exploited in the wild, or listed in the CISA Known Exploited Vulnerabilities catalogue? 4. Could exploitation be automated, and would it give an attacker control of the system?
The UK National Cyber Security Centre (NCSC) guidance on responding to active exploitation uses this kind of triage and recommends CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree to set the speed of action. Where the answers are mostly yes, you have an emergency. If mostly no, the patch goes through normal change, sooner if you like.
Agree the fast path in advance
John Sansbury, in The Journey to Service Excellence, names a security threat as one of the two main circumstances for an emergency change, and says each permissible circumstance should be documented in your change management policy. He is also blunt about the line not to cross: "Emergency changes should never be used as a proxy for an ‘urgent’ change, which simply implies a lack of planning."
So write the fast path down now, while things are calm:
- Who can declare an emergency change, and who authorises it out of hours. One named person per decision, with a deputy. - The minimum evidence needed: the vendor advisory, the systems affected, the exposure, the plan. - How it links to your incident process. The NCSC suggests managing the response through your existing IT incident process, because the on-call rotas and governance should already be in place. - What gets recorded afterwards, and when the post-implementation review happens.
Test as far as the clock allows
Emergency does not mean untested. John's position is that "Conventional wisdom is that all normal and emergency changes should both be successfully tested prior to approval and have a remediation plan." He adds a useful point for patching: "This used to be called a back-out plan, but it is not always possible to back out of a change; sometimes it is necessary to move forwards."
In practice that means compressed testing, not skipped testing. The NCSC suggests updating systems that are not business-critical first and following your normal update rings on a greatly accelerated timeline, perhaps only minutes between rings. If you cannot patch safely yet, mitigate: restrict access at the firewall, disable the vulnerable component, or limit access to your own IP range, and say so in the change record.
A short worked example
Take a hypothetical mid-sized organisation that learns on a Tuesday afternoon of a critical flaw, under active exploitation, in a widely used web component. The service desk lead checks the asset list and finds it on two internet-facing portals and one internal reporting server. The two portals meet the emergency criteria; the internal server does not.
The named change authority approves an emergency change for the portals within the hour. The team blocks external access to the vulnerable path at the firewall straight away, patches the less critical portal first, checks it, then patches the main one. The remediation plan is a known-good snapshot plus a forward fix from the vendor if needed. Security checks for compromise in parallel. The internal server is patched two days later through a normal change. On Friday the team reviews what slowed them down and adds one new step to the policy.
Common mistakes
- Calling every patch an emergency, so the fast path becomes the normal path and control quietly disappears. - No named decision maker out of hours, so the first hour is lost to finding someone. - Not knowing where the software runs. The NCSC warns that organisations may not even know they are running the affected software. - Treating the patch as the finish line. Check for compromise, record the change and review it. - Never rehearsing. Walking through last month's vulnerability costs an hour.
Where to go next
If your change policy does not yet separate standard, normal and emergency changes clearly, start there. The Exchange article Standard, Normal and Emergency Changes (https://exchange.esm.institute/knowledge/standard-normal-and-emergency-changes) sets out proportionate controls for each type, and you can ask me follow-up questions on the Exchange.
For the change enablement practice itself, PeopleCert describes its focus as maximising successful changes "by ensuring that risks have been accurately assessed, authorising changes, and managing change schedules". The emergency path does the same job, faster.
The quotations above are from The Journey to Service Excellence by John Sansbury, which covers operational change management, emergency changes and remediation planning in depth. The book is available to members of ESM's Exchange, so joining is the simplest way to read it.
Tags: esm-questions, change-management, emergency-change, patching, vulnerability-management, itil
Sources
- https://www.ncsc.gov.uk/collection/vulnerability-management/guidance/responding-to-active-exploitation
- https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave
- https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-change-enablement-3794
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- https://exchange.esm.institute/knowledge/standard-normal-and-emergency-changes
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
When the human in the loop becomes a rubber stamp: what UK regulators found about AI checks
5 min read
10 scheduled AI tasks for service management teams
8 min read
Boards expect AI savings: why almost no organisation is finding them
5 min read
AI rebounding: why some employers are asking back the people AI replaced
5 min read
AI Job Cuts and the Unfilled Role: Where Should Freed Capacity Go?
4 min read
AI and Middle Managers: Who Checks the Work When the Middle Thins?
5 min read
Related articles
When the human in the loop becomes a rubber stamp: what UK regulators found about AI checks
The Bank of England and FCA find most firms approve AI before launch but far fewer keep watching it, and the FCA warns human review can become a tick-box exercise. What leaders should check, and which toolkit tools help.
Boards expect AI savings: why almost no organisation is finding them
Gartner finds 77% of board members expect AI to deliver savings, but only 3% of organisations beat their savings goals through productivity. What leaders should agree instead, and which toolkit tools help.
AI rebounding: why some employers are asking back the people AI replaced
New SHL research finds some UK and US workers replaced by AI were later asked back. Why it happens, and how leaders can understand the work before automating it.
AI Job Cuts and the Unfilled Role: Where Should Freed Capacity Go?
Barclays' AI-assisted job cuts and a quieter freeze on junior hiring raise one leadership question: when AI frees capacity, who decides where it goes before the spreadsheet decides for you?
AI and Middle Managers: Who Checks the Work When the Middle Thins?
New Conference Board research shows managers are being asked to check a flood of AI output just as many organisations expect to need fewer of them. What it means for leaders, and the toolkit tools that help.
The AI confidence gap: why UK leaders and their teams see different futures
New Microsoft research finds 84% of UK leaders are confident about Britain's AI future but only 41% of employees agree. Here is what that gap means for leaders, and four practical ways to close it.