1. Purpose

The Security Event Classification Matrix provides a consistent method for classifying information security events based on their nature, credibility, potential impact, scope, and evidence.

The matrix helps the organization determine whether an event should be:

• Closed as a false positive
• Recorded as a routine security event
• Managed as a security weakness
• Treated as a suspected incident
• Declared as a confirmed security incident
• Escalated as a major or critical incident

The objective is to ensure that security events are assessed consistently while avoiding both under-reaction and unnecessary escalation.

---

2. Scope

This matrix applies to security events involving:

• Identity and authentication
• Access control
• Cloud environments
• Applications
• Databases
• Networks
• Endpoints
• Email
• Source code
• CI/CD
• SaaS platforms
• Customer information
• Personal data
• Confidential information
• Suppliers
• Physical assets
• Security controls
• Business operations

---

3. Classification Principles

Classification should be based on available evidence and should consider:

1. Is the event genuine?
2. Is unauthorized activity involved?
3. What security property is affected?
4. What information is involved?
5. What systems are affected?
6. What is the business impact?
7. What is the customer impact?
8. Is personal or regulated information involved?
9. Is an attacker active or persistent?
10. How widespread is the event?
11. Can the event be contained?
12. Are legal, regulatory, or contractual obligations potentially triggered?

Classification should be reassessed when new evidence becomes available.

---

4. Primary Event Classification

Classification	Meaning	Typical Action
CE-0 — False Positive	Alert or reported activity determined to be legitimate	Document and close
CE-1 — Routine Security Event	Genuine security-related activity with no material security impact	Record, monitor, close
CE-2 — Security Weakness	Event reveals a control weakness or policy deviation	Corrective action / risk treatment
CE-3 — Suspected Incident	Evidence indicates a credible possibility of security compromise, but facts are incomplete	Escalate and investigate
CE-4 — Confirmed Incident	Evidence confirms an information security incident	Activate incident response
CE-5 — Major/Critical Incident	Confirmed or highly credible incident with significant business, customer, security, regulatory, or operational impact	Immediate escalation and major incident response

---

5. CE-0 — False Positive

Use CE-0 when investigation demonstrates that the alert or reported activity was not actually a security event requiring response.

Examples

• Legitimate administrator activity incorrectly flagged.
• User login from a known VPN.
• Authorized vulnerability scan.
• Approved penetration test.
• Scheduled system activity.
• Expected automated cloud process.
• Security tool incorrectly triggering an alert.

Required Actions

• Record the assessment.
• Document why the alert was determined to be legitimate.
• Update detection rules if appropriate.
• Close the event.

Audit Evidence

Alert → Validation → Evidence → False Positive Decision → Closure

---

6. CE-1 — Routine Security Event

Use CE-1 when a genuine security-related event occurred but there is no evidence of material compromise.

Examples

• Blocked phishing email.
• Failed login attempts.
• Automated vulnerability scan.
• Malware blocked before execution.
• Unauthorized access attempt that was unsuccessful.
• Low-risk policy deviation.
• Routine security alert.

Required Actions

• Record event.
• Validate activity.
• Monitor where appropriate.
• Create corrective action if necessary.
• Close with documented reasoning.

---

7. CE-2 — Security Weakness

Use CE-2 when an event reveals a weakness requiring improvement even if no incident has occurred.

Examples

• MFA not enabled for a non-critical account where it should be.
• Excessive cloud permissions discovered.
• Security logs not retained for the expected period.
• Public cloud resource discovered but no evidence of access.
• Security patch overdue.
• Employee using an unapproved SaaS application.
• Supplier security control not operating as expected.

Required Actions

• Record the weakness.
• Assess associated risk.
• Assign corrective action.
• Track to closure.
• Reassess whether an incident occurred.

---

8. CE-3 — Suspected Incident

Use CE-3 when there is credible evidence suggesting compromise but the facts are incomplete.

Examples

• Suspicious privileged login with insufficient confirmation.
• Potential stolen credentials.
• Possible unauthorized database access.
• Suspicious cloud role creation.
• Endpoint exhibiting indicators of compromise.
• Potential customer-data exposure.
• Supplier reports suspicious activity but scope is unknown.

Required Actions

• Escalate to Security Lead.
• Preserve relevant evidence.
• Increase investigation.
• Assess severity.
• Consider containment.
• Activate an appropriate incident playbook if necessary.

Important Principle

Uncertainty should not prevent protective action when credible risk is present.

---

9. CE-4 — Confirmed Incident

Use CE-4 when evidence confirms that an information security incident has occurred.

Examples

