# Incident Response Checklist

**Obfuscation Hub Toolkit — starter template (Release 0.1)**

> Adapt this checklist to your organization before relying on it: insert your
> real names, systems, and contacts, and review it with leadership. It is an
> educational starting point — not legal advice, not a substitute for counsel
> or your cyber-insurance carrier's required procedures.

---

## How to use this checklist

Work top to bottom during an incident; phases overlap in practice. Anything in
[brackets] must be replaced with your organization's specifics **before** an
incident. Keep a printed or offline copy — incidents have a habit of affecting
the systems your documentation lives on.

---

## 0. Preparation (complete before any incident)

- [ ] Incident lead named: [name, backup name]
- [ ] Decision authority for business-impacting containment (e.g., cutting a
      vendor, taking a system offline): [name/role]
- [ ] Contact tree stored offline: leadership, IT/MSP, cyber-insurance carrier
      ([policy #, hotline]), legal counsel, key vendors
- [ ] Insurance notification requirements read and summarized: [deadline, approved-vendor requirements]
- [ ] Evidence storage location agreed (outside affected systems): [location]
- [ ] Severity levels defined (see table below), reviewed by leadership
- [ ] This checklist reviewed/exercised in the last 12 months: [date]

### Severity starter table (adjust to your business)

| Level | Definition (example) | First-hour expectation |
| --- | --- | --- |
| SEV-1 | Confirmed compromise, active data loss, or business-stopping outage | Incident lead engaged; leadership + insurer notified |
| SEV-2 | Probable compromise or contained malicious activity | Incident lead engaged; containment begun |
| SEV-3 | Suspicious activity, unconfirmed | Investigate within business hours; log everything |

## 1. Detection and triage

- [ ] Start the incident log NOW: time (with timezone), event, source, who observed it
- [ ] Record how the incident was detected and by whom
- [ ] Assign a severity level; note the reasoning
- [ ] Establish an out-of-band communication channel if email/chat may be affected: [channel]
- [ ] Do NOT power off affected machines unless destruction is in progress
      (memory and logs are evidence); isolate from network instead
- [ ] Notify per severity table

## 2. Containment

- [ ] Isolate affected endpoints (network isolation via EDR/management tool, or unplug)
- [ ] Disable or reset affected accounts; revoke active sessions and tokens
- [ ] Block attacker infrastructure (IPs/domains) where identified
- [ ] Suspend affected vendor/integration access if implicated
- [ ] Preserve before you change: screenshot, export, or note the state of
      anything you are about to modify
- [ ] Record every containment action in the log: time, action, actor
- [ ] Decision checkpoint: is business-impacting containment needed?
      Escalate to [decision authority] — do not decide alone

## 3. Eradication

- [ ] Identify root cause (initial access) to the extent possible — containment
      without root cause tends not to hold
- [ ] Remove persistence: malicious inbox rules, added accounts, scheduled
      tasks, unauthorized OAuth grants, rogue MFA registrations
- [ ] Reset credentials with confirmed or suspected exposure (order: admin
      accounts, then affected users, then service accounts)
- [ ] Patch or reconfigure the exploited weakness
- [ ] Rebuild compromised systems from known-good sources where confidence is low

## 4. Recovery

- [ ] Restore services in priority order: [list your critical services]
- [ ] Validate restores from backup (integrity + malware-free) before reconnecting
- [ ] Heighten monitoring on affected accounts/systems for [14/30] days
- [ ] Confirm with system owners that business function is actually restored
- [ ] Declare recovery formally; note date/time in the log

## 5. Communication (runs alongside all phases)

- [ ] Single spokesperson designated: [name]
- [ ] Internal updates on a stated cadence — even "no change" builds trust
- [ ] Legal/insurer consulted BEFORE external statements about data exposure
- [ ] Customer/partner notifications drafted with counsel where data may be affected
- [ ] Regulatory/contractual notification obligations checked: [list yours]

## 6. Post-incident review (within 2 weeks)

- [ ] Blameless review held; timeline reconstructed from the incident log
- [ ] Root cause and contributing factors documented
- [ ] What worked / what did not — honestly recorded
- [ ] Action items with owners and due dates (controls, monitoring, process)
- [ ] This checklist updated with lessons learned
- [ ] Evidence and log archived per retention policy: [location, duration]

---

*Source: Obfuscation Hub Toolkit. Structure informed by widely used incident
handling guidance (e.g., NIST SP 800-61). Verify current authoritative guidance
at csrc.nist.gov and cisa.gov.*