#
Review Checklist
Use this checklist to confirm that the company has reviewed the incident, identified what happened, understood why it happened, evaluated how well the response worked, and assigned improvement actions.
The goal of Review is not blame. The goal is to learn, improve controls, close gaps, and reduce the chance of the same incident happening again.
#
Post-Incident Review and Timeline Checklist
☐ Assign a review owner.
☐ Collect the incident records from Detect, Respond, and Recover.
☐ Include incident records, employee reports, alerts, logs, screenshots, emails, tickets, containment records, communication records, recovery records, validation evidence, leadership decisions, vendor notes, and open risks.
☐ Build a factual timeline from the earliest known sign of the incident through detection, triage, containment, eradication, recovery, and closure.
☐ Record when the incident may have started.
☐ Record when it was first detected and who reported it.
☐ Record when triage began and when severity was assigned.
☐ Record when leadership, IT, MSP, vendors, legal, insurance, or other support contacts were notified.
☐ Record when containment, eradication, recovery, and business validation occurred.
☐ Record major decision points and who approved them.
☐ Identify delays, confusion, missing information, and unclear ownership.
☐ Record business impact, including downtime, lost productivity, customer impact, vendor impact, fraud exposure, data exposure, recovery cost, and manual workarounds.
☐ Create a post-incident review summary.
☐ Assign follow-up owners for timeline gaps or unanswered questions.
#
Root Cause and Control Failure Analysis Checklist
☐ Identify the likely or confirmed initial entry point.
☐ Identify the immediate cause of the incident.
☐ Look beyond the first obvious cause to identify deeper root causes.
☐ Review whether identity and access controls failed or were missing.
☐ Review whether email security controls failed or were missing.
☐ Review whether endpoint, server, network, website, cloud, SaaS, or remote access controls failed or were missing.
☐ Review whether patching, hardening, backup, logging, alerting, or monitoring controls failed or were missing.
☐ Review whether vendor access, service accounts, API keys, OAuth apps, or third-party integrations contributed to the incident.
☐ Review whether business processes contributed to the incident or made the impact worse.
☐ Review whether employee reporting, escalation, or training gaps contributed to the incident.
☐ Separate confirmed findings from likely findings and unknowns.
☐ Group findings into improvement themes.
☐ Create a clear root cause and control failure summary.
#
Response and Recovery Performance Review Checklist
☐ Review how quickly and effectively the incident was detected.
☐ Review whether alerts, logs, employee reports, MSP notifications, vendor reports, or external reports worked as expected.
☐ Review whether triage was timely and accurate.
☐ Review whether evidence was preserved correctly.
☐ Review whether incident severity was classified correctly and updated when needed.
☐ Review whether containment actions were fast, controlled, verified, and recorded.
☐ Review whether communication with leadership, employees, vendors, customers, legal, insurance, or external support was clear and controlled.
☐ Review whether escalation to MSPs, vendors, legal, insurance, or external incident response support happened at the right time.
☐ Review whether eradication removed attacker access, persistence, exploited weaknesses, and unsafe configurations.
☐ Review whether recovery began only after the environment was stable enough.
☐ Review whether backups were usable and restored safely.
☐ Review whether systems were restored in the correct business priority order.
☐ Review whether business owners validated restored systems and processes.
☐ Review whether temporary workarounds were controlled and ended when no longer needed.
☐ Record what worked well.
☐ Record what did not work well.
☐ Record what slowed response or recovery.
☐ Record what must improve before the next incident.
#
Improvement Actions and Control Updates Checklist
☐ Convert each confirmed finding into one or more improvement actions.
☐ Prioritize actions by risk, business impact, recurrence likelihood, effort, cost, and criticality.
☐ Assign an owner to every improvement action.
☐ Assign a due date to every improvement action.
☐ Define what control, process, policy, checklist, training, tool, or configuration must change.
☐ Include improvements for MFA, passwords, admin access, vendor access, patching, hardening, endpoint protection, backups, email security, cloud and SaaS controls, logging, alerting, remote access, employee reporting, and business approval processes where relevant.
☐ Define how each fix will be verified.
☐ Update the cybersecurity playbook where the incident showed the playbook was incomplete.
☐ Update inventories, registers, checklists, policies, contact lists, recovery plans, and training materials where needed.
☐ Track improvement actions in a central tracker.
☐ Escalate blocked or high-risk actions to leadership.
☐ Record risk acceptance where leadership chooses to delay or not complete an action.
☐ Confirm completed actions with evidence.
☐ Provide leadership with a short status update on completed, open, overdue, and blocked actions.
#
Evidence, Reporting, and Leadership Closure Checklist
☐ Create the final evidence package.
☐ Include the timeline, incident record, logs, alerts, screenshots, suspicious emails, affected account records, affected device records, containment records, communication records, vendor notes, legal or insurance notes, recovery validation records, root cause analysis, control failure analysis, and improvement action tracker.
☐ Store evidence in a controlled location organized by incident ID.
☐ Restrict access to incident evidence.
☐ Confirm evidence is not scattered across personal inboxes, chat threads, desktops, or unmanaged folders.
☐ Prepare the final incident report.
☐ Include what happened, when it happened, how it was detected, what was affected, business impact, root cause, control failures, response actions, containment summary, recovery summary, remaining risks, and improvement actions.
☐ Review whether external reporting is required.
☐ Check cyber insurance requirements, customer contracts, vendor contracts, data processing agreements, privacy requirements, regulatory obligations, and legal guidance where applicable.
☐ Prepare and approve any required external communication.
☐ Brief leadership on the incident, business impact, root cause, current status, remaining risks, and required improvements.
☐ Confirm closure status as closed, conditionally closed, or still open.
☐ Assign owners and due dates for remaining actions.
☐ Record leadership approval of closure status.
☐ Define retention requirements for incident records.
☐ Hand open actions into the improvement tracker, risk register, or ongoing security roadmap.
#
Final Review Section Outputs
☐ Review owner assigned.
☐ Incident records collected.
☐ Incident timeline completed.
☐ Key decisions documented.
☐ Business impact recorded.
☐ Root cause analysis completed.
☐ Control failures identified.
☐ Confirmed findings, likely findings, and unknowns separated.
☐ Response performance reviewed.
☐ Recovery performance reviewed.
☐ External support and vendor performance reviewed.
☐ What worked well documented.
☐ What failed or slowed the response documented.
☐ Improvement actions created.
☐ Owners and due dates assigned.
☐ Control updates defined.
☐ Verification methods defined.
☐ Playbook updates identified.
☐ Blocked or high-risk actions escalated.
☐ Final evidence package completed.
☐ Final incident report completed.
☐ External reporting obligations considered.
☐ Leadership briefing completed.
☐ Closure status approved.
☐ Remaining risks documented.
☐ Incident records stored safely.
☐ Follow-up actions handed into ongoing improvement work.
#
Objective
Review turns an incident into improvement.
The company should leave this section able to say:
“We know what happened, why it happened, how well we handled it, what must change, who owns the improvements, and when those improvements will be completed.”