1. Purpose
The Incident Closure Report provides the formal record for closing an information security incident after investigation, containment, eradication, recovery, impact assessment, and required corrective actions have been completed or appropriately transferred for follow-up.
The report should demonstrate:
- What happened
- How the incident was detected
- What systems and information were affected
- How the incident was investigated
- What actions were taken
- Whether the threat was removed
- Whether recovery was successful
- Whether notification obligations were assessed
- What corrective actions remain
- What residual risk remains
- Why the incident can be formally closed
The closure decision should be based on available evidence and should not imply that every uncertainty has been eliminated.
2. Incident Information
| Field | Details |
|---|---|
| Incident ID | |
| Incident Title | |
| Incident Type | |
| Severity | Critical / High / Medium / Low |
| Date/Time Detected | |
| Date/Time Reported | |
| Investigation Start | |
| Containment Date/Time | |
| Recovery Date/Time | |
| Closure Date/Time | |
| Incident Owner | |
| Investigation Lead | |
| Business Owner | |
| Security Owner | |
| Current Status | Closed |
| Related Incident | |
| Related Change/Ticket | |
| Related Risk | |
| Related Supplier |
3. Executive Summary
Provide a concise management-level summary.
Incident Summary
Business Impact
Security Impact
Data Impact
Current Status
Closure Decision
4. Incident Classification
Incident Category
☐ Phishing
☐ Malware
☐ Ransomware
☐ Account Compromise
☐ Cloud Compromise
☐ Data Breach
☐ Vulnerability Exploitation
☐ Lost/Stolen Device
☐ Insider Incident
☐ Supplier Incident
☐ DDoS
☐ API Key Exposure
☐ Business Email Compromise
☐ Source Code/CI-CD Compromise
☐ Data Leakage
☐ Other
Severity
Initial Severity:
Final Severity:
Reason for Classification
5. Incident Description
What Happened?
How Was the Incident Detected?
Who/What Reported It?
Affected Environment
☐ Production
☐ Development
☐ Test
☐ Cloud
☐ Endpoint
☐ Network
☐ SaaS
☐ Email
☐ CI/CD
☐ Other
6. Scope of the Incident
Affected Systems
| System/Asset | Environment | Impact | Status |
|---|---|---|---|
Affected Identities
| Identity | Type | Activity | Impact |
|---|---|---|---|
Affected Information
| Information Type | Classification | Impact | Confirmed? |
|---|---|---|---|
| Yes/No |
Affected Customers/Users
7. Incident Timeline Summary
| Event | Date/Time | Evidence/Source |
|---|---|---|
| Initial suspicious activity | ||
| Initial access/compromise | ||
| Detection | ||
| Incident reported | ||
| Investigation started | ||
| Containment completed | ||
| Eradication completed | ||
| Recovery started | ||
| Recovery verified | ||
| Investigation completed | ||
| Closure decision |
Refer to the detailed Incident Timeline for the complete event history.
8. Investigation Summary
Investigation Performed
Evidence Reviewed
☐ Authentication logs
☐ Cloud logs
☐ Application logs
☐ Database logs
☐ Network logs
☐ Endpoint logs
☐ Email evidence
☐ Security alerts
☐ Configuration records
☐ Access records
☐ Backup records
☐ Supplier information
☐ Other
Evidence Preserved
Investigation Limitations
9. Root Cause
Immediate Cause
Contributing Factors
Root Cause
Why Existing Controls Did Not Prevent or Detect the Incident
Control Gap Identified?
Yes / No
Details:
10. Attack / Incident Path
Document the confirmed or most probable sequence.
Initial Access
↓
Compromised Identity/System
↓
Privilege or Access
↓
System/Resource Activity
↓
Data/System Impact
↓
Detection
↓
Containment
↓
Eradication
↓
Recovery
Final Determination
Where an element cannot be established, mark it as unknown rather than presenting an assumption as fact.
11. Impact Assessment
| Impact Area | Result | Details |
|---|---|---|
| Confidentiality | ||
| Integrity | ||
| Availability | ||
| Customer Data | ||
| Personal Data | ||
| Financial Information | ||
| Credentials/Secrets | ||
| Source Code | ||
| Intellectual Property | ||
| Business Operations | ||
| Regulatory Obligations | ||
| Contractual Obligations |
12. Data Exposure Assessment
Was Data Accessed?
Yes / No / Unknown
Was Data Modified?
Yes / No / Unknown
Was Data Deleted?
Yes / No / Unknown
Was Data Exfiltrated?
Yes / No / Unknown
Was Data Disclosed?
Yes / No / Unknown
Information Potentially Affected
Number of Records/Individuals Potentially Affected
Customer Impact
Data Exposure Conclusion
13. Containment Summary
| Containment Action | Date/Time | Owner | Result |
|---|---|---|---|
Was Containment Successful?
Yes / No / Partially
Evidence:
14. Eradication Summary
Document actions taken to remove the threat and prevent immediate recurrence.
| Eradication Action | Date/Time | Owner | Result |
|---|---|---|---|
Examples:
- Compromised accounts removed
- Credentials revoked
- Secrets rotated
- Malware removed
- Vulnerability patched
- Unauthorized roles removed
- Persistence removed
- Malicious code removed
- Compromised system rebuilt
- Security configuration corrected
Eradication Status
☐ Complete
☐ Partial
☐ Ongoing corrective action
15. Recovery Summary
| Recovery Activity | Completed | Verified By | Date |
|---|---|---|---|
| System restoration | Yes/No | ||
| Data restoration | Yes/No | ||
| Configuration validation | Yes/No | ||
| Credentials secured | Yes/No | ||
| Security controls restored | Yes/No | ||
| Monitoring restored | Yes/No | ||
| Business service validated | Yes/No |
Recovery Validation
16. AWS SaaS Example
For an AWS SaaS incident, closure evidence may include confirmation that:
- Compromised IAM credentials were revoked
- Active sessions were addressed
- MFA was verified
- IAM permissions were reviewed
- CloudTrail activity was investigated
- S3 access was reviewed
- RDS activity was reviewed
- ECS/EKS/EC2 activity was investigated where applicable
- Secrets and API keys were rotated
- Unauthorized resources or roles were removed
- Security Groups/network configuration were reviewed
- Cloud security monitoring was restored
- No additional persistence was identified
- Customer data exposure was assessed
- Recovery was validated
The closure report should reference the actual evidence rather than simply stating that these activities were performed.
17. Notification Assessment
Determine whether any notification or communication obligation applies.
Stakeholders Considered
☐ Management
☐ Customers
☐ Employees
☐ Supplier
☐ Cloud provider
☐ Legal counsel
☐ Privacy team
☐ Regulatory authority
☐ Law enforcement
☐ Insurer
☐ Certification body
☐ Contractual party
☐ Other
Notification Required?
☐ Yes
☐ No
☐ Under review
☐ Not applicable
Basis for Decision
Notification Completed?
Yes / No / N/A
Date:
18. Corrective Actions
| Action ID | Finding | Corrective Action | Owner | Due Date | Priority | Status |
|---|---|---|---|---|---|---|
| CA-001 | ||||||
| CA-002 | ||||||
| CA-003 |
Corrective actions should address the underlying weakness rather than only the immediate incident.
19. Open Actions at Closure
Not every corrective action must necessarily be completed before an incident is administratively closed.
Where appropriate, transfer outstanding actions into the organisation’s normal corrective-action or risk-management process.
| Action | Owner | Due Date | Risk | Tracking Reference |
|---|---|---|---|---|
Reason Incident Can Be Closed With Open Actions
20. Risk and Residual Risk
New or Changed Risk Identified?
Yes / No
Risk Reference
| Risk | Likelihood | Impact | Residual Risk | Treatment |
|---|---|---|---|---|
Risk Acceptance Required?
Yes / No
Risk Owner:
Approval:
21. Lessons Learned
What Worked Well?
What Did Not Work?
What Caused Delays?
What Evidence Was Missing?
What Detection Improvement Is Required?
What Preventive Control Should Be Improved?
What Should Change in the Incident Response Process?
22. Security Control Review
Determine whether the incident indicates weaknesses in existing security controls.
| Control Area | Issue Identified? | Improvement Required? | Action Reference |
|---|---|---|---|
| Access Control | |||
| MFA | |||
| Privileged Access | |||
| Logging | |||
| Monitoring | |||
| Vulnerability Management | |||
| Cloud Security | |||
| Endpoint Security | |||
| Backup | |||
| Secure Development | |||
| Supplier Security | |||
| Security Awareness | |||
| Incident Management |
23. Management Review
Management Review Date
Key Findings Presented
Management Decisions
Additional Resources Approved?
Yes / No
Additional Risk Accepted?
Yes / No
Further Investigation Required?
Yes / No
24. Closure Criteria
Before closing the incident, confirm that applicable criteria have been satisfied.
☐ Incident scope established
☐ Investigation completed
☐ Timeline completed
☐ Evidence preserved
☐ Root cause identified or documented as unknown
☐ Affected systems identified
☐ Affected information assessed
☐ Data exposure assessed
☐ Lateral movement assessed
☐ Persistence assessed
☐ Threat contained
☐ Threat eradicated
☐ Systems recovered
☐ Recovery validated
☐ Monitoring restored
☐ Notification requirements assessed
☐ Customer impact assessed
☐ Corrective actions assigned
☐ Residual risk assessed
☐ Lessons learned completed
☐ Management review completed
☐ Open actions transferred to appropriate tracking
☐ Closure approval obtained
25. Closure Decision
Incident Closure Status
☐ Closed
☐ Closed – Corrective Actions Open
☐ Closed – Risk Accepted
☐ Reopened
☐ Further Investigation Required
Closure Rationale
Date of Closure
Closed By
26. Final Incident Statement
Based on the investigation performed, available evidence, containment and eradication activities, recovery validation, impact assessment, and review of outstanding risks and corrective actions, the incident is considered suitable for closure.
Incident-specific conclusion:
27. Approval
| Role | Name | Decision | Date | Approval |
|---|---|---|---|---|
| Investigation Lead | ||||
| Incident Owner | ||||
| Security Owner | ||||
| Business Owner | ||||
| Management |
28. Evidence and Supporting Records
Attach or reference supporting records.
| Record | Reference | Location |
|---|---|---|
| Incident Report | ||
| Incident Timeline | ||
| Investigation Report | ||
| Evidence Log | ||
| Security Logs | ||
| Screenshots | ||
| Customer Communication | ||
| Regulatory Assessment | ||
| Corrective Action Register | ||
| Risk Assessment | ||
| Lessons Learned | ||
| Change Records | ||
| Other |
29. Audit Evidence Trail
A completed Incident Closure Report should demonstrate:
Incident Detected
→ Incident Reported
→ Incident Investigated
→ Evidence Preserved
→ Timeline Established
→ Impact Assessed
→ Root Cause Identified
→ Threat Contained
→ Threat Eradicated
→ Systems Recovered
→ Recovery Verified
→ Notification Requirements Assessed
→ Corrective Actions Assigned
→ Residual Risk Assessed
→ Lessons Learned
→ Management Review
→ Closure Approved
→ Incident Closed
30. ISO 27001 Connection
The Incident Closure Report supports the organisation’s incident management process by providing evidence that incidents are investigated, their consequences are assessed, response actions are completed, lessons are identified, and appropriate corrective actions are tracked.
The report can also provide supporting evidence for processes involving:
- Information security incident management
- Event monitoring and logging
- Access control
- Privileged access
- Cloud security
- Vulnerability management
- Malware protection
- Backup and recovery
- Supplier security
- Data protection
- Business continuity
- Corrective action
- Information security risk management
The level of investigation and closure documentation should be proportionate to the nature, severity, business impact, and information involved in the incident.
31. Startup Implementation Approach
For a startup, incident closure does not need to become a lengthy administrative exercise.
For a low-impact incident, a short closure record may be sufficient:
Incident → Investigation → Action → Verification → Closure
For a major incident, use:
Detection → Timeline → Evidence → Investigation → Impact Assessment → Root Cause → Containment → Eradication → Recovery → Notification Assessment → Corrective Actions → Residual Risk → Lessons Learned → Management Review → Closure
The important requirement is that the organisation can demonstrate a clear and defensible answer to:
What happened, what did we do, what remains, and why are we closing the incident?
Final Principle
Investigate + Contain + Eradicate + Recover + Assess Impact + Address Root Cause + Track Corrective Actions + Verify Recovery + Review Risk + Document Closure.