Illustrative internal IT matrix. The example contains no promised response or restoration times; agree these with service owners.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Define impact in business terms
Impact plus urgency is a better default than either affected headcount or arrival order. A single blocked approver can stop an organisation-wide payment process, whereas many users may tolerate a noncritical inconvenience with a workaround. Keep a documented override for security and other exceptional incidents, and preserve the reason so the next responder can reconstruct the decision.
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. An 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.
What the example matrix commits you to
The table contains nine impact-and-urgency combinations mapped to four response priorities. Those numbers describe a proposed classification scheme, not an industry-mandated scale or a restoration guarantee. Two incidents assigned P2 can have different technical recovery times while requiring the same coordination and update discipline.
A response target and a restoration target must be recorded separately. If a hypothetical P1 is acknowledged in ten minutes and restored in two hours, the ten-minute response does not establish ten-minute recovery. Use explicit stakeholder commitments instead of inserting generic SLA durations into the matrix.