Illustrative internal IT matrix. The example contains no promised response or restoration times; agree these with service owners.
Research-based; no hands-on test claim.Define impact in business terms
High impact might mean a critical organisation-wide process cannot operate. Medium impact could affect a department or a significant workflow. Low impact might affect one user with a viable workaround. Headcount alone is insufficient: one unavailable account can block a time-critical financial process.
Write examples for your actual services. Identify dependencies and customers affected indirectly. A apparently small technical fault can have high impact when it sits on a shared identity or payment path.
Assess how quickly the harm grows
High urgency means delay rapidly worsens the consequence or a deadline is imminent. Medium urgency allows a short controlled delay. Low urgency means the task can be planned without material escalation. Ask whether a workaround exists and whether it is sustainable.
Separate urgency from arrival order. A long-standing request can be low urgency, while a newly reported incident may need immediate coordination. Record the evidence for both dimensions so another responder can understand the decision.
Apply an illustrative matrix
Use the table as a starting point. P1 represents the most urgent coordinated response in this example; P4 represents planned handling. Define staffing, communication cadence and escalation for each priority before adopting it.
Do not automatically downgrade a possible security incident because only one device is visibly affected. Follow the organisation’s security incident process where containment or evidence preservation has different needs. Give the incident lead authority to override with a reason and review the decision as facts emerge.
| Impact / urgency | High urgency | Medium urgency | Low urgency |
|---|---|---|---|
| High impact | P1 | P2 | P3 |
| Medium impact | P2 | P3 | P4 |
| Low impact | P3 | P4 | P4 |
Reassess and communicate
Review priority when the scope, workaround or deadline changes. Keep the original classification and the change reason in the incident record. Update stakeholders when response expectations change.
After closure, compare the assigned priority with actual impact. Tune examples where responders repeatedly disagree. Avoid promising restoration within a fixed time if suppliers or technical dependencies make that promise unsupported; response and restoration targets are different commitments.