Security Incident Report Template
A standardised template for documenting and reporting security incidents — from phishing attempts to data breaches.
Purpose of Incident Reporting
A standardised security incident report ensures every incident is documented consistently, root causes are identified, and corrective actions are tracked. This template aligns with ISO 27001, DPDP Act 2023, and IT Act 2000 incident reporting requirements.
Section 1: Incident Details
- Incident ID: Unique identifier (e.g., SEC-2025-001).
- Reported Date & Time: When the incident was first reported.
- Reported By: Name, department, and contact of the person who reported it.
- Incident Category: Phishing, malware, unauthorised access, data breach, physical security, denial of service, policy violation, or other.
- Severity Level: Critical (SEV-1), High (SEV-2), Medium (SEV-3), Low (SEV-4) — as per the Incident Response Playbook.
- Systems Affected: List of affected devices, servers, accounts, or data repositories.
- Current Status: New, Investigating, Contained, Resolved, Closed.
Section 2: Incident Description
Provide a clear, chronological description of the incident: what happened, when it started, how it was discovered, and what immediate actions were taken. Include relevant log entries, screenshots, email headers, or system alerts as attachments.
Section 3: Containment Actions
Document every step taken to contain the incident: isolation of affected systems, revocation of compromised credentials, blocking of malicious IP addresses, shutdown of affected services, and notification of relevant stakeholders. Record timestamps for every action.
Section 4: Root Cause Analysis
Identify the root cause: was it a configuration error, software vulnerability, human error, physical breach, or third-party failure? For each root cause, note: contributing factors that enabled the incident, controls that should have prevented it (and why they failed), and whether similar risks exist elsewhere in the environment.
Section 5: Recovery Actions
Steps taken to restore normal operations: system restoration from backups, application of security patches, reconfiguration of security controls, password resets for affected accounts, and verification that the incident is fully resolved.
Section 6: Lessons Learned & Follow-Up
What went well during the response? What could have been better? What changes will be made to prevent recurrence? Each follow-up action must have: an owner, a deadline, and a check-box for completion. Schedule a post-incident review meeting within 5 business days of closure.
Put this into practice with workro desk.