Security Alert Investigation Checklist

1. Purpose

The Security Alert Investigation Checklist provides a consistent method for reviewing, validating, investigating, classifying, and closing security alerts.

It helps the Security/IT team determine whether an alert is:

A false positive
Legitimate business activity
A routine security event
A security weakness
A suspected security incident
A confirmed security incident
A major or critical incident

The checklist also helps ensure that important evidence is preserved and that significant alerts are properly recorded in the Security Event Register or escalated into the Incident Management Process.

2. When to Use This Checklist

Use this checklist for alerts generated by:

SIEM
EDR/XDR
Cloud security monitoring
IAM/SSO
AWS CloudTrail
GuardDuty
Security Hub
WAF
Firewall
Vulnerability scanners
Email security
Endpoint security
DLP
Application monitoring
Database monitoring
Network monitoring
CI/CD security tools
SaaS security monitoring
Third-party security services
Employee security reports

3. Investigation Principle

A security alert should not automatically be treated as a security incident.

The investigation should follow:

Alert → Validate → Understand → Correlate → Assess Impact → Classify → Escalate/Respond → Document → Close

Where necessary:

Alert → Security Event → Incident

4. Alert Identification

Field	Details
Alert ID
Alert Date
Alert Time
Time Zone
Detection Source
Alert Rule / Signature
Alert Name
Alert Severity from Tool
Assigned Investigator
Investigation Start
Investigation Deadline
Related Event ID
Related Incident ID

5. Initial Alert Review

Basic Checks

Alert received from an authorized security monitoring source
Alert ID recorded
Date/time recorded
Detection source identified
Alert rule/signature identified
Affected asset identified
Affected account/identity identified
Source IP identified where available
Destination/resource identified where applicable
Alert details preserved
Initial severity recorded
Duplicate alert checked

Initial Question

What exactly triggered the alert?

Avoid interpreting the alert before establishing the underlying facts.

6. Validate the Alert

Determine whether the alert represents genuine activity.

Validation Questions

Did the activity actually occur?
Is the affected system active?
Is the account valid?
Is the IP address expected?
Is the device known?
Is the application/process legitimate?
Was there an approved change?
Was maintenance scheduled?
Was security testing occurring?
Was vulnerability scanning occurring?
Is the activity generated by automation?
Is the alert rule known to generate false positives?
Is there evidence that the alert is legitimate?

Validation Result

False Positive
Legitimate Activity
Security Event
Security Weakness
Suspected Incident
Confirmed Incident
Major/Critical Incident
Unable to Determine

7. Identify the Affected Asset

Record all affected assets.

Asset Information

Field	Details
Asset
Asset Type	Laptop / Server / Application / Cloud / SaaS / Database / Network
Owner
Business Owner
Environment	Production / Development / Test
Criticality	Low / Medium / High / Critical
Location / Region
Internet Exposure	Yes / No
Customer Facing	Yes / No

Related Assets

User account
Privileged account
Server
Endpoint
Cloud account
Database
Storage
Application
API
Network
CI/CD
Source-code repository
SaaS application
Supplier system

8. Identify the Account or Identity

Where an identity is involved, determine:

Username identified
User verified
Account type identified
Privileged access checked
MFA status checked
Authentication method identified
Source location checked
Device checked
Recent password reset checked
Recent privilege change checked
Recent role/group change checked
Active sessions checked
API keys/tokens checked
OAuth/application access checked

Identity Assessment

Is the activity consistent with the user’s normal activity?

Yes
No
Unknown

9. Investigate the Timeline

Establish what happened before and after the alert.

Timeline

Time	Event	Source	Evidence

Investigate:

Activity immediately before alert
Triggering event
Activity immediately after alert
Previous related events
Subsequent activity
Similar alerts
Authentication activity
Privilege changes
Configuration changes
Data access
Network activity

Timeline Questions

