Incident Response

Incident response is a decision system under pressure. The goal is to protect the business, preserve evidence, contain the threat, restore trusted service, and convert lessons learned into stronger controls.

Triage Decision Record

incident_id: IR-2026-042
commander: <NAME>
severity: high
business_impact:
  - customer portal degraded
  - potential identity compromise
known_facts:
  - first alert time: 2026-05-26T14:20:00Z
  - affected assets: host01, vpn-gateway
  - suspected vector: stolen credentials
unknowns:
  - data access scope
  - persistence status
  - lateral movement extent
next_decisions:
  - preserve memory on host01 before isolation
  - disable suspected accounts after coordinated evidence capture
  - notify legal if regulated data access is confirmed

Response Lifecycle

Name the framework you are following, because the three in common use do not number the phases the same way. NIST SP 800-61 was revised in April 2025: revision 3 supersedes revision 2 and recasts incident response as outcomes spread across the six CSF 2.0 functions - govern, identify, protect, detect, respond, recover - rather than as a standalone linear sequence. ISO/IEC 27035-1:2023, the second edition that replaces the withdrawn 2016 edition, sets out five phases from plan-and-prepare through lessons learned. SANS PICERL - preparation, identification, containment, eradication, recovery, lessons learned - is the operational ordering this page uses and the sequence most runbooks are written against, so the six cards above follow it exactly. Keep containment and eradication as separate decisions with separate approvals: blocking egress and removing the actor's persistence carry different evidence risk, and they usually happen on different days under different change records.

Containment Strategy Matrix

Minimum Evidence Package

• Incident timeline with UTC timestamps and source system for each event.
• Alert IDs, case IDs, analyst notes, and containment approvals.
• Identity logs, endpoint triage package, network flows, DNS/proxy logs, and cloud audit records.
• Hashes for acquired images, memory captures, exported logs, and malware samples.
• Recovery validation: rebuilt hosts, rotated secrets, closed firewall changes, and monitoring window results.

EDR and SIEM as Evidence

An EDR console and a SIEM are views over a retention window, not archives. Two consequences follow. Export before you analyse, because every hour spent querying is an hour of expiry; and treat the query definition as part of the evidence, because the result is only meaningful next to the question that produced it.

Retention Is Per Field, Not Per Product

Vendors quote one number and mean another. Microsoft Defender XDR keeps raw advanced-hunting telemetry for 30 days while the portal retains alerts, incidents and device timelines for 180 — and streaming the tables into a Sentinel workspace extends the raw data only as far as that workspace's retention. The pattern generalises: detections outlive raw telemetry by an order of magnitude. "We have a year of EDR" usually means a year of detections and a handful of days of process events, so the first export is the raw telemetry for the incident window, the second is the detections, and the third is the configuration that decided what was recorded at all.

Export With Field Fidelity

A console CSV export is a rendering of the view on screen. Hidden columns stay hidden, long command lines are truncated at whatever width the exporter chose, and timestamps come out in the console's timezone rather than UTC. Use the API where one exists, name the fields explicitly, and keep JSON. Then convert to UTC exactly once and record the conversion, because a timeline built from two exports in two timezones is the most common way an EDR package becomes indefensible.

The Console Is Also an Attack Surface

Whoever administers the console can delete a device record, purge telemetry, add an exclusion, disable a policy or shorten retention — and every one of those actions changes what the remaining data means. The platform's admin audit trail is a separate record from the telemetry it governs: pull both, and read the admin trail first. An exclusion added at 02:10 to the folder where the malware landed is a finding, not housekeeping, and it also explains a detection gap you would otherwise attribute to the malware. Keep the exported copy somewhere the console administrator cannot reach, or the tamper question has no good answer.

Velociraptor as a Collection Path

Velociraptor is the practical way to turn an endpoint into a hashed evidence package rather than a set of screenshots. An offline collector embeds a configuration and a set of artifacts into a self-contained package you can run on a host with no server connectivity; the collection comes back as an archive you hash on receipt. The artifacts are versioned definitions, so record the artifact name and version with the package — the same query against a later artifact version is a different experiment.

