IT Incident Triage and Prioritisation: A Practical Guide
A simple structure to assess incident impact, set a priority and manage ownership through to service restoration.
In 30 seconds
- Purpose: restore service while prioritising work by impact and urgency.
- Inputs: the report, symptoms, affected scope and business constraints.
- Outputs: a qualified record, an owner, actions and confirmed restoration.
- When to use it: an unplanned service interruption or degradation.
“It has stopped working” is a starting signal, not a complete incident description. Effective triage turns it into usable information: the affected service, actual impact, urgency, owner and next step.
1. Capture the useful facts
Record the service, known start time, symptoms, affected users or locations and blocked activities. Ask what changed recently and whether a workaround exists. Keep observed facts separate from technical assumptions.
Never request a password in a ticket. Limit screenshots and logs to the information needed and keep them accessible only to the relevant people.
2. Separate impact from urgency
Impact describes the consequences: interrupted work, an unavailable critical function or affected users. Urgency describes how long the organisation can wait before those consequences become unacceptable.
| Illustrative situation | Suggested priority | Decision |
|---|---|---|
| Critical service unavailable with no workaround | Critical | Mobilise the relevant owners and coordinate communication. |
| Important function degraded with a temporary workaround | High | Assign an owner and agree the next status update. |
| Limited disruption with work still possible | Normal | Schedule work under the agreed service arrangements. |
Adapt this starting point with business owners. It does not establish contractual response or resolution times.
3. Give the record an owner
One owner follows the incident even when several teams are involved. They maintain the action history, coordinate escalation and communicate the next update. Work should not lose ownership when it crosses team boundaries.
4. Verify before closing
Confirm restoration with a service test and, where relevant, the user or business owner. Record the fix or workaround, remaining limitations and follow-up actions. Recurring incidents may require a separate investigation into their causes.
Example: access to a laboratory application
Two users cannot sign in. Before setting the priority, establish whether a critical activity is blocked, whether other accounts are affected and whether an authorised workaround exists. User count alone does not determine business impact.
A record structure to copy
- Affected service and business activity:
- Known start time and symptoms:
- Affected users, locations or processes:
- Impact, urgency and justified priority:
- Authorised workaround and limitations:
- Owner and next status update:
- Actions taken and results:
- Restoration checks and follow-up:
Common mistakes
Marking every record as urgent, confusing restoration with removal of the underlying cause, creating unlinked duplicates and closing without a test all make incident handling less reliable.
Deliverables
- An incident record structure to copy from this guide.
- An illustrative priority grid and closure checklist.
Operational summary
Capture facts, justify priority, assign an owner and verify restoration before closure.
Download
Make your support workflow clearer
NetQualIT can help establish shared triage criteria, clear ownership and follow-up that fits your activities.