1. Document Purpose
The Incident Investigation Template provides a structured method for investigating information security incidents from initial detection through evidence collection, root-cause analysis, impact assessment, remediation, and closure.
The objective is to ensure that investigations are:
- Structured and repeatable
- Evidence-based
- Properly documented
- Focused on determining what happened, how it happened, and what was affected
- Aligned with the organisation’s incident response process
- Capable of supporting management decisions, customer communication, regulatory assessment, and audit evidence
The template should be used together with the organisation’s Information Security Incident Management Policy, Incident Response Procedure, and applicable incident-specific playbooks.
2. Investigation Record
| Field | Details |
|---|---|
| Incident ID | |
| Incident Title | |
| Date/Time Detected | |
| Date/Time Reported | |
| Date/Time Investigation Started | |
| Reported By | |
| Investigation Lead | |
| Incident Owner | |
| Business Owner | |
| Severity | Critical / High / Medium / Low |
| Status | Open / Investigating / Contained / Recovering / Closed |
| Related Incident ID | |
| Related Change/Ticket | |
| Related Supplier | |
| Customer Impacted? | Yes / No / Unknown |
| Personal Data Involved? | Yes / No / Unknown |
| Regulatory Impact? | Yes / No / Unknown |
3. Incident Description
3.1 Initial Description
Record what was initially observed or reported.
Description:
3.2 Initial Source
☐ Employee
☐ Customer
☐ Supplier
☐ Security monitoring
☐ Cloud security alert
☐ Vulnerability scanner
☐ Endpoint security
☐ SIEM
☐ Application monitoring
☐ Customer support
☐ Management
☐ External notification
☐ Other
3.3 Initial Indicators
Record the initial indicators that triggered the investigation.
Examples:
- Unusual login
- Unknown IP address
- Suspicious AWS activity
- Unexpected administrator privilege
- Malware alert
- Data download
- Phishing email
- Unusual API calls
- Unauthorized configuration change
- Publicly exposed storage
- Failed authentication attempts
Indicators:
4. Investigation Scope
Define what systems, users, information, environments, and time periods are included in the investigation.
Systems
☐ Production
☐ Development
☐ Test
☐ Cloud infrastructure
☐ Endpoints
☐ Network
☐ Database
☐ Storage
☐ SaaS applications
☐ Email
☐ Identity/SSO
☐ CI/CD
☐ Source code repository
☐ API infrastructure
☐ Other
Information
☐ Customer information
☐ Personal data
☐ Employee information
☐ Financial information
☐ Credentials/secrets
☐ Source code
☐ Intellectual property
☐ Confidential information
☐ Security logs
☐ Other
Investigation Period
Start:
End:
Investigation Scope Statement
5. Investigation Team
| Role | Name | Responsibility |
|---|---|---|
| Investigation Lead | Overall investigation | |
| Incident Manager | Incident coordination | |
| IT/Security | Technical investigation | |
| Cloud/Infrastructure | Infrastructure analysis | |
| Application/Engineering | Application analysis | |
| HR | Employee-related investigation | |
| Legal/Privacy | Legal and notification assessment | |
| Management | Business decisions | |
| External Specialist | Specialist investigation |
Only personnel with a legitimate need should have access to investigation information.
6. Evidence Collection
Evidence should be collected, preserved, and handled in a manner appropriate to the nature and severity of the incident.
| Evidence ID | Evidence Type | Source | Date/Time Collected | Collected By | Storage Location | Integrity Verified |
|---|---|---|---|---|---|---|
| E-001 | Yes/No | |||||
| E-002 | Yes/No | |||||
| E-003 | Yes/No |
Potential Evidence Sources
- Authentication logs
- IAM logs
- CloudTrail
- CloudWatch
- Security alerts
- EDR/endpoint logs
- Firewall logs
- WAF logs
- VPN logs
- DNS logs
- Application logs
- Database logs
- API logs
- Email headers
- Email gateway logs
- Source-code repository logs
- CI/CD logs
- SaaS audit logs
- Network flow logs
- Backup logs
- Configuration history
- Vulnerability scan results
- User/device information
- Relevant tickets and communications
7. Evidence Handling
For important evidence, record:
- Who collected it
- When it was collected
- Where it came from
- How it was preserved
- Who accessed it
- Where it is stored
- Whether integrity was verified
| Evidence ID | Custodian | Access Date | Accessed By | Purpose | Integrity Check |
|---|---|---|---|---|---|
8. Timeline of Events
Construct a chronological timeline using verified evidence.
| Date/Time | Event | Source | Verified? | Investigator Notes |
|---|---|---|---|---|
| Yes/No | ||||
| Yes/No | ||||
| Yes/No | ||||
| Yes/No |
The timeline should distinguish between:
Known facts — supported by evidence.
Assumptions — currently believed but not confirmed.
Unknowns — information that has not yet been established.
9. Affected Identity / Account Investigation
Determine whether user, administrator, service, API, cloud, or supplier identities were involved.
| Identity | Type | Normal Activity | Suspicious Activity | Privilege Level | Compromised? |
|---|---|---|---|---|---|
| Employee/Admin/Service/API | Yes/No | ||||
Investigate:
- Authentication history
- Failed login attempts
- Successful login attempts
- MFA activity
- Password changes
- Session/token activity
- API key usage
- OAuth applications
- Privilege changes
- Role assignments
- Unusual locations/IP addresses
- Unusual devices
- Administrative activity
10. System and Resource Investigation
Identify systems that were accessed, modified, compromised, or potentially affected.
| System/Resource | Environment | Activity | Evidence | Impact | Status |
|---|---|---|---|---|---|
| Production/Dev/Test | |||||
Investigate:
- Configuration changes
- New accounts
- New roles
- New resources
- Security control changes
- Network changes
- Application changes
- Database activity
- Storage access
- Secret/key access
- Malware indicators
- Persistence mechanisms
- Unauthorized software
- Data transfers
11. AWS Investigation Example
For a SaaS company operating on AWS, investigation may include:
Identity
- IAM users
- IAM roles
- SSO/federated identities
- Access keys
- Temporary credentials
- MFA activity
Cloud Activity
- AWS CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- Config
- VPC Flow Logs
Resources
- EC2
- ECS/EKS
- Lambda
- RDS
- S3
- Secrets Manager
- KMS
- API Gateway
- WAF
- Security Groups
Investigation Questions
- Which identity performed the activity?
- From where?
- At what time?
- What permissions were available?
- Which resources were accessed?
- What configuration was changed?
- Was data accessed or downloaded?
- Were credentials or secrets accessed?
- Was persistence established?
- Did the attacker move to another resource?
- Were security controls disabled?
- Was customer data affected?
12. Attack Path / Incident Path
Document the suspected sequence of events.
Initial Entry
↓
Compromised Identity/System
↓
Privilege or Access Obtained
↓
Resource Access
↓
Lateral Movement
↓
Data/System Impact
↓
Persistence
↓
Detection
↓
Containment
↓
Eradication
↓
Recovery
Document the actual investigation findings below:
13. Root Cause Analysis
Determine the underlying cause rather than only documenting the immediate symptom.
Immediate Cause
What directly caused the incident?
Contributing Factors
☐ Weak authentication
☐ Missing MFA
☐ Excessive privilege
☐ Vulnerability
☐ Misconfiguration
☐ Inadequate monitoring
☐ Phishing/social engineering
☐ Malware
☐ Human error
☐ Supplier issue
☐ Inadequate security control
☐ Inadequate process
☐ Inadequate training
☐ Inadequate change management
☐ Other
Root Cause
Why Did Existing Controls Not Prevent or Detect It?
Control Gap Identified?
Yes / No
Control:
14. Impact Assessment
Assess actual and potential impact.
| Impact Area | Affected? | Details |
|---|---|---|
| Confidentiality | Yes/No/Unknown | |
| Integrity | Yes/No/Unknown | |
| Availability | Yes/No/Unknown | |
| Customer Data | Yes/No/Unknown | |
| Personal Data | Yes/No/Unknown | |
| Financial Data | Yes/No/Unknown | |
| Credentials/Secrets | Yes/No/Unknown | |
| Source Code | Yes/No/Unknown | |
| Intellectual Property | Yes/No/Unknown | |
| Business Operations | Yes/No/Unknown | |
| Regulatory Obligations | Yes/No/Unknown | |
| Contractual Obligations | Yes/No/Unknown | |
| Reputation/Customer Trust | Yes/No/Unknown |
15. Data Exposure Assessment
Determine whether information was:
- Accessed
- Viewed
- Downloaded
- Modified
- Deleted
- Exfiltrated
- Disclosed
- Lost
- Destroyed
| Information Type | Affected? | Number/Volume | Evidence | Exposure Confirmed? |
|---|---|---|---|---|
| Yes/No | ||||
| Yes/No |
Affected Population
Customers:
Employees:
Other individuals:
16. Lateral Movement Assessment
Determine whether the incident moved beyond the initially affected system.
| Source | Destination | Identity | Activity | Evidence | Confirmed? |
|---|---|---|---|---|---|
Check:
- Additional accounts
- Additional servers
- Cloud resources
- Databases
- Storage
- Network systems
- Source-code repositories
- CI/CD systems
- SaaS applications
- Supplier systems
17. Persistence Assessment
Determine whether unauthorized access could continue after the initial compromise.
Check for:
☐ New user accounts
☐ New IAM roles
☐ New API keys
☐ New access keys
☐ OAuth applications
☐ Scheduled tasks
☐ Startup services
☐ Modified CI/CD pipelines
☐ Backdoors
☐ Malware
☐ Unauthorized SSH keys
☐ Modified applications
☐ Web shells
☐ Other persistence mechanisms
Findings:
18. Containment Performed
Record actions taken to prevent further impact.
| Action | Date/Time | Performed By | Result |
|---|---|---|---|
| Account disabled | |||
| Session revoked | |||
| Credentials rotated | |||
| System isolated | |||
| Network access restricted | |||
| Resource isolated |
19. Eradication Performed
Record actions taken to remove the underlying threat.
Examples:
- Malware removed
- Unauthorized account removed
- Unauthorized IAM role removed
- Access keys revoked
- Secrets rotated
- Vulnerability patched
- Malicious software removed
- Persistence removed
- Unauthorized configuration reverted
- Compromised system rebuilt
- Security controls restored
Eradication Summary:
20. Recovery and Validation
Record how affected systems were safely restored.
| Recovery Activity | Completed | Verified By | Date |
|---|---|---|---|
| System restored | Yes/No | ||
| Configuration verified | Yes/No | ||
| Credentials secured | Yes/No | ||
| Security controls restored | Yes/No | ||
| Monitoring enabled | Yes/No | ||
| Data integrity verified | Yes/No | ||
| Business service validated | Yes/No |
Recovery Validation
21. Notification Assessment
Determine whether notification or communication obligations apply.
Potential stakeholders:
☐ Management
☐ Customers
☐ Employees
☐ Supplier
☐ Cloud provider
☐ Insurer
☐ Legal counsel
☐ Privacy team
☐ Regulatory authority
☐ Law enforcement
☐ Certification body
☐ Contractual party
☐ Other
Notification Assessment:
Decision:
☐ Notification required
☐ Notification not required
☐ Under legal/privacy review
☐ Further investigation required
Decision Owner:
22. Corrective Actions
| Action ID | Finding | Corrective Action | Owner | Due Date | Priority | Status |
|---|---|---|---|---|---|---|
| CA-001 | ||||||
| CA-002 | ||||||
| CA-003 |
Corrective actions should address the root cause and not only the immediate incident.
23. Preventive Improvements
Consider whether improvements are required to:
- Policies
- Procedures
- Access control
- MFA
- Privileged access
- Monitoring
- Logging
- Vulnerability management
- Secure configuration
- Cloud security
- Endpoint security
- Backup
- Business continuity
- Supplier management
- Security awareness
- Secure development
- Incident response
- Detection capabilities
Improvements Required:
24. Risk Assessment
Determine whether the incident creates a new or changed information security risk.
| Risk | Likelihood | Impact | Risk Level | Treatment |
|---|---|---|---|---|
Residual Risk
Risk Acceptance Required?
Yes / No
Risk Owner:
Approval:
25. Lessons Learned
What Worked Well?
What Did Not Work?
What Took Too Long?
What Evidence Was Missing?
What Control Should Be Improved?
What Should Be Changed in the Incident Response Process?
26. Investigation Findings Summary
Confirmed Facts
Unconfirmed Findings
Unknowns / Limitations
Root Cause
Business Impact
Security Impact
Data Impact
27. Final Investigation Conclusion
Incident Conclusion:
Incident Cause:
Affected Systems:
Affected Information:
Containment Status:
Eradication Status:
Recovery Status:
Notification Assessment:
Residual Risk:
28. Closure Criteria
The incident investigation should not be closed until applicable criteria have been satisfied.
☐ Investigation scope completed
☐ Evidence collected and preserved
☐ Timeline established
☐ Affected systems identified
☐ Affected identities investigated
☐ Data exposure assessed
☐ Lateral movement assessed
☐ Persistence assessed
☐ Root cause identified or documented as unknown
☐ Threat contained
☐ Threat eradicated
☐ Recovery completed
☐ Recovery validated
☐ Notification requirements assessed
☐ Corrective actions assigned
☐ Residual risk assessed
☐ Lessons learned completed
☐ Management review completed
☐ Investigation record approved
☐ Incident formally closed
29. Investigation Approval
| Role | Name | Decision | Date | Signature/Approval |
|---|---|---|---|---|
| Investigation Lead | ||||
| Incident Owner | ||||
| Security Owner | ||||
| Management |
30. Audit Evidence Trail
A completed investigation should provide a traceable chain:
Incident Detected
→ Incident Reported
→ Investigation Initiated
→ Scope Defined
→ Evidence Preserved
→ Timeline Established
→ Identity/System Activity Investigated
→ Attack Path Determined
→ Data Impact Assessed
→ Root Cause Identified
→ Containment Completed
→ Threat Eradicated
→ Systems Recovered
→ Recovery Verified
→ Notification Requirements Assessed
→ Corrective Actions Assigned
→ Residual Risk Assessed
→ Lessons Learned
→ Management Review
→ Incident Closed
31. Practical Example — AWS SaaS Startup
Incident
A developer reports an unexpected AWS login and the security team identifies an unfamiliar API activity.
Investigation
The investigation team reviews:
- AWS CloudTrail
- IAM activity
- MFA events
- Access keys
- S3 access
- RDS activity
- ECS activity
- Secrets Manager
- Security Group changes
- VPC Flow Logs
The investigation determines that a developer access key was exposed and used from an unauthorized source.
The team establishes:
Initial Cause: Exposed developer credential
Access Obtained: AWS IAM
Activity: S3 and infrastructure API calls
Data Exposure: No confirmed customer-data access
Persistence: No unauthorized IAM users or roles identified
Containment: Access key disabled and sessions revoked
Eradication: Credentials rotated and affected access reviewed
Recovery: AWS configuration validated
Root Cause: Credential was exposed through an insecure development workflow.
Corrective Actions
- Implement stronger secret-management controls
- Review developer access
- Strengthen credential scanning
- Review CI/CD secrets
- Improve monitoring for unusual AWS activity
- Conduct developer security awareness training
The investigation record provides evidence not only of what happened, but also that the organisation investigated the incident, assessed impact, contained the threat, addressed the root cause, and evaluated residual risk.
32. ISO 27001 Connection
The Incident Investigation Template supports the organisation’s information security incident management process by providing evidence that security events are investigated, their causes and impacts are assessed, and appropriate corrective actions are identified.
The investigation should connect back to the organisation’s:
- Information security risk assessment
- Risk treatment plan
- Statement of Applicability
- Incident management process
- Access control
- Logging and monitoring
- Vulnerability management
- Backup and recovery
- Supplier security
- Cloud security
- Secure development
- Business continuity
- Corrective action process
The exact investigation activities should remain risk-based and appropriate to the nature, severity, and potential impact of the incident.
33. Startup Implementation Approach
A startup does not need a large forensic team or expensive investigation platform for every incident.
A practical approach is:
Small Incident
→ Incident ticket
→ Basic evidence collection
→ Timeline
→ Impact assessment
→ Corrective action
→ Closure
Major Incident
→ Dedicated incident record
→ Investigation lead
→ Evidence preservation
→ Detailed timeline
→ Identity/system investigation
→ Data exposure assessment
→ Root-cause analysis
→ Legal/privacy assessment
→ Corrective actions
→ Management review
The objective is not to create paperwork.
The objective is to create defensible evidence showing what happened, what was investigated, what was affected, what was done, and why the incident was closed.
Final Principle
Investigate the Facts + Preserve the Evidence + Establish the Timeline + Determine the Impact + Identify the Root Cause + Remove the Threat + Correct the Weakness + Verify Recovery + Document the Decision.