Module 8 · Incident Response Playbook 🔒

An incident response (IR) playbook is the written plan your team executes when things go wrong. Not the feature of a tool, not an idea, not a slide deck — a concrete document that says “when X happens, do Y, then Z, with owner A accountable.” This module covers playbook structure, the core playbooks every organisation should have, and how to make them actually useful.

Why written playbooks matter

At 2am during a real incident, people forget. Pressure degrades decision-making. Playbooks compensate: follow the script, don’t re-derive the workflow under stress. Also: onboarding (new staff know the process), auditing (demonstrable), and legal (defensible).

Playbook structure

1. Scope — what incident type this covers
2. Roles — who does what (Incident Commander, Scribe, Comms, Technical Lead, Executive Sponsor)
3. Trigger — what activates this playbook
4. Initial response checklist — first 30 minutes
5. Investigation steps — scope, impact, root cause
6. Containment — stop the bleeding
7. Eradication — remove attacker foothold
8. Recovery — restore to clean state
9. Communication — who’s notified, when, by whom, with what message
10. Lessons learned — post-incident review process
11. Evidence handling — chain of custody, storage
12. External contacts — law enforcement, regulator, DPA, cyber-insurance

Core playbooks to build first

1. Ransomware — the one most organisations face
2. Data breach / exfiltration — with DPDP notification obligations (if India)
3. Phishing / credential compromise — common, lower-severity but frequent
4. DDoS — operational response
5. Insider threat — HR-involved, legal-heavy
6. Third-party / supply-chain breach — cascading compromise

Sample structure — Ransomware playbook

# RANSOMWARE RESPONSE PLAYBOOK

## Trigger
User reports files can't open, ransom note visible, EDR alert on ransomware TTPs,
unusual encryption activity on file servers.

## Roles (auto-assigned based on rota)
- Incident Commander: [name] / backup: [name]
- Scribe: designated
- Technical Lead: CTO or delegated
- Communications: CEO signs off external
- Legal: [firm] / [contact]

## T+0 to T+30 min — Contain
[ ] IC acknowledges alert; opens incident channel (Slack/Teams)
[ ] Isolate affected systems from network (but DON'T power off — lose memory)
[ ] Disable VPN access for affected users
[ ] Rotate credentials of any potentially compromised accounts
[ ] Preserve encrypted files samples for analysis
[ ] Begin log collection from affected systems
[ ] Notify CEO, Legal, Insurance contact (insurance clock starts now)
[ ] Do NOT pay ransom; do NOT communicate with attackers yet

## T+30 min to T+2 hrs — Scope
[ ] Forensics team begins memory + disk acquisition
[ ] Identify initial access vector (phishing? RDP? supply chain?)
[ ] Enumerate affected systems + data
[ ] Confirm backup integrity (separate isolated copy)
[ ] Identify PII/PHI/financial data in affected scope
[ ] If Indian Data Principals affected: DPDP 72-hour clock started

## T+2 to T+24 hrs — Eradicate + Recover
[ ] Confirm attacker removed from environment
[ ] Restore from clean backups (verified-clean, not infected)
[ ] Rotate ALL credentials (assume worst case)
[ ] Patch initial access vector
[ ] Re-enable services progressively with enhanced monitoring

## T+24 to T+72 hrs — Notify + Document
[ ] DPDP notification to Board (if personal data affected)
[ ] Customer notifications as required
[ ] Public communication (if warranted)
[ ] Regulatory filings (RBI, SEBI, sector-specific)
[ ] Preserve all evidence for potential prosecution

## Communication templates
[ ] Internal all-hands message (template below)
[ ] Customer notification (template below)
[ ] Regulator notification (template below)
[ ] Press statement (legal-reviewed template below)

## External contacts
- Cyber insurance: [policy number, hotline]
- Incident response retainer: [firm, 24/7]
- Law enforcement: CERT-In (cybersecurity incidents in India)
- Data Protection Board: [process for DPDP breach notification]
- Outside counsel: [firm, contact]

## Evidence handling
- Memory dumps: SHA-256 hashed, AWS S3 with Object Lock, retained 7 years
- Logs: centralized SIEM, separate archive bucket
- Photos: timestamped, annotated

Tabletop exercises

Playbooks only work if the team has rehearsed. Tabletop exercises walk through a simulated incident — 2-3 hours, full team present, facilitator introduces new information every 15 min, team works through the playbook. Surfaces gaps in process, capability, or alignment.