• Confirmed compromised account.
• Confirmed malware execution.
• Unauthorized production access.
• Confirmed data exposure.
• Confirmed privilege escalation.
• Confirmed cloud compromise.
• Confirmed ransomware.
• Confirmed unauthorized source-code access.

Required Actions

• Activate Incident Response Procedure.
• Assign Incident Commander where appropriate.
• Determine severity.
• Preserve evidence.
• Contain the threat.
• Investigate.
• Assess impact.
• Communicate according to requirements.
• Recover.
• Track corrective actions.

---

10. CE-5 — Major/Critical Incident

Use CE-5 when an incident presents significant impact or credible risk to critical business operations, customers, information, or regulatory obligations.

Examples

• Major ransomware attack.
• Cloud administrator compromise affecting production.
• Significant customer-data breach.
• Large-scale data exfiltration.
• Widespread production compromise.
• Critical supplier compromise affecting customer services.
• Major security-driven outage.
• Significant financial fraud.
• Compromise affecting multiple critical systems.

Required Actions

• Immediate executive escalation.
• Activate major incident response.
• Assign Incident Commander.
• Involve Legal/Privacy where applicable.
• Activate BCP/DR where required.
• Coordinate customer/supplier communications.
• Preserve evidence.
• Establish frequent status updates.
• Assess notification obligations.
• Track recovery and corrective actions.

---

11. Classification Decision Matrix

Use the following decision logic.

Question	No	Yes
Is the alert/event genuine?	CE-0	Continue
Is there a security concern?	CE-1	Continue
Does it reveal a control weakness?	CE-2 may apply	Continue
Is unauthorized activity suspected?	Monitor/CE-2	Continue
Is compromise credible but unconfirmed?	CE-3	Continue
Is compromise confirmed?	CE-3	CE-4
Is impact significant/critical?	CE-4	CE-5
Is active attacker activity present?	Continue assessment	Immediate escalation
Is critical/customer/personal data affected?	Continue assessment	Escalate
Is critical production affected?	Continue assessment	Escalate

---

12. Impact Dimensions

Classification should consider the following dimensions.

12.1 Confidentiality

Level	Description
None	No information exposure
Low	Low-sensitivity information potentially exposed
Medium	Confidential information involved
High	Sensitive customer, personal, regulated, financial, or strategic information involved
Critical	Significant or widespread sensitive information exposure

---

12.2 Integrity

Level	Description
None	No unauthorized modification
Low	Minor non-critical change
Medium	Business information or configuration modified
High	Production/application/database changes
Critical	Critical systems or data materially compromised

---

12.3 Availability

Level	Description
None	No service impact
Low	Minor degradation
Medium	Limited service disruption
High	Significant production disruption
Critical	Major or widespread service outage

---

13. Customer Impact

Level	Description
None	No customer impact
Low	Internal event with no customer effect
Medium	Limited customer impact
High	Significant impact to one or more customers
Critical	Widespread or material customer impact

Customer impact should be based on confirmed facts where possible.

---

14. Data Classification Impact

Level	Example
None	No sensitive information
Low	Internal information
Medium	Confidential business information
High	Customer or personal information
Critical	Significant regulated, financial, health, authentication, or other highly sensitive information

---

15. Scope Assessment

Scope	Description
S1 — Isolated	One user, device, account, or system
S2 — Limited	Small number of users/systems
S3 — Broad	Multiple systems/business functions
S4 — Widespread	Enterprise-wide or multiple customers
S5 — Unknown	Scope cannot currently be determined

Unknown scope should not automatically be classified as low risk.

---

16. Attacker Activity

Level	Description
A0	No malicious activity identified
A1	Attempted activity
A2	Suspicious activity
A3	Confirmed unauthorized access
A4	Confirmed privilege/persistence
A5	Active attacker with ongoing access or impact

A4 and A5 activity should normally trigger immediate escalation.

---

17. Persistence Assessment

Consider whether an attacker could maintain access.

Level	Description
None	No evidence of persistence
Possible	Persistence cannot be excluded
Suspected	Indicators suggest persistence
Confirmed	Persistence mechanism identified
Active	Attacker currently has ongoing access

---

18. Business Criticality

Level	Description
Low	Non-critical system/process
Medium	Important business system
High	Critical business process
Critical	Core production/customer/revenue system

---

19. Regulatory and Contractual Impact

Consider whether the event may involve:

• Personal data
• Financial information
• Health information
• Regulated information
• Customer contractual commitments
• Security commitments
• Certification requirements
• Regulatory reporting requirements
• Breach notification requirements

Where the answer is potentially yes, involve the appropriate Privacy, Legal, Compliance, or business owner early.

---

20. Overall Classification Guidance

A practical classification approach is:

Low Concern

Typically:

CE-0 / CE-1

Examples:

