Run or document a security incident response — contain, eradicate, recover, and learn. Use when responding to a breach/compromise/security incident, writing an IR plan or runbook, or producing a post-incident report. Produces a phase-by-phase response (triage, contain, eradicate, recover, post-incident) with the immediate actions, comms, evidence-handling, and a blameless review. For incidents on systems you own or defend.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add mohitagw15856/pm-claude-skills --skill security-incident-response --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Security Incident Response?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/mohitagw15856-security-incident-response)More formats (shields.io, HTML) on the badges page.
---
name: security-incident-response
description: "Run or document a security incident response — contain, eradicate, recover, and learn. Use when responding to a breach/compromise/security incident, writing an IR plan or runbook, or producing a post-incident report. Produces a phase-by-phase response (triage, contain, eradicate, recover, post-incident) with the immediate actions, comms, evidence-handling, and a blameless review. For incidents on systems you own or defend."
homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/security-incident-response.html
metadata:
{
"openclaw": { "emoji": "🔐" }
}
---
# Security Incident Response Skill
In a security incident, the order of operations matters: contain before you clean, preserve evidence before
you wipe, and communicate deliberately. This skill drives a structured response through the standard phases,
or documents one after the fact — with the immediate actions, decision points, comms, and a blameless
post-incident review. For systems you own or are authorized to defend.
## Required Inputs
Ask for these only if they aren't already provided:
- **What's happening** — the observed incident (malware, unauthorized access, data exfiltration, ransomware, account compromise), and how it was detected.
- **Scope so far** — affected systems/accounts/data, whether it's ongoing, entry point if known.
- **Environment & stakes** — what's at risk (PII, funds, availability), regulatory/notification obligations.
- **Resources** — who's responding, tooling/access available, and any IR plan already in place.
## Output Format
### Incident response: [incident]
**Severity & summary** — classify severity (e.g. SEV1–3) and state, in two lines, what's known and what's at stake.
**Phase-by-phase actions:**
1. **Triage & declare** — confirm it's a real incident, assign severity and an incident lead, start a timeline/log.
2. **Contain** — stop the bleeding *without* destroying evidence: isolate hosts, revoke sessions/keys, block IOCs, disable compromised accounts. Preserve forensic data (snapshots, logs, memory) before wiping.
3. **Eradicate** — remove the root cause: close the entry point, remove malware/backdoors, patch the exploited flaw, rotate all potentially exposed credentials/secrets.
4. **Recover** — restore from known-good, verify integrity, monitor closely for recurrence, return to normal service deliberately.
5. **Post-incident** — a **blameless** review: timeline, root cause, what worked/didn't, and action items to prevent recurrence.
**Communications** — who to notify and when: internal (leadership, legal), customers, and any **regulatory/breach-notification** obligations (with the clock — many have strict deadlines). Draft the holding line.
**Evidence & chain of custody** — what to preserve and how, in case of legal/law-enforcement involvement.
**IOCs & detection** — indicators of compromise seen, and detections/monitoring to add.
## Quality Checks
- [ ] Severity is classified and an incident lead + running timeline are established first
- [ ] Containment preserves evidence (snapshots/logs) before eradication/wiping
- [ ] Eradication addresses the root cause and rotates all potentially exposed credentials
- [ ] Recovery restores from known-good with heightened monitoring
- [ ] Communications cover internal, customer, and regulatory/breach-notification duties with timing
- [ ] The post-incident review is blameless and produces concrete prevention action items
## Anti-Patterns
- [ ] Do not wipe/rebuild before preserving forensic evidence — you lose the ability to understand the breach
- [ ] Do not skip credential rotation — attackers persist via stolen keys/tokens
- [ ] Do not go quiet on comms — silence with customers/regulators creates legal and trust damage
- [ ] Do not blame individuals in the review — blameless analysis surfaces the real systemic causes
- [ ] Do not declare "recovered" without monitoring for re-compromise
- [ ] Do not act on systems you don't own or aren't authorized to defend
## Based On
Incident-response practice (NIST SP 800-61 / SANS PICERL: prepare, identify, contain, eradicate, recover, lessons-learned).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!