1. Purpose
The Event-to-Incident Decision Checklist provides a consistent, evidence-based method for determining whether a security event should remain an event or be escalated and managed as a formal information security incident.
The checklist helps the organization avoid two common problems:
- Treating every security alert as an incident
- Failing to escalate a genuine security incident because the initial event appeared low-risk
The decision should be based on available evidence, potential impact, scope, unauthorized activity, and risk.
2. Core Decision Principle
The basic decision flow is:
Security Alert / Event
↓
Validate
↓
Is the activity genuine?
↓
Assess unauthorized activity and impact
↓
Determine classification
↓
Does it meet the organization’s incident criteria?
↓
No → Record / Correct / Monitor / Close
Yes → Create Incident → Escalate → Investigate → Respond
If facts are incomplete but there is a credible possibility of significant compromise, the event should remain under investigation and be escalated appropriately rather than being closed prematurely.
3. Event Information
| Field | Details |
|---|---|
| Event ID | |
| Event Date/Time | |
| Date Reported | |
| Source | |
| Event Title | |
| Event Category | |
| Reporter / Detection System | |
| Investigator | |
| Affected Asset | |
| Affected Business Process | |
| Affected Environment | Production / Test / Development |
| Related Alert ID | |
| Related Event ID | |
| Related Incident ID |
4. Step 1 — Is the Event Genuine?
Determine whether the reported activity actually occurred.
Validation
- Alert/report is valid
- Activity confirmed in logs
- Affected system confirmed
- Account/identity confirmed
- Evidence available
- Alert is not a duplicate
- Alert is not a known false positive
Decision
Is the event genuine?
- Yes
- No
- Unknown
If No
Classify as:
CE-0 — False Positive
Record the evidence and close the event.
If Unknown
Do not close the event solely because evidence is incomplete.
Continue investigation and assess whether escalation is required.
5. Step 2 — Was the Activity Authorized?
Determine whether the activity was expected and approved.
Check:
- Approved change
- Approved maintenance
- Authorized administrator activity
- Authorized security testing
- Approved vulnerability scan
- Expected automation
- Expected cloud activity
- Expected user activity
- Expected supplier activity
Decision
Was the activity authorized?
- Yes
- No
- Possibly
- Unknown
If Clearly Authorized
The event may remain a routine security event unless another security concern exists.
If Unauthorized or Possibly Unauthorized
Continue the incident decision assessment.
6. Step 3 — Is There a Security Weakness?
Determine whether the event exposes a weakness even if there is no confirmed incident.
Examples:
- Missing MFA
- Excessive permissions
- Public cloud storage
- Weak configuration
- Overdue security patch
- Excessive account privileges
- Logging gap
- Inadequate monitoring
- Unapproved SaaS
- Supplier control weakness
- Security policy deviation
Decision
Does the event identify a security weakness?
- No
- Yes
- Unknown
If yes, consider:
CE-2 — Security Weakness
Create a corrective action and assess the associated risk.
A security weakness does not automatically mean a security incident occurred.
7. Step 4 — Is Unauthorized Access Confirmed?
Check whether someone or something accessed a system or information without authorization.
- No unauthorized access
- Attempted access only
- Suspicious access
- Possible unauthorized access
- Confirmed unauthorized access
- Unknown
Examples
Attempted:
Repeated failed login attempts with no successful authentication.
Possible:
Suspicious login followed by incomplete evidence.
Confirmed:
Authentication succeeded using compromised credentials and activity was not authorized.
Confirmed unauthorized access is a strong indicator that the event should be assessed as an incident.
8. Step 5 — Is There Evidence of Compromise?
Check for:
- Compromised credentials
- Malware execution
- Unauthorized privilege escalation
- Unauthorized configuration changes
- Unauthorized account creation
- Unauthorized cloud resources
- Persistence
- Lateral movement
- Data access
- Data exfiltration
- Source-code compromise
- CI/CD compromise
- Security-control manipulation
Decision
Is compromise confirmed?
- No
- Suspected
- Confirmed
- Unknown
Confirmed compromise generally requires formal incident handling.
9. Step 6 — Could Information Have Been Affected?
Determine whether the event could affect information.
Information Categories
- Public information
- Internal information
- Confidential information
- Restricted information
- Customer information
- Personal data
- Financial information
- Health information
- Credentials
- Secrets
- Source code
- Intellectual property
- Regulated information
Assessment
| Question | Result |
|---|---|
| Could information have been accessed? | |
| Could information have been changed? | |
| Could information have been disclosed? | |
| Could information have been deleted? | |
| Could information have been copied/exfiltrated? |
If significant information exposure is suspected or confirmed, escalate the assessment.
10. Step 7 — Assess Confidentiality, Integrity and Availability
Confidentiality
Was information potentially viewed, accessed, copied, or disclosed without authorization?
- No
- Possible
- Confirmed
Integrity
Was information, code, configuration, or a system potentially modified without authorization?
- No
- Possible
- Confirmed
Availability
Was a system or service disrupted or made unavailable?
- No
- Possible
- Confirmed
11. Step 8 — Assess Customer Impact
Determine whether customers may be affected.
- No customer impact
- Possible customer impact
- Confirmed customer impact
- Significant customer impact
- Unknown
Consider:
- Customer data
- Customer accounts
- Production service
- Service availability
- Customer transactions
- Customer confidentiality
- Contractual commitments
- Customer security commitments
Significant customer impact should trigger escalation according to the organization’s incident criteria.
12. Step 9 — Assess Personal or Regulated Data
Determine whether personal or regulated information may be involved.
- No
- Possible
- Confirmed
- Significant
- Unknown
If applicable, initiate the organization’s privacy/legal assessment process.
Do not wait for complete certainty before notifying the appropriate internal privacy/legal function when the potential impact warrants early assessment.
13. Step 10 — Assess Attacker Activity
Determine whether an attacker is involved.
| Level | Description |
|---|---|
| A0 | No attacker activity identified |
| A1 | Attempted activity |
| A2 | Suspicious activity |
| A3 | Confirmed unauthorized access |
| A4 | Confirmed privilege escalation or persistence |
| A5 | Active attacker / ongoing impact |
Current Level
A0 / A1 / A2 / A3 / A4 / A5
Higher levels should generally receive greater urgency and escalation.
14. Step 11 — Assess Persistence
Determine whether unauthorized access may continue.
- No persistence identified
- Possible persistence
- Suspected persistence
- Confirmed persistence
- Active persistence
- Unknown
Look for:
- New accounts
- New IAM roles
- New access keys
- Tokens
- OAuth applications
- SSH keys
- Scheduled tasks
- Backdoors
- Modified services
- CI/CD credentials
- Unauthorized integrations
Confirmed or active persistence should be treated as a significant incident indicator.
15. Step 12 — Assess Lateral Movement
Determine whether the activity moved between systems.
- None
- Attempted
- Possible
- Suspected
- Confirmed
- Unknown
Review:
- Authentication logs
- Network logs
- Cloud role assumptions
- Internal connections
- Database access
- Server access
- Endpoint activity
- CI/CD activity
- Source-code access
16. Step 13 — Assess Scope
Determine how broadly the event may have affected the organization.
| Scope | Description |
|---|---|
| S1 | Single user/asset |
| S2 | Limited systems/users |
| S3 | Multiple systems/business functions |
| S4 | Broad or organization-wide |
| S5 | Unknown |
Current Scope
S1 / S2 / S3 / S4 / S5
Unknown scope should not automatically be treated as low risk.
17. Step 14 — Assess Business Impact
Consider:
- Production availability
- Revenue
- Critical business processes
- Customer commitments
- Financial impact
- Operational disruption
- Contractual obligations
- Regulatory obligations
- Certification commitments
- Reputational considerations
- Business continuity
Business Impact
- None
- Low
- Medium
- High
- Critical
- Unknown
18. Step 15 — Check Immediate Escalation Triggers
Escalate immediately when applicable.
- Privileged account compromise
- Cloud administrator compromise
- Active attacker
- Ransomware
- Significant data exfiltration
- Customer data exposure
- Personal/regulated data exposure
- Production compromise
- Major production outage
- Security logging disabled/manipulated
- Critical supplier compromise
- Financial fraud/BEC
- Significant regulatory impact
- Significant contractual impact
- Business continuity activation
If one or more significant triggers exist, do not wait for the event to become fully understood before escalating to the appropriate response function.
19. Step 16 — Classify the Event
Use the organization’s Security Event Classification Matrix.
| Classification | Meaning |
|---|---|
| CE-0 | False Positive |
| CE-1 | Routine Security Event |
| CE-2 | Security Weakness |
| CE-3 | Suspected Incident |
| CE-4 | Confirmed Incident |
| CE-5 | Major/Critical Incident |
Current Classification
CE-0 / CE-1 / CE-2 / CE-3 / CE-4 / CE-5
Classification Rationale
20. Step 17 — Apply the Incident Decision
Question 1
Is there confirmed unauthorized access, compromise, or other activity that meets the organization’s incident definition?
- Yes → Create Incident
- No → Continue assessment
- Unknown → Continue investigation and assess escalation
Question 2
Is there credible evidence of potential significant impact even though facts are incomplete?
- Yes → Escalate / investigate as suspected incident
- No → Continue event management
Question 3
Is there only a security weakness without evidence of an incident?
- Yes → Security Weakness + Corrective Action
- No → Continue assessment
Question 4
Is the activity legitimate with no material security concern?
- Yes → Routine Event / False Positive
- No → Continue assessment
21. Decision Matrix
| Condition | Typical Decision |
|---|---|
| False positive | Close as CE-0 |
| Legitimate security-related activity | Record as CE-1 where appropriate |
| Security weakness only | CE-2 + corrective action |
| Suspicious activity with incomplete evidence | CE-3 + investigation/escalation |
| Confirmed unauthorized access | CE-4 + incident response |
| Confirmed compromise with significant impact | CE-4/CE-5 + immediate escalation |
| Major customer/data/business impact | CE-5 or applicable higher-severity incident |
| Unknown but potentially significant scope | Investigate + escalate based on credible risk |
This is a decision aid, not a substitute for professional judgment and the organization’s approved incident criteria.
22. Incident Creation Decision
Should an Incident Record Be Created?
- Yes
- No
- Pending further investigation
If Yes
Incident ID: __________________
Incident Title: __________________
Incident Severity: SEV-1 / SEV-2 / SEV-3 / SEV-4
Incident Commander / Owner: __________________
Response Playbook: __________________
If No
Reason:
23. Required Actions When Converting to an Incident
When the decision is Event → Incident:
- Create Incident ID
- Link original Event ID
- Preserve relevant evidence
- Assign Incident Owner
- Determine severity
- Activate appropriate response team
- Apply Incident Escalation Matrix
- Activate specialized playbook where applicable
- Begin incident timeline
- Assess customer impact
- Assess privacy/regulatory impact
- Assess business continuity impact
- Record containment actions
- Start investigation
- Track corrective actions
The original security event record should not be deleted. It should remain linked to the incident.
24. When an Event Should Remain an Event
An event may remain an event where:
- Activity was legitimate
- Alert was a false positive
- No unauthorized activity occurred
- No material impact exists
- A routine security event was detected and controlled
- A security weakness exists but there is no evidence of exploitation
- Required corrective action can be managed through normal risk/control processes
Example:
Automated vulnerability scan detects an outdated package.
No exploitation occurred.
Possible outcome:
CE-2 — Security Weakness
Create a corrective action rather than automatically creating an incident.
25. When an Event Should Become an Incident
Examples include:
Account Compromise
Suspicious login → investigation → stolen credentials confirmed → unauthorized access confirmed.
Decision: Create incident.
Cloud Compromise
Unexpected AWS IAM activity → unauthorized role creation → privilege escalation confirmed.
Decision: Create incident.
Data Exposure
Employee sends confidential customer information to an unauthorized recipient.
Decision: Assess as potential incident and initiate applicable privacy/security assessment.
Malware
EDR alert → malware execution confirmed → malicious process establishes persistence.
Decision: Create incident.
Ransomware
Endpoint alert → encryption activity confirmed → multiple systems affected.
Decision: Immediate incident escalation.
26. AWS SaaS Example
Initial Event
AWS monitoring reports an unusual login to a production AWS account.
Stage 1 — Validate
CloudTrail confirms the login occurred.
Result: Genuine event.
Stage 2 — Authorization
The user confirms they did not perform the login.
Result: Unauthorized activity suspected.
Stage 3 — Investigation
Security reviews:
- IAM
- MFA
- CloudTrail
- Role assumptions
- Access keys
- S3
- RDS
- ECS
- Security groups
- Secrets Manager
- CI/CD
An unfamiliar IAM role was created after the login.
Stage 4 — Classification
The event becomes:
CE-4 — Confirmed Incident
Stage 5 — Response
Create:
INC-2026-XXXX
Then:
- Contain the compromised identity
- Revoke sessions
- Rotate credentials
- Investigate privilege escalation
- Investigate data access
- Check persistence
- Preserve evidence
- Assess customer impact
- Determine incident severity
- Activate the appropriate response playbook
The original Security Event remains in the register and links to the incident.
27. Reassessment Rule
The Event-to-Incident decision is not necessarily final.
Reassess when:
- New evidence is discovered
- Scope increases
- Unauthorized access is confirmed
- Data exposure is identified
- Persistence is found
- Lateral movement is identified
- Customer impact changes
- Business impact increases
- A supplier confirms compromise
- An attacker remains active
Example:
CE-1 → CE-3 → CE-4 → CE-5
may occur as evidence develops.
Conversely, an event can be downgraded when evidence demonstrates that the initially suspected impact did not occur.
Every reclassification should be documented.
28. Decision Record
| Field | Details |
|---|---|
| Event ID | |
| Investigator | |
| Assessment Date/Time | |
| Initial Classification | |
| Final Classification | |
| Severity | |
| Unauthorized Activity | |
| C/I/A Impact | |
| Information Impact | |
| Customer Impact | |
| Business Impact | |
| Scope | |
| Attacker Activity | |
| Persistence | |
| Lateral Movement | |
| Incident Created | Yes / No |
| Incident ID | |
| Escalation Required | Yes / No |
| Decision Maker | |
| Decision Rationale | |
| Evidence References | |
| Corrective Action | |
| Residual Risk | |
| Closure Date |
29. Audit Evidence
The organization should retain:
- Event record
- Original alert/report
- Investigation checklist
- Evidence references
- Classification decision
- Severity assessment
- Escalation decision
- Incident record, if created
- Investigation timeline
- Corrective actions
- Reclassification records
- Closure decision
An auditor should be able to trace:
Security Alert → Security Event → Decision → Incident or Closure
30. Relationship With Other Documents
The checklist connects the following process:
Security Alert
↓
Security Alert Investigation Checklist
↓
Security Event Reporting Form
↓
Security Event Register
↓
Event-to-Incident Decision Checklist
↓
Security Event Classification Matrix
↓
Incident Severity Matrix
↓
Incident Escalation Matrix
If an incident is created:
Incident Register
↓
Incident Investigation
↓
Incident Response Playbook
↓
Corrective Action Tracker
↓
Incident Closure Report
↓
Lessons Learned / Management Review
31. Startup Implementation
A startup can implement this process without a complex GRC platform.
A simple workflow is:
Alert → Ticket/Event ID → Investigator → Decision Checklist → Event or Incident → Corrective Action → Closure
The minimum decision fields are:
Event ID
Alert Source
Event Description
Affected Asset
Evidence
Authorized?
Unauthorized Activity?
C/I/A Impact
Information Impact
Customer Impact
Business Impact
Attacker Activity
Scope
Classification
Incident Required?
Incident ID
Severity
Escalation
Action
Owner
Decision Rationale
Closure
The key is to ensure that the decision is consistent and documented, rather than dependent entirely on individual judgment.
32. ISO 27001 Alignment
This checklist supports organizational processes related to:
- Information security event reporting
- Assessment of information security events
- Information security incident management
- Logging and monitoring
- Access control
- Evidence preservation
- Corrective action
- Risk treatment
- Continual improvement
The checklist is an organizational implementation tool. ISO/IEC 27001 does not prescribe this exact decision tree or form.
The organization should define its own incident criteria based on its:
- Risk assessment
- ISMS
- Statement of Applicability
- Business context
- Customer commitments
- Legal/regulatory requirements
- Contractual obligations
33. Final Audit Trail
Security Alert/Event Detected
→ Event Recorded
→ Activity Validated
→ Authorization Checked
→ Security Weakness Assessed
→ Unauthorized Access Assessed
→ Compromise Assessed
→ Information Impact Assessed
→ C/I/A Impact Assessed
→ Customer/Business Impact Assessed
→ Attacker Activity Assessed
→ Persistence Assessed
→ Lateral Movement Assessed
→ Scope Determined
→ Event Classified
→ Incident Criteria Checked
→ Incident Created or Event Retained
→ Severity/ Escalation Determined
→ Response / Corrective Action
→ Reassessment
→ Residual Risk Considered
→ Decision Documented
→ Closure
Final Principle
Validate the Event + Establish Authorization + Assess Compromise + Assess Impact + Determine Scope + Apply Incident Criteria + Escalate Credible Risk + Create the Incident When Required + Preserve the Decision Trail.
The key distinction is simple:
An alert is a signal.
An event is something that occurred.
An incident is an event that meets the organization’s defined criteria for formal security-incident management.
The purpose of this checklist is to make that transition evidence-based, consistent, and auditable.