Legal Incident Response Plan

---
name: legal-incident-response-plan
description: Create a legal data breach response plan — severity levels, response team, containment, investigation, notification deadlines by jurisdiction, communication templates and tabletop exercises. Use when the user has no written plan for a data breach and needs one drafted, through regulator and customer notices. Not for technical playbooks; see /security-incident-response.
metadata:
  argument-hint: "[project] [--skip-checks]"
  workflow: legal
  phase: 3
  artifact: 03-comply.md
---

# Incident Response Plan

Create a data breach and security incident response plan for "$ARGUMENTS". Define incident classification, response procedures, notification requirements, communication templates, and post-incident review processes.

> **Note:** AI-generated legal content does not constitute legal advice. Consult a qualified attorney.

**Arguments.** `$ARGUMENTS` may contain the project name and optional flags. Take the first token as `<project>` and treat `--skip-checks` as a flag; never include flags in file paths. All paths below use `<project>`. If `--skip-checks` is present, skip the prerequisite check and, **before writing any artifact**, append one line to `.singularskills/log.jsonl`: `{"ts":"<ISO timestamp>","skill":"legal-incident-response-plan","workflow":"legal","phase":3,"project":"<project>","event":"skipped","artifact":"03-comply.md","note":"<reason or \"none given\">"}`.

## Prerequisites

**Part of a workflow.** This skill is phase 3 (Comply) of the Legal Lifecycle workflow (`legal`); cross-domain workflows run it too. First check `.singularskills/log.jsonl` for an open run for this project: a `run-started` line with `"project":"<project>"` and no later `run-finished` line for the same `workflow` and `project`. If one exists, the conductor is running you: continue here. Otherwise, if the user asked to start, run, continue or resume a process or workflow rather than this one step, do not continue here: invoke the `workflow` skill with the workflow the user asked for, or `legal` when they named none, followed by `<project>`; it runs this phase in order, asks before it writes and records the run. Otherwise continue here: a later phase runs on its own, behind its gate.

