When do we patch outside the monthly cycle, and how fast?

Start

A fix arrives that may not wait for the monthly cycle

It usually starts with a vendor advisory saying a flaw is being exploited, a flaw added to a known-exploited list, an open finding newly reported as exploited, a provider's notice, or a fix released between cycles. Release-day and between-cycle releases are reviewed within the same time, 1 working day in the pack's default, and routed the same way.

• Then: Find every affected system, and record first detection

Step

Find every affected system, and record first detection

Search the inventory and the scanner for the 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. The deadline clock starts at first detection on each system, not at the advisory, and does not wait for business hours. For an already open finding, the new deadline is the earlier of the old and the new.

• Then: Is the flaw being exploited in real attacks?

Decision

Is the flaw being exploited in real attacks?

Yes when there is reliable evidence of attacks anywhere: a known-exploited catalogue such as CISA's, the vendor's advisory, a national CSIRT or sector feed, or an incident of your own. Public exploit code alone is an early-warning signal that may justify raising the priority, not proof of exploitation. Check again at each weekly triage.

• Yes: Is the system internet-facing, or rated Critical?
• No, or no reliable evidence: Would the monthly cycle verify it only after its deadline?

Decision

Is the system internet-facing, or rated Critical?

Internet-facing means reachable from the internet, directly or through a published service, or from any network you do not fully control, such as partner links, guest Wi-Fi or third-party connections. Take criticality from the inventory. Unknown exposure counts as internet-facing and unknown criticality as Critical.

• Yes, or not known: Priority 1: tell security and approve an emergency change
• No: Would the monthly cycle verify it only after its deadline?

Step

Priority 1: tell security and approve an emergency change

Rate and route within 4 hours of the advisory, and tell the Head of Information Security at once. The Head of IT approves the emergency change, or the on-call approver by phone out of hours, never the person who will deploy it. If nobody answers within 30 minutes and waiting would let harm spread, mitigate first and record why. The patch itself always waits for an approver.

• Then: Does a provider patch this service for you?

Decision

Does a provider patch this service for you?

For software as a service, or hosting where the provider patches the platform, the provider fixes it under its contract. Its contract period does not change your own deadline for your exposure.

• Yes: Ask the provider today; mitigate your side within 72 hours
• No: Mitigate within 72 hours, the same day where possible

Step

Ask the provider today; mitigate your side within 72 hours

Ask the provider the same day whether it is affected, what it has done and when it will fix it. Unless its fix is confirmed sooner, have your own mitigation in place within 72 hours of first detection: block or restrict access, turn off the affected feature, or enforce stronger sign-in in front of it. Patch your own clients, agents and connectors through the emergency route, and raise a missed clause period under the contract.

• Then: Is there any sign the flaw was used against you?

Step

Mitigate within 72 hours, the same day where possible

The first day is for the mitigation, not the patch. Choose the one that removes exposure soonest with least effect on the service: the vendor's workaround, a web application firewall or intrusion prevention rule, blocking it from the internet, turning off the feature, or isolating the system. Test that the vulnerable function can no longer be reached. If it will miss 72 hours, tell the Head of IT and security, and isolate meanwhile.

• Then: Is there any sign the flaw was used against you?

Decision

Is there any sign the flaw was used against you?

Start the check no later than the mitigation and finish it before the patch. Look back to when the flaw was first exploited anywhere: the vendor's indicators of compromise, files, accounts or tasks nobody in IT created, unusual connections, monitoring alerts, or missing logs. If the check could not cover that whole period, extend it or record why and keep watching the system. Without a sign, emergency patching stays a risk response.

• Yes, or suspected: Report it through the incident route now
• No: Can the patch be installed within 7 days of first detection?

Outcome

Report it through the incident route now

Report it at once and keep the mitigation. Once your incident process declares an incident, the incident manager leads: patching does not remove an attacker who is already in, so they decide whether to patch, isolate or rebuild, and evidence is kept before anything is wiped, unless waiting would let harm spread. The patch keeps its deadline.

Decision

Can the patch be installed within 7 days of first detection?

Test it for 2 hours on one test or least critical system first. Where deployment will stop a customer-facing service, the system owner agrees the time; while the mitigation holds, that can be the quietest hour inside the 7 days. If the patch failed its test with a confirmed fault, or the vendor has not released one, the answer is no.

• Yes: Deploy internet-facing systems first, one node at a time
• No, or not known: Request a deferral before the deadline passes

Step

Deploy internet-facing systems first, one node at a time

Take a snapshot first. Patch internet-facing systems first, then the rest; behind a load balancer, take one node out, patch, check, return it, then the next. Run the service check within 30 minutes of each restart and roll back a node that fails. Verify with a targeted rescan within 1 working day, and keep the mitigation until the rescan is clean.

• Then: Verified by rescan inside the deadline, then reviewed

Decision

Would the monthly cycle verify it only after its deadline?

Compare the date the cycle would have the patch installed and verified on that system, its window plus 1 working day, with the system's deadline. If later, it leaves the cycle. An exploited flaw on an internal, less critical system is Priority 2 at 14 days: usually expedited, never left to wait a month.

• Yes, or not known: Can a window be found or added inside the deadline?
• No: Leave it in the monthly cycle

Outcome

Leave it in the monthly cycle

It goes in this month's cycle under the pre-approved standard change, or for a Priority 3 or 4 fix released between cycles, usually the next one. It still keeps its own deadline from first detection.

Decision

Can a window be found or added inside the deadline?

Look for a window this cycle that comes earlier, or another system's window its owner can share. If there is none, ask for an extra window inside the deadline; the emergency window can be used. A team short of people is not a reason to stop here: escalate to the Head of IT for the people.

• Yes: Expedite it as a normal change, approved within 1 working day
• No, or not known: Request a deferral before the deadline passes

Step

Expedite it as a normal change, approved within 1 working day

The Head of IT approves the normal change within 1 working day. Test as the cycle does, on the pilot ring or a test copy for the pilot's working days where the deadline allows; otherwise use the emergency route's short test on one system. Deploy, verify with a rescan, and record it with the month's deployments.

• Then: Verified by rescan inside the deadline, then reviewed

Outcome

Verified by rescan inside the deadline, then reviewed

The finding closes on the rescan, and an emergency's mitigation is removed only then. Within 5 working days of closure, review what slowed each step. In the pack's worked example the advisory was found only because the vendor emailed its customers, so the vendor's feed was added to the exploitation sources.

Outcome

Request a deferral before the deadline passes

The system owner requests it on the deferral form, for an accepted reason, before the deadline. For Priority 1 the 72-hour mitigation must be in place first, and the vulnerability standard's approver decides, or the exception band's approver where that one is more senior. The mitigation stays and the system is watched more closely until the patch is in.