An Emergency Patching Playbook for Zero-Days

An emergency patching playbook is a short, pre-agreed plan for the moments when a vulnerability in something you run is being exploited and a fix is missing or brand new. It sets out what triggers the playbook, who triages, how you find every affected system, which interim mitigations you can apply before a patch exists, how emergency changes get approved, how you check for compromise before and after patching, how you confirm the fix, and who hears what along the way. The point is to make those decisions calmly in advance, so the emergency itself is spent executing.

What counts as a zero-day for this playbook?

Strictly, a zero-day is a vulnerability exploited before the vendor has a fix. In practice, the same urgency applies when a patch has just been released and exploitation is already underway, or is expected within days.

For this playbook, treat any of these as in scope:

• A vulnerability under active exploitation with no patch available
• A newly patched vulnerability with confirmed exploitation
• A critical, remotely exploitable flaw in an internet-facing product you run, where public exploit details are circulating

NIST SP 800-40 Rev. 4 makes a similar distinction in its maintenance plans. It separates emergency patching from emergency mitigation, which covers what you do before a patch is available. Your playbook needs both.

What should trigger the emergency patching playbook?

Decide your trigger criteria in advance and write them down. A simple test is three questions:

1. Do we run the affected product, or might we?
2. Is exploitation confirmed or very likely?
3. Is the affected system reachable by an attacker, especially from the internet?

A "yes" to the first two is usually enough to open the playbook. A "yes" to all three means you move at full speed.

Where do zero-day alerts come from?

Build a single intake channel, such as a shared mailbox or ticket queue, and feed it from:

• Vendor security advisories. Subscribe to the security notification lists of every vendor in your inventory. Prioritize edge devices such as firewalls, VPN gateways, remote access tools and file transfer servers.
• CISA's Known Exploited Vulnerabilities (KEV) catalog. CISA adds vulnerabilities once there is reliable evidence of exploitation. The catalog is available as a machine-readable feed, and you can subscribe to update notifications.
• CISA alerts and advisories. These often include mitigation guidance and indicators of compromise.
• Information sharing groups. Sector ISACs, and the MS-ISAC for U.S. state, local, tribal and territorial organizations.
• Your suppliers. Managed service providers and hosted software vendors should tell you when their platforms are affected. Confirm in your contracts that they will.

Assign a named person, with a backup, to watch the intake every working day. Alerts that land in an unwatched inbox don't trigger anything.

How do you triage a zero-day quickly?

The first hour is about deciding how big the problem is. Appoint a lead for the event, open a single working document or channel, and answer these questions:

• Which products and versions are affected?
• Does exploitation require authentication, a specific configuration or a particular feature to be enabled?
• What can an attacker do if it succeeds, such as run code, read data or take over accounts?
• Is a patch available? If not, has the vendor published a workaround?
• Are indicators of compromise available yet?

Record the decision and the time: activate fully, monitor and reassess, or close as not applicable. Timestamps help later, both for the post-event review and for any regulatory or insurance questions.

How do you find exposure in your asset inventory?

This is where a good inventory pays off. You need a list of every affected instance with an owner, and you need it fast.

Check configurations as well as versions, because many vulnerabilities only apply when a particular feature is on. Don't forget disaster recovery sites, lab and test environments, and appliances that nobody logs in to anymore.

The output is an exposure list: each affected system, its owner, whether it's internet-facing, and its status. That list drives everything that follows.

What can you do before a patch exists?

When there's no fix yet, you mitigate. Options, roughly in order of preference:

1. Apply the vendor's workaround. This is often a configuration change or disabling a specific component. Follow it exactly, and check the advisory for updates, since workarounds are sometimes revised.
2. Disable the affected feature or service if the business can manage without it for a while.
3. Restrict access. Take management interfaces off the internet, allow-list known source addresses, or put the service behind a VPN.
4. Add virtual patching rules to a WAF or IPS if a reliable signature is available and the traffic passes through it.
5. Isolate or shut down the system temporarily. This is a business decision, so have the owner and leadership make it with the risk laid out clearly.

