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 classificationPRD/*.htmlorPRD/*.md— security section, RBAC, NFRs, integrationsData/Stakeholder-Directory.*— escalation contacts with roles and emailsOperational/DR-Plan*.html— recovery procedures to reference (if exists)
Step 2: Ask Discovery Questions
Only ask what can't be inferred:
- What constitutes an "incident" for this product? (data breach, service outage, unauthorized access, integration failure, data corruption)
- Who is the Incident Commander? (default: PM, but confirm)
- Vendor support model? (SLA response times, escalation contacts, ticket system)
- Legal/privilege considerations? (e.g., ProductB has legal privilege — incidents may require legal counsel)
- 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.mdfor playbook structure
6. Communication Protocol
- Internal (team Slack/Teams channel)
- Stakeholder (email using
/pmstudio-comms incidenttemplate) - 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
- Zero external dependencies. The HTML must render fully offline. No CDN links. During an incident, internet may be unreliable.
- Real contacts only. Pull names/emails from project files. Leave blanks with "[TBD — add contact]" markers rather than guessing.
- 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.
- Severity ties to data. Always tie severity classification to the product's data classification. Don't create a severity matrix that ignores data sensitivity.
- 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.