• False positive
• Blocked phishing
• Failed login
• Routine vulnerability scan

Control Weakness

Typically:

CE-2

Examples:

• Misconfiguration
• Missing security control
• Excessive permissions
• Retention weakness

Credible Suspicion

Typically:

CE-3

Examples:

• Possible account compromise
• Suspicious privileged activity
• Potential data exposure

Confirmed Security Incident

Typically:

CE-4

Examples:

• Confirmed compromised account
• Confirmed unauthorized access
• Confirmed malware
• Confirmed data exposure

Significant Incident

Typically:

CE-5

Examples:

• Major ransomware
• Significant data breach
• Critical cloud compromise
• Widespread production compromise

---

21. Severity Relationship

The Event Classification and Incident Severity are related but should not be treated as identical.

For example:

Event Classification	Possible Severity
CE-0	N/A
CE-1	Usually N/A / Low
CE-2	Usually N/A / Low
CE-3	SEV-3 to SEV-1 depending on risk
CE-4	SEV-4 to SEV-1 depending on impact
CE-5	Usually SEV-1 / Critical

The final severity should be determined using the organization’s Incident Severity Matrix.

---

22. Examples

Example 1 — Blocked Phishing

An employee receives a phishing email.

The email is blocked before delivery.

No user interaction occurs.

Classification: CE-1 — Routine Security Event

Action: Record and monitor.

---

Example 2 — Phishing Link Clicked

An employee clicks a phishing link but does not enter credentials.

Endpoint and email security controls show no evidence of compromise.

Classification: CE-1 or CE-2 depending on the control weakness identified.

Action: Investigate, monitor, and address awareness/control gaps.

---

Example 3 — Possible Credential Compromise

An employee reports entering credentials into a suspicious website.

No unauthorized login is confirmed yet.

Classification: CE-3 — Suspected Incident

Action: Preserve evidence, reset credentials, revoke sessions where appropriate, investigate authentication activity, and assess further impact.

---

Example 4 — Confirmed Account Compromise

Authentication logs confirm unauthorized access to the employee’s account.

Classification: CE-4 — Confirmed Incident

Action: Activate Account Compromise Playbook.

---

Example 5 — AWS Administrator Compromise

CloudTrail confirms unauthorized use of a privileged AWS identity, followed by IAM policy changes.

Classification: CE-4 or CE-5 depending on impact.

Action: Immediate escalation, evidence preservation, identity containment, investigation, and cloud compromise response.

---

Example 6 — Customer Data Exposure

Unauthorized access to a storage location containing customer personal information is confirmed.

Classification: CE-4 or CE-5 depending on scope and impact.

Action: Incident response + privacy assessment + legal/regulatory assessment.

---

23. AWS SaaS Classification Example

Consider a SaaS startup operating on AWS.

Event

Security monitoring reports:

New IAM role created in the production AWS account.

Initial Assessment

The security team determines:

• The role was not approved.
• It has administrative permissions.
• The role was created by an unfamiliar identity.
• CloudTrail confirms subsequent activity.

Classification

The event is no longer a routine security alert.

It becomes:

CE-3 → Suspected Incident

If unauthorized access is confirmed:

CE-4 → Confirmed Incident

If the attacker accesses customer data and affects production:

CE-5 → Major/Critical Incident

The classification should evolve as evidence develops.

---

24. Classification Record

Each event assessment should record:

Event Details

Event ID:
Date/Time:
Source:
Event Type:
Affected Asset:

Assessment

Genuine Event: Yes / No
Unauthorized Activity: Yes / No / Unknown
Confidentiality Impact:
Integrity Impact:
Availability Impact:
Customer Impact:
Data Impact:
Business Impact:
Scope:
Attacker Activity:
Persistence:
Regulatory/Contractual Impact:

Classification

CE-0 / CE-1 / CE-2 / CE-3 / CE-4 / CE-5

Incident Severity

SEV-1 / SEV-2 / SEV-3 / SEV-4 / N/A

Decision

Describe why the classification was selected.

Evidence

List supporting evidence.

Escalation

Record who was notified and when.

Follow-up

Record investigation, corrective action, monitoring, or incident response.

Assessor

Name / Role / Date

---

25. Reclassification Rules

An event classification should be updated when new evidence materially changes the assessment.

Examples:

CE-1 → CE-3

A routine phishing event reveals that credentials may have been submitted.

CE-3 → CE-4

Investigation confirms unauthorized account access.

CE-4 → CE-5

Investigation confirms widespread customer-data exposure.

CE-4 → CE-2

Investigation determines no incident occurred but identifies a significant security weakness.

Every reclassification should document:

• Previous classification
• New classification
• Evidence causing the change
• Decision maker
• Date/time
• Impact on response

