Emergency Out-of-Band Patching Procedure
Handles actively exploited vulnerabilities requiring deployment within hours rather than the monthly cycle.
Available soon
- Format
- Word
- Size
- 64 KB
- Length
- 20 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- The clock
- Procedure steps
- When the flaw may already have been used against us
- Services a provider patches
- When the patch cannot be installed within the deadline
- The expedited route
- Outputs and records
- Timing targets
- Escalation
- Worked example: an exploited flaw in the ordering platform
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure says what to do when a vendor patch cannot wait for the monthly cycle. Its main use is the hours after a vendor announces a flaw that attackers are already using: find out which systems are exposed, make the flaw unreachable within P01's 72 hours, test the patch briefly, deploy it within 7 days, prove it worked, and hand over at once to the incident pack if there is any sign the flaw was used against us.
It is the working routine behind rules PM-11 to PM-13 of the Patch Management Standard. The deadlines are the Vulnerability & Exposure Management Standard's, unchanged; the times in this procedure are targets for each step inside them.
Scope
This procedure applies to:
- every Priority 1 patch: an exploited vulnerability on an internet-facing or Critical system (the emergency route, RT-E);
- every patch the monthly cycle would not have installed and verified by its deadline (the expedited route, RT-X);
- services a provider patches for us, where the flaw is exploited (PM-13);
- everyone in the roles below, at any hour.
It does not cover the investigation of a compromise: once there is a sign the flaw was used against us, the [[Security Incident Management Policy]] and its procedures lead, and this procedure serves them. It does not cover weaknesses no vendor patch fixes: the Vulnerability Triage & Remediation Operating Procedure handles those, on the same deadlines.
Roles
Role | What they do in this procedure |
|---|---|
IT Operations Manager [[e.g. IT Operations Manager]] | Runs the procedure: confirms which systems are affected, records first detection, rates and routes, coordinates the mitigation, the test and the deployment, verifies, and writes the review. |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Is told of every Priority 1 at once; rates the flaw with the coordinator; runs or commissions the compromise check; declares nothing, but reports any sign of use as an incident at once (P09 IM-01). |
Head of IT [[e.g. Head of IT]] | Approves the emergency change. Accountable that the deadlines are met. |
On-call approver [[the on-call approver list]] | Approves the emergency change out of hours when the Head of IT cannot be reached, by phone, never for a change they will deploy. |
System owner [[the business owner of each system or service]] | Agrees the time of any deployment that will stop a customer-facing service; checks the service after it. |
Application team [[e.g. the ordering platform team]] | Tests and deploys the patch for applications it runs. |
Service provider [[e.g. managed IT provider]] | Applies the mitigation or the patch where it runs the system; tells us when it cannot fix a flaw in time (P06 CL-08). |
Incident manager [[e.g. Information Security Manager, with a named deputy]] | Takes the lead the moment an incident is declared, and decides from then on whether to patch, isolate or rebuild (P09). |
Guidance — delete before approval
Exploited flaws are often announced late in the week. Put the on-call approver list, the duty engineer and the security monitoring provider's emergency number in one place, and test once a quarter that someone answers out of hours.
Triggers and inputs
What starts this procedure
Trigger | Where it is seen | Who usually sees it first |
|---|---|---|
A vendor's advisory says a flaw in a product we run is being exploited | The vendor's security notices; the vendor's email to customers | IT Operations Manager |
A flaw is added to a list of vulnerabilities known to be exploited | [[e.g. CISA Known Exploited Vulnerabilities catalogue]]; the vulnerability triage | Head of Information Security |
A finding already open is newly reported as exploited, and is re-rated Priority 1 (P01 RM-12) | The vulnerability triage | Head of Information Security |
A provider tells us of a flaw in a service it runs for us (P06 CL-08) | The provider's notice | IT Operations Manager |
The release review finds a Priority 1 fix in the month's releases (CY-02) | The Monthly Patch Cycle Operating Procedure | IT Operations Manager |
Threat intelligence, the monitoring provider or the news reports attacks on a product we run | [[Threat intelligence source; security monitoring provider]] | Anyone: report it to the service desk at once |
Which route
Ask in order, for each affected system, and stop at the first yes.
Question | Yes | No |
|---|---|---|
Is the flaw exploited, and is the system internet-facing or Critical? (Priority 1 in the P01 model.) | Emergency. Steps ES-1 to ES-9 below. An emergency change, approved by the Head of IT or the on-call approver, never by the person deploying it. | Next question. |
Would the monthly cycle have it installed and verified only after the system's P01 deadline? | Expedited. See The expedited route. A normal change, approved by the Head of IT within [[1]] working day. | Monthly cycle. Leave it to the Monthly Patch Cycle Operating Procedure. |
Internet-facing has one meaning in this pack: reachable from the internet, directly or through a published service, without first connecting to the organisation's private network; or reachable from any network the organisation does not fully control, such as partner links, guest Wi-Fi or third-party connections. A flaw that is exploited on an internal system of lower criticality is Priority 2: usually expedited, never left to wait a month.
Inputs
Input | Where it comes from |
|---|---|
Asset inventory: product, version, exposure and criticality of each system | [[Asset inventory; device management tool]] |
The vendor's advisory, with any workaround and indicators of compromise | [[Vendor security notices]] |
The scanner, with the vendor's check for the flaw where there is one | [[Scanning tool]] |
The on-call approver list, the duty engineer and the security monitoring provider's emergency number | [[On-call list]] |
The ring and window plan, for the order of deployment and the redundant pairs | Patch Deployment Ring & Maintenance Window Plan |
The incident reporting route | [[Incident Triage & First-Hour Assessment Procedure]] |
The clock
A Priority 1 patch must take the emergency route: decided within [[4]] hours of the advisory, an emergency change approved by the Head of IT or the on-call approver and never by the person deploying it, the mitigation within 72 hours (P01 VM-09) and the patch within 7 days. Any sign the vulnerability was used against us is reported as an incident at once (P09 IM-01), and the incident manager then leads (PM-11).
P01's clock starts at first detection: the time the scan or the inventory search found the flaw on the system, or the time a finding already open was re-rated Priority 1. It does not start at the advisory, and it does not wait for business hours. Every target below is a step inside P01's 72 hours and 7 days.
Step | Target | |
|---|---|---|
ES-1 | Confirm it applies | [[4]] hours of the advisory, at any hour for internet-facing systems |
ES-2 | Rate and route | [[4]] hours of the advisory |
ES-3 | Look for signs it was used against us | Started no later than the mitigation, and finished before the patch is deployed (ES-7) |
ES-4 | Approve the emergency change | Before the mitigation, unless waiting would let harm spread |
ES-5 | Mitigate | 72 hours of first detection (P01 VM-09), and the same day where possible |
ES-6 | Test briefly | [[2]] hours |
ES-7 | Deploy | 7 days of first detection (P01) |
ES-8 | Verify | Within 1 working day of deployment |
ES-9 | Review | [[5]] working days of closure |
Guidance — delete before approval
The mitigation, not the patch, is what the first day is for. A tested firewall rule or the vendor's workaround in place within hours makes the flaw unreachable while the patch is tested properly. Most organisations that are breached through an exploited flaw had the patch available; few had the mitigation in place.
Procedure steps
Take the steps in order. Where two can run together (the compromise check and the mitigation usually can), do both.
Step | What to do | Who | Within | Output |
|---|---|---|---|---|
ES-1 Confirm it applies | Check the inventory and the scanner for every system running the affected product and version. Record the time of first detection: P01's clock starts there (VM-08), or at the re-rating (RM-12). | IT Operations Manager; on call: [[the duty engineer]] | [[4]] hours of the advisory, at any hour for internet-facing systems | List of affected systems; time of first detection |
ES-2 Rate and route | Rate it with the P01 model. Priority 1 takes this route; tell the Head of Information Security at once (P01). | IT Operations Manager, with the Head of Information Security | [[4]] hours of the advisory | Priority per system; route; security told |
ES-3 Look for signs it was used against us | Run the vendor's indicators of compromise and check the logs of the affected systems. Any sign of use is reported as an incident at once (P09 IM-01); from then on the incident manager leads, and evidence is kept before anything is rebuilt (P09 IM-07). | [[Security monitoring provider]]; Head of Information Security | Started no later than the mitigation, and finished before the patch is deployed (ES-7) | Compromise check result, with what was checked |
ES-4 Approve the emergency change | The Head of IT approves, or the on-call approver by phone, never the person who will deploy it. The approval is recorded on the change within 1 working day. | Head of IT, or the on-call approver | Before the mitigation, unless waiting would let harm spread | Emergency change, approved |
ES-5 Mitigate | Apply the vendor's workaround, a web application firewall rule, a block from the internet, or disable the affected feature or system. | IT operations, or the provider who runs the system | 72 hours of first detection (P01 VM-09), and the same day where possible | Mitigation in place and tested; time recorded |
ES-6 Test briefly | Install on one test or least critical system and check that the service starts and does its main task. | IT operations; the application team | [[2]] hours | Test result |
ES-7 Deploy | Internet-facing systems first, then the rest, one member of a redundant pair at a time. Where the deployment will stop a customer-facing service, the system owner agrees the time first. | IT operations; the system owner agrees the time | 7 days of first detection (P01) | Deployment record, with times |
ES-8 Verify | The four verification checks, with a targeted rescan (PM-10, P01 VM-13). The mitigation stays until the rescan is clean. | IT Operations Manager | Within 1 working day of deployment | Verification record; rescan; mitigation removed or kept |
ES-9 Review | What slowed each step, and what to change. Record the timeline on the change. | IT Operations Manager, with the Head of Information Security | [[5]] working days of closure | Review note on the change; actions |
ES-1 Confirm it applies: in detail
- Search the inventory and the scanner for the affected product and every affected version, including copies inside appliances and applications.
- Run a targeted scan of internet-facing systems at once if the scanner has a check for the flaw.
- Record the first detection on each system as the time the scan or the inventory search found it. If it was already an open finding, its deadline is the earlier of its old one and the new one.
ES-4 Approve the emergency change: in detail
The emergency change replaces the month's standard change for this patch. It is approved before the mitigation starts, unless waiting would let harm spread; then the approval follows within 1 working day.
- In working hours: the Head of IT, in writing.
- Out of hours: the on-call approver on duty, by phone; the coordinator writes the approval on the change with the time, and the approver confirms it in writing within 1 working day.
- Never the person who will deploy it. If the only approver available would also deploy it, the next one on the on-call list approves.
- If nobody on the list answers within [[30 minutes]] and waiting would let harm spread, apply the mitigation without waiting and record why; the approval follows within 1 working day. The patch itself always waits for an approver.
The emergency change records, beyond the organisation's normal change fields:
Field | What to record |
|---|---|
Advisory | Vendor, product, vendor reference, and the time the advisory was published |
Systems | Every affected system, by name, with its exposure and criticality |
First detection | The time on each system: P01's clock starts there |
Priority and deadlines | Priority 1: mitigation due 72 hours and patch due 7 days after first detection, as dates and times |
Signs of use | The compromise check: what was looked at, by whom, when, and the result |
Mitigation | What, on which systems, when it was in place, and how it was tested |
Approval | Who approved, how (in writing or by phone), and when; never the person deploying |
Test | Where it was tested, from and to, and the result (target [[2]] hours) |
Deployment | Each system, the order, start and end times, and the service check |
Verification | The rescan, its time and result, and when the mitigation was removed |
Review | What slowed each step, and the actions agreed |
ES-5 Mitigate: in detail
- Choose the mitigation from the table below. Prefer the one that removes exposure soonest with the least effect on the service.
- Test it: show the vulnerable function can no longer be reached, for example with a request the rule should block, and record the result.
- Record the time the mitigation was in place. P01's 72 hours run from first detection, not from the advisory.
The mitigation options, fastest and least disruptive first:
Mitigation | When it fits | How to test it |
|---|---|---|
The vendor's workaround | The advisory gives one: a setting, a registry change or a feature to turn off | Apply it, then check the setting is in effect and the service still works |
A web application firewall or intrusion prevention rule | The flaw is reached over the web or the network, and the vendor or the firewall supplier publishes a rule | Send a harmless test request the rule should block, and check it is blocked and logged |
Block it from the internet | The system or the vulnerable service does not need to be reached from outside, or only by known addresses | Try to reach it from outside the network, and check the attempt is refused |
Turn off the affected feature or service | The vulnerable part is not essential, or the business agrees to lose it for a few days | Check it no longer answers, and tell its users |
Isolate or take the system offline | None of the above is possible and the system is exposed. A customer-facing service is stopped only on the decision the incident pack sets | Check it can no longer be reached, and record who decided |
ES-7 Deploy: in detail
- Take a snapshot or backup of each system first.
- Deploy internet-facing systems first. Behind a load balancer or cluster, take one node out, patch it, check it, put it back, then the next.
- Run the service check within [[30]] minutes of each restart, and roll back that node if it fails.
When the flaw may already have been used against us
ES-3 starts no later than the mitigation, and finishes before the patch is deployed (ES-7): the mitigation stops new use of the flaw, and the check finds earlier use before anything on the system changes. Look for these signs on every affected system, over the period since the flaw was first exploited anywhere, not only since we learned of it:
- The vendor's indicators of compromise are found on an affected system.
- Files, accounts, scheduled tasks or web pages appear that nobody in IT created.
- The affected system made connections to addresses the advisory or threat feeds name, or that it never normally contacts.
- The monitoring provider alerts on the affected system in the period since the flaw was first exploited anywhere.
- Logs that should exist are missing or were cleared.
Any one of them is reported as an incident at once, through the reporting route: everyone must report a suspected security event at once through the reporting route; nobody is blamed for a report made in good faith (P09 IM-01). The incident manager then leads. The category is IC-06, exploited vulnerability.
What changes when an incident is declared
- The incident manager decides whether to patch, isolate or rebuild; patching a compromised system does not remove an attacker who is already in.
- Evidence is preserved before a system is patched, wiped or rebuilt, unless waiting would let the harm spread (P09 IM-07).
- A decision to stop a customer-facing service is the executive incident lead's, or the incident manager's where waiting would let the harm spread (P09 IM-08).
- The patch still has its P01 deadline, and a restored system returns to service patched, scanned and monitored (P09 recovery criteria).
The rules behind these are the incident pack's: evidence must be preserved before systems are wiped or rebuilt, unless waiting would let the harm spread; who handled it, and when, must be recorded (IM-07). A decision to stop a customer-facing service must be taken by the executive incident lead, or by the incident manager where waiting would let the harm spread; a ransom may only be paid on the decision of the board or its equivalent (IM-08).
Question | Yes | No |
|---|---|---|
Is any sign found at ES-3? | Report an incident now (P09 IM-01). Keep the mitigation. Preserve evidence before patching, unless waiting would let the harm spread. The incident manager decides the rest. | Record what was checked and the result on the change. Continue at ES-6. |
Did the check cover the whole period since the flaw was first exploited anywhere? | Record it. | Extend the check, or record why it could not be, and keep watching the system until the next review. |
Guidance — delete before approval
Patching is not cleaning. If an attacker used the flaw before the patch, they may have left an account, a scheduled task or a web shell that the patch does not remove. That is why ES-3 comes before ES-7, and why the incident manager, not the patch team, decides what happens to a system with signs of use.
Services a provider patches
Where a provider patches a cloud or software service, the contract must carry the vulnerability management clause of the third-party pack (P06 CL-08), and the provider's security notices must be checked every month. The organisation patches its own side: clients, agents, connectors and configuration. For an exploited flaw in a provider's service, the organisation applies its own mitigation within P01's 72 hours while the provider fixes it (PM-13).
Under the clause, the provider must tell us within [[2]] working days of becoming aware of a critical vulnerability that affects the services and cannot be fixed within the period in the clause, with the mitigation it has applied. So when an exploited flaw affects a provider's service:
- Ask the provider, the same day, whether it is affected, what it has done and when it will be fixed.
- Apply our own mitigation within P01's 72 hours if the provider's fix is not confirmed by then: block or restrict access to the service, turn off the affected feature, or enforce stronger sign-in in front of it.
- Patch our side: clients, agents, connectors and configuration, through the emergency route.
- Record the provider's answers and dates on the change. A provider that misses the clause's periods is raised under the contract, and assessed again under the Supplier Security Assessment Procedure.
When the patch cannot be installed within the deadline
A Priority 1 patch that will not be installed within 7 days of first detection needs a deferral, requested before the deadline passes, on the Patch Deferral Request Form (PM-14). It is the one case where the mitigation is not optional:
When | What applies | |
|---|---|---|
DA-1 | Priority 1 | Only once the 72-hour mitigation is in place (P01 VM-09), and approved by the approver of the vulnerability standard (P01 VM-18), or by the band's approver where that approver is more senior. |
The accepted reasons are the standard's (PM-15). For an emergency the usual ones are a patch that failed its test with a confirmed fault (DR-1), and no patch yet from the vendor (DR-4). Until the patch is in, the mitigation stays, the system is watched more closely, and the finding stays open.
The expedited route
A patch whose P01 deadline would pass before the monthly cycle has it installed and verified must take the expedited route: the next window inside its deadline, or an extra window (PM-12). Any patch whose P01 deadline would pass before the cycle has it installed and verified: typically a Priority 2 fix released between cycles (PM-12).
What to do | Who | |
|---|---|---|
1 | At the release review, the patch is routed RT-X: the cycle would not have it installed and verified by the system's deadline. | IT Operations Manager |
2 | Find the next window inside the deadline: a window this cycle that comes earlier, or another system's window the system owner can share. | IT Operations Manager; system owner |
3 | If there is none, ask for an extra window inside the deadline, as a normal change. | IT Operations Manager |
4 | Approve the normal change within the route's approval time. | Head of IT |
5 | Test it as the cycle does: the pilot ring or a test copy, observed for the pilot's working days where the deadline allows; otherwise the emergency route's short test on one system. | IT operations; the application team |
6 | Deploy, verify with a rescan, and record it with the month's deployments. | IT operations; IT Operations Manager |
7 | If no window inside the deadline can be found, the system owner requests a deferral before the deadline passes (PM-14). Workload is not an accepted reason: escalate to the Head of IT for the people instead. | System owner; IT Operations Manager |
An expedited patch can use the emergency window (MW-E): any time the emergency change sets (PM-11), for priority 1 patches, and expedited patches with no window inside their deadline.
Guidance — delete before approval
Expedited patches are usually Priority 2 fixes released between cycles. Look at the next cycle's dates at the release review: if the deadline falls before the last window that would install it, route it now, not when it is already late.
Outputs and records
Output | Step | Held in |
|---|---|---|
List of affected systems and first detection times | ES-1 | Emergency change record |
Priority, route and the time security was told | ES-2 | Emergency change record |
Compromise check result | ES-3 | Emergency change record; the incident case if one is opened |
Approval, with who, how and when | ES-4 | Emergency change record |
Mitigation, its test and time | ES-5 | Emergency change record; the P01 finding |
Test result, deployment record and service checks | ES-6, ES-7 | Emergency change record |
Rescan and the finding closed | ES-8 | Emergency change record; the P01 finding |
Review note and actions | ES-9 | Emergency change record; [[action log]] |
Timing targets
Activity | Target | Basis |
|---|---|---|
Affected systems found and first detection recorded | Within [[4]] hours of the advisory, at any hour for internet-facing systems | ES-1 |
Rated, routed and security told | Within [[4]] hours of the advisory | PM-11; ES-2 |
Emergency change approved | Before the mitigation; recorded within 1 working day | PM-11; ES-4 |
Mitigation in place | Within 72 hours of first detection, and the same day where possible | P01 VM-09; ES-5 |
Short test | [[2]] hours | PM-05; ES-6 |
Patch deployed | Within 7 days of first detection | P01; ES-7 |
Verified with a rescan | Within 1 working day of deployment | PM-10; ES-8 |
Reviewed | Within [[5]] working days of closure | ES-9 |
Expedited change approved | Within [[1]] working day | RT-X |
Escalation
When | Who is told | By when |
|---|---|---|
A Priority 1 is confirmed | Head of Information Security | At once (ES-2) |
Any sign the flaw was used against us | The incident reporting route (P09 IM-01) | At once |
The mitigation will not be in place within 72 hours | Head of IT and Head of Information Security | As soon as it is known; isolate the system meanwhile |
The patch will not be in within 7 days | The system owner requests a deferral; the approver of the vulnerability standard decides, or the band's approver where that approver is more senior (DA-1) | Before the deadline passes |
The deadline passes with no approved deferral | Reported as overdue; escalated as the Vulnerability & Exposure Management Standard sets, and to its approver after a further 14 days | The day after the deadline (VM-19) |
A provider does not answer or misses the clause's period | Head of IT | The same day |
Worked example: an exploited flaw in the ordering platform
EXAMPLE, not part of the procedure. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Its ordering platform runs on two web servers behind a load balancer, in its own subscription at the cloud hosting provider (P06 SUP-002), which patches the platform beneath them. EM-2026-01: emergency security release of the ordering platform's web commerce software, for a remote code execution flaw the vendor reports is being exploited.
The timeline
When | What happened | Who |
|---|---|---|
Thu 24 Sep 2026 08:00 | The vendor publishes its emergency security release of the ordering platform's web commerce software, for a remote code execution flaw the vendor reports is being exploited. | Vendor |
Thu 24 Sep 2026 09:15 | The vendor's email is read; the inventory search finds the affected software on WEB-01 and WEB-02. First detection: P01's clock starts. | IT Operations Manager |
Thu 24 Sep 2026 09:40 | Rated Priority 1 on both: exploited, and the web servers are internet-facing (ES-2). Emergency route. The Head of Information Security told at the same time. | IT Operations Manager; Head of Information Security |
Thu 24 Sep 2026 10:00 | Emergency change, approved in writing; recorded the same day. | Head of IT |
Thu 24 Sep 2026 10:30 | Compromise check started on both web servers: the vendor's indicators of compromise and the servers' logs (ES-3). | Security monitoring provider (P06 SUP-006) |
Thu 24 Sep 2026 12:40 | Mitigation in place: a web application firewall rule from the vendor's advisory, blocking requests to the vulnerable function on both web servers. | Hosting provider (P06 SUP-002) |
Thu 24 Sep 2026 16:00 | Compromise check finished: none of the vendor's indicators found on either web server, and no unusual connections in their logs since the flaw was first reported exploited. No incident. | Security monitoring provider (P06 SUP-006) |
Fri 25 Sep 2026 10:00 | Patch tested on the ordering platform's staging copy. | The ordering platform team |
Fri 25 Sep 2026 11:45 | Test passed. The system owner agrees Sunday 02:00, the platform's quietest hour for the deployment. | The ordering platform team; system owner |
Sun 27 Sep 2026 02:00 | Deployment starts: WEB-02, then WEB-01, behind the load balancer. | The ordering platform team |
Sun 27 Sep 2026 03:30 | Deployment complete on both web servers. | The ordering platform team |
Sun 27 Sep 2026 03:45 | Service check passed on both web servers. | The ordering platform team's duty engineer |
Mon 28 Sep 2026 | Working exploit code is published. | Public |
Mon 28 Sep 2026 09:00 | Targeted rescan: the vulnerability is gone on both. The finding is closed (P01 VM-13). | IT Operations Manager |
Tue 29 Sep 2026 09:20 | The web application firewall blocks the first attempts. Reported by the hosting provider and triaged as INC-2026-018: Severity 4, exploited vulnerability (P09). | Hosting provider (SUP-002); IT service desk |
Fri 2 Oct 2026 | Review: every step met its target. The release review found the advisory only because the vendor emails its customers; the vendor's feed is added to the exploitation sources (P01). | IT Operations Manager; Head of Information Security |
Checks against the limits
Check | Limit | Actual | Met | Basis |
|---|---|---|---|---|
Rated and routed, from the advisory | 4 hours | 1 hour 40 minutes | Yes | PM-11; ES-2 |
Approved before the mitigation | Before ES-5 | 2 hours 40 minutes before | Yes | ES-4 |
Mitigated, from first detection | 72 hours | 3 hours 25 minutes | Yes | P01 VM-09; ES-5 |
Compromise check started, by the mitigation | By ES-5 | 2 hours 10 minutes before | Yes | ES-3 |
Compromise check finished, before deployment | Before ES-7 | 2 days 10 hours before | Yes | ES-3 |
Test | 2 hours | 1 hour 45 minutes | Yes | PM-05; ES-6 |
Patched, from first detection | 7 days (by 1 Oct 2026) | 2 days 18 hours 15 minutes | Yes | P01; ES-7 |
Verified, from deployment | 1 working day | 1 working day | Yes | PM-10; ES-8 |
Reviewed, from closure | 5 working days | 4 working days | Yes | ES-9 |
The flaw was mitigated 3 hours 25 minutes after first detection, and patched on 27 Sep 2026, 3 days in, inside the 7-day deadline of 1 Oct 2026. The deployment waited for the platform's quietest hour, agreed by the system owner on 25 Sep, because the mitigation was holding. EXAMPLE
Exploit code was published on 28 Sep 2026, after the patch. The attempts that followed were blocked by the firewall rule and found nothing to exploit: the service desk triaged them as INC-2026-018, a Severity 4 incident, with its root cause recorded as "none on our side: an internet-wide campaign against a published weakness." The compromise check at ES-3 had found no sign of earlier use, so no incident was declared during the emergency itself. EXAMPLE
Guidance — delete before approval
What this example teaches, from the review on 2 Oct 2026: Every step met its target. The release review found the advisory only because the vendor emails its customers; the vendor's feed is added to the exploitation sources (P01). A procedure is only as fast as the way the advisory reaches it.
An expedited patch that went wrong
REL-03, security fix to the search component the ordering platform is built on, was Priority 2 on both web servers, due 16 Sep 2026. Routed as expedited at the release review on 2 Sep, because neither window would have both web servers verified by the 16 Sep deadline: Window A installs WEB-01 on the deadline day, verified the next working day, and Window B comes after it. Deployed on 22 Sep: the ordering platform team is two engineers short (P05 TA-03). No deferral was requested before the deadline; the finding was reported overdue and escalated to the asset owner's manager on 17 Sep (P01 VM-19). It was verified on 23 Sep 2026, 7 days late. EXAMPLE
What the procedure asked for: an extra window inside the deadline (step 3 of the expedited route), and if the team could not staff it, escalation to the Head of IT for the people, not a quiet slip. A shortage of staff is never an accepted reason for a deferral (PM-15). The organisation's risk register tracks the cause as a treatment action: bring the ordering platform's patching back to 95% within deadline after two engineers left, at risk. EXAMPLE
Related documents
Document | Relationship |
|---|---|
Patch Management Standard | The rules this procedure runs: PM-11, PM-12, PM-13 and PM-14 |
Vulnerability & Exposure Management Standard | The Priority 1 deadlines, first detection and the approver of a Priority 1 deferral (VM-09, VM-18) |
Monthly Patch Cycle Operating Procedure | Sends Priority 1 and expedited patches here from the release review |
Patch Deployment Ring & Maintenance Window Plan | The order of deployment, the redundant pairs and the emergency window |
Patch Deployment Verification Checklist | The verification checks at ES-8 |
Patch Deferral Request Form | A Priority 1 patch that cannot go in on time |
Security Incident Management Policy | Takes the lead when there is a sign the flaw was used against us |
Incident Triage & First-Hour Assessment Procedure | How an incident is reported and triaged |
Supplier Contract Security Clause Library | Clause CL-08, which binds providers to fix and to tell us |
Adapting this template
Guidance — delete before approval
Small organisation: the coordinator, the approver and the deployer may be two people. Keep the separation in ES-4: whoever deploys does not approve. Keep the change record and the compromise check; they are what you will be asked for if the flaw is later found to have been used. A managed security provider can run ES-3 for you.
Regulated entity (NIS2, DORA): DORA's technical standards ask patch procedures to identify emergency procedures for patching, and NIS2's Implementing Regulation expects patches applied within a reasonable time after they become available. This procedure is written as that emergency procedure. Keep the change record for the period your regulator expects, and run the incident reporting screen under the incident pack whenever ES-3 finds a sign of use.
IT run by a service provider: give the provider this procedure's targets in the contract, and ask for the times of first detection, mitigation, deployment and rescan on every emergency. The decision on the route, the approval and the compromise check's result stay with [[Organisation Name]].
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 8.8 — Management of technical vulnerabilities | The whole procedure: exploited vulnerabilities fixed within P01's deadlines |
ISO/IEC 27001:2022 | Annex A 8.32 — Change management | ES-4: the emergency change and its approval |
ISO/IEC 27001:2022 | Annex A 5.26 — Response to information security incidents | When the flaw may already have been used against us: the hand-off to incident response |
ISO/IEC 27001:2022 | Annex A 5.22 — Monitoring, review and change management of supplier services | Services a provider patches |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | The whole procedure: the response to an exploited flaw chosen, prioritised and tracked |
NIST CSF 2.0 | PR.PS-02 — “Software is maintained, replaced, and removed commensurate with risk” | ES-6 to ES-8: the patch tested, deployed and verified |
NIST CSF 2.0 | ID.RA-07 — “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked” | When the patch cannot be installed within the deadline: the deferral |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(e) — “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” | The whole procedure |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Who the Implementing Regulation binds; for other entities it shows what is expected |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 6.6.1 — “The relevant entities shall specify and apply procedures, coherent with the change management procedures referred to in point 6.4.1 as well as with vulnerability management, risk management and other relevant management procedures, for ensuring that: (a) security patches are applied within a reasonable time after they become available; (b) security patches are tested before being applied in production systems; (c) security patches come from trusted sources and are checked for integrity; (d) additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2.” | ES-5 to ES-8: patches applied quickly, tested, from trusted sources; the mitigation where the patch is not yet applied |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(f) — “have appropriate and comprehensive documented policies for patches and updates” | The whole procedure |
DORA — Delegated Regulation (EU) 2024/1774 | Article 10(2)(f) — the vulnerability management procedures shall “prioritise the deployment of patches and other mitigation measures to address the vulnerabilities identified” | Which route and The clock: patches and mitigations prioritised |
DORA — Delegated Regulation (EU) 2024/1774 | Article 10(4) — the patch management procedures shall “(a) to the extent possible identify and evaluate available software and hardware patches and updates using automated tools; (b) identify emergency procedures for the patching and updating of ICT assets; (c) test and deploy the software and hardware patches and the updates referred to in Article 8(2), points (b)(v), (vi) and (vii); (d) set deadlines for the installation of software and hardware patches and updates and escalation procedures in case those deadlines cannot be met.” | Point (b): the emergency route as a whole; points (c) and (d): ES-6 to ES-8, the timing targets and the escalation table |
ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement.
Definitions
Term | Meaning in this procedure |
|---|---|
Compensating control | A measure that makes a vulnerability harder to exploit while the patch is not installed: blocking the vulnerable service, restricting who can reach the system, disabling the affected feature or isolating the system. It counts only once it has been tested (P02 EX-07). |
Compromise check | The search at ES-3 for signs the flaw was used against us, over the period since it was first exploited anywhere. |
Emergency route | Deploying a patch for a Priority 1 vulnerability out of band, with an emergency change, the 72-hour mitigation and a short test (PM-11). |
Expedited route | Deploying a patch outside the monthly cycle because its P01 deadline would pass before the cycle has it installed and verified (PM-12). |
Exploited vulnerability | A vulnerability with reliable evidence of use in real attacks: the vendor says so, it is on a list of known exploited vulnerabilities, or credible threat information reports it. |
First detection | The time the flaw was first found on a system, by a scan or an inventory search, or the time an open finding was re-rated. P01's deadlines run from it. |
Indicators of compromise | Files, addresses, accounts or log entries the vendor or threat feeds name as signs that a flaw was used. |
Internet-facing | Reachable from the internet, directly or through a published service, without first connecting to the organisation's private network; or reachable from any network the organisation does not fully control, such as partner links, guest Wi-Fi or third-party connections. |
Mitigation | A measure applied within P01's 72 hours that makes the flaw unreachable or unusable until the patch is in. |
Release | One publication of patches by a vendor, on its release day or out of turn, with the vendor's advisory saying what each fixes and how severe it is. |
Rollback | Removing a patch, or restoring the system to its state before the patch, because the patch broke something. |
Verified | Installed, the service checked by its owner, and a scan no longer finds the vulnerability (P01 VM-13). |