# Review Overview

The Review section defines how the company learns from incidents, improves its controls, and prevents problems from happening again.

Respond and Recover are about managing the incident and restoring operations. Review is about stepping back after the pressure has reduced and asking what incidents revealed.

The goal isn't to blame people but rather to understand what happened, what worked, what failed, what was missing, and what must be improved.

A company should not treat recovery as the end of the incident. If the company restores systems but never reviews the root cause, weak controls, unclear ownership, missing evidence, communication gaps, or recovery delays, the same type of incident may return.

# What This Section Covers

The Review section should include the following main subsections.

# 1. Post-Incident Review and Timeline

This subsection reconstructs what happened.

The company should create a clear timeline from the first sign of the issue through detection, triage, containment, eradication, recovery, and closure.

The timeline should include when the incident started, when it was noticed, who reported it, what systems or accounts were affected, what actions were taken, when containment occurred, when recovery began, and when business operations returned to normal.

The practical question is:

“What happened, when did it happen, who knew, and what actions were taken?”

# 2. Root Cause and Control Failure Analysis

This subsection identifies why the incident happened or why it was able to cause impact.

The company should review the technical cause, business process cause, human process cause, and control gaps.

Examples may include missing MFA, weak password practices, exposed remote access, unpatched systems, unsafe file sharing, poor vendor access control, insufficient backups, missing logs, unclear ownership, delayed reporting, weak email controls, or poor change management.

The practical question is:

“What allowed this incident to happen, spread, remain unnoticed, or cause damage?”

# 3. Response and Recovery Performance Review

This subsection reviews how well the company handled the incident.

The company should assess whether detection worked, triage was fast enough, evidence was preserved, containment actions were effective, communication was clear, external support was used appropriately, recovery was safe, backups worked, and business operations were restored in the right order.

This is where the company identifies process problems, communication gaps, tool gaps, unclear authority, missing contacts, documentation issues, or recovery delays.

The practical question is:

“How well did we respond and recover, and where did the process break down?”

# 4. Improvement Actions and Control Updates

This subsection turns lessons learned into specific actions.

The company should create a prioritized improvement plan with owners, due dates, expected outcomes, and leadership approval where needed.

Actions may include enabling MFA, improving backups, changing access rules, patching systems, hardening configurations, updating detection alerts, improving employee reporting, revising vendor access, fixing documentation, changing payment approval procedures, or improving recovery testing.

The practical question is:

“What exactly will we change so this is less likely to happen again?”

# 5. Evidence, Reporting, and Leadership Closure

This subsection closes the incident formally.

The company should store final records, evidence, timelines, decisions, communications, technical findings, recovery validation, legal or insurance notes, customer or regulatory communication, and improvement actions.

Leadership should receive a short closure summary that explains what happened, business impact, root cause, response results, recovery status, remaining risks, and approved next steps.

The practical question is:

“Is the incident documented, closed, and converted into clear improvement work?”

# Review Section Table of Contents

1. Post-Incident Review and Timeline

2. Root Cause and Control Failure Analysis

3. Response and Recovery Performance Review

4. Improvement Actions and Control Updates

5. Evidence, Reporting, and Leadership Closure

# Expected Outputs from the Review Section

At the end of the Review section, the company should have:

• A complete incident timeline.
• A root cause analysis.
• A list of failed, missing, weak, or delayed controls.
• A review of detection, response, containment, communication, recovery, and business continuity performance.
• A prioritized improvement plan.
• Assigned owners and due dates for corrective actions.
• Updated policies, procedures, checklists, or technical controls where needed.
• A final incident closure summary.
• Stored evidence and documentation.
• Leadership approval of follow-up actions.
• A clear handoff into the ongoing improvement and education parts of the playbook.

# Objective

An incident is not fully closed until the company learns from it.

A company should leave this section able to say:

“We know what happened, why it happened, how well we responded, what must change, who owns those changes, and when they will be completed.”

That is review.

---