pmstudio-irp git:20260914.e75f220A

Immutable. This exact content is served forever at /api/v1/blob/207c81ba98043eba.

---
name: pmstudio-irp
description: "Use when the user asks for an incident response plan, IRP, escalation matrix or incident playbook. Writes an offline HTML plan with severities, escalation contacts and comms; DR restores service, IRP runs the incident."
domain: ops
---

# IRP — Incident Response Plan

## Purpose

Generates an Incident Response Plan specific to the product/platform. Not a generic IT incident template — this plan is scoped to the product, uses its real stakeholders as escalation contacts, and ties severity to its data classification.

## Process

### Step 1: Read Context

**Read all that exist:**
- `CLAUDE.local.md` — architecture, stakeholders, vendor contacts, data classification
- `PRD/*.html` or `PRD/*.md` — security section, RBAC, NFRs, integrations
- `Data/Stakeholder-Directory.*` — escalation contacts with roles and emails
- `Operational/DR-Plan*.html` — recovery procedures to reference (if exists)

### Step 2: Ask Discovery Questions

Only ask what can't be inferred:

1. **What constitutes an "incident" for this product?** (data breach, service outage, unauthorized access, integration failure, data corruption)
2. **Who is the Incident Commander?** (default: PM, but confirm)
3. **Vendor support model?** (SLA response times, escalation contacts, ticket system)
4. **Legal/privilege considerations?** (e.g., ProductB has legal privilege — incidents may require legal counsel)
5. **Existing Coco Inc incident process?** (does the team already report through ServiceNow, Slack, etc.)

### Step 3: Generate IRP Document

**Output:** `Operational/IRP-{ProductName}-{Date}.html`

Self-contained HTML with print-optimized CSS. No CDN dependencies — this document must work offline during an actual incident.

**12 sections:**

**1. Purpose & Scope**
- Which product/instance this plan covers
- What qualifies as an incident vs. a support request
- Relationship to firm-wide incident process

**2. Severity Classification**

Build product-specific severity matrix. See `references/severity-matrix.md` for the framework.

Key rule: **Data classification drives minimum severity.**
- Purple Data incident = auto-SEV1
- Red Data incident = minimum SEV2
- Yellow/Green = severity based on impact

| Severity | Definition | Response Time | Example |
|----------|-----------|---------------|---------|
| SEV1 — Critical | Data breach, complete service outage, legal/regulatory exposure | 15 min | Purple Data accessed by unauthorized user |
| SEV2 — High | Significant functionality loss, data integrity issue, >50% users affected | 1 hour | Integration failure causing data sync halt |
| SEV3 — Medium | Partial functionality loss, workaround available, <50% users affected | 4 hours | Single module unavailable, manual process possible |
| SEV4 — Low | Minor issue, cosmetic, single-user impact | Next business day | Report formatting error, UI glitch |

**3. Detection & Reporting**
- How incidents are typically detected (user report, monitoring, vendor notification)
- Reporting channel (email, Slack, ServiceNow ticket)
- What information to include when reporting

**4. Escalation Matrix**
- Per-severity: who to contact, in what order, with backup contacts
- Pull real names and emails from stakeholder directory
- Include vendor escalation path

**5. Response Procedures**
- Per-severity playbooks with triage, containment, investigation, resolution steps
- See `references/escalation-patterns.md` for playbook structure

**6. Communication Protocol**
- Internal (team Slack/Teams channel)
- Stakeholder (email using `/pmstudio-comms incident` template)
- Vendor (support ticket + phone for SEV1-2)
- Leadership (when to escalate to SteerCo)
- Per-severity: who communicates what, when, through which channel

**7. Evidence Preservation**
- What to capture: screenshots, logs, timestamps, affected records
- Where to store: incident folder in SharePoint, not in the product itself
- Chain of custody for legal/privilege incidents

**8. Resolution & Recovery**
- Handoff to DR/Recovery plan (if exists)
- Verification steps before declaring resolved
- Service restoration confirmation checklist

**9. Post-Incident Review (PIR)**
- PIR meeting within 48 hours of resolution
- Template: timeline, impact, root cause, contributing factors, what went well, what to improve, action items
- PIR document stored in `Meeting-Notes/PIR-{Date}-{Summary}.md`

**10. Roles & Responsibilities**
- Incident Commander (owns coordination)
- Communications Lead (owns stakeholder updates)
- Technical Lead (owns diagnosis and fix)
- Vendor Liaison (owns vendor communication)
- Legal Counsel (for privilege/regulatory incidents)

**11. Vendor Escalation**
- Vendor support tiers and SLA response times
- Escalation contacts (from project memory)
- Ticket creation procedure
- When to bypass normal support (SEV1 phone escalation)

**12. Review & Maintenance**
- Review cadence: semi-annually or after any SEV1-2 incident
- Tabletop exercise schedule: annually
- Contact list verification: quarterly
- Version history

### Step 4: Present for Review

Show the complete plan structure with key content decisions highlighted:
- Severity matrix with product-specific examples
- Escalation matrix with real names
- Any assumptions made

Ask for approval before writing the file.

## Critical Rules

1. **Zero external dependencies.** The HTML must render fully offline. No CDN links. During an incident, internet may be unreliable.
2. **Real contacts only.** Pull names/emails from project files. Leave blanks with "[TBD — add contact]" markers rather than guessing.
3. **Legal privilege awareness.** If the project involves legal privilege (like ProductB/Tax), include a section on when to involve legal counsel and how to protect privilege during incident response.
4. **Severity ties to data.** Always tie severity classification to the product's data classification. Don't create a severity matrix that ignores data sensitivity.
5. **Actionable, not aspirational.** Every procedure should be something the team can actually execute today with current tools and access. Don't include monitoring procedures if no monitoring exists yet.