You get the alert at 4:40 on a Thursday afternoon: a critical remote code execution flaw in a product you run, exploit code already circulating, vendor advisory live. There is no threat intel team down the hall. There is you, a ticket queue, and a colleague who just went offline. What happens over the next 72 hours — the order you do things in, and what you deliberately skip — matters far more than how fast you push a patch.
The first block is for facts, not action. Read the vendor advisory itself, not the summary someone reposted. Then write down the answers to five questions, with timestamps, in one shared document.
Be careful with severity scores. CVSS describes technical severity; it knows nothing about your architecture. A 9.8 in a service you never exposed is a lower operational priority than a 7.5 on the appliance guarding your remote access. Check whether the vendor or a national authority has flagged active exploitation, and whether the flaw has landed in a known-exploited-vulnerability catalog. Those catalogs exist precisely to give small teams a reality check on urgency.
Now turn a generic advisory into a list of hosts. This is the step small teams skip, and it is the step that determines whether the next 60 hours feel calm or chaotic.
If discovery returns "unknown," treat that as a finding in its own right. An hour spent hunting shadow instances now is cheaper than a week of incident response later. Assign one person to own the inventory and one to own the technical verification, even if those are the same two people doing everything else.
If exploitation is confirmed and you cannot patch yet, buy time with compensating controls. Their job is not to be perfect. It is to raise the cost of an attack and to generate noise you can actually detect.
Containment breaks things. Test the change on one system, keep a rollback path ready, and name the person authorized to reverse it at 2 a.m. without a committee meeting.
Containment without detection only means you will not know when it fails.
Then hunt backward. Assume the worst case: if this was exploited last week, what would you see? Search historical logs for the artifact, not just live traffic. Absence of evidence is only meaningful if you know your logs would have captured it.
In parallel, stage the patch. Name the maintenance window, define the canary ring, document the rollback, and pre-write the change ticket so the approval is a formality rather than a debate. Order deployments by exposure, not alphabetically.
Silence is a decision with consequences. So is a vague update that tells people nothing.
We are aware of the flaw in the affected product. It does not currently affect the services you use, and we are applying the vendor's mitigation tonight. We will confirm completion by Friday morning.
Two sentences of fact and a next-update time beat three paragraphs of reassurance. Draft the template before you need it, and let one person own the wording so the message stays consistent.
Notification duties differ by jurisdiction and sector, and some have short clocks attached. Check your obligations with counsel before you publish anything you cannot walk back.
The point of this checklist is not to finish everything in three days. It is to force a sequence so that panic does not set the order: assess, map, contain, detect, patch, communicate. Some steps will overlap. Some will take longer than a day on their own, and that is fine.
Keep the exposure map, the log, and the message templates you wrote this time. Next disclosure, you will start the clock at hour four instead of hour zero — and that head start is the whole advantage.
Photo: AMORIE SAM / Pexels