Post-incident review checklist

A lessons-learned review — this is not a statute

Audience: the engineering leader who has to close the corrective actions, the incident commander who holds the timeline, and counsel who may later hand the write-up to an auditor or a customer. The we've-been-breached page on this site is the first-moves hub. The incident-timeline page on this site is the UTC chronology the review must cite. The root-cause-analysis page on this site is the blameless method for what failed. This page is the meeting and the register: what worked, what failed, which lessons you will keep, which corrective actions have an owner and a due date, and which controls or policies change. It does not rank DFIR firms, does not name any, and does not start a notification clock.

NIST SP 800-61r2 is a guide to handling computer security incidents — guidance, not a statute. Its last phase is post-incident activity: hold a lessons-learned meeting, write what happened, and use the experience to improve the process, the controls, and the training. NIST says hold that meeting within a few days of the incident; waiting too long is how impressions rot. That 'few days' is NIST guidance, not a legal deadline this page starts. ISO/IEC 27035-1:2023 is a standard of principles and process for information security incident management, including applying lessons learned; it is not a law, and this page does not reproduce it. A blameless frame is industry best practice in incident review: the write-up names systems, incentives, missing detections, and missing controls, not a person to punish. That is practice, not a statute. Last verified 7 September 2026. Not legal advice.

• Schedule the review while the facts are in living memory. NIST SP 800-61r2: within a few days of the incident. That is guidance, not a filing clock.
• Walk what worked and what failed against the timeline and the images, not against recollection. The incident-timeline page on this site is the UTC template.
• Keep RCA and the review distinct. RCA names the cause. The review captures lessons, assigns corrective actions, and decides which controls and policies change. The root-cause-analysis page on this site is the RCA template.
• Every corrective action needs a named owner, a due date in UTC, and a test. 'Be more careful' is not an action.
• Documented lessons are a requirement of ISO 27001 and SOC 2 programs when those programs apply to you. This checklist is practitioner guidance. Mapping is not filing.
• This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.

Requirement, guidance, or this checklist

Do not treat this page as an ISO clause or a SOC 2 criterion. Documented lessons-learned and corrective action are requirements of those programs when the program applies. NIST's meeting window is guidance. This checklist is practitioner best practice. Last verified 7 September 2026. Not legal advice.

The full checklist

Copy the list. Walk it in a scheduled meeting with the people who were on the incident, not a status-page audience. Unknowns stay on the list. This product does not ship a downloadable checklist file or a review wizard; the bullets are the checklist. Last verified 7 September 2026. Not legal advice.

• Schedule the meeting within a few days of the incident (NIST SP 800-61r2 guidance). Put a named owner on the invite. Do not wait for a quiet month.
• Attendance: commander, engineering lead who will own actions, the examiner who holds the images, and counsel if the write-up may be handed to an auditor, insurer, or regulator. Names belong on the attendance list, not in the cause line.
• What worked: detections that fired, containment that held, decisions that aged well, communications that did not tip the actor. Cite the timeline row.
• What failed: missed detections, dirty restores, missing images, clocks you discovered late, controls that were on paper. Cite the timeline row or the evidence ID.
• Root cause: if RCA is not written yet, write it first. The root-cause-analysis page on this site is the blameless template. The review does not replace RCA.
• Lessons: one sentence each, tied to a change you will actually make or a residual you will actually accept. A lesson with no action and no acceptance is a slogan.
• Corrective-action register: one row per change — what will be different, owner, due date in UTC, test that it worked. Use the template below.
• Control and policy updates: which control, which policy, what wording or setting changes, who publishes it. The policies library in the signed-in app stores YOUR policies; it does not draft this update.
• Residual / accepted: what you will not change, and why, routed through YOUR risk-acceptance process.
• Package: timeline, images, RCA, this review, the register, and any filings actually sent. One owner for the package.
• Do not close the incident because production is up. Recovery is not review. The document-containment-recovery page on this site is the action-log template; keep the action log with the package.

