Route security alerts by how soon a human must act. Page someone for urgent, exposed and confirmed issues, post to chat for same day work, and create a ticket for everything else. Add quiet hours and a fallback owner so nothing waits on one person.
A routing table
| Class | Example | Route | Expected response |
|---|---|---|---|
| Urgent | Confirmed exploitation or a reachable critical flaw on an internet facing service | Page on-call | Minutes |
| Same day | New high severity finding on a production service | Team chat channel plus ticket | Within the working day |
| Planned | Medium findings, upgrades available | Ticket in team queue | Within the SLA |
| Background | Low severity, dev only | Weekly digest | Reviewed in batch |
Your own thresholds will differ. What matters is that each class has one route and one expected response.
Inputs to routing
Severity alone is a blunt tool. Combine a few signals:
- Exposure: internet facing or internal.
- Reachability: is the vulnerable code path called?
- Known exploitation: is there evidence of active use?
- Asset criticality: does the service handle payments, health data or secrets?
- Fix available: is there a safe upgrade?
A high score with no reachable path and no exposure may belong in the planned class. A medium score on an exposed, exploited component may not.
Quiet hours without blind spots
Decide what may wait until morning and what may not. Planned and background items wait. Urgent items do not, so they page. Write this down so people do not guess at 2 a.m.
For same day items arriving at night, queue them and send one summary when the working day starts instead of waking a channel.
Escalation when nobody answers
- Send to the primary owner.
- If no acknowledgement within a set time, notify the secondary.
- If still none, notify the team lead and the security rota.
- Record each step on the ticket.
See when to escalate an overdue vulnerability for the overdue case, and page, ticket or dashboard for the deeper decision guide.
Review the routes
Every quarter, look at pages that turned out not to need one, and tickets that should have paged. Adjust thresholds. Alert routes drift as the system changes.
Quick check
Should every critical severity finding page someone?
No. Page for critical findings that are exposed, reachable or exploited. Others can go to a same day channel and a ticket.
What if the on-call person does not respond?
Escalate to a secondary after a set time, then to the team lead, and record each step on the ticket.
Safeguard's reachability analysis and policies can help classify findings before they are routed, and you can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
