If a vulnerability affects a business-critical service, what happens next?

Start

A vulnerability affects a business-critical service

The news may come from a scan, a vendor advisory or a news report. Two questions decide what happens next: has it already been used against you, and is it being used against anyone. The severity score and the service's importance matter, but they come after those two.

• Then: Confirm which systems are affected, and when it was found

Step

Confirm which systems are affected, and when it was found

List the systems behind the service that run the vulnerable version, and whether each is internet-facing or rated Critical. Record the date the weakness was first detected on each one, because every deadline counts from it. When a widely exploited flaw is announced, run a targeted scan of internet-facing systems rather than waiting for the schedule.

• Then: Is there any sign it has already been used against you?

Decision

Is there any sign it has already been used against you?

This asks about your own systems, not the world. Look for the indicators the vendor or your national CSIRT has published, unexpected accounts, files or processes, and odd outbound connections from the affected systems. Exploitation elsewhere is a separate question, asked next. If you have not been able to check yet, treat the answer as yes.

• Yes, or not yet checked: Raise it as a possible incident now
• No signs, after checking: Is the weakness being exploited in the wild?

Step

Raise it as a possible incident now

Tell the vulnerability standard's owner at once. Signs that the weakness has already been used against you are the pack's own example of when to raise it under your incident procedure, so raise it now. With credible signs of compromise the question is no longer how fast to patch. It is what the attacker has done and how to stop it.

• Then: Could containment affect safety or an essential service?

Decision

Could containment affect safety or an essential service?

Disconnecting, shutting down or isolating a business-critical service can cause more harm than the attacker. This applies where the service supports physical safety, care, payments, supply or other operations people depend on. If the answer is yes, or you cannot tell, contain at once the least disruptive way, but do not stop the service until its owner and specialists are in. That is the incident pack's rule.

• Yes, or not known: Plan containment with specialists and the service owner
• No: Contain, and preserve evidence before rebuilding

Outcome

Plan containment with specialists and the service owner

Bring incident responders, the service owner and the people who run the operational side together, with outside incident-response help if you lack the skills. Agree how far to go before any disconnection, and keep containing meanwhile with steps that limit the attacker while keeping the service safe, such as closing specific access paths or disabling affected accounts. Record who decided and why. A patch applied along the way does not show the attacker has gone.

Step

Contain, and preserve evidence before rebuilding

Isolate or restrict the affected systems through your incident procedure. Keep logs and, where you can, memory and disk images before changes overwrite them. Apply the vendor's mitigation or patch as part of containment. It does not replace the investigation.

• Then: Run it as an incident: the patch alone does not end it

Outcome

Run it as an incident: the patch alone does not end it

A patch closes the way in. It does not remove accounts, web shells or other footholds the attacker left, and it says nothing about data taken. Eradication and recovery follow from what the investigation finds. Reconnect or return the service to normal only on that evidence.

Decision

Is the weakness being exploited in the wild?

Yes when there is reliable evidence of real attacks anywhere: the CISA Known Exploited Vulnerabilities catalogue, a vendor advisory saying so, or a national CSIRT or sector feed. Public proof-of-concept code, a high CVSS score or a high EPSS score is not exploitation. Working exploit code and a high EPSS score are early-warning signals that can raise a priority, but none of these makes an emergency. If you don't know, the pack treats it as not exploited and checks again at the next weekly triage.

• Yes: Is the system internet-facing, or rated Critical?
• No, or not known: Rate it on severity, exposure and criticality

Decision

Is the system internet-facing, or rated Critical?

Critical means failure or compromise would stop a core business service or expose highly sensitive data, so most systems behind a business-critical service qualify. Internet-facing includes partner links and guest networks. If either is unknown, answer yes.

• Yes, or not known: Priority 1: notify at once and mitigate without waiting
• No: Priority 2: fix within the pack's 14 days

Outcome

