1. Purpose

An Incident Escalation Matrix defines when an information security incident must be escalated, to whom, and within what timeframe.

It helps ensure that significant incidents receive the appropriate technical, management, legal, privacy, business continuity, customer, and supplier attention without unnecessary escalation of routine events.

The matrix should be aligned with the organization’s Incident Severity Matrix, risk assessment, contractual obligations, regulatory requirements, and incident response procedures.

---

2. Scope

This matrix applies to security incidents involving:

• Employee and administrator accounts
• Cloud platforms and infrastructure
• SaaS applications
• Customer information
• Personal or regulated information
• Production systems
• Endpoints and servers
• Source code and CI/CD environments
• Network infrastructure
• Suppliers and third parties
• Malware and ransomware
• Phishing and account compromise
• Data breaches
• Unauthorized access
• Vulnerability exploitation
• Availability or service disruption
• Loss or theft of information assets

---

3. Escalation Principles

Incident escalation should follow these principles:

1. Escalate based on risk and impact.
2. Start with the highest credible severity when facts are incomplete.
3. Escalate immediately when critical business, customer, security, privacy, or regulatory impact is suspected.
4. Do not delay containment while waiting for management approval.
5. Escalate when the incident exceeds the capability or authority of the current responder.
6. Reassess severity as investigation produces new facts.
7. Document every significant escalation and decision.
8. Maintain a clear incident owner throughout the incident lifecycle.

---

4. Incident Severity and Escalation

Severity	Typical Situation	Initial Escalation	Management Escalation	Target
SEV-1 Critical	Major breach, ransomware, critical cloud compromise, major production outage, significant customer impact	Incident Commander + Security Lead	Executive Management + Legal/Privacy + Business Owner	Immediate
SEV-2 High	Significant account compromise, limited breach, critical vulnerability exploitation, major supplier incident	Security Lead + Incident Manager	Relevant Business/IT Management	≤ 30 minutes
SEV-3 Medium	Contained malware, phishing with limited impact, isolated unauthorized access	Security/IT Team	Security or IT Manager as required	≤ 4 hours
SEV-4 Low	Blocked phishing, unsuccessful attack, routine security event, low-risk policy violation	IT/Security Team	Normally no management escalation	Business-as-usual

The organization may define different response targets based on its risk appetite, operating model, contractual commitments, and regulatory obligations.

---

5. Functional Escalation Matrix

Incident Condition	Escalate To	Reason
Suspicious security event	Security/IT Team	Initial validation
Confirmed security incident	Incident Manager	Formal incident management
SEV-1 incident	Incident Commander	Central coordination
Major production impact	Engineering/Operations Lead	Service restoration
Customer impact	Customer/Business Owner	Customer coordination
Personal data exposure	Privacy/Data Protection Lead	Privacy assessment
Regulatory impact	Legal/Compliance	Regulatory assessment
Contractual notification requirement	Legal/Contract Owner	Contract obligation
Financial fraud/BEC	Finance + Security + Management	Financial risk
Employee misconduct suspected	HR + Legal + Security	Personnel/legal assessment
Supplier-originated incident	Supplier Owner + Security	Third-party coordination
Cloud compromise	Cloud/Security Engineering	Technical containment
Ransomware	Security + IT + Business Continuity	Containment and recovery
Critical vulnerability exploitation	Security + Engineering	Emergency remediation
Major service outage	IT/Engineering + Business Owner	Business continuity
Media/public exposure	Executive Management + Legal/Communications	Controlled communication

---

6. SEV-1 Escalation

SEV-1 incidents require immediate escalation.

Examples

• Significant customer data breach
• Major ransomware attack
• Critical cloud account compromise
• Privileged administrator compromise
• Large-scale data exfiltration
• Major production compromise
• Widespread malware infection
• Critical supplier compromise affecting production
• Major business service outage caused by a security incident

Escalation Path