---

26. Escalation Triggers

Regardless of initial classification, immediately escalate when there is credible evidence of:

• Active attacker
• Privileged account compromise
• Cloud administrator compromise
• Ransomware
• Significant data exfiltration
• Customer/personal-data exposure
• Critical production compromise
• Major security-driven outage
• Widespread malware
• Critical vulnerability exploitation
• Security controls being deliberately disabled
• Significant supplier compromise
• Major financial fraud
• Regulatory or contractual notification concerns

---

27. Relationship With Incident Management

The classification matrix works as part of the wider incident-management lifecycle:

Security Alert

↓

Security Event

↓

Event Assessment

↓

Classification Matrix

↓

False Positive / Routine Event / Weakness / Suspected Incident / Confirmed Incident

↓

Severity Assessment

↓

Escalation

↓

Incident Response

↓

Investigation

↓

Recovery

↓

Corrective Action

↓

Closure

---

28. Roles and Responsibilities

Role	Responsibility
Security/IT Team	Initial event assessment
Security Lead	Classification and escalation
Incident Commander	Major incident classification/coordination
Investigator	Evidence-based assessment
Cloud/IT Team	Technical impact assessment
Application/DevOps	Application and production assessment
Privacy	Personal-data assessment
Legal/Compliance	Regulatory and contractual assessment
Business Owner	Business impact assessment
Supplier Owner	Third-party event assessment
Executive Management	Major incident decisions and risk acceptance

---

29. Common Classification Errors

Avoid:

1. Treating Every Alert as an Incident

A security alert requires assessment before incident declaration.

2. Treating Every Event as Low Risk

A seemingly small event may reveal a serious control weakness.

3. Waiting for Complete Certainty

Active threats may require containment before investigation is complete.

4. Ignoring Unknown Scope

Unknown scope should trigger additional investigation.

5. Confusing Access With Exfiltration

Unauthorized access does not automatically prove that information was copied or exfiltrated.

6. Failing to Reclassify

Classification should change when evidence changes.

7. Ignoring Business Impact

Technical impact alone may not reflect the actual severity.

8. Ignoring Privacy Impact

Personal-data involvement should be assessed early.

---

30. Startup Implementation Model

A startup can implement the matrix using a simple ticketing system or security-event register.

Minimum fields:

Event ID → Date → Source → Description → Asset → Evidence → C/I/A → Data → Customer Impact → Scope → Attacker Activity → Classification → Severity → Action → Owner → Status → Closure

The organization does not need a complex SOC platform to implement a consistent classification process.

The key requirement is that decisions are:

Consistent + Risk-Based + Evidence-Supported + Traceable.

---

31. ISO 27001 Connection

The Security Event Classification Matrix supports the organization’s process for assessing and responding to information security events.

It can support activities associated with:

• Information security event reporting
• Assessment of information security events
• Incident management
• Incident response
• Logging and monitoring
• Access control
• Evidence preservation
• Communication
• Corrective action
• Continual improvement

The organization’s exact classification thresholds should be aligned with its:

• Risk assessment
• Security objectives
• Business context
• Incident criteria
• Legal and regulatory obligations
• Customer commitments
• Statement of Applicability

ISO 27001 should not be interpreted as requiring these exact CE-0 to CE-5 labels. They are an organizational mechanism for consistently implementing a risk-based event assessment process.

---

32. Audit Evidence

Useful audit evidence includes:

• Security Event Classification Matrix
• Information Security Event Assessment Procedure
• Security Event Register
• Event Assessment Records
• Security Alerts
• Investigation Records
• Incident Severity Assessments
• Escalation Records
• Evidence Preservation Records
• Incident Reports
• Corrective Action Records
• Incident Closure Reports
• Tabletop Exercise Records

An auditor should be able to trace:

Event → Evidence → Assessment → Classification → Severity → Escalation → Response → Corrective Action → Closure

---

33. Final Audit Trail

Security Event Detected
↓
Event Recorded
↓
Event Validated
↓
Evidence Preserved
↓
C/I/A Impact Assessed
↓
Information Impact Assessed
↓
Customer/Business Impact Assessed
↓
Scope Assessed
↓
Attacker Activity Assessed
↓
Event Classified
↓
Incident Severity Determined
↓
Escalation Performed Where Required
↓
Incident Response / Corrective Action / Monitoring Initiated
↓
Classification Reassessed as Evidence Changes
↓
Residual Risk Assessed
↓
Decision Documented
↓
Event/Incident Closed

---

Final Principle

Classify the Facts + Assess the Impact + Consider the Risk + Escalate Credible Threats + Reclassify When Evidence Changes + Document Every Decision.