Create command before creating noise
Confirm that an incident process is active, name an incident commander, identify technical and business decision-makers, and open a controlled communication channel. Establish severity, known impact, suspected scope, regulatory or contractual triggers, and who is authorized to isolate systems, engage external support, notify insurers, or contact authorities.
Maintain a timestamped decision log that separates observed facts from hypotheses. Record data sources, actions, owners, approvals, and expected consequences. A single trusted chronology reduces duplicated work and becomes essential for investigation, reporting, and post-incident learning.
Preserve evidence while improving visibility
Identify the systems, accounts, endpoints, cloud resources, logs, and business processes most likely to clarify scope. Preserve volatile or short-retention evidence according to legal and investigative requirements, and document acquisition handling. Avoid broad cleanup actions that destroy the evidence needed to understand persistence or impact.
Check whether logging and security tools can be trusted. Compromised identity, endpoint management, or monitoring infrastructure may produce incomplete evidence. Use independent data sources where possible and protect investigation accounts and communications from the suspected environment.
Contain deliberately, with business context
Containment should reduce harm without creating a larger outage or warning an active adversary prematurely. Options may include disabling or resetting specific accounts, isolating endpoints, restricting network paths, blocking indicators, revoking sessions or tokens, protecting backup systems, and pausing risky automation. Sequence decisions around safety, critical services, and evidence.
CISA's ransomware guidance emphasizes protecting backups and avoiding reinfection during recovery. Confirm that recovery copies and administration paths are isolated before destructive activity can reach them. Keep executives, legal counsel, communications, privacy, operations, and affected service owners aligned on what is known and what remains uncertain.
Move toward trusted recovery and continued risk management
Define what a trusted recovery state means: known-good identity, remediated access paths, clean builds, patched vulnerabilities, changed credentials, validated monitoring, protected backups, and business acceptance. Prioritize critical services and avoid restoring into the same conditions that enabled the incident.
NIST SP 800-61 Revision 3 frames incident response across the Cybersecurity Framework rather than as an isolated sequence owned only by a response team. Carry findings into governance, asset understanding, protection, detection, recovery design, exercises, supplier controls, and risk decisions. The first 24 hours matter, but the operating improvements that follow determine whether the next incident is smaller.