/irp

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 procedu