Security/IT Responder → Incident Commander → Security Leadership → Executive Management → Legal/Privacy → Business Owner → External Parties Where Required

Additional parties may include:

• Cloud provider
• Cyber insurance provider
• External incident response provider
• Certification body, where applicable
• Customers
• Regulators
• Law enforcement
• Other contractual stakeholders

External notification should only occur after the appropriate legal, privacy, contractual, regulatory, or management assessment.

---

7. SEV-2 Escalation

SEV-2 incidents require prompt management visibility.

Examples

• Compromised privileged employee account
• Limited cloud account compromise
• Unauthorized access to confidential information
• Exploitation of a critical internet-facing vulnerability
• Significant malware incident
• Business email compromise involving sensitive information
• Significant supplier security incident

Escalation Path

Security/IT Responder → Security/Incident Manager → Relevant IT/Business Manager → Legal/Privacy/Supplier Owner Where Applicable

Escalate to executive management if the impact increases or the incident becomes SEV-1.

---

8. SEV-3 Escalation

SEV-3 incidents can normally be managed by the operational security or IT team.

Examples

• Contained malware
• Phishing attempt where credentials were not disclosed
• Limited unauthorized access attempt
• Isolated endpoint security event
• Minor SaaS security issue
• Low-impact policy violation

Escalation should occur when:

• The event becomes more severe.
• Additional systems are affected.
• Customer information becomes involved.
• Credentials are compromised.
• Persistence is identified.
• Business impact increases.
• Investigation exceeds the team’s capability.

---

9. SEV-4 Escalation

SEV-4 events normally remain within routine operational processes.

Examples

• Blocked phishing email
• Automated vulnerability scanning
• Repeated unsuccessful login attempts
• Blocked malicious attachment
• Low-risk security policy deviation

SEV-4 events should still be logged where required by the organization’s monitoring and incident management processes.

Repeated SEV-4 events may indicate a systemic weakness and should be considered for trend analysis or risk assessment.

---

10. Immediate Escalation Triggers

Regardless of the original severity, immediately escalate an incident if any of the following are identified:

Identity

• Privileged account compromise
• Administrator credentials compromised
• MFA bypass or compromise
• API key or access key exposure
• Service account compromise

Data

• Customer information exposure
• Personal data exposure
• Financial information exposure
• Credentials or secrets exposed
• Source code or intellectual property exposure

Cloud

• Cloud root or privileged account compromise
• Unauthorized IAM role creation
• Security logging disabled
• Encryption controls modified
• Public exposure of sensitive storage
• Unauthorized production resource creation

Business

• Critical production outage
• Significant customer impact
• Material financial impact
• Major contractual impact
• Business continuity activation required

Threat Activity

• Active attacker persistence
• Lateral movement
• Data exfiltration
• Ransomware
• Destructive activity
• Repeated exploitation attempts

Third Parties

• Critical supplier compromise
• Cloud provider incident affecting the organization
• Subprocessor breach involving organizational data
• Supplier incident affecting customer services

---

11. Escalation Decision Logic

Use the following decision sequence:

Security Event Detected

↓

Is the event confirmed as an incident?

• No → Continue monitoring / close event
• Yes → Continue assessment

↓

Determine severity

↓

Is there customer, personal, regulated, financial, legal, contractual, or regulatory impact?

• Yes → Escalate to the relevant function
• No → Continue technical response

↓

Is the incident beyond the responder’s authority or capability?

• Yes → Escalate
• No → Continue response

↓

Has the impact increased?

• Yes → Reclassify and escalate
• No → Continue response

↓

Contain → Investigate → Eradicate → Recover → Verify → Close

---

12. Escalation Time Targets

Severity	Initial Response	Management Escalation	Reassessment
SEV-1	Immediate	Immediate	Continuous
SEV-2	≤ 30 minutes	≤ 1 hour	At major investigation milestones
SEV-3	≤ 4 hours	As required	At investigation milestones
SEV-4	Normal operational process	Normally not required	During routine review

