how do you write a security incident report example

Security Incident Documentation and Reporting Protocol

Document ID: SEC-SOP-[]
Version: []
Effective Date: []
Review Cycle: [] Months

1. Purpose & Scope

The purpose of this protocol is to standardize the documentation of security events to ensure legal defensibility, regulatory compliance, and post-mortem utility. This procedure applies to all [Company Name] personnel, contractors, and third-party vendors who detect or respond to a security event within the [Company Name] infrastructure.

2. Prerequisites

• Access to [Incident Management System Name] or secure repository.
• Verified credentials for [Log Management/SIEM Tool].
• Read-only access to [Company Name] Information Security Policy.
• Encrypted communication channel (e.g., [Secure Messaging Platform]).

3. Roles & Responsibilities (RACI)

4. Procedure Phases

Phase I: Initial Documentation (T+0 to T+60 minutes)

• Record the precise [Date/Time] of incident discovery.
• Assign a unique [Incident Tracking Number].
• Document the [Primary Point of Contact] for the reporting party.
• Define the [Scope of Impact] (e.g., specific servers, user accounts, or data sets).

Phase II: Fact Gathering and Evidence Chain

• Attach [Log File ID/Link] as primary evidence.
• List all [System Assets] involved in the event.
• Conduct [Brief Interview] with stakeholders; document findings in [Appendix A].
• Verify the [Integrity Hash] of all collected digital evidence.

Phase III: Narrative Construction

• Draft the [Executive Summary] (max 200 words).
• Chronologically detail the [Timeline of Events] using UTC timestamps.
• List [Mitigation Actions] performed to contain the threat.
• Identify [Root Cause Analysis (RCA)] status (Pending/Complete).

Phase IV: Review and Submission

• Submit draft to [Chief Information Security Officer] for technical review.
• Submit draft to [Legal Department] for compliance review.
• Archive final report in [Secure Storage Location].

5. Quality Assurance and Professional Standards

• Pro-Tip: Use objective, non-emotive language. Avoid phrases like "I think" or "it seems." Use "Evidence suggests" or "Logs indicate."
• Common Pitfall: Failing to document the "Time of Discovery" vs. "Time of Occurrence." Always track both.
• QA Checklist: Ensure no PII (Personally Identifiable Information) is included in the incident narrative unless strictly required for the investigation.

6. FAQs

Q: How much detail should be included in the narrative?
A: Include sufficient detail for a third-party auditor to reconstruct the timeline without needing to ask follow-up questions. If a step is not documented, it did not happen.

Q: Should I document failed containment attempts?
A: Yes. Documenting unsuccessful mitigation steps is vital for post-mortem analysis to prevent future resource wastage and to demonstrate due diligence to regulators.

Q: Who should be the final audience for this report?
A: The report should be written for two audiences: technical responders (for remediation) and executive leadership/legal (for risk assessment).