Increase monitoring on affected systems at the same time. Verify each mitigation took effect, and track it as temporary, because mitigations have a way of becoming permanent.

How should emergency changes be approved?

Your normal change process was designed for routine work. An emergency path needs to be faster without being careless. Agree on it before you need it:

• Named emergency approvers, a small group with deputies, reachable out of hours.
• Quick approval, documented after. Approval in a call or chat is fine, provided it's written into the change record afterward.
• Pre-approved change types. Consider pre-authorizing vendor-published workarounds and access restrictions on internet-facing systems.
• A rollback plan. Take configuration backups or snapshots before changing anything.
• Staged rollout where time allows. Patch one instance, check it, then do the rest.
• A post-implementation review within a few days, to catch anything that went wrong.

Should you check for compromise before patching?

Yes, briefly, and in parallel with mitigation where possible. If a vulnerability was exploited before you acted, patching closes the door but doesn't remove anything an attacker left behind. Some patches and reboots also overwrite logs or temporary files that would show what happened.

Before patching

• Preserve relevant logs and, where practical, take a snapshot or forensic image of internet-facing systems.
• Check for the indicators of compromise published by the vendor or CISA. Vendors sometimes release integrity-checking tools for their appliances.
• Look for new or changed accounts, unexpected files in web directories, configuration changes, unusual processes and unexpected outbound connections.
• Look back to at least the earliest known exploitation date.

On an internet-facing system under active exploitation, don't let investigation delay mitigation for long. Capture evidence quickly, then act.

After patching

• Keep heightened monitoring on affected systems for several weeks.
• Recheck indicators as vendors and CISA update their guidance.
• If compromise is suspected, rotate credentials, keys and certificates stored on or used by the system.
• If you find evidence of compromise, move to your incident response plan. The event is no longer a patching exercise.

How do you validate the fix?

"Patched" should mean verified rather than merely deployed. For each system on the exposure list:

• Confirm the installed version or build matches the vendor's fixed release.
• Rescan once your scanner has a detection check for the vulnerability.
• Run any vendor-provided verification tool.
• Remove temporary mitigations only after the patch is confirmed, and only if they're no longer needed.
• Update the exposure list until every entry is closed, mitigated with an approved exception, or decommissioned.

Who needs to hear what, and when?

Communication is part of the response, not an afterthought. Set a regular update rhythm during the active phase and keep one source of truth.

Keep messages factual. Say what you know, what you don't know yet, and when the next update will come.

What should the playbook document include?

Keep the playbook short enough to use under pressure. A few pages is usually right:

• Roles: event lead, asset owners, emergency change approvers, communications owner
• Contact list, including out-of-hours numbers and vendor support routes
• Intake sources and trigger criteria
• Inventory queries and where to run them
• Pre-approved mitigations and emergency change steps
• Compromise check steps and evidence preservation guidance
• Validation criteria
• Communication templates
• Post-event review questions

Test it with a tabletop exercise at least once a year, using a realistic but fictional vulnerability in a product you actually run.

Frequently asked questions

How fast should we patch a zero-day?

As fast as you can do it safely. For internet-facing systems under active exploitation, aim to have mitigations in place within hours and the patch within days. CISA's due dates for KEV entries, which bind U.S. federal civilian agencies under Binding Operational Directive 22-01, are a useful outside reference.

What if we can't tell whether we run the affected software?

Assume you might, and search more widely: software inventories, scanner data, network traffic, procurement records and supplier questionnaires. Treat a slow answer from your inventory as a finding to fix after the event.

What if the vendor never releases a patch?

This happens with end-of-life products. Keep the interim mitigations in place, document the risk with an owner and an expiry date, and plan the replacement.

Key takeaways

• Write down trigger criteria and intake sources before you need them, and make sure someone watches the intake.
• Keep an asset inventory good enough to produce an exposure list in under an hour.
• Pre-agree interim mitigations and an emergency change path.
• Check for compromise before and after patching, because a patch doesn't remove what an attacker left behind.
• Verify every fix, communicate on a regular rhythm, and review the event afterward.