1. Purpose
The Incident Severity Matrix provides a consistent method for classifying information security incidents according to their potential or actual impact.
Severity classification helps the organisation determine:
- How quickly the incident should be responded to
- Who should be notified
- How much investigation is required
- Whether business continuity procedures should be activated
- Whether legal/privacy assessment is required
- Whether customers or suppliers may need to be informed
- What level of management involvement is appropriate
- What evidence and documentation should be retained
Severity should be reassessed as new information becomes available. An incident may be downgraded or escalated during investigation.
2. Severity Levels
| Severity | Description | Typical Response |
|---|---|---|
| SEV-1 Critical | Severe or potentially severe impact to critical systems, sensitive information, customers, or business operations | Immediate response and senior management involvement |
| SEV-2 High | Significant security or business impact requiring urgent response | Priority response and management/security escalation |
| SEV-3 Medium | Limited or contained impact requiring structured investigation and remediation | Normal incident response |
| SEV-4 Low | Minor security event with limited or no material impact | Routine handling and monitoring |
The organisation may use different names, such as Critical / High / Medium / Low, instead of SEV-1 to SEV-4.
3. Primary Severity Dimensions
Severity should consider multiple dimensions rather than relying on a single factor.
Assess:
- Confidentiality
- Integrity
- Availability
- Customer impact
- Personal/regulated data
- Business impact
- Financial impact
- Regulatory/contractual impact
- Scope
- Persistence and attacker access
- Criticality of affected systems
- Ability to contain the incident
4. Confidentiality Impact
| Level | Assessment |
|---|---|
| Critical | Confirmed or highly credible exposure of highly sensitive, regulated, or large-scale customer/business information |
| High | Significant unauthorised access to confidential, customer, personal, financial, or security-sensitive information |
| Medium | Limited unauthorised access to confidential information |
| Low | No confirmed sensitive information exposure or exposure is negligible |
Questions
- Was information accessed?
- Was information downloaded?
- Was information exfiltrated?
- What classification did the information have?
- How many records or individuals were affected?
- Was customer or regulated information involved?
5. Integrity Impact
| Level | Assessment |
|---|---|
| Critical | Critical systems/data significantly modified, corrupted, or manipulated |
| High | Important systems or information materially altered |
| Medium | Limited modification of systems or information |
| Low | No meaningful integrity impact |
Examples
- Database modification
- Source-code modification
- Financial record alteration
- Security configuration manipulation
- Unauthorised application deployment
- Tampering with audit logs
6. Availability Impact
| Level | Assessment |
|---|---|
| Critical | Critical business/customer services unavailable for a significant period |
| High | Important services materially disrupted |
| Medium | Limited service disruption |
| Low | No meaningful service interruption |
Consider:
- Duration
- Number of affected users
- Criticality of service
- Customer impact
- Recovery complexity
- SLA commitments
7. Customer Impact
| Level | Assessment |
|---|---|
| Critical | Major or widespread customer impact, significant service disruption, or significant customer data exposure |
| High | Multiple customers materially affected |
| Medium | Limited number of customers affected |
| Low | No confirmed customer impact |
Record actual impact where known rather than estimating unnecessarily.
8. Personal or Regulated Data Impact
| Level | Assessment |
|---|---|
| Critical | Significant exposure or compromise of sensitive/regulated personal data or potentially major regulatory consequences |
| High | Confirmed unauthorised access to personal or regulated information |
| Medium | Limited personal data exposure or potential exposure requiring assessment |
| Low | No personal/regulated data involved |
Important: The severity classification does not itself determine whether regulatory notification is required. Applicable legal, regulatory, contractual, and privacy requirements should be separately assessed.
9. Business Impact
| Level | Assessment |
|---|---|
| Critical | Threatens critical business operations or ability to provide key services |
| High | Significant disruption to business operations |
| Medium | Limited operational disruption |
| Low | Negligible business impact |
Consider:
- Critical business processes
- Revenue-generating services
- Customer commitments
- Internal operations
- Business continuity requirements
- Recovery effort
10. Financial Impact
Where practical, estimate direct and reasonably identifiable financial impact.
| Level | Example |
|---|---|
| Critical | Major financial exposure or material business loss |
| High | Significant financial impact |
| Medium | Moderate financial impact |
| Low | Minor or negligible financial impact |
Do not delay incident response while attempting to calculate an exact financial amount.
11. Regulatory and Contractual Impact
| Level | Assessment |
|---|---|
| Critical | Potential significant regulatory, contractual, or legal consequences |
| High | Likely contractual/regulatory assessment or significant obligation |
| Medium | Possible notification, contractual review, or compliance impact |
| Low | No identified material regulatory/contractual impact |
Examples:
- Privacy requirements
- Customer security clauses
- Data-processing agreements
- Regulatory requirements
- Insurance requirements
- Contractual notification obligations
12. Scope
| Level | Typical Scope |
|---|---|
| Critical | Enterprise-wide, multiple critical systems, major customer population, or extensive compromise |
| High | Multiple systems, teams, environments, or customers |
| Medium | One important system, application, account, or limited group |
| Low | Individual endpoint, isolated event, or limited account |
13. Attacker Access and Persistence
| Level | Assessment |
|---|---|
| Critical | Confirmed active attacker access, privileged compromise, persistent access, or broad control |
| High | Confirmed compromise with meaningful access or potential lateral movement |
| Medium | Limited compromise or suspicious access with contained scope |
| Low | Attempted attack without confirmed compromise |
14. System Criticality
| Level | Example |
|---|---|
| Critical | Production platform, identity provider, critical database, core cloud account, security infrastructure |
| High | Important production application or business system |
| Medium | Internal business system or non-critical production component |
| Low | Non-critical endpoint or low-value system |
15. Severity Decision Matrix
Use the highest relevant impact as the starting point, then apply professional judgement based on the overall circumstances.
| Impact | Confidentiality | Integrity | Availability | Customer | Data/Regulatory | Suggested Severity |
|---|---|---|---|---|---|---|
| Very Significant | Critical | Critical | Critical | Critical | Critical | SEV-1 |
| Significant | High | High | High | High | High | SEV-2 |
| Limited | Medium | Medium | Medium | Medium | Medium | SEV-3 |
| Minor | Low | Low | Low | Low | Low | SEV-4 |
Escalation Rule
If different dimensions produce different severity levels, use the highest credible severity until investigation establishes that the higher impact is not applicable.
Example:
A compromised employee account normally appears to be a medium incident. However, if the account has privileged production access and there is evidence of access to customer data, the incident should be assessed at the higher applicable severity.
16. SEV-1 — Critical
Definition
A security incident with actual or potentially severe impact to critical systems, sensitive information, customers, or business operations.
Typical Examples
- Major ransomware affecting production
- Compromise of a critical cloud account
- Significant customer data breach
- Compromise of privileged identity infrastructure
- Major production outage caused by a security incident
- Large-scale data exfiltration
- Widespread compromise across multiple systems
- Significant supply-chain compromise affecting production
Response
- Immediate incident response
- Incident commander/lead assigned
- Senior management notified
- Security/IT leadership engaged
- Legal/privacy assessment initiated where relevant
- Evidence preservation prioritised
- Business continuity considered
- Customer/regulatory notification assessment initiated
- Frequent status updates
- Formal investigation and closure report required
17. SEV-2 — High
Definition
A significant security incident requiring urgent investigation and containment but with a more limited scope than SEV-1.
Typical Examples
- Compromised privileged user
- Confirmed cloud account compromise with limited scope
- Confirmed access to confidential customer information
- Significant malware infection
- Exploitation of a critical internet-facing vulnerability
- Compromised production application
- Significant supplier security incident
- Business email compromise involving financial or sensitive information
Response
- Urgent incident response
- Security/IT management notified
- Incident owner assigned
- Evidence preserved
- Containment initiated promptly
- Impact and data exposure assessed
- Corrective actions recorded
- Management review based on risk
18. SEV-3 — Medium
Definition
A contained incident with limited business or security impact requiring investigation and corrective action.
Typical Examples
- Single-user malware detection successfully contained
- Phishing email where no credentials were disclosed
- Limited unauthorised access attempt
- Low-impact policy violation
- Isolated endpoint security event
- Minor SaaS security incident with no confirmed sensitive data exposure
Response
- Incident ticket created
- Investigation performed
- Appropriate containment
- Evidence recorded
- Root cause assessed where relevant
- Corrective action assigned
- Closure documented
19. SEV-4 — Low
Definition
A minor security event or unsuccessful attempt with negligible impact.
Typical Examples
- Blocked phishing attempt
- Routine unsuccessful login attack
- Automated vulnerability scan
- Spam or malicious message blocked before user interaction
- Low-risk security policy deviation
Response
- Record event where required
- Monitor
- Apply routine remediation
- Escalate if additional evidence changes severity
20. Incident Severity Assessment Form
Incident
Incident ID:
Date/Time:
Assessor:
Confidentiality
☐ Critical
☐ High
☐ Medium
☐ Low
☐ None
Reason:
Integrity
☐ Critical
☐ High
☐ Medium
☐ Low
☐ None
Reason:
Availability
☐ Critical
☐ High
☐ Medium
☐ Low
☐ None
Reason:
Customer Impact
☐ Critical
☐ High
☐ Medium
☐ Low
☐ None
Reason:
Data/Regulatory Impact
☐ Critical
☐ High
☐ Medium
☐ Low
☐ None
Reason:
Business Impact
☐ Critical
☐ High
☐ Medium
☐ Low
☐ None
Reason:
Scope
☐ Critical
☐ High
☐ Medium
☐ Low
Reason:
Attacker Access
☐ Critical
☐ High
☐ Medium
☐ Low
☐ Attempt Only
Reason:
21. Final Severity
Initial Severity
Current Severity
Final Severity
Severity Rationale
Evidence Supporting Classification
22. Severity Escalation
An incident should be reassessed when new information indicates increased impact.
Escalation Triggers
☐ Customer data identified
☐ Personal/regulated data identified
☐ Additional systems affected
☐ Privileged account compromised
☐ Lateral movement identified
☐ Data exfiltration identified
☐ Production impact identified
☐ Attacker persistence identified
☐ Additional customers affected
☐ Supplier compromise identified
☐ Regulatory/contractual obligation identified
☐ Business continuity risk identified
☐ Scope significantly increased
☐ Other
Escalated From
Escalated To
Reason
Date/Time
23. Severity Downgrade
An incident may be downgraded where investigation establishes that the initially suspected impact did not occur.
Downgraded From
Downgraded To
Evidence Supporting Downgrade
Approved By
24. Response Requirements by Severity
| Activity | SEV-1 | SEV-2 | SEV-3 | SEV-4 |
|---|---|---|---|---|
| Incident Record | Required | Required | Required | As appropriate |
| Investigation | Detailed | Detailed | Standard | Basic |
| Evidence Preservation | Required | Required | As appropriate | As appropriate |
| Management Notification | Immediate | Prompt | As appropriate | Usually not required |
| Legal/Privacy Assessment | Promptly assess | Assess | As appropriate | Usually not required |
| Customer Impact Assessment | Required | Required | As appropriate | Usually not required |
| Root Cause Analysis | Required | Required | As appropriate | Optional |
| Corrective Action | Required | Required | As appropriate | As appropriate |
| Formal Closure Report | Required | Required | Recommended | Simplified |
| Management Review | Required | Recommended | As appropriate | Not normally required |
These are organisational response guidelines; applicable legal, regulatory, contractual, or customer obligations may require additional actions.
25. Communication Expectations
The severity level should help determine communication frequency.
| Severity | Suggested Communication |
|---|---|
| SEV-1 | Frequent updates until stabilised; management-level reporting |
| SEV-2 | Regular updates during containment and investigation |
| SEV-3 | Updates at major response milestones |
| SEV-4 | Update when material status changes |
The organisation should define exact communication channels and escalation contacts separately.
26. Example — AWS SaaS Incident
Scenario
A developer’s AWS access key is exposed.
Initial investigation shows:
- The key was used from an unusual location.
- S3 API calls occurred.
- No customer data access is initially confirmed.
- No privileged escalation is identified.
- The key is quickly disabled.
- CloudTrail shows limited activity.
- No persistence is found.
Initial Assessment
The incident may initially be treated as SEV-2 because an AWS credential was compromised and production/cloud resources were accessed.
Further investigation may establish that:
- Access was limited
- No sensitive customer data was accessed
- No privilege escalation occurred
- No persistence was established
- No customer service disruption occurred
The organisation may then reassess the severity based on the evidence and its defined criteria.
The important principle is:
Severity is based on the actual and credible potential impact, and should be reassessed as investigation evidence becomes available.
27. Severity Review Checklist
Before finalising the classification:
☐ Incident type identified
☐ Affected systems identified
☐ Affected identities identified
☐ Confidentiality impact assessed
☐ Integrity impact assessed
☐ Availability impact assessed
☐ Customer impact assessed
☐ Personal/regulated data assessed
☐ Business impact assessed
☐ Financial impact considered
☐ Regulatory/contractual impact assessed
☐ Scope assessed
☐ Privileged access assessed
☐ Lateral movement assessed
☐ Persistence assessed
☐ Data exfiltration assessed
☐ Initial severity recorded
☐ Current severity reviewed
☐ Escalation/downgrade documented where applicable
☐ Appropriate response level activated
28. Relationship With Incident Management
The severity matrix should operate as part of the broader incident management lifecycle:
Security Event
↓
Validate
↓
Classify
↓
Assign Severity
↓
Notify Appropriate Stakeholders
↓
Contain
↓
Investigate
↓
Eradicate
↓
Recover
↓
Reassess Severity
↓
Lessons Learned
↓
Close
Severity is therefore not a one-time decision. It should be updated when material facts change.
29. Audit Evidence Trail
A completed severity assessment should demonstrate:
Incident Detected
→ Incident Validated
→ Impact Assessed
→ Severity Assigned
→ Response Level Selected
→ Stakeholders Notified
→ Investigation Conducted
→ New Evidence Reviewed
→ Severity Reassessed
→ Containment/Recovery Completed
→ Final Severity Recorded
→ Incident Closed
30. ISO 27001 Connection
The Incident Severity Matrix supports the organisation’s incident management arrangements by providing a consistent risk-based method for classifying and prioritising information security incidents.
It can support activities related to:
- Information security incident management
- Security event assessment
- Incident response
- Logging and monitoring
- Access control
- Cloud security
- Vulnerability management
- Business continuity
- Supplier incidents
- Data protection
- Risk management
- Corrective action
The severity model should be aligned with the organisation’s risk criteria, business context, incident response capability, contractual obligations, and applicable legal/regulatory requirements.
31. Startup Implementation Approach
A startup can keep the model simple:
SEV-1 — Critical
Stop → Escalate → Contain → Investigate → Recover → Management Review
SEV-2 — High
Respond Quickly → Contain → Investigate → Remediate → Review
SEV-3 — Medium
Investigate → Contain → Correct → Monitor → Close
SEV-4 — Low
Record → Monitor → Correct if Required → Close
The objective is not to create unnecessary bureaucracy.
The objective is to ensure that a major incident receives materially different attention from a routine security event.
Final Principle
Validate the Event + Assess the Impact + Classify the Severity + Respond Proportionately + Reassess as Facts Change + Escalate When Necessary + Document the Decision.