What happened first?
What happened next?
Was there a sequence of related events?
Was the activity isolated?
Did activity continue after detection?
Is there evidence of persistence?

10. Correlate Security Data

Do not investigate an alert in isolation when additional data is available.

Correlate with:

Identity

Authentication logs
SSO logs
MFA logs
IAM logs
Privilege changes

Endpoint

EDR/XDR
Process activity
File activity
Malware alerts
Network connections

Network

Firewall
VPN
DNS
Proxy
Network flow logs
WAF

Application

Application logs
API logs
Authentication
Administrative activity
Error logs

Cloud

CloudTrail
CloudWatch
GuardDuty
Security Hub
IAM
S3
RDS
ECS/EKS
Lambda
VPC Flow Logs
WAF

Development

Source-code repository
CI/CD logs
Deployment records
Secrets management
Dependency alerts

11. Determine Whether Activity Was Authorized

Ask:

Was this activity expected?
Was it performed by an authorized person?
Was there a business requirement?
Was there an approved change?
Was there a maintenance window?
Was there a security test?
Was there an automation process?
Was the account authorized for this activity?
Were the permissions appropriate?

Authorization Result

Authorized
Unauthorized
Possibly Unauthorized
Unknown

Supporting Evidence

12. Investigate Privilege Changes

Check for:

New user
New IAM role
New administrator
Group membership change
Privilege escalation
Policy modification
Security-control modification
MFA modification
API key creation
Token creation
Service account creation
OAuth authorization
Administrative configuration change

If unauthorized privilege escalation is suspected, escalate according to the Incident Escalation Matrix.

13. Investigate Persistence

Determine whether an attacker or unauthorized user could maintain access.

Check:

New accounts
New roles
New access keys
API tokens
OAuth applications
Scheduled tasks
Startup processes
Backdoors
Modified CI/CD credentials
New SSH keys
Modified cloud policies
Unauthorized integrations

Persistence Assessment

None identified
Possible
Suspected
Confirmed
Active

14. Investigate Data Access

Determine whether information was accessed.

Check:

Customer data
Personal data
Financial information
Confidential information
Credentials
Secrets
Source code
Intellectual property
Production database
Cloud storage
Backups
Logs
Security configuration

Data Access Result

No evidence of access
Possible access
Confirmed access
Data exfiltration suspected
Data exfiltration confirmed
Unknown

15. Investigate Lateral Movement

Determine whether activity moved from one system to another.

Check:

Authentication to additional systems
Remote access
Internal network connections
Privilege reuse
Credential reuse
Service-account activity
Cloud role assumption
Database access
Server-to-server activity
CI/CD access
Source-code access

Lateral Movement Result

None identified
Possible
Suspected
Confirmed
Unknown

16. Cloud / AWS Investigation

For AWS-related alerts, review the relevant services.

Identity

IAM
IAM roles
IAM policies
SSO
MFA
Access keys
STS AssumeRole activity

Logging

CloudTrail
CloudWatch
VPC Flow Logs

Detection

GuardDuty
Security Hub
AWS Config

Infrastructure

EC2
ECS/EKS
Lambda
RDS
S3
Security Groups
VPC
Load Balancers

Secrets and Data

Secrets Manager
KMS
S3 access
Database access
Backup/snapshot activity

AWS Investigation Questions

Was a new IAM role created?
Were privileges changed?
Was an access key created?
Was an unusual region accessed?
Were resources created unexpectedly?
Were security groups changed?
Was logging disabled?
Was customer data accessed?
Were secrets accessed?
Were backups modified or deleted?
Was infrastructure changed?
Was CI/CD accessed?

17. Determine Attack Activity

Assess whether there is evidence of malicious or unauthorized activity.

Indicator	Result
Unauthorized authentication
Credential misuse
Privilege escalation
Malware
Exploitation
Data access
Data exfiltration
Persistence
Lateral movement
Security-control modification
Destructive activity

Attacker Activity