These are organizational targets and should be adjusted according to business requirements and applicable obligations.

---

13. Escalation Contact Matrix

Maintain an approved contact list containing:

Role	Primary Contact	Backup Contact	Escalation Trigger	Availability
Incident Manager	Name/Contact	Name/Contact	Confirmed incident	24×7 / Business Hours
Security Lead	Name/Contact	Name/Contact	SEV-1/SEV-2	24×7
IT/Engineering Lead	Name/Contact	Name/Contact	Production impact	24×7
Privacy Lead	Name/Contact	Name/Contact	Personal data	As Required
Legal Counsel	Name/Contact	Name/Contact	Legal/regulatory issue	As Required
Business Owner	Name/Contact	Name/Contact	Business/customer impact	As Required
Executive Management	Name/Contact	Name/Contact	SEV-1	As Required
Supplier Owner	Name/Contact	Name/Contact	Supplier incident	As Required
Cloud Provider	Contact	Backup Contact	Cloud incident	As Required

Contact information should be maintained securely and tested periodically.

---

14. Internal Escalation Rules

The incident owner should escalate when:

• Required skills are unavailable.
• Required technical access is unavailable.
• The incident affects multiple teams.
• The incident involves privileged personnel.
• Evidence may be lost without specialist support.
• Legal or privacy expertise is required.
• Customer communication may be necessary.
• External investigation is required.
• Business continuity procedures may need activation.
• The incident cannot be contained within the expected timeframe.

---

15. External Escalation

External escalation may include:

• Cloud service provider
• SaaS provider
• Managed security service provider
• Cybersecurity incident response provider
• Cyber insurer
• Legal counsel
• Privacy counsel
• Regulators
• Law enforcement
• Customers
• Business partners
• Contractual stakeholders

External communication should be coordinated through authorized personnel.

Technical responders should not independently notify customers, regulators, media, or law enforcement unless the organization’s procedure explicitly authorizes them to do so.

---

16. AWS SaaS Startup Example

Scenario

A developer reports an unexpected AWS login.

The security team identifies:

• An unusual IAM authentication event.
• A newly created IAM role.
• An unexpected policy attachment.
• Access to production resources.

Initial Assessment

The event is treated as a potential SEV-1 or SEV-2 until investigation establishes the actual scope and impact.

Escalation

Developer → Security Team → Incident Manager → Cloud Engineering → Security Lead

Because privileged cloud activity is involved:

Security Lead → Executive Management

If customer or personal information may have been accessed:

Privacy/Legal → Business Owner

If the AWS environment requires provider assistance:

AWS Support/Security Contact → Incident Response Team

Response

The team can simultaneously:

1. Preserve CloudTrail and other relevant evidence.
2. Disable or restrict the compromised identity.
3. Revoke active sessions.
4. Rotate credentials and secrets.
5. Investigate IAM activity.
6. Review S3, RDS, ECS, Lambda and other affected resources.
7. Determine whether data was accessed or exfiltrated.
8. Assess customer and regulatory impact.
9. Reclassify severity based on evidence.
10. Continue containment and recovery.

The escalation process should not delay immediate containment actions that are necessary to reduce risk.

---

17. Escalation and Severity Reassessment

Incident severity is not necessarily fixed when the incident is first reported.

For example:

Phishing Email

→ Initially SEV-4

→ Employee clicked link

→ SEV-3

→ Credentials submitted

→ SEV-2

→ MFA session compromised

→ SEV-2/SEV-1 depending on impact

→ Production administrator accessed

→ Potential SEV-1

→ Customer data accessed

→ SEV-1 and privacy/legal assessment

This demonstrates why incident classification should be continuously reassessed as evidence becomes available.

---

18. Escalation Record

Each significant escalation should record:

