Incident Triage Matrix
The incident triage matrix provides classification criteria for determining incident severity, assigning priority, and routing incidents to the appropriate response playbook. Use this reference during initial incident assessment to ensure consistent classification across responders.
Incident categories
Incidents fall into distinct categories based on their primary characteristic. Each category routes to specific playbooks and may have different severity thresholds.
| Category | Definition | Primary indicators | Initial playbook |
|---|---|---|---|
| Security: Malware | Malicious software detected on endpoints or servers | AV/EDR alerts, suspicious processes, unusual network traffic | Malware Containment |
| Security: Ransomware | Encryption malware affecting data availability | Ransom notes, encrypted files, mass file modification | Ransomware Response |
| Security: Account compromise | Unauthorised access to user accounts | Impossible travel, credential stuffing alerts, user report | Account Compromise |
| Security: Privileged access breach | Compromise of administrative accounts | Admin credential exposure, suspicious privileged activity | Privileged Access Breach |
| Security: Phishing | Email-based attack campaign targeting users | User reports, mail gateway alerts, similar messages to multiple users | Phishing Campaign Response |
| Security: Data breach | Confirmed or suspected data exfiltration | DLP alerts, data found externally, unusual data access patterns | Data Breach Response |
| Security: Protection data breach | Breach involving safeguarding or case management data | Protection case data exposed, safeguarding records accessed | Protection Data Breach Response |
| Security: Web application attack | Attacks targeting web applications | WAF alerts, injection attempts, application errors | Web Application Attack |
| Security: Insider threat | Suspected malicious insider activity | Data exfiltration patterns, policy violations, HR referral | Insider Threat Investigation |
| Security: Device loss | Lost or stolen device containing organisational data | User report, device tracking loss | Device Loss or Theft |
| Availability: Service outage | Critical service unavailable to users | Monitoring alerts, user reports, health check failures | Major Service Outage |
| Availability: Infrastructure failure | Physical or virtual infrastructure component failure | Hardware alerts, hypervisor errors, storage failures | Infrastructure Recovery |
| Availability: Cloud failure | Cloud service or region unavailability | Cloud provider status, region-wide errors | Cloud Failover |
Severity levels
Severity reflects the actual or potential impact of an incident on organisational operations, data, and people. Assign severity based on the highest applicable criterion.
Critical: Severity 1
Immediate threat to organisational operations, safety, or data requiring emergency response.
| Criterion | Threshold |
|---|---|
| Service impact | Core business services unavailable to all users |
| Data impact | Confirmed exfiltration of protection data, PII of more than 1,000 individuals, or financial data |
| Financial impact | Potential loss exceeding £100,000 |
| Safety impact | Direct threat to physical safety of staff or beneficiaries |
| Reputational impact | Incident will become public knowledge within 24 hours |
| Regulatory impact | Mandatory breach notification triggered (GDPR 72-hour clock started) |
| Spread potential | Active ransomware encryption in progress, worm-like propagation |
High: Severity 2
Significant impact requiring urgent response within working hours or limited after-hours escalation.
| Criterion | Threshold |
|---|---|
| Service impact | Core business service degraded affecting more than 50% of users, or non-core service unavailable |
| Data impact | Suspected exfiltration, confirmed access to sensitive data without exfiltration confirmation |
| Financial impact | Potential loss between £10,000 and £100,000 |
| Safety impact | Potential indirect threat to safety through compromised communications or data |
| Reputational impact | Incident affects external stakeholders (partners, donors, beneficiaries) |
| Regulatory impact | Potential regulatory notification required pending investigation |
| Spread potential | Malware contained but cleanup incomplete, compromised credentials not yet fully rotated |
Medium: Severity 3
Moderate impact manageable within standard working hours with established procedures.
| Criterion | Threshold |
|---|---|
| Service impact | Non-core service degraded, or localised outage affecting single office or team |
| Data impact | Unauthorised access attempt blocked, policy violation without data exposure |
| Financial impact | Potential loss between £1,000 and £10,000 |
| Safety impact | No safety implications |
| Reputational impact | Internal impact only |
| Regulatory impact | No regulatory notification required |
| Spread potential | Isolated incident with no propagation indicators |
Low: Severity 4
Minor impact handled through standard service management processes.
| Criterion | Threshold |
|---|---|
| Service impact | Single user affected, cosmetic issues, minor functionality problems |
| Data impact | Failed attack with no access achieved |
| Financial impact | Potential loss under £1,000 |
| Safety impact | None |
| Reputational impact | None |
| Regulatory impact | None |
| Spread potential | None |
Priority matrix
Priority determines response urgency and resource allocation. Calculate priority from severity and urgency using the matrix below. Urgency measures how quickly the incident impact grows or the window for effective response closes.
Urgency levels
| Urgency | Definition | Examples |
|---|---|---|
| Immediate | Impact growing every minute, response window under 1 hour | Active ransomware encryption, ongoing data exfiltration, service outage during critical operations |
| High | Impact growing hourly, response window under 4 hours | Compromised credentials in use, phishing campaign actively receiving clicks, degraded service during business hours |
| Medium | Impact stable or growing slowly, response window under 24 hours | Contained malware awaiting cleanup, suspected breach requiring investigation, weekend service degradation |
| Low | No time pressure, can be scheduled | Failed attack logged for analysis, minor policy violation, cosmetic issues |
Priority calculation
| Immediate urgency | High urgency | Medium urgency | Low urgency | |
|---|---|---|---|---|
| Critical severity | P1 | P1 | P2 | P2 |
| High severity | P1 | P2 | P2 | P3 |
| Medium severity | P2 | P2 | P3 | P3 |
| Low severity | P3 | P3 | P4 | P4 |
Response requirements by priority
Each priority level carries specific response time and resource commitments.
| Priority | Initial response | Status updates | Resolution target | Staffing model |
|---|---|---|---|---|
| P1 | 15 minutes | Every 30 minutes until stable, then hourly | 4 hours to stable state | Incident commander plus dedicated team, 24/7 coverage until resolved |
| P2 | 1 hour | Every 2 hours during business hours | 8 hours to stable state | Assigned responder with backup, extended hours as needed |
| P3 | 4 hours | Daily during active investigation | 3 business days | Assigned responder during business hours |
| P4 | 1 business day | On status change | 10 business days | Normal queue processing |
Initial response means acknowledging the incident, assigning ownership, and beginning assessment. Stable state means active threat contained, immediate impact mitigated, and no further deterioration expected without change.
Escalation triggers
Escalate to the next priority level when any trigger condition occurs during incident handling.
Escalate from P2 to P1
| Trigger | Action |
|---|---|
| Scope expansion | Incident affects additional systems, offices, or data beyond initial assessment |
| Exfiltration confirmed | Evidence of data leaving organisational control |
| Regulatory clock | Discovery triggers mandatory notification timeline |
| Recovery failure | Planned remediation unsuccessful after 2 attempts |
| Executive involvement | Media inquiry, donor inquiry, or board notification required |
| Safety concern | Any indication of physical safety implications |
Escalate from P3 to P2
| Trigger | Action |
|---|---|
| User impact growth | Affected user count doubles or exceeds 50 |
| Persistence discovered | Attacker established persistence mechanisms |
| Lateral movement | Evidence of movement between systems |
| Time sensitivity | External deadline creates urgency (audit, go-live, emergency response) |
| Resource constraint | Resolution blocked by unavailable resources or expertise |
Escalate from P4 to P3
| Trigger | Action |
|---|---|
| Pattern identified | Similar incidents indicate coordinated activity |
| Repeat occurrence | Same incident type for same user or system within 30 days |
| Policy violation | Investigation reveals deliberate policy circumvention |
Communication requirements
Communication recipients and channels vary by priority level. The incident commander (P1) or assigned responder (P2-P4) owns communication delivery.
P1 incidents
| Recipient | Timing | Channel | Content |
|---|---|---|---|
| Executive leadership | Within 30 minutes of classification | Phone call, then email | Nature, impact, actions in progress, next update time |
| IT leadership | Within 15 minutes | Phone call or instant message | Full technical details, resource needs |
| Affected department heads | Within 1 hour | Phone call | Impact on their operations, expected duration, workarounds |
| All staff (if service impact) | Within 2 hours | Email and intranet | Service status, workarounds, expected resolution |
| External parties (donors, partners) | As determined by executive | Per relationship protocol | Approved messaging only |
| Regulatory authorities | Per regulatory timeline | Formal notification | Legal-reviewed content |
P2 incidents
| Recipient | Timing | Channel | Content |
|---|---|---|---|
| IT leadership | Within 2 hours | Summary, impact, timeline | |
| Affected department heads | Within 4 hours | Impact and workarounds | |
| Affected users | As needed | Service status, workarounds |
P3 and P4 incidents
| Recipient | Timing | Channel | Content |
|---|---|---|---|
| Affected users | On resolution | Email or ticket update | Resolution confirmation, prevention guidance |
| IT leadership | Weekly summary | Report | Aggregated incident metrics |
Category-specific classification
Some incident categories have specific severity criteria that override general thresholds.
Ransomware severity
| Condition | Minimum severity |
|---|---|
| Encryption active and spreading | Critical |
| Encryption stopped, cleanup required | High |
| Ransomware detected, execution prevented | Medium |
Account compromise severity
| Condition | Minimum severity |
|---|---|
| Privileged account compromised | Critical |
| Account with access to protection data | Critical |
| Account with access to financial systems | High |
| Standard user account | Medium |
| Failed compromise attempt | Low |
Data breach severity
| Data type | Records | Minimum severity |
|---|---|---|
| Protection/safeguarding data | Any | Critical |
| Financial data (payment cards, bank details) | Any | Critical |
| PII (names with identifiers) | Over 1,000 | Critical |
| PII (names with identifiers) | 100-1,000 | High |
| PII (names with identifiers) | Under 100 | Medium |
| Internal operational data | Any | Medium |
| Public data | Any | Low |
Device loss severity
| Condition | Minimum severity |
|---|---|
| Device with protection data, unencrypted | Critical |
| Device with protection data, encrypted | High |
| Device with PII, unencrypted | High |
| Device with PII, encrypted | Medium |
| Device with standard data, encrypted | Low |
Service outage severity
| Service type | User impact | Minimum severity |
|---|---|---|
| Core service (email, ERP, case management) | All users | Critical |
| Core service | Over 50% of users | High |
| Core service | Under 50% of users | Medium |
| Supporting service | All users | High |
| Supporting service | Partial | Medium |
| Non-critical service | Any | Low |
Worked examples
Example 1: Ransomware detection
Situation: EDR alerts on 3 endpoints showing encryption behaviour at 14:30 on Tuesday. Files with .locked extension appearing in shared drives.
Classification:
- Category: Security: Ransomware (encryption indicators)
- Severity: Critical (active encryption spreading)
- Urgency: Immediate (impact growing every minute)
- Priority: P1
Routing: Ransomware Response
Response requirements: 15-minute initial response, incident commander assigned, 24/7 coverage until contained.
Example 2: Phishing report
Situation: User reports suspicious email at 09:15. Email contains link to credential harvesting site. User did not click. Mail gateway shows same email sent to 45 recipients.
Classification:
- Category: Security: Phishing (campaign targeting multiple users)
- Severity: High (multiple users targeted, potential for credential compromise)
- Urgency: High (other users may click, response window under 4 hours)
- Priority: P2
Routing: Phishing Campaign Response
Response requirements: 1-hour initial response, message quarantine, recipient notification.
Example 3: Laptop theft
Situation: Staff member reports laptop stolen from vehicle on Saturday evening. Laptop has full disk encryption enabled. Contains programme data including beneficiary names and locations for food distribution.
Classification:
- Category: Security: Device loss
- Severity: High (PII present, encryption provides protection but not certainty)
- Urgency: Medium (theft already occurred, no active threat, response window under 24 hours)
- Priority: P2
Routing: Device Loss or Theft
Response requirements: 1-hour initial response (next business day given weekend), remote wipe, access review.
Example 4: Email service degradation
Situation: Users report slow email delivery starting at 11:00 Monday. Messages taking 15-30 minutes to deliver. Approximately 200 users affected across headquarters.
Classification:
- Category: Availability: Service outage (core service degraded)
- Severity: Medium (service degraded not unavailable, HQ only)
- Urgency: High (business hours, impact ongoing)
- Priority: P2
Routing: Major Service Outage for investigation, escalate if vendor issue to Service Continuity
Response requirements: 1-hour initial response, 2-hour status updates, investigate root cause.
Example 5: Failed brute force
Situation: SIEM alerts show 500 failed authentication attempts against single user account over 2 hours from multiple IP addresses. Account locked after 10 failures. No successful authentication.
Classification:
- Category: Security: Account compromise (attack attempted)
- Severity: Low (attack blocked, no access achieved)
- Urgency: Low (no ongoing threat, attack unsuccessful)
- Priority: P4
Routing: Log for analysis, no playbook activation required. If pattern repeats across accounts, escalate to Account Compromise.
Response requirements: Standard queue, verify account lockout, review for password spray pattern.
Example 6: Protection database access
Situation: Audit log review shows former contractor account accessed case management system 3 days after contract end. Account should have been disabled. Contractor viewed 12 protection cases before access was noticed and revoked.
Classification:
- Category: Security: Data breach / Protection data breach
- Severity: Critical (protection data accessed by unauthorised individual)
- Urgency: High (access revoked but data exposure occurred, regulatory notification likely)
- Priority: P1
Routing: Protection Data Breach Response
Response requirements: 15-minute response, safety assessment for affected cases, regulatory notification assessment, safeguarding team coordination.
Quick reference card
For printing or quick consultation during active incidents.
+--------------------------------------------------------------------+| INCIDENT PRIORITY QUICK REFERENCE |+--------------------------------------------------------------------+| || SEVERITY INDICATORS || Critical: Safety threat, >1000 PII, active encryption, || all-user outage, regulatory notification || High: >50% user impact, sensitive data access, || £10-100k exposure, external stakeholder impact || Medium: Localised impact, blocked attacks, single office || Low: Single user, failed attacks, cosmetic issues || || URGENCY INDICATORS || Immediate: Impact growing per minute, <1hr response window || High: Impact growing hourly, <4hr response window || Medium: Stable impact, <24hr response window || Low: No time pressure, schedulable || || PRIORITY = SEVERITY x URGENCY || P1: Critical+Immediate/High, High+Immediate || P2: Critical+Medium/Low, High+High/Medium, Medium+Immediate/High || P3: High+Low, Medium+Medium/Low, Low+Immediate/High || P4: Low+Medium/Low || || RESPONSE TIMES || P1: 15 min initial, 30 min updates, 4hr stable || P2: 1 hr initial, 2hr updates, 8hr stable || P3: 4 hr initial, daily updates, 3 day resolution || P4: 1 day initial, on-change updates, 10 day resolution || |+--------------------------------------------------------------------+See also
- Incident Response Framework for the conceptual framework underlying incident classification
- Incident Management for the operational incident management process and record-keeping
- Evidence Collection for evidence preservation procedures applicable to all incident types
- Ransomware Response for ransomware-specific response procedures
- Account Compromise for account-level security incident response
- Data Breach Response for data exposure incident response
- Protection Data Breach Response for safeguarding data incident response
- Major Service Outage for availability incident response