A0 — None identified
A1 — Attempted
A2 — Suspicious
A3 — Confirmed unauthorized access
A4 — Confirmed privilege/persistence
A5 — Active attacker / ongoing impact

18. Preserve Evidence

Before making significant investigative or containment changes, preserve relevant evidence where practical.

Alert details saved
Relevant logs preserved
Screenshots captured where useful
Email/message preserved
Cloud activity preserved
Endpoint evidence preserved
Network evidence preserved
Configuration state recorded
Timeline established
Evidence IDs assigned
Evidence storage secured
Access restricted
Chain of custody maintained where required

Refer to the organization’s Evidence Preservation Procedure.

If immediate containment is necessary, protecting the environment takes priority over delaying action solely to preserve evidence.

19. Assess Impact

Confidentiality

None
Low
Medium
High
Critical
Unknown

Integrity

None
Low
Medium
High
Critical
Unknown

Availability

None
Low
Medium
High
Critical
Unknown

Customer Impact

None
Possible
Confirmed
Significant
Unknown

Personal / Regulated Data

None
Possible
Confirmed
Significant
Unknown

Business Impact

None
Low
Medium
High
Critical
Unknown

20. Determine Scope

Estimate the affected scope.

Scope	Description
S1	Isolated asset/user
S2	Limited systems/users
S3	Multiple systems/business functions
S4	Broad or organization-wide
S5	Scope unknown

Unknown scope should not automatically be treated as low risk.

21. Determine Event Classification

Based on the investigation:

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

Classification Rationale

22. Determine Incident Severity

If the alert represents or may represent an incident, assess severity using the Incident Severity Matrix.

SEV-1 — Critical
SEV-2 — High
SEV-3 — Medium
SEV-4 — Low
Not applicable

Severity Rationale

23. Escalation Check

Immediately escalate where applicable:

Privileged account compromise
Cloud administrator compromise
Active attacker
Ransomware
Significant data exposure
Customer impact
Personal/regulated data exposure
Production compromise
Major outage
Significant financial fraud
Critical supplier compromise
Security logging manipulation
Regulatory/contractual impact
BCP/DR activation required

Escalation Decision

No escalation required
Security Lead
IT/Cloud Lead
Incident Commander
Privacy/Legal
Business Management
Executive Management
Supplier
External Incident Response
Other

24. Response Actions

Depending on the investigation, actions may include:

Monitor
Block malicious activity
Disable account
Revoke sessions
Rotate credentials
Remove unauthorized access
Isolate endpoint
Isolate workload
Block IP/domain
Remove malware
Patch vulnerability
Correct configuration
Restore secure configuration
Investigate data exposure
Activate incident response
Notify supplier
Conduct privacy/legal assessment
Initiate business continuity response

Record all significant actions.

25. Corrective Actions

If the alert identifies a weakness, create a corrective action.

Finding	Corrective Action	Owner	Target Date	Verification

Examples:

Finding: Administrative account does not have MFA.

Corrective Action: Enforce MFA for all privileged accounts.

Verification: Review identity configuration and authentication logs.

26. Investigation Conclusion

Investigation Summary

Final Determination

False Positive
Legitimate Activity
Routine Security Event
Security Weakness
Suspected Incident
Confirmed Incident
Major/Critical Incident

Related Record

Security Event ID: __________________

Incident ID: __________________

Corrective Action ID: __________________

27. Closure Checklist

Alert investigated
Alert source validated
Affected asset identified
Identity investigated
Timeline established
Related events reviewed
Evidence preserved
Data access assessed
Lateral movement assessed
Persistence assessed
Scope assessed
C/I/A impact assessed
Customer impact assessed
Classification assigned
Severity assessed
Escalation completed where required
Incident record created where required
Corrective actions assigned
Residual risk considered
Security Event Register updated
Investigation conclusion documented
Closure approved

28. AWS SaaS Investigation Example

Alert

AWS GuardDuty generates an alert for suspicious API activity associated with a developer identity.

