incident-response

---
name: incident-response
description: Use when a security incident is declared and needs classification, triage, escalation routing, or forensic evidence collection. Covers SEV1-SEV4 severity and the DFRWS forensic lifecycle.
category: Engineering
version: 1.0.0
tools: []
---

# Incident Response

Full lifecycle for declared security incidents: classify, score severity, filter false positives, collect forensic evidence, and route escalation. This is not proactive threat hunting and not post-incident compliance mapping — it covers classifying, triaging, and managing incidents that have already been declared.

## Scope vs. adjacent skills

| Skill | Focus | Approach |
|---|---|---|
| incident-response (this) | Active incidents | Reactive — classify, escalate, collect evidence |
| threat-detection | Pre-incident hunting | Proactive — find threats before alerts fire |
| cloud-security | Cloud posture assessment | Preventive — IAM, S3, network misconfiguration |
| red-team | Offensive simulation | Offensive — test detection and response capability |

## Triage: what to establish for every event

For any security event (SIEM alert, EDR detection, threat intel feed, or user report), establish: event type, affected host, associated user, source IP, timestamp, and a summary of raw evidence. Then classify against the incident taxonomy, apply false-positive filters, score severity, and determine the escalation path — walk the user through this in chat rather than assuming automated tooling.

## Incident taxonomy (14 types)

Classification drives default severity, MITRE technique mapping, and response SLA:

| Incident Type | Default Severity | MITRE Technique | Response SLA |
|---|---|---|---|
| ransomware | SEV1 | T1486 | 15 minutes |
| data_exfiltration | SEV1 | T1048 | 15 minutes |
| apt_intrusion | SEV1 | T1566 | 15 minutes |
| supply_chain_compromise | SEV1 | T1195 | 15 minutes |
| domain_controller_breach | SEV1 | T1078.002 | 15 minutes |
| credential_compromise | SEV2 | T1110 | 1 hour |
| lateral_movement | SEV2 | T1021 | 1 hour |
| malware_infection | SEV2 | T1204 | 1 hour |
| insider_threat | SEV2 | T1078 | 1 hour |
| cloud_account_compromise | SEV2 | T1078.004 | 1 hour |
| unauthorized_access | SEV3 | T1190 | 4 hours |
| policy_violation | SEV3 | N/A | 4 hours |
| phishing_attempt | SEV4 | T1566.001 | 24 hours |
| security_alert | SEV4 | N/A | 24 hours |

### SEV escalation triggers

Any of these force a re-declaration to a higher severity, regardless of initial classification:

| Trigger | New Severity |
|---|---|
| Ransomware note found | SEV1 |
| Active exfiltration confirmed | SEV1 |
| CloudTrail or SIEM disabled | SEV1 |
| Domain controller access confirmed | SEV1 |
| Second system compromised | SEV1 |
| Exfiltration volume exceeds 1 GB | SEV2 minimum |
| C-suite account accessed | SEV2 minimum |

## Severity framework (SEV1–SEV4)

| Level | Name | Criteria | Response Invoked | Escalation Path |
|---|---|---|---|---|
| SEV1 | Critical | Confirmed ransomware; active PII/PHI exfiltration (>10K records); domain controller breach; defense evasion (CloudTrail disabled); supply chain compromise | Full response, in parallel | SOC Lead → CISO → CEO → Board Chair |
| SEV2 | High | Confirmed unauthorized access to sensitive systems; credential compromise with elevated privileges; lateral movement confirmed; ransomware indicators without confirmed execution | Triage + containment + forensics | SOC Lead → CISO |
| SEV3 | Medium | Suspected unauthorized access (unconfirmed); malware detected and contained; single account compromise (no priv escalation) | Triage + containment | SOC Lead → Security Manager |
| SEV4 | Low | Security alert with no confirmed impact; informational indicator; policy violation with no data risk | Triage only | L3 Analyst queue |

Response timing: SEV1 → immediate 15-minute war room, all hands. SEV2 → 1-hour bridge call, async coordination. SEV3/SEV4 → standard ticket-based handling.

## False positive filtering

Apply these five filters before escalating, to prevent false-positive inflation:

| Filter | Description | Example Pattern |
|---|---|---|
| CI/CD agent activity | Known build/deploy agents flagged as anomalies | jenkins, github-actions, circleci, gitlab-runner |
| Test environment tagging | Assets tagged as non-production | test-, staging-, dev-, sandbox- |
| Scheduled job patterns | Expected batch processes triggering alerts | cron, scheduled_task, batch_job, backup_ |
| Whitelisted identities | Explicitly approved service accounts | svc_monitoring, svc_backup, datadog-agent |
| Scanner activity | Known security scanners and vulnerability tools | nessus, qualys, rapid7, aws_inspector |

A confirmed false positive suppresses escalation; log the suppression reason for audit purposes. Recurring false positives from the same source should be tuned out at the detection layer, not filtered repeatedly at triage.

