What this prompt does
This prompt builds a full incident response playbook tuned to your specific threat, org type, and compliance obligations — not a generic checklist you'd find in an ISO 27001 template pack. It follows the NIST SP 800-61 lifecycle (Prepare → Detect → Contain → Eradicate → Recover → Post-Incident Activity) but forces the AI to generate concrete, named actions rather than vague guidance like "isolate the affected system."
What makes this template structurally sound is that the variables are load-bearing. [containment_strategy] changes the entire Containment section: "aggressive isolation" produces network segmentation commands, while "covert monitoring" produces packet capture and canary token instructions. [backup_type] directly shapes restoration steps — immutable S3 snapshots versus bare-metal images require completely different validation checklists. The prompt explicitly asks for minute-by-minute containment steps, which prevents the AI from generating abstract advice and forces operational specificity.
The communication section is deliberately built around your [compliance] variable. HIPAA, PCI-DSS, and GDPR each have different breach notification windows and mandatory disclosures, and the prompt threads that through both customer notification language and regulatory filing templates.
When to use it
- You're a solo security engineer at a SaaS startup and need a ransomware playbook before your first SOC tool is even deployed.
- Your team just passed a SOC 2 audit and needs documented IR procedures to satisfy the CC7 control family.
- You're running a tabletop exercise and need a realistic scenario-specific playbook to test against, not a templated handout.
- A client engagement requires you to deliver an IR runbook as a deliverable within 48 hours.
- You're onboarding a junior analyst and want a structured guide they can follow without senior oversight at 3 AM.
- Post-breach, you need to rebuild your playbook with lessons learned already baked in.
Example output
For [incident_type] = credential stuffing attack on customer login endpoint:
DETECTION
- Alert rule: >50 failed logins from distinct IPs in 60s on /api/auth/login
- IOC: User-agents cycling through known credential-stuffing tool signatures
- Triage: Cross-reference IPs against threat intel feed; check for successful
logins from same IP range (true positive signal)
CONTAINMENT (minute-by-minute)
T+0: Enable Cloudflare rate limiting rule on /api/auth/login (pre-staged;
name your rule during preparation — e.g., RATE-AUTH-01)
T+5: Notify affected user segment via internal Slack #incidents
T+15: Force password reset for accounts with successful logins from flagged IPs
T+30: Decision point — if attack continues, enable CAPTCHA on login endpoint
Pro tips
- Set
[containment_strategy]to "isolate" vs "monitor" deliberately — monitoring is legally and operationally correct if you need forensic evidence for law enforcement, but isolation is correct if patient-zero machines are still actively exfiltrating data. The playbook changes significantly depending on which you choose. - For
[compliance] = GDPR, the AI will generate 72-hour notification language per Article 33. Check that the customer notification draft it produces does not describe the vulnerability specifics — disclosing technical details of the flaw in a breach notice is a scope violation you want to catch before it goes out. - Run the prompt twice with different
[team_size]values (e.g., "2-person team" vs "dedicated SOC of 15") — escalation matrices and role assignments will differ substantially, which helps you identify where your current team has coverage gaps. - The prompt asks for forensic-sound evidence collection. If you're on AWS, specify that in
[infrastructure]— you'll get EC2 memory capture steps via SSM Run Command and CloudTrail log preservation commands, not genericddinstructions that assume physical access to the host.
