Escalate an overdue vulnerability on the day it misses its deadline, not at the next monthly review. Tell the asset owner first, then their manager, then whoever can accept risk. Each step should ask for a decision: fix, mitigate, or formally accept, with a new date.
Why escalation needs a ladder
Overdue items usually are not ignored out of carelessness. They are blocked by competing work, unclear ownership, or a fix that is harder than expected. A ladder turns a stuck ticket into a decision someone with authority must make.
Without one, the security team ends up chasing engineers one message at a time, which drains goodwill and still produces no decision.
A four step ladder
| Step | When | Who is told | What they must decide |
|---|---|---|---|
| 1. Owner nudge | One working day before the deadline | Asset or service owner | Is the date safe, or does the owner need help? |
| 2. Deadline missed | The day it passes | Owner and their manager | New date with a reason, or a mitigation now |
| 3. Repeated miss | Second missed date | Head of engineering or product | Resource the fix or take the risk |
| 4. Risk acceptance | When fixing is not planned | Risk owner with authority | Accept in writing with an expiry date |
The timings are examples. Set yours in policy and apply them evenly, which matters more than the exact numbers.
Make each message easy to act on
A good escalation note has five parts:
- The vulnerability and the affected service, in plain words.
- The original deadline and how overdue it is.
- Why it matters: is it reachable, exposed to the internet, or known to be exploited?
- The options on the table, with a recommendation.
- The decision needed and by when.
Skip the severity adjectives. A single line saying the issue is on a known exploited list, if it is, carries more weight than three paragraphs of alarm. CISA describes its catalog as one input to vulnerability prioritization, which is a fair way to frame it.
Escalate faster for urgent signals
Some signals should skip steps. Evidence of active exploitation, exposure on the internet, or a reachable code path in a production service justify going straight to step 3. The NIST patching guide describes emergency patching and emergency mitigation as separate scenarios from routine work, and an overdue emergency item should be treated that way.
Keep it blameless
Escalation is about the item, not the person. Say "this has missed its date, what is blocking it" rather than naming individuals in a channel. Track the pattern too. If the same team keeps missing dates, that points to a capacity problem, which is something leadership can fix.
Close the loop
When an escalated item is resolved, record how long it was overdue and why. Review the list monthly for common causes, such as slow approvals or a shared library that every team depends on. Fixing the cause removes whole classes of future escalations.
Quick check
Who should be able to accept the risk of an overdue vulnerability?
Someone who owns the business risk and has authority to accept it, not the security analyst or the engineer who owns the ticket.
Should every overdue item be escalated to executives?
No. Use the ladder. Most items resolve at the first two steps, and only repeated misses or high risk items need senior attention.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
