Overview
Post-Incident Review is the structured process used to analyze a security incident after resolution to identify root causes, control gaps, and improvement actions. It ensures incidents are documented, lessons learned are captured, and corrective actions are tracked in alignment with SOC 2 CC7.4 and CC7.5.
Step-by-Step Process
Confirm incident closure
The Security Lead verifies that the incident has been fully resolved and that containment, eradication, and recovery actions are complete. This confirmation ensures the review focuses on analysis rather than active response. The output is a confirmed incident closure status.
Role: Security Lead
Schedule post-incident review
The Security Lead schedules a review meeting within 5 business days of incident closure and invites relevant stakeholders such as IT, Engineering, and Compliance. The meeting invite should include the incident ID and timeline. The output is a calendar invitation with attendees and agenda.
Role: Security Lead
Compile incident documentation
The Security Analyst gathers all incident-related materials, including alerts, logs, tickets, and response timelines. These materials are organized chronologically for review. The output is a consolidated incident review packet.
Role: Security Analyst
Conduct root cause analysis
During the review meeting, participants analyze what happened, why it happened, and which controls failed or underperformed. The Security Lead facilitates discussion and ensures conclusions are evidence-based. The output is a documented root cause and contributing factors.
Role: Security Lead
Identify corrective actions
The team defines specific remediation and preventive actions to address identified gaps. Each action is assigned an owner and target completion date. The output is a corrective action list tied to the incident.
Role: Security Lead
Document lessons learned
The Security Lead documents lessons learned, including what worked well and what needs improvement. This information is added to the organization’s incident knowledge base. The output is an updated post-incident review document.
Role: Security Lead
Track remediation to completion
Assigned owners track corrective actions to completion and provide status updates. The Security Lead periodically reviews progress and closes actions when evidence is provided. The output is completed remediation records with closure dates.
Role: Security Lead
What You Need Before Starting
- Closed incident ticket with incident ID and severity
- Access to security monitoring logs and alerts
- Incident response timeline or war room notes
- Access to documentation tool (Confluence, Notion, or Google Docs)
Evidence Your Auditor Expects
- Post-incident review document dated and approved within 5 business days of incident closure
- Meeting calendar invite and attendance record showing review participants and date
- Corrective action list with assigned owners and target dates
- Screenshots or exports showing corrective actions marked complete with timestamps
How This Looks In Your Tools
Confluence
In Confluence, navigate to the Space used for Security or Compliance documentation and select “Create” from the top navigation. Choose a standard “Page” and select or apply a Post-Incident Review template if available. Enter the incident ID, date, summary, root cause, and lessons learned in clearly labeled sections.
To document corrective actions, insert a table using Insert > Table and include columns for Action Item, Owner, Due Date, and Status. Use the @mention feature to assign owners and the Status macro to show progress. When complete, select “Publish” and verify the page shows the correct created and last updated timestamps.
Notion
In Notion, go to the Security or Incident Management workspace and click “New Page.” Title the page with the incident ID and “Post-Incident Review.” Add sections for Incident Summary, Timeline, Root Cause, and Lessons Learned using headings.
Create a linked database or inline table for corrective actions by typing “/table” and defining properties for Owner, Due Date, and Status. Assign owners using the Person property and update status as actions progress. Confirm the page shows the correct creation date in the page properties.
Google Docs
In Google Drive, navigate to the Incident Response folder and click New > Google Docs. Name the document “Post-Incident Review – [Incident ID].” Use the document outline (Format > Paragraph styles) to structure sections for summary, root cause, and lessons learned.
Insert a table (Insert > Table) to track corrective actions with columns for Action, Owner, Due Date, and Status. Share the document with reviewers using the Share button and set appropriate permissions. Use File > Version history to verify timestamps for audit purposes.
Common Audit Findings
- Post-incident reviews not performed timely
- This occurs when reviews are delayed or forgotten after incident resolution. Prevent this by enforcing a required review within a defined timeframe and tracking it as part of incident closure criteria.
- Lack of documented root cause analysis
- Teams may summarize incidents without analyzing underlying causes. Use a standardized review template with a mandatory root cause section to ensure consistent analysis.
- Corrective actions not tracked to completion
- Action items are often identified but not followed through. Assign owners and due dates and require evidence of completion before closing actions.
- Missing stakeholder participation
- Relevant teams may not be included in the review, leading to incomplete findings. Define required roles for attendance based on incident type and severity.