The worst time to decide who can disable an administrator account is while that account is being abused. The same is true for restoring a database, notifying customers, calling legal counsel, or preserving a compromised laptop. Incident response works because those decisions were discussed before the alert arrived.

Disaster recovery is related but not identical. Incident response manages a suspected or confirmed security event. Disaster recovery restores technology and data after a serious disruption, whether the cause is ransomware, operator error, fire, hardware failure, or something else. A major incident often needs both.

Current NIST Guidance

NIST SP 800-61 Revision 3 was finalized in April 2025 and superseded Revision 2. Rather than presenting response as an isolated four-step loop, it connects incident response to all six functions of NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond, and Recover.

Preparation therefore sits throughout the program. Governance defines authority and reporting. Inventory and protection reduce exposure. Detection finds events. Response contains and removes the threat. Recovery restores operation. Lessons feed back into every function.

Preparation

A response plan should identify:

  • incident roles, alternates, and decision authority;
  • severity criteria and escalation paths;
  • legal, privacy, regulatory, insurance, and contractual contacts;
  • communication channels that do not depend on the affected environment;
  • access to identity, endpoint, cloud, network, and application logs;
  • evidence-handling procedures;
  • containment options and their business impact;
  • restoration priorities and clean recovery sources;
  • suppliers and service providers involved in response;
  • exercise and review cadence.

Keep essential contact and recovery information available offline. A beautifully organized wiki is little help if the identity provider or network used to reach it is down.

Detection and Triage

An alert becomes an incident after enough evidence shows that response is warranted. Triage asks:

  • What happened, and how confident are we?
  • Which identities, assets, data, and locations may be affected?
  • Is the activity continuing?
  • What is the safety, business, legal, and privacy impact?
  • Which evidence is volatile?
  • Who needs to know now?

Do not wait for perfect certainty before limiting obvious harm. At the same time, avoid destroying evidence or shutting down a critical service on the basis of one weak signal.

Create a timeline with sources and confidence levels. Separate observed facts from hypotheses so that an early assumption does not quietly become the official story.

Containment

Containment limits the attacker’s reach while preserving enough evidence and business operation to continue the investigation.

Examples include:

  • revoking a token or privileged session;
  • isolating an endpoint from the network;
  • blocking a malicious destination;
  • disabling a vulnerable route;
  • placing an affected cloud account under stricter organization policy;
  • rotating an exposed key;
  • diverting traffic to a known-clean service.

Short-term containment buys time. Longer-term containment may introduce a safe temporary architecture while the root cause is removed. Rebuilding systems and declaring them clean belongs to eradication and recovery, not containment itself.

Every action can change evidence. Record who acted, when, why, and what state changed.

Eradication

Eradication removes the attacker’s access and the weakness that made it possible. That may require:

  • removing malware and persistence;
  • closing an exploited vulnerability;
  • rotating credentials and keys, including downstream copies;
  • invalidating sessions;
  • reviewing identity and policy changes;
  • rebuilding from known-good artifacts;
  • checking peer systems for the same path;
  • confirming that the attacker did not establish another foothold.

Deleting one malicious file is not enough if the compromised administrator account remains active.

Recovery

Recovery returns systems to a trustworthy operating state. Restore in an order based on business dependencies, not whichever server is easiest to start.

Monitor restored systems closely. Reintroduce connectivity in stages, validate security controls, and keep a rollback path. “The service is online” is different from “the service is trustworthy and complete.”

Evidence and Forensics

Evidence may be needed for technical understanding, disciplinary action, insurance, litigation, or law enforcement. Requirements vary by jurisdiction and case, so involve appropriate specialists.

Practical handling includes:

  • capture volatile evidence when it matters;
  • use documented collection tools and time sources;
  • hash collected artifacts within a trusted evidence process;
  • restrict evidence access;
  • record chain of custody;
  • preserve original sources where possible;
  • respect employee, customer, and bystander privacy;
  • avoid letting ordinary cleanup overwrite logs or snapshots.

A hash helps detect later alteration when its reference value is protected. It does not prove who collected the evidence or that the source was truthful.

Communication

Incidents create an information vacuum. If the response team does not provide careful updates, rumor will fill it.

Prepare communication for:

  • executives and operational teams;
  • employees;
  • customers and affected people;
  • regulators and law enforcement where required;
  • insurers, partners, and suppliers;
  • media and the public.

State what is known, what is not yet known, what action is being taken, and when the next update will come. Do not guess at attribution or impact. Notification deadlines vary, so legal and privacy review should begin early rather than after the investigation feels complete.

Disaster Recovery Terms

Two targets guide recovery design:

  • Recovery Time Objective (RTO): the target time to restore a service after disruption.
  • Recovery Point Objective (RPO): the maximum tolerable amount of data loss expressed as time.

An RPO of four hours means the recovery design should normally avoid losing more than four hours of committed data. It does not say how quickly the service returns; that is the RTO.

A business impact analysis identifies critical services, dependencies, maximum tolerable disruption, manual workarounds, and recovery order.

Backups That Can Survive an Attack

Backups are not “always available.” Ransomware and compromised administrators often target them.

A resilient program commonly keeps:

  • more than one copy;
  • more than one storage type or failure domain;
  • at least one isolated, offline, or suitably immutable copy;
  • separate credentials and administration;
  • monitored backup jobs;
  • documented retention and deletion;
  • regular restoration tests.

The familiar 3-2-1 pattern—three copies, two media or failure types, one off-site—can be a useful starting point, but architecture matters more than counting labels.

Recovery also needs identity configuration, keys, certificates, infrastructure code, dependency manifests, network policy, and operational knowledge. Restoring a database without the identity and application layers may not restore the service.

Exercises

Different exercises test different weaknesses:

  • tabletop: walk through decisions and communication;
  • technical simulation: practice investigation and containment in a controlled environment;
  • restoration test: recover data and services from backups;
  • failover exercise: move operation to another environment;
  • full exercise: combine technical, executive, legal, and communication work.

Record action items with owners and deadlines. An annual meeting that produces no changed control is theatre, not readiness.

After the Incident

Hold a blameless review focused on system improvement:

  • What happened and how do we know?
  • Which signals worked or failed?
  • Which decision or access path slowed containment?
  • Did recovery meet RTO and RPO?
  • Which assumptions were wrong?
  • Which controls will change, who owns them, and by when?

Blameless does not mean nobody is accountable. It means the review looks beyond the last person who clicked or typed and examines the conditions that allowed one action to have such a large effect.

Conclusion

Incident response is an organizational capability, not a binder or a security-team ceremony. It connects technical evidence, business priorities, legal duties, communication, and recovery. The plan becomes credible only after people have exercised it and restored something real.

References