What Is Post-Incident Review (PIR)?

NIST SP 800-61 Revision 2 lists nine questions for a lessons learned meeting. The last three are the only ones that point forward, and they are the ones teams skip. Corrective actions, precursors and indicators to watch for next time, and the tools needed to detect the next one. Everything before them is history. Those three are the product.

A post-incident review is the meeting where an incident either becomes detection logic or becomes an anecdote people repeat at handover for two years. Nothing about the incident decides which. The mechanics of the meeting decide it.

What the standard actually says

Section 3.4.1 of SP 800-61r2 (Computer Security Incident Handling Guide, August 2012) opens with a sentence worth keeping:

One of the most important parts of incident response is also the most often omitted: learning and improving.

The same section gives timing: "The meeting should be held within several days of the end of the incident." It gives an attendance rule: "The primary consideration in holding such meetings is ensuring that the right people are involved." And it names the output: "it is also important to document the major points of agreement and action items and to communicate them to parties who could not attend the meeting."

Revision 3 shipped in April 2025 and reorganized the whole document around CSF 2.0 Functions, which means the nine questions now live in a superseded publication. They are still the best checklist in print. Google's SRE book calls the same artifact a postmortem and lists concrete triggers for writing one: user-visible downtime beyond a threshold, data loss of any kind, on-call engineer intervention, resolution time above a threshold, and a monitoring failure. That last trigger is the one security teams should steal. If a human found it before your tooling did, that is a PIR regardless of impact.

Timing

"Within several days" cuts both ways, and both failure modes are real.

Too early and you get the meeting while people are still on adrenaline and four hours of sleep. Defensiveness is high, and the containment decisions are too recent to be discussed as decisions rather than accusations. Too late and recall goes. Nobody remembers why they closed that alert on day two.

There is a hard deadline underneath the soft one, and it is telemetry retention. If your EDR keeps 30 days of raw process events and your PIR lands on day 35, you cannot answer the questions that matter. Export the relevant slice on the day containment finishes. Our working rule for lab exercises: after the rotation has handed over and everyone has had a full night, before the shortest retention window closes.

Who is in the room

The analyst who triaged the first alert. The responder who isolated the host. The engineer who wrote the containment script at 2am. Their managers are optional.

This is the single most common structural failure in a PIR. The meeting fills with people who can approve things and empties of people who touched a keyboard, and the output becomes a policy statement instead of a rule. The person who dismissed the alert on day two is the most valuable attendee in the room, and they will only speak if the room has already established that dismissing it was reasonable given what they could see.

Separate the timeline from the analysis

Build the timeline first, as a standalone artifact, and circulate it before the meeting. One row per fact. Timestamp in UTC, the observation, the source that proves it. No interpretation in the row.

2026-03-14T08:12:41Z  outlook.exe writes invoice_03.iso to Downloads   Sysmon EID 11
2026-03-14T08:14:02Z  rundll32.exe launched from mounted volume D:\    Sysmon EID 1
2026-03-14T08:14:09Z  outbound 443 to 185.x.x.x, no prior resolution   Sysmon EID 3
2026-03-14T09:41:55Z  net.exe group "Domain Admins" /domain           Security 4688
2026-03-14T09:42:10Z  EDR alert raised, closed as benign at 10:07Z    case mgmt

That block is a reconstruction from patterns in public reporting, not telemetry from a case we worked. The format is the point. Every row cites its source, so the meeting cannot argue about whether something happened.

Analysis then runs as a separate pass over the finished timeline. Mixing them turns a PIR into an argument about facts, and that argument consumes the hour and produces nothing. If a claim has no source column, it belongs in analysis.

The four questions that produce action

Everything else in a PIR is optional. These are not.

1. What did we detect, and when? Compare first malicious activity to first alert to first human eyes. Three timestamps, two gaps. The gaps are the finding.

2. What did we miss, and why? Split "why" into no telemetry, telemetry but no rule, and rule but no alert. Those are three different tickets to three different owners.

3. What slowed us down? Approval waits, missing credentials, a runbook that pointed at a decommissioned console, an EDR isolation that needed a manager who was asleep.

4. What did we assume that was wrong? The assumption that patient zero was patient zero. The assumption that the service account only ran from one host.

The three detection questions

These are the ones this catalog exists for, and they are more specific than the generic four.

Which telemetry did we wish we had. Usually the answer is a setting, not a product. Process creation events without arguments are the classic: Security 4688 logs the image path but not the command line unless the policy is on.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1
HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging = 1

Which rule should have fired. Write it during the PIR, in the meeting, as a draft. A rule that gets written a week later gets written by someone reading a document instead of someone who remembers the shape of the intrusion.