# Repack an offline collector with the triage artifacts embedded
velociraptor.exe --config collector.yaml config repack --artifacts Windows.KapeFiles.Targets,Windows.System.Pslist offline-collector.zip

# Query one endpoint's process table through a running server
velociraptor.exe query "SELECT Pid, Ppid, Name, Exe, CommandLine FROM pslist()"

# Hash the package before it leaves the host
Get-FileHash -Algorithm SHA256 offline-collector.zip

A live collection is itself a change to the host: the collector runs as SYSTEM, writes files, and leaves entries in the execution artefacts you are about to examine. Say so in the manifest, and prefer the collector over a hand-run script for the same reason — it is repeatable, it logs what it did, and the artifact definition is reviewable.

Notification and Reporting Clocks

Almost every statutory clock in incident response starts at determination, not at discovery, and each regime defines awareness in its own words. That makes the determination record — who decided, when, on what basis — evidence in its own right, and it is usually the first document a regulator or a plaintiff asks for.

What Awareness Means in Each Regime

The SEC rule starts its four business days when the registrant determines the incident is material, and the determination itself must be made without unreasonable delay after discovery — so the gap between discovery and determination is examined, not ignored. GDPR awareness is usually read as the point at which the controller has a reasonable degree of certainty that a personal data breach has occurred, not the point at which someone suspected one. NIS2 speaks of becoming aware of a significant incident, with the significance test applied to the incident rather than to the evidence. None of these starts when an alert fires, and none of them pauses because the investigation is incomplete.

Record the determination as a decision with a time and an author, not as a sentence in a status update. The record below is deliberately short; the point is that every field can be defended later, including the ones that say what you did not know yet.

incident_id: IR-2026-042
aware_utc: 2026-05-26T14:20:00Z
determination_utc: 2026-05-26T18:05:00Z
decided_by: [incident-commander, general-counsel]
basis: >
  Confirmed unauthorised mailbox access for 41 accounts; personal data of EU
  customers in scope; registrant status requires a materiality assessment.
regimes:
  - gdpr_art33:
      deadline_utc: 2026-05-29T18:05:00Z
      notified_utc: null
  - sec_8k_item_1_05:
      deadline_utc: 2026-06-01T21:00:00Z
      filed_utc: null
not_notified:
  - regime: nis2
    reason: entity not in scope of national transposition
review_utc: 2026-05-27T09:00:00Z

The not_notified block matters as much as the deadlines. A documented decision that a regime does not apply, with the reason and the reviewer, is the difference between a judgement call and an omission — and it is the record you will be asked for when the scope of the incident is revised three weeks later.

Serial and Overlapping Clocks

One incident can trigger all of the regimes above, and they do not synchronise. A 72-hour GDPR clock does not move because the SEC clock is measured in business days, and a NIS2 early warning at 24 hours may be due before anyone has established scope. Phased reporting is the mechanism that makes this survivable: GDPR expressly allows information to be provided in phases as it becomes available, NIS2 has an early warning followed by a fuller notification and a final report, and the SEC rule contemplates amendments. Plan the phases in advance, name who signs each one, and keep every filed version — the corrections are part of the record, not an embarrassment to be tidied away.

The organisations that meet these deadlines reliably do three things before an incident. They pre-agree the thresholds, so that determining materiality, significance or a personal data breach is the application of a written test rather than a debate. They name a signatory and a deputy for every notification, because a clock that stops for an unavailable executive is a self-inflicted breach. And they keep a clock tracker beside the timeline, in UTC, showing awareness, determination, each deadline and each filing reference — which is the same list a regulator asks for first.

After-Action Improvements

finding,owner,due_date,validation
Missing alert for impossible travel,identity-team,2026-06-15,test with approved account
No DNS logs for branch office,network-team,2026-06-30,confirm query visibility in SIEM
Backup restore runbook stale,infrastructure-team,2026-06-20,complete tabletop and restore test
Evidence storage access too broad,security-ops,2026-06-10,review ACL and audit logs