How should IT teams handle emergency patches when a critical vulnerability drops?

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.