INCIDENT COMMAND / TECHNICAL RESPONSE

Make accountable response decisions

Preserve evidence, control business impact, contain deliberately, and restore trust—not just service availability.

Aligned to NIST SP 800-61 Rev. 3 and CSF 2.0Last reviewed: July 17, 2026
01 / PREPARE

Build authority and access before the incident

NIST SP 800-61 Rev. 3 integrates response across the six functions of CSF 2.0. The operating workflow on this site—prepare, validate, scope, contain, recover, and improve—provides a practical execution layer within that broader risk-management model.

Minimum incident command roles
RoleAccountabilityCannot be assumed
Incident leadObjectives, severity, cadence, decisions, coordination, and closureUnlimited authority over production, safety, legal, or public communications
Technical leadInvestigation plan, evidence quality, scoping, and technical recommendationsBusiness-risk acceptance
Operations ownersExecution, dependency knowledge, rollback, recovery, and service validationForensic interpretation
Scribe / evidence custodianUTC timeline, decision record, artifacts, hashes, and transfersThat chat history is a sufficient case record
Legal / privacy / communicationsPrivilege, notification, disclosure, stakeholder, and regulatory guidanceTechnical incident command
Executive business ownerMaterial risk, business tradeoffs, crisis resources, and external accountabilitySelection of low-level containment commands

Prepared capabilities

Operational access

  • Break-glass identities and clean administrative workstations
  • EDR, identity, network, cloud, SaaS, backup, and virtualization access
  • Protected evidence storage with retention and access logging
  • Out-of-band communications independent of primary identity

Decision readiness

  • Delegated containment authority and explicit exceptions
  • Critical service, data, identity, dependency, and recovery owners
  • Legal, privacy, insurer, vendor, communications, and authority contacts
  • Tested restoration, credential rotation, and clean-room procedures
02 / ACTIVATE

Establish control during the first hour

First 15 minutes

  1. Validate the signal and preserve the original alert.
  2. Assign the incident lead, technical lead, scribe, and initial severity.
  3. Move to a protected channel and use UTC.
  4. Identify affected identities, assets, services, and short-retention evidence.
  5. State known facts, assumptions, confidence, and immediate safety constraints.

By 60 minutes

  1. Build the initial timeline and earliest known activity.
  2. Search across identity, endpoint, network, cloud, SaaS, and data telemetry.
  3. Identify privilege, persistence, lateral movement, data access, and active impact.
  4. Present containment options with impact, authority, rollback, and validation.
  5. Set technical and stakeholder update times.

Download the complete first-hour checklist

03 / SEVERITY

Rate observed impact and required coordination

Severity is dynamic. It should combine operational impact, scope, privilege, data sensitivity, propagation, confidence, safety, and legal or contractual exposure. Reassess after every material change.

Severity summary—adapt response targets to your organization
LevelTypical conditionCoordinationInitial update target
SEV-1 CriticalSafety or critical service at risk; enterprise/control-plane compromise; destructive action; material data impactIncident command, executive, legal/privacy, communications, and applicable external parties15 minutes
SEV-2 HighMajor service, multiple systems, high-value assets, privileged abuse, or probable sensitive-data accessIncident command, owners, legal/privacy as applicable30 minutes
SEV-3 ModerateContained asset, account, application, or segment without confirmed material impactIncident lead and affected owners2 hours
SEV-4 LowBlocked attempt or low-risk event without unauthorized accessQueue ownerBusiness day

Download the authoritative severity worksheet

04 / INVESTIGATE

Scope by trust boundary, not product console

Identity and access

Sessions, authentication methods, roles, groups, OAuth grants, applications, secrets, service principals, mailbox persistence, and administrative changes.

Systems and workloads

Process lineage, persistence, credentials, network connections, virtualization, backups, images, registries, orchestration, and management tooling.

Data and business

Repositories, object access, exports, sharing, exfiltration evidence, service dependencies, customer effect, safety, and recovery priority.

Evidence preservation: collect volatile and short-retention evidence first. Record source, collector, UTC timestamps, acquisition method, tool version, SHA-256, storage, transfers, and system changes introduced. Do not delay necessary safety or containment action solely to achieve perfect collection.

Download the evidence and chain-of-custody record

05 / CONTAIN

Use a decision gate before disruptive action

Containment gate

TriggerWhat evidence justifies action now?
AuthorityWho can approve and execute it?
TradeoffOperational, safety, evidence, and adversary effects?
ValidationHow will success, failure, and rollback be verified?
Containment options and safeguards
ActionUse whenSafeguardValidate
Isolate endpoint or workloadActive malicious execution, command and control, or propagationConfirm critical-service and management-path dependenciesIsolation state plus absence of related communications
Restrict identityConfirmed or high-confidence session/credential abuseMap service-account and break-glass dependencies firstSession revocation, sign-in block, and persistence review
Segment network pathLateral movement, destructive spread, or exfiltrationModel domain, backup, safety, and production dependenciesFlow, firewall, EDR, and application health evidence
Block indicator or behaviorReliable malicious infrastructure, artifact, or actionIndicators expire; test business collision and bypass pathsBlocked attempt plus hunt for alternate infrastructure
Suspend automation or integrationCompromised token, pipeline, application, or control planeUnderstand downstream recovery and availability effectNo new actions; secrets rotated; trust re-established
06 / RECOVER

Restore trust before declaring recovery

Service availability is not evidence that the threat has been removed. Recovery requires a known-good state, removed persistence, rotated trust material, tested business function, and enhanced monitoring.

Technical exit criteria

  • Initial access and persistence addressed
  • Compromised credentials, tokens, keys, and certificates rotated
  • Systems rebuilt or validated from trusted baselines
  • Required patches and configuration changes tested
  • Recovery data and infrastructure verified clean
  • Detection coverage added for observed behavior

Business exit criteria

  • Service owner validates required transactions and dependencies
  • Security lead accepts residual technical uncertainty
  • Legal/privacy decisions and preservation obligations recorded
  • Monitoring window, owner, and rollback threshold set
  • Stakeholders receive a factual recovery update
  • Corrective actions have owners and verification methods
07 / COMMUNICATE

Separate operational coordination from stakeholder updates

Communication channels and content
AudienceContentGuardrail
Response teamObjectives, evidence, hypotheses, decisions, tasks, and next technical checkpointUse a protected out-of-band channel if primary identity or collaboration is affected
Executives and business ownersKnown business impact, control state, material uncertainty, decisions required, and next updateNo unsupported attribution or recovery estimate
Legal, privacy, insurer, regulatorsFacts needed to assess privilege, coverage, notification, and preservationFollow counsel and policy; restrict unnecessary personal information
Customers, partners, publicApproved facts, impact, actions, and protective guidanceOnly authorized communications leads publish externally

Download the executive status-update template

08 / IMPROVE

Close findings only after verification

  • Reconstruct the UTC timeline and decision points.
  • Identify detection, telemetry, access, ownership, communication, containment, and recovery gaps.
  • Translate findings into specific control, playbook, architecture, training, or recovery changes.
  • Assign owners, due dates, dependencies, risk acceptance, and validation methods.
  • Retest affected detections, access paths, playbooks, and restoration procedures.

Exercise objectives

Tabletops and simulations should test observable capabilities: time to establish command, obtain evidence, identify business ownership, approve containment, shift to out-of-band communications, restore a critical service, and deliver an executive update under uncertainty.

Download the post-incident review template