Run this skill's gate before writing: `sh <this skill's folder>/scripts/gate.sh <project> <project root>`, where `<project root>` is the folder that contains `.singularskills/` (use `.` when you are already there). If it exits non-zero, stop and tell the user what it printed, unless `--skip-checks` was given (see Arguments). On a refusal, before you stop, append this line to `.singularskills/log.jsonl` (create the folder and file if missing): `{"ts":"<ISO timestamp>","skill":"legal-incident-response-plan","workflow":"legal","phase":3,"project":"<project>","event":"refused","artifact":"03-comply.md","note":"<what the gate printed>"}`. Once the gate has passed, or under `--skip-checks` once you have appended the `skipped` line, append this line before you start work: `{"ts":"<ISO timestamp>","skill":"legal-incident-response-plan","workflow":"legal","phase":3,"project":"<project>","event":"started","artifact":"03-comply.md","note":""}`.

Check that `.singularskills/legal/<project>/00-assess.md` exists. If it does not exist, stop and tell the user:

> "Run an Assess skill first (e.g. `/legal-risk-assessment <project>`) to generate the prerequisite assessment artifact."

## Process

1. **Read inputs:**
   - Read `.singularskills/legal/<project>/00-assess.md` for risk, jurisdiction, and data practice context
   - Read any existing security or compliance artifacts in `.singularskills/legal/<project>/` for additional context

2. **Define incident types and severity classification:**
   - **P1 — Critical:** confirmed data breach with sensitive personal data exposed, ransomware with data exfiltration, compromise of authentication systems, regulatory notification thresholds met
   - **P2 — High:** unauthorized access to systems containing personal data, significant service disruption, suspected data breach under investigation, insider threat confirmed
   - **P3 — Medium:** attempted unauthorized access (blocked but notable), minor data exposure (non-sensitive, limited scope), malware detection on non-critical systems, policy violations with data implications
   - **P4 — Low:** phishing attempts (no compromise), minor policy violations, vulnerability discovered (not exploited), suspicious activity under monitoring
   - Escalation criteria between severity levels

3. **Create detection and identification procedures:**
   - Technical detection sources (SIEM, IDS/IPS, endpoint detection, DLP, log monitoring)
   - Human reporting channels (employee reporting, customer complaints, partner notifications, threat intelligence feeds)
   - Initial triage checklist (what happened, when, what systems/data affected, is it ongoing, initial severity assessment)
   - Documentation requirements from point of detection

4. **Define incident response team:**
   - **Incident Commander** — overall coordination, decision authority, stakeholder communication
   - **Technical Lead** — technical investigation, containment, remediation
   - **Legal Counsel** — notification obligations, regulatory requirements, privilege considerations, law enforcement liaison
   - **Communications Lead** — internal and external communications, media handling
   - **Executive Sponsor** — business decisions, resource authorization, board reporting
   - Contact information and escalation paths (primary and backup for each role)
   - External resources (forensics firm, outside counsel, crisis communications, cyber insurance carrier)

5. **Containment procedures:**
   - **Immediate containment** (first 1-4 hours) — isolate affected systems, preserve evidence, block attack vectors, activate incident response team
   - **Short-term containment** (4-48 hours) — implement temporary fixes, enhanced monitoring, assess scope
   - **Long-term containment** — system rebuilds, credential resets, architecture changes
   - Decision framework for system shutdown vs. monitored containment
   - Evidence preservation requirements during containment

6. **Investigation steps:**
   - Root cause analysis methodology
   - Scope determination (what data, how many records, which individuals, geographic scope)
   - Affected data and individual identification
   - Attack vector and timeline reconstruction
   - Forensic evidence collection and chain of custody
   - Engagement criteria for external forensics

7. **Notification requirements by jurisdiction:**
   - **GDPR (EU):** 72 hours to supervisory authority (Article 33), without undue delay to individuals when high risk (Article 34)
   - **US state breach notification laws:** varies 30-90 days depending on state (document requirements for each applicable state)
   - **Sector-specific:** HIPAA — 60 days to HHS, individuals, and media (if 500+ affected); GLBA — 36 hours to primary federal regulator; PCI DSS — immediate to acquiring bank and card brands
   - **Other jurisdictions:** document notification requirements based on assessment context
   - Notification content requirements per jurisdiction
   - Attorney General notification requirements
   - Credit monitoring obligations

8. **Draft communication templates:**
   - **Regulatory notification** — nature of breach, categories and approximate number of data subjects, DPO contact, likely consequences, measures taken
   - **Affected individual notice** — plain language description, data involved, steps taken, recommended protective actions, contact information for questions
   - **Media statement** — brief factual statement, commitment to transparency, contact for inquiries
   - **Internal communication** — employee notification, management briefing, board notification
   - **Customer FAQ** — anticipated questions and approved responses
   - Version control and approval workflow for all communications

9. **Evidence preservation procedures:**
   - System logs and their retention
   - Forensic image requirements
   - Chain of custody documentation
   - Legal hold procedures
   - Attorney-client privilege considerations for investigation materials

10. **Post-incident review process:**
    - Lessons learned meeting (within 1-2 weeks of incident closure)
    - Root cause analysis documentation
    - Control improvement recommendations
    - Policy and procedure updates
    - Training needs identified
    - Metrics tracking (detection time, containment time, notification time, total resolution time)

11. **Tabletop exercise plan:**
    - Exercise scenarios (one per incident type/severity)
    - Participant roles and preparation
    - Exercise facilitation guide
    - Evaluation criteria
    - Recommended frequency (at minimum annually, quarterly for high-risk organizations)
    - Documentation and improvement tracking

12. **Write the artifact** — append to `.singularskills/legal/<project>/03-comply.md` under a `## Incident Response Plan` section. Create the file with a `# Comply — <project>` heading if it does not exist; if a `## Incident Response Plan` section already exists, replace only that section. The section contains:

    - **Incident Classification** — types and severity levels (P1-P4)
    - **Detection and Identification** — sources, channels, and triage procedures
    - **Incident Response Team** — roles, contacts, and escalation paths
    - **Containment Procedures** — immediate, short-term, and long-term actions
    - **Investigation Framework** — root cause, scope, and forensics
    - **Notification Requirements** — jurisdiction-by-jurisdiction obligations and timelines
    - **Communication Templates** — regulatory, individual, media, and internal templates
    - **Evidence Preservation** — collection, custody, and legal hold procedures
    - **Post-Incident Review** — lessons learned and improvement process
    - **Tabletop Exercise Plan** — scenarios, facilitation, and schedule
    - **Compliance Gaps** — identified gaps with remediation recommendations

## Output

The incident response plan appended to `.singularskills/legal/<project>/03-comply.md`. Present a summary to the user highlighting:
- Incident severity classification (P1-P4) defined
- Incident response team roles identified
- Notification requirements by jurisdiction with timelines
- Communication templates drafted
- Tabletop exercise plan and recommended frequency
- Critical gaps in current incident preparedness

**Record the run.** After you have written your section, append this line to `.singularskills/log.jsonl` (the `started` line of Prerequisites, with `"event":"finished"`): `{"ts":"<ISO timestamp>","skill":"legal-incident-response-plan","workflow":"legal","phase":3,"project":"<project>","event":"finished","artifact":"03-comply.md","note":""}`.

This artifact is shared by every skill of phase 3 (Comply). The frontmatter is written once, by whoever creates the file: if you create it, open it with the block below (`skill` is the phase title, `started` the time of that first write; `gate` is `passed` when the gate ran clean and `skipped` under `--skip-checks`); if it already exists, leave the block alone except to update `finished` and to set `gate` to the worst value among the sections (`skipped` over `passed`).

```yaml
---
skill: Comply
workflow: legal
phase: 3
project: <project>
started: <ISO timestamp>
finished: <ISO timestamp>
agent: <the agent you run in, or "unknown">
gate: <passed|skipped>
---
```

Open your `## Incident Response Plan` section with one italic line, `*<skill name> · <ISO timestamp> · gate: <passed|skipped>*` (your skill name is `legal-incident-response-plan`).

End your section with `### Decisions` and `### Open questions` (one level under your `## Incident Response Plan` heading, so the section stays one block), in this shape:

```markdown
### Decisions
- <what was chosen> — <why> — <what was rejected>

### Open questions
- <what the next phase or a reviewer must settle>
```