1. Purpose
The Incident Investigation Report is the formal record of an investigation into a confirmed or suspected information security incident.
It documents:
What happened → When it happened → How it happened → What was affected → What evidence supports the findings → What impact occurred → Why it happened → What was done → What remains at risk → What will be improved.
The report should provide a clear, evidence-based record that can be reviewed by:
- Security management
- Incident response teams
- IT and engineering teams
- Business management
- Privacy/legal teams
- Internal auditors
- External auditors
- Customers where appropriate
- Regulators where applicable
- Other authorized stakeholders
The report should distinguish confirmed facts, observations, assumptions, hypotheses, and conclusions.
2. Scope
This report may be used for investigations involving:
- Account compromise
- Cloud compromise
- Data breach
- Phishing
- Malware
- Ransomware
- Unauthorized access
- Privilege escalation
- Vulnerability exploitation
- Insider activity
- Supplier incidents
- Application security incidents
- CI/CD compromise
- Production security incidents
- Loss or disclosure of information
- Security control failures
- Significant security events requiring formal investigation
The level of investigation should be proportionate to the incident’s severity, impact, risk, and available evidence.
3. Investigation Principles
The investigation should follow these principles:
1. Follow the evidence
Conclusions should be supported by available evidence.
2. Preserve evidence
Relevant evidence should be protected before it is altered or lost, where practical.
3. Separate facts from assumptions
Do not present an unverified hypothesis as a confirmed fact.
4. Establish the timeline
Determine what happened and when.
5. Determine the scope
Identify affected systems, identities, information, customers, suppliers, and environments.
6. Assess impact
Evaluate confidentiality, integrity, availability, business, customer, privacy, financial, regulatory, and contractual impact as applicable.
7. Identify root cause
Determine why the incident occurred and why existing controls did not prevent or detect it.
8. Verify recovery
Do not consider an incident resolved simply because systems are operational.
9. Track corrective actions
Investigation findings should result in accountable actions where improvement is required.
10. Document uncertainty
If evidence is unavailable, record the limitation rather than inventing a conclusion.
4. Investigation Report Information
| Field | Details |
|---|---|
| Incident ID | INC-YYYY-0001 |
| Investigation ID | INV-YYYY-0001 |
| Incident Title | |
| Incident Type | |
| Severity | SEV-1/SEV-2/SEV-3/SEV-4 |
| Event ID | |
| Date Detected | |
| Date Reported | |
| Investigation Start | |
| Investigation End | |
| Incident Commander | |
| Lead Investigator | |
| Business Owner | |
| Security Lead | |
| Status | Open/Investigating/Completed |
| Report Version | |
| Report Date | |
| Classification | Internal/Confidential/Restricted |
5. Executive Summary
Provide a concise summary for management.
The executive summary should answer:
- What happened?
- When was it detected?
- What systems or information were involved?
- Was unauthorized access confirmed?
- What was the business/customer impact?
- What actions were taken?
- What is the current status?
- What are the key corrective actions?
Example
On 30 September 2026, the security team identified suspicious activity involving a privileged AWS identity. Investigation identified unauthorized IAM activity and changes to cloud resources. CloudTrail, IAM, GuardDuty, and application evidence were reviewed to establish the activity timeline and determine whether customer information was accessed. The compromised identity was contained, credentials were rotated, unauthorized changes were removed, and affected resources were reviewed. The investigation identified weaknesses in privileged-access monitoring and credential management. Corrective actions have been assigned to strengthen MFA enforcement, privileged access controls, monitoring, and credential lifecycle management.
The summary should be updated if significant investigation facts change.
6. Incident Description
Describe the incident in factual terms.
Include:
- Initial event
- Detection method
- Reporter/source
- Affected system
- Identity/account involved
- Initial suspicious activity
- Initial assessment
- How the incident was confirmed
- Initial response
Avoid unsupported statements about attacker identity or motivation.
7. Investigation Objectives
Define what the investigation is intended to establish.
Examples:
- Determine whether unauthorized access occurred.
- Identify the compromised identity.
- Determine the initial access method.
- Establish the attack timeline.
- Determine which systems were accessed.
- Determine whether data was accessed or exfiltrated.
- Identify privilege escalation.
- Identify persistence mechanisms.
- Determine business impact.
- Identify root cause.
- Determine whether customer or personal data was affected.
- Identify control weaknesses.
- Determine required corrective actions.
8. Investigation Questions
Document the specific questions investigators need to answer.
| Question | Status | Conclusion |
|---|---|---|
| Was the activity unauthorized? | Complete | Confirmed |
| Which identity was involved? | Complete | IAM identity identified |
| When did unauthorized activity begin? | Complete | Timeline established |
| Was privilege escalated? | Complete | Determined from IAM evidence |
| Was customer data accessed? | Investigating | |
| Was data exfiltrated? | Investigating | |
| How did the compromise occur? | Complete | Root cause identified |
| Were other systems affected? | Complete | Scope established |
Questions may remain open if evidence is unavailable.
9. Investigation Team
| Role | Name | Responsibility |
|---|---|---|
| Incident Commander | Overall incident decision authority | |
| Lead Investigator | Investigation coordination | |
| Security Lead | Security analysis | |
| Cloud/IT Lead | Infrastructure investigation | |
| Application Lead | Application investigation | |
| Privacy Lead | Personal-data assessment | |
| Legal/Compliance | Legal/regulatory assessment | |
| Business Owner | Business impact | |
| Communications | Stakeholder communication |
For startups, one person may hold multiple roles, provided conflicts of interest and required independence are appropriately managed.
10. Evidence Register
List all significant evidence used.
| Evidence ID | Description | Source | Purpose | Integrity | Finding Linked |
|---|---|---|---|---|---|
| EV-2026-0042 | CloudTrail export | AWS | API activity | Verified | F-001 |
| EV-2026-0043 | IAM history | AWS IAM | Privilege changes | Verified | F-002 |
| EV-2026-0044 | GuardDuty finding | AWS | Suspicious activity | Verified | F-001 |
| EV-2026-0045 | S3 access evidence | AWS S3 | Data access | Verified | F-003 |
Refer to the Evidence Register and Chain-of-Custody Form for detailed evidence handling.
11. Evidence Assessment
For significant evidence, record:
- Source
- Collection method
- Time period
- Reliability considerations
- Integrity status
- Relevance
- Limitations
Evidence Assessment
| Evidence | What It Shows | Limitation |
|---|---|---|
| CloudTrail | API activity | Does not by itself establish user intent |
| IAM history | Permission changes | May not identify original credential theft |
| S3 logs | Object access | Retention may limit historical coverage |
| Application logs | Application activity | May not capture all infrastructure activity |
12. Fact / Observation / Hypothesis / Conclusion
Investigators should clearly distinguish different levels of certainty.
| Type | Meaning | Example |
|---|---|---|
| Fact | Directly supported by evidence | IAM role was created at 09:14 UTC |
| Observation | Evidence-based finding | Activity originated from an unfamiliar IP |
| Hypothesis | Possible explanation requiring validation | Credential may have been exposed through phishing |
| Conclusion | Supported determination | The IAM identity was used without authorization |
This distinction prevents speculation from becoming part of the official incident record.
13. Investigation Timeline
Establish a chronological sequence.
| Date/Time | Event | Evidence | Source | Confidence |
|---|---|---|---|---|
| 30-Sep 08:41 | Suspicious login | EV-001 | Identity logs | High |
| 30-Sep 08:46 | IAM role created | EV-002 | CloudTrail | High |
| 30-Sep 08:51 | S3 access observed | EV-003 | S3 logs | High |
| 30-Sep 09:02 | Alert generated | EV-004 | GuardDuty | High |
| 30-Sep 09:08 | Identity contained | EV-005 | IAM | High |
Use UTC or another defined time standard consistently.
14. Initial Access Investigation
Determine how unauthorized activity began.
Potential sources include:
- Compromised password
- Stolen access key
- Phishing
- Credential reuse
- Exposed secret
- Vulnerability exploitation
- Misconfiguration
- Compromised endpoint
- Supplier access
- OAuth/token compromise
- Insider activity
- Unauthorized physical access
If the initial access method cannot be established, record:
Initial access method could not be conclusively determined based on available evidence.
Do not select a cause simply because it appears plausible.
15. Identity and Authentication Investigation
Review:
- User identity
- Service account
- IAM identity
- SSO account
- API key
- OAuth token
- MFA activity
- Authentication source
- Login location
- Authentication time
- Failed logins
- Successful logins
- Session activity
- Privilege changes
- Credential rotation
- Token activity
Determine:
- Which identity was used?
- Was the activity authorized?
- Was MFA used?
- Were credentials compromised?
- Was privilege escalated?
- Were additional identities created?
16. Privilege Escalation Investigation
Determine whether the attacker or unauthorized user obtained additional privileges.
Review:
- IAM policy changes
- Role creation
- Role assumption
- Group membership
- Administrative privileges
- Security-policy changes
- Sudo/root activity
- Application administrator roles
- Database privileges
- CI/CD permissions
Document:
Initial privilege → Changed privilege → Action enabling escalation → Resulting access
17. System and Resource Investigation
Identify affected resources.
Cloud
- AWS accounts
- IAM
- EC2
- ECS/EKS
- Lambda
- S3
- RDS
- VPC
- Security groups
- WAF
- KMS
- Secrets Manager
Application
- APIs
- Web applications
- Admin consoles
- Authentication services
- Databases
- Background jobs
Endpoint
- Laptop
- Workstation
- Server
- Mobile device
Record whether each resource was:
- Accessed
- Modified
- Created
- Deleted
- Disabled
- Exposed
- Compromised
18. Data Access Assessment
Determine what information was potentially accessed.
Categories may include:
- Customer information
- Employee information
- Personal data
- Financial information
- Authentication information
- Confidential business information
- Source code
- Intellectual property
- Security configuration
- Credentials
- Regulated information
Record:
| Information | Location | Access Confirmed? | Exfiltration Confirmed? | Impact |
|---|---|---|---|---|
| Customer records | RDS | Yes | Unknown | Under assessment |
| Source code | Git repository | No | No evidence | None identified |
Avoid recording unnecessary sensitive information directly in the report.
19. Data Exfiltration Assessment
Determine whether information left the controlled environment.
Review:
- Network activity
- S3 downloads
- Database queries
- API activity
- File transfers
- DNS activity
- Cloud provider telemetry
- Endpoint activity
- External destinations
- Unusual data volumes
Classify the result:
- No evidence identified
- Suspected
- Possible
- Confirmed
- Unable to determine
Where the evidence is insufficient, clearly document the limitation.
20. Lateral Movement
Determine whether the unauthorized activity moved between systems.
Review:
- Authentication events
- Remote access
- IAM role assumptions
- Service accounts
- Network connections
- Internal APIs
- Database access
- Administrative tools
- CI/CD systems
- Supplier connections
Document:
Initial System → Intermediate System → Target System
21. Persistence Investigation
Determine whether unauthorized access could continue after the initial compromise.
Review:
- New users
- IAM roles
- Access keys
- OAuth applications
- Scheduled jobs
- Backdoors
- Malware
- Startup services
- SSH keys
- API keys
- CI/CD credentials
- Modified security controls
Document whether persistence was:
- Not identified
- Suspected
- Confirmed
- Removed
22. AWS SaaS Investigation Example
Scenario
A SaaS startup detects an unusual login to an AWS administrative identity.
Investigation sequence:
Suspicious Identity Activity
↓
CloudTrail Review
↓
IAM Policy/Role Investigation
↓
Privilege Escalation Assessment
↓
S3/RDS Access Review
↓
Security Group Review
↓
Secrets/KMS Investigation
↓
CI/CD Investigation
↓
Lateral Movement Assessment
↓
Data Access Assessment
↓
Containment
↓
Eradication
↓
Recovery
↓
Verification
The investigation should not stop after identifying the suspicious login. It should determine what the identity actually did.
23. Containment Actions
Document actions taken during the investigation.
| Action | Date/Time | Owner | Purpose | Result |
|---|---|---|---|---|
| Disabled compromised identity | Security | Stop unauthorized access | Completed | |
| Revoked active sessions | Cloud Team | Prevent continued access | Completed | |
| Rotated credentials | IT | Remove compromised credentials | Completed | |
| Restricted affected resource | Engineering | Limit exposure | Completed |
Containment actions should be linked to the Incident Register and timeline.
24. Evidence Preservation
Record whether evidence was preserved before or during investigation.
Examples:
- CloudTrail
- Identity logs
- Application logs
- Endpoint evidence
- Network logs
- Screenshots
- Configuration history
- Database audit logs
- CI/CD records
Reference:
- Evidence ID
- Collection Form
- Evidence Register
- Chain-of-Custody Form where applicable
25. Root Cause Analysis
The investigation should determine:
Direct Cause
What immediately caused the incident?
Contributing Factors
What conditions allowed the incident to occur or increase its impact?
Root Cause
What underlying process, technology, people, governance, supplier, or control weakness allowed the incident to occur?
Example
Direct cause:
Compromised privileged credential was used to access AWS.
Contributing factors:
Insufficient privileged-access monitoring and excessive permissions.
Root cause:
Privileged identity management and credential lifecycle controls were not sufficiently implemented for the affected administrative workflow.
The final root cause should be supported by evidence.
26. Security Control Effectiveness
Assess controls that should have:
- Prevented the incident
- Detected the incident
- Limited the impact
- Supported investigation
- Enabled recovery
| Control Area | Expected Protection | Observed Effectiveness | Gap |
|---|---|---|---|
| MFA | Prevent unauthorized login | Partially effective | Review privileged identities |
| Least privilege | Limit access | Ineffective for affected identity | Excessive permissions |
| Logging | Detect activity | Effective | CloudTrail available |
| Monitoring | Detect abnormal activity | Partially effective | Alerting improvement required |
| Credential management | Protect credentials | Gap identified | Rotation/process improvement |
Avoid automatically concluding that a control failed simply because an incident occurred. Assess what the control was designed to do and what the evidence shows.
27. Impact Assessment
Assess the incident across relevant dimensions.
Confidentiality
Was information accessed or disclosed?
Integrity
Was information, configuration, code, or systems modified?
Availability
Were services unavailable or degraded?
Business
Was revenue, operations, delivery, or productivity affected?
Customer
Were customers affected?
Privacy
Was personal data involved?
Regulatory
Could notification or other regulatory obligations apply?
Contractual
Were customer or supplier commitments affected?
Financial
Was there financial loss, fraud, or potential exposure?
28. Impact Summary
| Impact Area | Assessment | Evidence | Status |
|---|---|---|---|
| Confidentiality | |||
| Integrity | |||
| Availability | |||
| Customer | |||
| Personal Data | |||
| Business | |||
| Financial | |||
| Regulatory | |||
| Contractual |
29. Notification Assessment
Where applicable, assess whether notification requirements may exist.
Potential stakeholders include:
- Customers
- Data subjects
- Suppliers
- Cloud providers
- Regulators
- Law enforcement
- Cyber insurer
- Contractual partners
- Executive management
The investigation report should record:
- Requirement assessed
- Responsible function
- Decision
- Decision date
- Approval
- Notification completed/not required
- Supporting evidence
Legal and regulatory determinations should be made by appropriately authorized personnel.
30. Eradication
Document actions taken to remove the cause or attacker access.
Examples:
- Remove unauthorized IAM users
- Remove unauthorized IAM roles
- Remove malicious policies
- Rotate credentials
- Revoke tokens
- Remove malware
- Remove persistence
- Patch vulnerabilities
- Remove unauthorized applications
- Rebuild compromised workloads
- Restore secure configurations
31. Recovery
Document how affected services were restored.
Recovery may include:
Identity → Security Controls → Infrastructure → Network → Database → Storage → Application → Integrations → Monitoring → Business Service
Record:
- Recovery date/time
- Systems recovered
- Recovery method
- Validation performed
- Owner
- Result
32. Recovery Verification
Recovery is not complete simply because the service is available.
Verify:
☐ Unauthorized access removed
☐ Credentials rotated
☐ Sessions revoked
☐ Persistence removed
☐ Security controls restored
☐ Vulnerabilities addressed where applicable
☐ Logging enabled
☐ Monitoring operational
☐ Backups available
☐ Data integrity checked
☐ Application functionality verified
☐ Customer service verified
☐ Increased monitoring completed
33. Investigation Findings
Record formal findings.
| Finding ID | Finding | Evidence | Risk | Action Required |
|---|---|---|---|---|
| F-001 | Privileged identity was used without authorization | EV-0042 | High | Credential controls |
| F-002 | Excessive permissions existed | EV-0043 | High | Least-privilege review |
| F-003 | Monitoring did not immediately identify activity | EV-0044 | Medium | Detection improvement |
Findings should be traceable to evidence.
34. Corrective Actions
Each significant finding should result in an action where appropriate.
| Action ID | Finding | Corrective Action | Owner | Target Date | Status |
|---|---|---|---|---|---|
| CA-001 | F-001 | Strengthen privileged credential controls | IT | Open | |
| CA-002 | F-002 | Review administrative permissions | Cloud | Open | |
| CA-003 | F-003 | Improve privileged activity monitoring | Security | Open |
Reference the organization’s Corrective Action Tracker.
35. Residual Risk
After containment and corrective actions, assess remaining risk.
| Risk | Initial Risk | Treatment | Residual Risk | Decision |
|---|---|---|---|---|
| Privileged identity compromise | High | Credential rotation + MFA + monitoring | Medium | Track improvement |
| Excessive cloud privileges | High | Permission redesign | Low/Medium | Accepted/treated |
Residual risk should be assessed according to the organization’s risk methodology.
36. Lessons Learned
Record what should be retained or improved.
What worked?
- Centralized logging
- Fast incident reporting
- Clear escalation
- AWS audit logs
- Defined response roles
What did not work?
- Delayed detection
- Excessive privileges
- Incomplete alerting
- Unclear ownership
What should change?
- Improve privileged access management
- Improve detection rules
- Conduct additional tabletop exercises
- Update incident playbooks
- Improve credential lifecycle controls
Link lessons to the Lessons Learned Register.
37. Management Review
Management should review significant investigation results where appropriate.
Record:
- Key findings
- Business impact
- Customer impact
- Residual risk
- Corrective actions
- Resource requirements
- Policy/procedure changes
- Risk acceptance decisions
- Improvement priorities
- Management decisions
Management Decision
Decision: ______________________
Date: ______________________
Decision Owner: ______________________
Supporting Evidence: ______________________
38. Investigation Limitations
Every investigation should document material limitations.
Examples:
- Logs unavailable
- Retention period expired
- Endpoint unavailable
- Third-party evidence unavailable
- Clock synchronization issue
- Incomplete historical telemetry
- Encryption prevented analysis
- Evidence corrupted
- Customer system inaccessible
Example
Authentication logs covering the first two hours of the suspected compromise were unavailable because the relevant logging configuration had not been enabled. The investigation therefore cannot conclusively establish the initial authentication method during that period.
This is preferable to making an unsupported conclusion.
39. Investigation Conclusion
The conclusion should summarize only what the investigation supports.
Include:
- Whether an incident occurred
- What caused it
- What was affected
- Whether unauthorized access was confirmed
- Whether data access was confirmed
- Whether exfiltration was confirmed
- Business/customer impact
- Root cause
- Corrective actions
- Remaining uncertainty
- Residual risk
Example Structure
Incident: Confirmed.
Unauthorized access: Confirmed.
Affected environment: AWS production environment.
Affected identity: Privileged cloud identity.
Customer data access: Assessed based on available evidence.
Exfiltration: Confirmed / Not confirmed / Unable to determine.
Root cause: Documented control weakness.
Containment: Completed.
Recovery: Completed and verified.
Corrective actions: Assigned.
Residual risk: Assessed and documented.
40. Investigation Closure Criteria
The investigation may be considered complete when:
☐ Investigation objectives addressed
☐ Timeline established
☐ Evidence collected and reviewed
☐ Evidence gaps documented
☐ Scope determined
☐ Identity activity investigated
☐ System/resource activity investigated
☐ Data access assessed
☐ Lateral movement assessed
☐ Persistence assessed
☐ Root cause determined or documented as undetermined
☐ Impact assessed
☐ Notification requirements assessed
☐ Containment completed
☐ Eradication completed
☐ Recovery verified
☐ Corrective actions assigned
☐ Residual risk assessed
☐ Lessons learned recorded
☐ Management review completed where required
☐ Final report approved
41. Approval
Lead Investigator
Name: ______________________
Role: ______________________
Date: ______________________
Signature/Approval: ______________________
Security Lead
Name: ______________________
Date: ______________________
Decision: Approved / Returned for Revision
Business Owner
Name: ______________________
Date: ______________________
Decision: Approved / Returned for Revision
Management
Name: ______________________
Date: ______________________
Decision: Approved / Further Action Required
42. Investigation Evidence Trail
The report should maintain references to:
- Incident Reporting Form
- Incident Register
- Incident Severity Matrix
- Incident Escalation Matrix
- Incident Response Playbook
- Incident Timeline
- Evidence Collection Form
- Evidence Register
- Chain-of-Custody Form
- Root Cause Analysis
- Corrective Action Tracker
- Lessons Learned Register
- Risk Register
- ISMS Improvement Log
- Incident Closure Report
43. Startup-Friendly Investigation Model
A startup can operate a lightweight but defensible investigation process:
Security Event
↓
Incident Created
↓
Incident ID Assigned
↓
Investigation Objectives Defined
↓
Evidence Preserved
↓
Timeline Established
↓
Identity/System/Data Investigation
↓
Impact Assessed
↓
Root Cause Identified
↓
Containment & Eradication
↓
Recovery Verified
↓
Corrective Actions Assigned
↓
Residual Risk Assessed
↓
Lessons Learned
↓
Management Review
↓
Investigation Report Approved
↓
Incident Closed
The process should scale with incident severity.
A minor event does not necessarily require the same investigation depth as a major cloud compromise or data breach.
44. ISO 27001 Alignment
The Incident Investigation Report can support the organization’s ISMS processes relating to:
- Information security incident management
- Security event assessment
- Evidence preservation
- Logging and monitoring
- Access control
- Risk assessment and treatment
- Corrective actions
- Lessons learned
- Continual improvement
- Management review
The report should be aligned with the organization’s defined incident criteria, risk methodology, documented information requirements, and applicable legal, regulatory, and contractual obligations.
It should also connect investigation findings back to the organization’s risk register, Statement of Applicability, controls, corrective actions, and improvement process where relevant.
45. Audit Evidence
An auditor should be able to select a significant incident and trace:
Incident
→ Investigation
→ Evidence
→ Timeline
→ Finding
→ Root Cause
→ Impact Assessment
→ Corrective Action
→ Risk Reassessment
→ Lessons Learned
→ Management Review
→ Closure
This demonstrates that incidents are not merely recorded—they are investigated and used to improve the ISMS.
46. Final Audit Trail
Security Event Detected
→ Incident Reported
→ Incident Validated
→ Severity Classified
→ Investigation Authorized
→ Investigation Objectives Defined
→ Evidence Identified
→ Evidence Preserved
→ Timeline Established
→ Identity Investigated
→ Systems Investigated
→ Data Access Assessed
→ Lateral Movement Assessed
→ Persistence Assessed
→ Impact Assessed
→ Root Cause Identified
→ Containment Completed
→ Eradication Completed
→ Recovery Completed
→ Recovery Verified
→ Findings Documented
→ Corrective Actions Assigned
→ Residual Risk Assessed
→ Lessons Learned
→ Management Review
→ Investigation Report Approved
→ Incident Closed
47. Final Principle
An incident investigation is complete when the organization can explain what happened, establish the facts through evidence, determine the impact, understand why it happened, address the underlying weakness, verify recovery, and document what remains uncertain.
Incident Investigation Principle
Establish the Facts + Preserve Evidence + Build the Timeline + Determine Scope + Assess Impact + Identify Root Cause + Correct the Weakness + Verify Recovery + Reassess Risk + Document the Conclusion