Priority 1: notify at once and mitigate without waiting

It does not wait for the weekly meeting. In the pack's defaults: notify the standard owner immediately, open a Priority 1 ticket with the detection date, put a compensating control in place within 72 hours, and install the fix within 7 days. Both clocks run from detection.

• Then: Can a control go in within 72 hours without stopping the service?

Outcome

Priority 2: fix within the pack's 14 days

Exploited, but on an internal system that is not rated Critical. An exploited weakness is never below Priority 2, whatever its score. The pack's default deadline is 14 days, with escalation to the asset owner's manager if it is still open on day 10.

• Then: Can the fix be installed by its deadline?

Decision

Can a control go in within 72 hours without stopping the service?

The pack's examples are blocking access to the vulnerable service, disabling the affected feature, or isolating the system. On a business-critical service a narrow control may be enough: in the pack's gateway example, the management portal was taken off the internet and the vendor's published mitigation applied. Record what was done and when. The control does not lower the priority or extend the 7-day fix.

• Yes: apply and record it: Can the fix be installed by its deadline?
• No, or not known: Take it to the approver and the incident process

Outcome

Take it to the approver and the incident process

A Priority 1 with no control at 72 hours goes to the standard's approver and into the incident process at once. Where the only control available would stop the service, that is a decision for the service owner and specialists together, not an automatic disconnection.

Decision

Can the fix be installed by its deadline?

Plan the fix with the service owner early, because a business-critical service usually needs a change window. Ask before the deadline, not after it has passed.

• Yes: Install the fix, then rescan
• No: Request an exception before the deadline

Outcome

Request an exception before the deadline

If the fix genuinely cannot be installed in time, request an exception while the finding is still in date. In the pack, the vulnerability standard's approver decides Priority 1 exceptions, and every exception names a risk owner and the compensating controls. Where the exception standard sets a higher approver or a shorter duration, the stricter rule applies.

Step

Install the fix, then rescan

Report the fix early enough for a confirming scan before the deadline. A ticket marked 'patched' is not evidence. For a Priority 1, verify with a targeted scan.

• Then: Did a look back over the exposed period find any sign of use?

Decision

Did a look back over the exposed period find any sign of use?

The weakness was exploitable, and exploited elsewhere, until the fix went in. A patch removes the flaw, not anything an attacker already did through it. Check the affected systems for indicators over the whole period they were exposed. If you find any, go back to incident handling.

• Yes, or not checked: Raise it as a possible incident now
• No: Fixed, confirmed by a rescan

Outcome

Fixed, confirmed by a rescan

A finding is closed when a later scan no longer reports it, or other objective evidence shows the fixed state. That proves the weakness is gone. It does not prove nobody used it, which is why exploited weaknesses get the look back.

Step

Rate it on severity, exposure and criticality

On a Critical system that is not exploited: Critical or High severity is Priority 2; Medium is Priority 2 if internet-facing and 3 if internal; Low is Priority 4. On a High or Standard system, read the same table without that uplift. Only exploitation creates a Priority 1. Working exploit code, a high EPSS score or reports of ransomware groups using the flaw can justify raising the priority; the triage chair decides and records why, and no approval is needed.

• Then: Plan the fix at its priority, and keep watching

Outcome

Plan the fix at its priority, and keep watching

Give it an owner and the deadline for its priority, and fix it through a planned change on the service. Business-critical does not by itself mean emergency. What changes that is new evidence.

• Then: At weekly triage, is it now exploited, or seen in your systems?

Decision

At weekly triage, is it now exploited, or seen in your systems?

Check open findings against the exploitation sources every week. If it is newly exploited, re-rate it that week: its new deadline is the earlier of the old one and the date the change became known plus the new priority's period. If signs of compromise appear, start again at the first question.

• Yes: start again: Is there any sign it has already been used against you? (back to an earlier step)
• No: fix by the deadline: Fixed, confirmed by a rescan