Add PIR near-miss notification gates

skills/incident-response/post-incident-review/SKILL.md

@@ -58,6 +58,9 @@ Before conducting the PIR, gather or confirm:
 - [ ] **Existing controls** -- Documentation of security controls that were in place at the time of the incident (detection rules, access controls, network segmentation, patching cadence).
 - [ ] **Previous PIR reports** -- Any prior post-incident reviews for similar incident types, to identify recurring patterns.
 - [ ] **Metrics data** -- Timestamps needed to compute MTTD, MTTR, and MTTC (see Step 4).
+- [ ] **Near-miss evidence** -- For blocked attempts, evidence that no compromise occurred, the control that blocked the attempt, recurrence count, and timestamps for attempt, detection, and block.
+- [ ] **Response action decision records** -- Containment/recovery actions taken, expected benefit, expected side effects, rollback criteria, break-glass owner, and whether evidence collection or operations were affected.
+- [ ] **Legal/privacy notification data** -- For suspected personal-data, regulated-data, customer, or contractual impact, timestamps for legal/privacy engagement, regulatory assessment, notification decision, deadline, and current status.
 
 ---
 
@@ -186,6 +189,26 @@ Organize contributing factors into categories to ensure comprehensive analysis:
 
 Compute the following metrics for the incident. These metrics enable trend analysis across incidents and benchmark against industry data.
 