Field	Description
Incident ID	Unique incident reference
Date/Time	Time of escalation
Current Severity	SEV-1/2/3/4
Previous Severity	Previous classification
Reason for Escalation	Trigger or new information
Escalated By	Person initiating escalation
Escalated To	Role/team/person
Information Provided	Key facts communicated
Decision	Action or response decision
Severity After Escalation	Updated classification
Follow-up Required	Required action
Owner	Responsible person
Evidence	Supporting records

---

19. Downgrade and De-escalation

An incident may be downgraded when investigation establishes that the assumed impact does not exist or is materially lower than initially believed.

Downgrading should be supported by evidence.

For example:

Suspected Data Breach → Investigation → No unauthorized data access confirmed → Severity reduced

The incident record should document:

• Evidence supporting the downgrade
• Person approving the decision
• Date/time
• Revised severity
• Remaining risks
• Any monitoring requirements

---

20. Escalation Failure Handling

If an escalation contact cannot be reached:

1. Attempt the primary contact.
2. Contact the designated backup.
3. Use the next management level.
4. Activate the emergency contact process where applicable.
5. Record the failed escalation attempts.
6. Continue technical containment and evidence preservation.
7. Document any resulting delay or risk.

Critical incidents should not remain unowned because a single escalation contact is unavailable.

---

21. Relationship With Other Incident Documents

The Incident Escalation Matrix should operate together with:

• Incident Management Policy
• Incident Response Procedure
• Incident Severity Matrix
• Incident Register
• Incident Investigation Template
• Incident Timeline Template
• Incident Closure Report
• Corrective Action Tracker
• Incident Communication Template
• Incident Notification Template
• Incident Response Playbooks
• Incident Response Contact List
• Business Continuity and Disaster Recovery Procedures

The Severity Matrix determines the level of the incident, while the Escalation Matrix determines who needs to be involved and when.

---

22. ISO 27001 Connection

Incident escalation supports the organization’s information security incident management process by ensuring that security events are assessed, handled, communicated, investigated, and followed through in a controlled manner.

The organization should determine its escalation requirements based on:

• Information security risks
• Business impact
• Asset and information criticality
• Customer requirements
• Legal and regulatory obligations
• Contractual commitments
• Incident severity
• Organizational responsibilities

The escalation matrix should therefore be treated as an operational control mechanism supporting the ISMS rather than as a standalone compliance checklist.

---

23. Startup Implementation Approach

A startup does not need a large security operations center to implement effective escalation.

A practical structure can be:

Founder/Executive
↓
Security/Compliance Lead
↓
Engineering/IT Lead
↓
Business/Customer Owner
↓
Legal/Privacy/Supplier Support

For a small team:

• One person may hold multiple roles.
• Primary and backup contacts should still be identified.
• Critical contacts should be available outside business hours.
• Escalation channels should be tested.
• Incident severity should be reassessed during investigation.
• Important decisions should be documented.

The objective is not to create a complicated hierarchy.

The objective is to ensure:

The Right Incident → Reaches the Right Person → At the Right Time → With Enough Information to Make the Right Decision.

---

24. Incident Escalation Audit Trail

A useful audit trail is:

Security Event Detected
→ Incident Confirmed
→ Severity Assigned
→ Escalation Trigger Identified
→ Incident Owner Assigned
→ Technical Team Escalated
→ Management Escalated Where Required
→ Privacy/Legal Assessed Where Required
→ Business Owner Informed Where Required
→ External Parties Engaged Where Required
→ Severity Reassessed
→ Containment Coordinated
→ Recovery Coordinated
→ Escalation Closed
→ Corrective Actions Assigned
→ Lessons Learned
→ Management Review

---

25. Final Principle

Detect the Incident + Classify the Severity + Escalate Early + Involve the Right People + Communicate Clearly + Reassess as Facts Change + Document Every Decision.

An effective escalation process ensures that incidents do not remain isolated within the technical team when they have broader business, customer, privacy, legal, regulatory, contractual, or operational consequences.