## Forensic evidence collection

Follow the DFRWS six-phase framework and the principle of volatile-first acquisition:

| Phase | Activity | Priority |
|---|---|---|
| Identification | Identify what evidence exists and where | Immediate |
| Preservation | Prevent modification — write-block, snapshot, legal hold | Immediate |
| Collection | Acquire evidence in order of volatility | Immediate |
| Examination | Technical analysis of collected evidence | Within 2 hours |
| Analysis | Interpret findings in investigative context | Within 4 hours |
| Presentation | Produce findings report with chain of custody | Before incident closure |

**Volatile evidence — collect first, in order:**
1. Live memory (RAM dump) — lost on reboot
2. Running processes and open network connections
3. Logged-in users and active sessions
4. System uptime and current time (for timeline anchoring)
5. Environment variables and loaded kernel modules

**Chain of custody** — every evidence item needs: a SHA-256 hash at acquisition time, an acquisition timestamp in UTC with timezone offset, tool provenance (e.g. FTK Imager, Volatility, dd, AWS CloudTrail export), investigator identity, and a transfer log of custody changes.

## Escalation paths

**By severity:**

| Severity | Immediate Contact | Bridge Call | External Notification |
|---|---|---|---|
| SEV1 | SOC Lead + CISO (15 min) | Immediate war room | Legal + PR standby; regulatory notification per deadline table |
| SEV2 | SOC Lead (30 min async) | 1-hour bridge | Legal notification if PII involved |
| SEV3 | Security Manager (4 hours) | Async only | None unless scope expands |
| SEV4 | L3 Analyst queue (24 hours) | None | None |

**By incident type:**

| Incident Type | Primary Escalation | Secondary |
|---|---|---|
| Ransomware / APT | CISO + CEO | Board if data at risk |
| PII/PHI breach | Legal + CISO | Regulatory body (per deadline table) |
| Cloud account compromise | Cloud security team | CISO |
| Insider threat | HR + Legal + CISO | Law enforcement if criminal |
| Supply chain | CISO + Vendor management | Board |

## Regulatory notification obligations

The notification clock starts at incident declaration, not at investigation completion:

| Framework | Incident Type | Deadline | Penalty |
|---|---|---|---|
| GDPR (EU 2016/679) | Personal data breach | 72 hours after discovery | Up to 4% global revenue |
| PCI-DSS v4.0 | Cardholder data breach | 24 hours to acquirer | Card brand fines |
| HIPAA (45 CFR 164) | PHI breach (>500 individuals) | 60 days after discovery | Up to $1.9M per violation category |
| NY DFS 23 NYCRR 500 | Cybersecurity event | 72 hours to DFS | Regulatory sanctions |
| SEC Rule (17 CFR 229.106) | Material cybersecurity incident | 4 business days after materiality determination | SEC enforcement |
| CCPA / CPRA | Breach of sensitive PI | Without unreasonable delay | AG enforcement; private right of action |
| NIS2 (EU 2022/2555) | Significant incident (essential services) | 24-hour early warning; 72-hour notification | National authority sanctions |

**Operational rule:** if scope is unclear at declaration, assume the most restrictive applicable deadline and confirm scope within the first response window.

## SEV1 response timeline

T+0 detection arrives → T+5 classify against taxonomy with false-positive filtering → T+10 if SEV1, page CISO, open war room, start the regulatory clock → T+15 begin forensic collection (volatile evidence first) in parallel with a containment assessment → T+30 human approval gate before any containment action → T+45 execute approved containment → T+60 assess containment effectiveness and brief Legal if PII/PHI is in scope → T+4h finalize the forensic evidence package and dwell-time estimate → T+8h build the eradication and recovery plan → T+72h submit regulatory notification if GDPR/NIS2 was triggered.

## Anti-patterns

1. **Starting the notification clock at investigation completion** — regulatory clocks (GDPR 72 hours, PCI 24 hours) start at discovery, not investigation completion. Declaring late exposes the organization to maximum penalties even if the incident itself was minor.
2. **Containing before collecting volatile evidence** — rebooting or isolating a system destroys RAM, running processes, and active connections. Volatile evidence collection must happen in parallel with containment, never after.
3. **Skipping false-positive verification before escalation** — escalating every alert to SEV1 degrades SOC credibility and causes alert fatigue. Always apply false-positive filters before paging the CISO.
4. **Undocumented incident command decisions** — every decision made during a SEV1, including decisions made under uncertainty, must be logged with timestamp and rationale. Undocumented decisions cannot be defended in regulatory investigations.
5. **Treating incident closure as investigation completion** — incidents close when eradication and recovery are complete, not when the investigation is done. Forensic reporting and regulatory submissions may continue after operational closure.
6. **Single-source classification** — classifying an incident from a single data source (one SIEM alert) without corroborating evidence frequently leads to misclassification.