+Before computing durations, classify the metric mode:
+
+- **Confirmed compromise** -- Initial compromise, detection, containment, and recovery timestamps are supported by evidence. Compute MTTD, MTTC, MTTR, dwell time, and escalation time.
+- **Near miss / blocked attempt** -- Evidence shows the attempted attack was blocked before production compromise or data exposure. Do not force compromise-to-detection or recovery metrics. Mark MTTD, dwell time, and MTTR as `Not applicable` with evidence, then compute near-miss metrics instead.
+- **Uncertain compromise** -- Compromise may have occurred but the timestamp is unknown or only bounded by a range. Report confidence, source, earliest/latest possible timestamps, and avoid pretending an exact mean exists.
+
+#### Near-Miss Metrics
+
+Use these metrics when no compromise or recovery timestamp applies:
+
+| Metric | Formula | What It Measures |
+|--------|---------|-----------------|
+| **Attempt Detection Time** | Detection - First Attempt | Time from first attempted abuse to detection or alerting |
+| **Time to Block** | Block - First Attempt | Time from first attempted abuse to effective prevention/containment by control |
+| **Control That Blocked Attempt** | Named preventive/detective control | Which control prevented escalation into an incident |
+| **Recurrence Count** | Similar blocked attempts in last 12 months | Whether the same attack pattern is recurring |
+| **False-Negative Review** | Manual review outcome | Whether any related attempts bypassed detection or prevention |
+
+Near-miss PIRs are complete only when they explain why compromise/recovery metrics are not applicable and document the evidence supporting that conclusion. A blocked credential-stuffing attempt, for example, should not be penalized for missing a recovery timestamp if no production asset was compromised.
+
 #### Mean Time to Detect (MTTD)
 
 ```
@@ -251,7 +274,36 @@ Map the incident to specific control failures -- what should have prevented, det
 | **Process gap** | IR playbook did not cover the incident type or was outdated | Update IR playbooks; conduct tabletop exercises; review annually |
 | **Communication failure** | Stakeholders were not notified, or notification was delayed | Formalize escalation matrix; automate notifications; test communication procedures |
 
-### Step 6: Lessons Learned and Remediation Plan
+### Step 6: Response Action Impact Review
+
+Review whether response actions introduced avoidable operational, forensic, customer, or recovery harm. NIST post-incident questions explicitly ask whether any response steps inhibited recovery; the PIR must capture that evidence without blaming responders for risk-based decisions.
+
+| Action | Expected Benefit | Side Effect / Harm | Evidence Impact | Rollback Criteria | Break-Glass Owner | PIR Finding |
+|---|---|---|---|---|---|---|
+| [Containment or recovery action] | [Risk reduced] | [Operational/customer/evidence impact] | [None / delayed / degraded / lost] | [Documented condition] | [Owner/team] | [No issue / follow-up needed] |
+
+**Classification guidance:**
+
+- Do not mark an action as bad solely because it caused impact. Some containment choices intentionally trade availability for risk reduction.
+- Flag a PIR finding when the expected side effect was not documented, the action lacked rollback criteria, responder access was blocked without break-glass ownership, or evidence collection was delayed/degraded without an explicit decision record.
+- Record when the action worked as intended and the side effect was accepted by the incident commander or business owner.
+
+### Step 7: Legal and Privacy Notification Clock
+
+For suspected personal-data, regulated-data, customer, payment, healthcare, contractual, or cross-border exposure, track the notification clock explicitly. If legal/privacy review is not applicable, state why.
+
+| Clock Field | Required Evidence |
+|---|---|
+| **Potentially Regulated Data** | Data category, system, jurisdiction, and confidence |
+| **Legal/Privacy Engaged At** | Timestamp and communication source |
+| **Regulatory Assessment Started At** | Timestamp, owner, and assessment record |
+| **Notification Decision** | Notify / no-notify / pending, with rationale |
+| **Decision Deadline** | Regulatory, contractual, customer, or internal SLA deadline |
+| **Current Status** | On time / late / blocked / not applicable |
+
+Flag a PIR finding when legal/privacy engagement, regulatory assessment, notification decision, or deadline tracking is missing for a plausible data-exposure incident.
+
+### Step 8: Lessons Learned and Remediation Plan
 
 Convert analysis findings into specific, measurable, assignable, and time-bound remediation actions.
 
@@ -335,6 +387,16 @@ root cause, and the number/priority of remediation actions identified.]
 | MTTR (Detection to Recovery) | [duration] | [comparison to org average] |
 | Escalation Time | [duration] | [SLA target] |
 
+### Near-Miss Metrics
+| Metric | Value | Evidence / Applicability |
+|---|---|---|
+| Attempt Detection Time | [duration or "Not applicable"] | [source] |
+| Time to Block | [duration or "Not applicable"] | [source] |
+| Control That Blocked Attempt | [control name] | [evidence] |
+| Recurrence Count | [count] | [lookback window/source] |
+| False-Negative Review | [complete/incomplete/not applicable] | [evidence] |
+| Compromise/Recovery Metrics Applicability | [Applicable / Not applicable / Uncertain] | [why] |
+
 ### Root Cause Analysis
 **Method:** [5 Whys / Fishbone / Both]
 
@@ -353,6 +415,21 @@ root cause, and the number/priority of remediation actions identified.]
 ### What Could Be Improved
 - [Gap or failure identified during retrospective]
 
+### Response Action Impact Review
+| Action | Expected Benefit | Side Effect / Harm | Evidence Impact | Rollback Criteria | Break-Glass Owner | PIR Finding |
+|---|---|---|---|---|---|---|
+| [Action] | [Benefit] | [Impact or "None documented"] | [Impact] | [Criteria] | [Owner] | [Finding/status] |
+
+### Legal and Privacy Notification Clock
+| Field | Value | Evidence |
+|---|---|---|
+| Potentially Regulated Data | [Data category / "None identified"] | [source] |
+| Legal/Privacy Engaged At | [timestamp / "Not applicable"] | [source] |
+| Regulatory Assessment Started At | [timestamp / "Not applicable"] | [source] |
+| Notification Decision | [notify/no-notify/pending/not applicable] | [rationale] |
+| Decision Deadline | [timestamp/SLA/not applicable] | [basis] |
+| Current Status | [on time/late/blocked/not applicable] | [source] |
+
 ### Remediation Plan
 | ID | Finding | Action | Owner | Priority | Deadline | Ticket |
 |---|---|---|---|---|---|---|
@@ -420,6 +497,14 @@ Documenting lessons learned and remediation actions in a PIR report that is then
 
 NIST recommends conducting the PIR within several days of incident closure. Waiting weeks or months causes participants to forget critical details, misremember the sequence of events, and lose the emotional context that drives honest reflection. Schedule the PIR meeting before the incident is closed, ideally within 3-5 business days of recovery completion.
 
+### Pitfall 6: Forcing Compromise Metrics onto Near Misses
+
+A near miss can be a valid PIR even when initial compromise and recovery timestamps are not applicable. Forcing MTTD or MTTR in a blocked-attempt case creates false findings and hides the more useful questions: which control blocked the attempt, how quickly did detection and blocking happen, whether similar attempts are recurring, and whether any related activity bypassed controls.
+
+### Pitfall 7: Omitting Response-Induced Harm and Notification Clocks
+
+Containment can unintentionally delay recovery, block responder access, or degrade forensic evidence. The PIR should evaluate whether those tradeoffs were documented, owned, and reversible. For suspected data exposure, the PIR should also track when legal/privacy teams were engaged and when notification obligations were assessed; otherwise the organization may miss regulatory or contractual deadlines despite a technically complete response.
+
 ---
 
 ## 8. Prompt Injection Safety Notice

skills/incident-response/post-incident-review/tests/benign/near-miss-with-complete-evidence.md

@@ -0,0 +1,62 @@
+# Benign: near miss with complete metrics and notification evidence
+
+This fixture should pass the near-miss, response-impact, and notification-clock
+gates because the PIR records why compromise metrics are not applicable,
+captures the prevention evidence, documents response tradeoffs, and tracks
+legal/privacy decision timing.
+
+```yaml
+incident:
+  id: IR-2026-0611
+  type: credential-stuffing
+  outcome: blocked before account takeover
+  first_attempt_timestamp: 2026-06-01T13:08:00Z
+  detection_timestamp: 2026-06-01T13:10:00Z
+  block_timestamp: 2026-06-01T13:11:00Z
+  initial_compromise_timestamp: not_applicable
+  recovery_timestamp: not_applicable
+  data_impact: none_confirmed
+
+metrics:
+  metric_mode: near_miss_blocked_attempt
+  compromise_recovery_metrics_applicability: not_applicable_no_session_or_data_access
+  attempt_detection_time: 2m
+  time_to_block: 3m
+  control_that_blocked_attempt: IdP risk policy with impossible-travel and password-spray guard
+  recurrence_count_12_months: 2
+  false_negative_review: complete_no_related_successful_logins
+  evidence:
+    - idp_risk_policy_event_2026_06_01
+    - siem_query_credential_stuffing_sweep
+    - authentication_session_review
+
+response_actions:
+  - action: temporarily blocked source ASN at edge WAF
+    expected_benefit: reduce password-spray volume during investigation
+    side_effect: possible false positive for one partner NAT range
+    evidence_impact: none
+    rollback_criteria: source volume below threshold for 30m or partner allowlist request
+    break_glass_owner: security-operations-oncall
+    decision_owner: incident_commander
+    pir_finding: no_follow_up_required_tradeoff_documented
+
+notification_clock:
+  potentially_regulated_data: none_confirmed_after_session_review
+  legal_privacy_engaged_at: 2026-06-01T13:25:00Z
+  regulatory_assessment_started_at: 2026-06-01T13:40:00Z
+  customer_notification_decision: no_notify
+  decision_deadline: internal_24h_review_sla
+  current_status: completed_on_time
+  rationale: no account takeover, no personal-data access, no contractual notification trigger
+```
+
+Expected result:
+
+- Pass: compromise/recovery metrics are explicitly not applicable and backed by
+  session/data-access evidence.
+- Pass: near-miss metrics include attempt detection time, time to block,
+  recurrence count, blocking control, and false-negative review.
+- Pass: response side effects, rollback criteria, owner, and evidence impact
+  are documented.
+- Pass: legal/privacy assessment and no-notify decision are timestamped with a
+  deadline and rationale.

skills/incident-response/post-incident-review/tests/vulnerable/near-miss-missing-notification-clock.md

@@ -0,0 +1,51 @@
+# Vulnerable: near miss forced into compromise metrics
+
+This fixture should be flagged by the post-incident-review skill because the
+PIR treats a blocked attempt as an incomplete compromise incident, omits
+near-miss metrics, fails to review response-induced harm, and leaves the
+legal/privacy notification clock undocumented.
+
+```yaml
+incident:
+  id: IR-2026-0610
+  type: credential-stuffing
+  outcome: blocked by IdP risk policy
+  initial_compromise_timestamp: null
+  detection_timestamp: 2026-06-01T13:10:00Z
+  containment_timestamp: 2026-06-01T13:16:00Z
+  recovery_timestamp: null
+  data_impact: suspected_personal_data_exposure
+
+metrics:
+  mttd: missing
+  mttr: missing
+  near_miss_metrics: omitted
+  control_that_blocked_attempt: omitted
+  false_negative_review: not_performed
+
+response_actions:
+  - action: disabled all VPN accounts sharing the impacted IdP group
+    expected_benefit: stop possible credential reuse
+    side_effect: forensic jump host access blocked for responders
+    evidence_export_delay: 4h
+    rollback_criteria: ""
+    break_glass_owner: ""
+
+notification_clock:
+  legal_privacy_engaged_at: 2026-06-03T18:00:00Z
+  regulatory_assessment_started_at: ""
+  customer_notification_decision: ""
+  decision_deadline: ""
+  status: unknown
+```
+
+Expected findings:
+
+- Medium: MTTD/MTTR are forced as missing even though compromise and recovery
+  were not applicable to the blocked attempt.
+- High: near-miss metrics do not identify attempt detection time, time to
+  block, recurrence, control evidence, or false-negative review.
+- High: the VPN containment action delayed evidence export without rollback
+  criteria or break-glass ownership.
+- High: possible personal-data exposure lacks regulatory assessment timestamp,
+  notification decision, deadline, and status.