Investigation

The investigator:

Records the alert.
Creates or links a Security Event ID.
Reviews CloudTrail events.
Confirms the identity involved.
Checks MFA and authentication activity.
Reviews the source IP/location.
Checks recent IAM changes.
Reviews assumed roles.
Checks S3 access.
Checks RDS activity.
Reviews ECS/EC2 activity.
Checks Secrets Manager and KMS activity.
Reviews security-group changes.
Checks CI/CD activity.
Determines whether customer data was accessed.
Checks for persistence.
Checks lateral movement.
Preserves relevant evidence.
Determines scope.
Classifies the event.
Assesses incident severity if required.
Escalates if necessary.
Creates an incident record if unauthorized activity is confirmed.
Tracks corrective actions.
Documents the final determination.

The important principle is that the investigator does not conclude “AWS alert = incident.”

The evidence determines the classification.

29. Investigation Quality Checks

Before closing the investigation, ask:

Facts

What actually happened?
What evidence supports the conclusion?

Authorization

Was the activity authorized?
Was there an approved change?

Scope

What systems were affected?
What identities were involved?
What information could have been accessed?

Threat

Was unauthorized access confirmed?
Was privilege escalation identified?
Was persistence identified?
Was lateral movement identified?

Impact

Was confidentiality affected?
Was integrity affected?
Was availability affected?
Were customers affected?
Was personal or regulated information involved?

Response

Was the threat contained?
Was evidence preserved?
Were required stakeholders notified?
Were corrective actions assigned?

Closure

Is the conclusion supported by evidence?
Are related records linked?
Has residual risk been considered?
Is management review required?

30. Audit Evidence

For audit purposes, retain:

Alert record
Alert investigation checklist
Security Event ID
Evidence references
Investigation timeline
Log analysis
Classification decision
Severity assessment
Escalation record
Incident record, where applicable
Corrective action
Closure decision

An auditor should be able to select a security alert and trace:

Alert → Investigation → Evidence → Classification → Response → Corrective Action → Closure

31. Relationship With Other Security Documents

The checklist works with:

Security Alert
↓
Security Alert Investigation Checklist
↓
Security Event Reporting Form
↓
Security Event Register
↓
Security Event Classification Matrix
↓
Incident Severity Matrix
↓
Incident Escalation Matrix
↓
Incident Investigation / Response
↓
Corrective Action Tracker
↓
Incident Closure Report

This creates a controlled process from automated detection through final resolution.

32. ISO 27001 Alignment

This checklist supports the organization’s implementation of processes related to:

Information security event reporting
Information security event assessment
Incident management
Logging and monitoring
Access control
Evidence preservation
Corrective action
Continual improvement

The checklist is an organizational implementation tool and is not itself a prescribed ISO/IEC 27001 document.

Its fields and thresholds should be tailored to the organization’s:

ISMS
Risk assessment
Statement of Applicability
Security architecture
Incident response process
Legal/regulatory requirements
Customer and contractual commitments

33. Final Audit Trail

Security Alert Generated
→ Alert Recorded
→ Alert Validated
→ Affected Asset Identified
→ Identity Investigated
→ Timeline Established
→ Related Events Correlated
→ Evidence Preserved
→ Data Access Assessed
→ Persistence Assessed
→ Lateral Movement Assessed
→ Scope Determined
→ C/I/A Impact Assessed
→ Customer/Business Impact Assessed
→ Classification Assigned
→ Severity Assessed
→ Escalation Decision
→ Incident Created if Required
→ Response / Corrective Action
→ Reassessment
→ Residual Risk Considered
→ Investigation Closed

Final Principle

Validate the Alert + Establish the Facts + Correlate the Evidence + Investigate Identity and Activity + Assess Impact + Classify Based on Evidence + Escalate When Required + Document the Decision.

A security alert is a signal, not automatically an incident. The investigation process converts that signal into an evidence-based security decision.