Which alert fired and got dismissed. This is the most valuable question in the whole review and the one most reliably avoided, because it has a name attached to it. Ask it about the alert, never about the analyst. The useful output is not "an analyst made a mistake". It is "this rule produces an alert a reasonable analyst cannot action", which is a detection engineering defect.

Query your own case management data before the meeting so nobody has to volunteer it:

SELECT a.rule_name,
       count(*) AS closures,
       min(a.closed_at) AS first_close
FROM alerts a
JOIN incident_hosts h ON a.hostname = h.hostname
WHERE a.disposition IN ('false_positive', 'benign')
  AND a.closed_at BETWEEN h.first_activity - INTERVAL '30 days'
                      AND h.contained_at
GROUP BY a.rule_name
ORDER BY closures DESC

Schemas differ, so treat that as a shape rather than something to paste. Any rule appearing in that result set was firing on the intrusion and losing.

The fix for the row in the timeline above is not "alert on domain group discovery", which is the rule that was already being dismissed. It is a discriminator that makes the alert actionable:

title: Domain group discovery from a document or script host parent
id: 3f9a71c4-6b28-4d51-8ae7-2c0d94f6b1a3
status: experimental
description: >
  Detects net.exe domain group enumeration whose parent process is an Office
  application, a script host or an archive tool. Domain group discovery alone
  is closed as administrative activity at high rates. The parent constrains it
  to the post-exploitation case.
references:
  - https://attack.mitre.org/techniques/T1069/002/
author: HuntRule
date: 2026-07-31
tags:
  - attack.discovery
  - attack.t1069.002
logsource:
  product: windows
  category: process_creation
detection:
  group_enum:
    Image|endswith:
      - '\net.exe'
      - '\net1.exe'
    CommandLine|contains|all:
      - ' group '
      - '/domain'
  delivery_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\7zFM.exe'
      - '\WinRAR.exe'
  condition: group_enum and delivery_parent
falsepositives:
  - Helpdesk and inventory scripts launched through cscript or wscript
  - Administrators running audit scripts from an Office macro
level: high

What it catches: the enumeration step when it still descends from the delivery chain. What it misses is larger. It misses the same discovery once the operator has an interactive shell under explorer.exe or cmd.exe, which is most of the time after the first hour. It misses Get-ADGroupMember, [adsisearcher] and every SharpHound-style collector, because those speak LDAP directly and never invoke net.exe. It produces nothing if ProcessCreationIncludeCmdLine_Enabled is unset, because the /domain argument is the whole condition. Pair it with an LDAP query volume baseline rather than shipping it alone. Related discovery techniques worth mapping in the same pass are T1087.002 for net user /domain and T1482 for domain trust enumeration.

The output contract

Every finding leaves the meeting with three fields. An owner who is a person, a due date that is a date, and a verification step that someone other than the owner can run.

A PIR that produces a document instead of tickets has failed. The document is a byproduct. If the findings do not exist in the same tracker as the rest of engineering work, with the same review cadence, they will not be done and nobody will notice they were not done.

Anti-patterns

Blame. The reason the dismissed-alert question gets avoided. A team that punishes the analyst who closed the alert buys silence, and silence is what a PIR exists to break.

More training. The non-action that looks like an action. It has no verification step, which is how you spot it. "Train analysts on ISO mount detection" cannot be verified. "Add ISO mount events to the triage runbook with a worked example, replayed by purple team" can.

Findings that quietly expire. The worst of the three because it is invisible. A finding with an owner who left, a due date nine months back and no closure record is worse than no finding, because it made the last PIR look successful. Audit the previous review's open items at the start of every new one. If the first agenda item is uncomfortable, the process is working.

Summary

A post-incident review is a mechanism, not a meeting, and the mechanism decides whether an incident produces detection logic. Run it within several days per SP 800-61r2, after fatigue has cleared and before your shortest retention window closes. Fill the room with the people who did the work rather than the people who approved it, build the timeline as a sourced artifact before anyone analyzes it, and ask the three detection questions explicitly, including the one about the alert that fired and got closed. Every finding needs an owner, a date and a verification step, and the previous review's open items are the first agenda item of the next one. The discipline this sits inside is covered in what incident response actually involves.

Confirm these are on before the next PIR asks for them:

Security 4688   Process creation, with ProcessCreationIncludeCmdLine_Enabled = 1
Security 4624   Successful logon (source IP and logon type)
Security 4648   Logon with explicit credentials
Security 4768/4769  Kerberos TGT and service ticket requests
Sysmon   1      Process creation with hashes and parent
Sysmon   3      Network connection with initiating process
Sysmon   11     File create
PowerShell/Operational 4104  Script block logging
Directory Service 1644  LDAP query logging (needs field engineering registry keys)

Windows discovery and post-exploitation rules are in the catalog at /rules?domain=windows. If your PIR named a rule that fires and gets dismissed, /rules?q=discovery is where the tuned replacements live.