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.
| Role | Accountability | Cannot be assumed |
|---|---|---|
| Incident lead | Objectives, severity, cadence, decisions, coordination, and closure | Unlimited authority over production, safety, legal, or public communications |
| Technical lead | Investigation plan, evidence quality, scoping, and technical recommendations | Business-risk acceptance |
| Operations owners | Execution, dependency knowledge, rollback, recovery, and service validation | Forensic interpretation |
| Scribe / evidence custodian | UTC timeline, decision record, artifacts, hashes, and transfers | That chat history is a sufficient case record |
| Legal / privacy / communications | Privilege, notification, disclosure, stakeholder, and regulatory guidance | Technical incident command |
| Executive business owner | Material risk, business tradeoffs, crisis resources, and external accountability | Selection 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
Establish control during the first hour
First 15 minutes
- Validate the signal and preserve the original alert.
- Assign the incident lead, technical lead, scribe, and initial severity.
- Move to a protected channel and use UTC.
- Identify affected identities, assets, services, and short-retention evidence.
- State known facts, assumptions, confidence, and immediate safety constraints.
By 60 minutes
- Build the initial timeline and earliest known activity.
- Search across identity, endpoint, network, cloud, SaaS, and data telemetry.
- Identify privilege, persistence, lateral movement, data access, and active impact.
- Present containment options with impact, authority, rollback, and validation.
- Set technical and stakeholder update times.
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.
| Level | Typical condition | Coordination | Initial update target |
|---|---|---|---|
| SEV-1 Critical | Safety or critical service at risk; enterprise/control-plane compromise; destructive action; material data impact | Incident command, executive, legal/privacy, communications, and applicable external parties | 15 minutes |
| SEV-2 High | Major service, multiple systems, high-value assets, privileged abuse, or probable sensitive-data access | Incident command, owners, legal/privacy as applicable | 30 minutes |
| SEV-3 Moderate | Contained asset, account, application, or segment without confirmed material impact | Incident lead and affected owners | 2 hours |
| SEV-4 Low | Blocked attempt or low-risk event without unauthorized access | Queue owner | Business day |
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.
Use a decision gate before disruptive action
Containment gate
| Action | Use when | Safeguard | Validate |
|---|---|---|---|
| Isolate endpoint or workload | Active malicious execution, command and control, or propagation | Confirm critical-service and management-path dependencies | Isolation state plus absence of related communications |
| Restrict identity | Confirmed or high-confidence session/credential abuse | Map service-account and break-glass dependencies first | Session revocation, sign-in block, and persistence review |
| Segment network path | Lateral movement, destructive spread, or exfiltration | Model domain, backup, safety, and production dependencies | Flow, firewall, EDR, and application health evidence |
| Block indicator or behavior | Reliable malicious infrastructure, artifact, or action | Indicators expire; test business collision and bypass paths | Blocked attempt plus hunt for alternate infrastructure |
| Suspend automation or integration | Compromised token, pipeline, application, or control plane | Understand downstream recovery and availability effect | No new actions; secrets rotated; trust re-established |
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
Separate operational coordination from stakeholder updates
| Audience | Content | Guardrail |
|---|---|---|
| Response team | Objectives, evidence, hypotheses, decisions, tasks, and next technical checkpoint | Use a protected out-of-band channel if primary identity or collaboration is affected |
| Executives and business owners | Known business impact, control state, material uncertainty, decisions required, and next update | No unsupported attribution or recovery estimate |
| Legal, privacy, insurer, regulators | Facts needed to assess privilege, coverage, notification, and preservation | Follow counsel and policy; restrict unnecessary personal information |
| Customers, partners, public | Approved facts, impact, actions, and protective guidance | Only authorized communications leads publish externally |
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.