Escalation rule: escalate when a decision, owner, deadline, or risk acceptance is needed beyond normal triage. Escalation should clarify responsibility, not create panic.
Escalation Ladder
Know when normal triage is no longer enough.
Use this page when a vulnerability may need emergency patching, SOC escalation, risk approval, vendor pressure, or leadership visibility.
Level 1
Validateconfirm source, version, exposure, ownerLevel 2
Assignpatch, mitigation, detection, monitoringLevel 3
Escalateblocked, exploited, exposed, no-patchLevel 4
Deciderisk acceptance, emergency change, leadershipEscalation Triggers
Move up the ladder when these conditions appear
Emergency patch
Exploited plus reachable
Escalate when KEV, confirmed exploitation, public PoC, or ransomware relevance overlaps with internet-facing or business-critical exposure.
SOC escalation
Detection is needed before remediation completes
Escalate to SOC when exploitation is plausible, patching is delayed, indicators exist, or visibility gaps could hide compromise.
Risk approval
Residual risk needs explicit ownership
Escalate to risk owners when patching is blocked, no patch exists, compensating controls are partial, or an exception will outlive the normal SLA.
Vendor escalation
Guidance is unclear or unsupported
Escalate to vendor or support channels when affected/fixed versions conflict, supersedence is unclear, workarounds are risky, or product support status is ambiguous.
Leadership visibility
Business decision or public impact is possible
Escalate to leadership when business-critical services are exposed, downtime is likely, accepted risk is material, or blockers require executive decision.
Trust review
The signal is too uncertain for action
Escalate to trust review when source confidence is low, records are disputed or rejected, or live-derived output conflicts with source material.
Escalation Evidence
What must be known before raising urgency
What changed?
KEV addition, exploit activity, public PoC, vendor advisory, patch release, exposure discovery, blocked owner, or new business impact.
What is affected?
Product, version, asset group, business service, environment, reachability, authentication requirement, and owner.
What decision is needed?
Emergency change, mitigation approval, detection assignment, vendor clarification, accepted risk, or leadership direction.
What is the deadline?
Target date, review date, SLA, patch window, exception expiry, or trigger that forces immediate re-review.
Do Not Escalate Yet
Cases where validation should come first
No affected asset found
Use exposure validation before emergency patching if the product, version, or reachability is still unknown.
Weak source confidence
Use Trust Review if a record is disputed, rejected, stale, or contradicted by vendor guidance.
PoC without environment fit
Public exploit code matters, but escalation should still consider exposure, controls, privilege requirements, and business impact.
No owner identified
Find the asset, patch, SOC, risk, or business owner before sending a high-pressure request.
Copy Starter
Escalation note template
Escalation reason: [KEV / exploited / exposed / no patch / blocked owner / vendor ambiguity] Affected scope: [product, version, asset group, business service] Evidence: [source, timestamp, exploit signal, exposure proof, owner note] Decision needed: [emergency patch / mitigation / SOC hunt / risk acceptance / vendor clarification] Owner: [team/person]. Deadline or review: [date/time]. Uncertainty: [what still needs validation and who is checking it]
Recommended next move: pick the trigger, gather evidence, choose the stakeholder, then send the handoff and track the follow-up.