Corrective-action register template

Copy the fields. Fill them from the review, not from a standup that starts with names. Each row is a change with an owner, a due date, and — once done — what actually changed. This product does not ship a downloadable register or assign the owner; the table is the template. Last verified 7 September 2026. Not legal advice.

Worked example (fictional)

Fictional. Not a real incident, not customer data, not a named CVE, not an org on this product. The names, hosts, and times are invented so the fields are visible. Do not treat the actions as a playbook for YOUR estate. Last verified 7 September 2026. Not legal advice.

What to do now

Do this once containment is in force and the evidence hold exists. Do not skip it because the site is up. Last verified 7 September 2026. Not legal advice.

• Schedule the post-incident review within a few days of the incident (NIST SP 800-61r2 guidance). Put it on a calendar with a named owner. That window is guidance, not a legal deadline this page starts.
• If YOUR ISO 27001 or SOC 2 program applies, treat documented lessons and corrective action as a requirement of that program — then use this checklist as the practitioner method, not as the clause.
• Open the UTC timeline and the RCA. If either is still a Slack thread, make it a table first. The incident-timeline and root-cause-analysis pages on this site are the templates.
• Walk what worked, what failed, and the lessons. Fill the corrective-action register with owners, due dates, and tests. Record control and policy updates, or record residual acceptance.
• Keep the write-up with the evidence package. Counsel decides whether it is handed to an auditor, an insurer, or a regulator. Mapping is not filing.
• Track every action until the test passes or a recorded acceptance holds the residual. Closing the incident ticket is not close-out.

Where this shows up in ShipReady Metrics

The signed-in app does not run a post-incident review wizard and does not schedule a PIR. It does not capture lessons, assign corrective-action owners, or update policies for you. The cyber risk register lives under Security. An accepted-risk gate lives under Security → Risk register → Accepted — a recorded decision that a residual risk will not be treated now; it is not a PIR close-out. The policies library lives under Compliance → Policies; it stores YOUR policies and does not draft a post-incident policy update. Compliance remediation tasks open from control gaps (signed-in app → Compliance → Remediation) and auto-close when the control is re-evidenced; that queue is not an incident corrective-action register and does not assign PIR owners. Continuous monitoring (signed-in app → Compliance → Continuous monitoring) holds a security-incident register that grades containment clocks and whether a high/critical incident still owes a post-mortem flag — a boolean, not a lessons-learned write-up — and an ISO 27001 Clause 10.2 nonconformity CAPA form (root-cause text plus corrective action on a logged nonconformity). Native incident-response evidence maps a completed post-incident review to SOC 2 CC7.5 and ISO/IEC 27001 Annex A 5.27 as a met/not-met flag; that mapping is not the review. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a PIR, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits.

Primary sources (last verified 7 September 2026)

Every operational and program-requirement claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.

NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012) this cluster cites for post-incident activity — lessons learned, a write-up of what happened, using the experience to improve, and holding the meeting within a few days of the incident — guidance, not a statute, last verified still final on 7 September 2026. ISO/IEC 27035-1:2023 is named as the incident-management principles-and-process standard that includes applying lessons learned; it is not a law, is not reproduced here, and the catalog URL is not the full text. ISO/IEC 27001:2022 Clause 10.2 (nonconformity and corrective action) and Annex A control 5.27 (learning from information security incidents) are requirements of that ISMS program only when the standard applies to you; they are not reproduced here, and the catalog URL is not the full text. SOC 2 Trust Services Criteria CC7.3 / CC7.4 / CC7.5 are AICPA criteria for a SOC 2 examination; this product maps a completed post-incident review to CC7.5; this page does not reproduce the TSC. The SANS Incident Handler's Handbook is a practitioner PICERL checklist that ends at lessons learned, not a standard. A blameless frame is industry best practice in incident review, not a statute. This checklist is practitioner guidance.

Frequently asked questions