Security Incident Response: Plan, Contain, Recover

Security Incident Response

Security incident response is the organized way a team handles a suspected or confirmed attack — a leaked credential, a compromised account, ransomware, data exfiltration, a malicious dependency. Its goals are to limit damage, remove the attacker, restore normal operation, meet legal obligations, and learn enough to prevent a repeat.

Incidents are decided before they happen. Teams that have written runbooks, practiced them, collected logs, and arranged emergency access respond in hours; teams improvising under pressure take days, destroy evidence by accident, and miss notification deadlines. Most of incident response is preparation.

TL;DR

Prepare first: roles, contact lists, runbooks for likely scenarios, emergency access, and logs that are already being retained.
Triage quickly: confirm whether it is an incident, assign a severity, and appoint an incident commander.
Contain before you clean up, and preserve evidence before you wipe anything.
Eradicate the root cause and every foothold, then recover with monitoring for re-entry.
Communicate through a channel the attacker cannot read, and check legal notification deadlines early — GDPR allows 72 hours for notifying the supervisory authority.
Finish with a blameless post-incident review that produces specific, owned improvements.

Quick Example

A runbook excerpt for one of the most common incidents: a cloud access key exposed in a public repository.

Each step maps to a phase of the response, and the order matters: deactivating the key before investigating stops further damage without destroying the evidence of what already happened.

Core Concepts

Events, Alerts, and Incidents

An event is anything observable — a login, a configuration change. An alert is an event or pattern flagged as possibly malicious. An incident is a confirmed or strongly suspected violation of security policy that needs a coordinated response. Triage turns alerts into incidents or closes them, and most alerts should close quickly.

The Response Lifecycle

NIST SP 800-61 Revision 3 frames the same work within the NIST Cybersecurity Framework 2.0 functions (govern, identify, protect, detect, respond, recover); the lifecycle above remains the practical sequence during an incident.

Severity Levels

Severity drives who is paged, how fast, and who must be told. Define levels in advance:

Roles

Borrow from incident command: an incident commander coordinates and decides, a technical lead directs the investigation, a communications lead handles internal and external updates, and a scribe keeps a timestamped log of facts and decisions. Legal counsel joins any incident that may involve personal data, regulators, or law enforcement.

Handling an Incident

Containment Without Destroying Evidence

Short-term containment buys time: disable compromised accounts, revoke sessions and tokens, isolate hosts at the network level, block malicious domains. Prefer actions that preserve state — isolate a virtual machine rather than terminating it, deactivate a key rather than deleting it — and capture memory, disk snapshots, and relevant logs before re-imaging anything.

Scoping

Answer, with evidence: how did the attacker get in, what could they reach, what did they actually do, and is any access still active? Identity provider logs, cloud audit logs, endpoint telemetry, and application audit logs are the primary sources — which is why they must be collected and retained before an incident. See Security Information and Event Management.

Eradication and Recovery

Remove every foothold, not just the first one found: backdoor accounts, new API keys, OAuth grants, scheduled tasks, modified CI pipelines. Rotate secrets the attacker could have seen (Secrets Management), patch the entry point, and restore systems from known-good images or immutable backups. Monitor closely afterwards; attackers often try to return.

Communication and Notification

Run incident communication in a channel the attacker cannot read — if email or chat may be compromised, move to an out-of-band channel. Notification duties vary by jurisdiction and contract: under the GDPR, a personal data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, and affected individuals must be told when the risk to them is high. Involve legal counsel early; deadlines start when you become aware, not when the investigation ends. See GDPR Engineering.

Best Practices

Write Runbooks for Your Likeliest Incidents

Cover leaked credentials, compromised user and admin accounts, phishing, ransomware on an endpoint, a malicious or compromised dependency (Software Supply Chain Security), and cloud resource abuse such as cryptomining. Each runbook lists first actions, evidence to collect, and who to involve.

Exercise the Plan

Tabletop exercises — walking through a realistic scenario around a table — expose missing access, unclear authority, and outdated contacts at no cost. Run one or two a year, and after significant organizational change.

Keep a Timeline From Minute One

Record every observation and decision with a UTC timestamp and the source of the evidence. The timeline drives scoping, notifications, the post-incident review, and any legal follow-up.

Arrange Emergency Access in Advance

Break-glass accounts, out-of-band communication, and on-call contacts for cloud providers and key vendors should exist and be tested before they are needed.

Review Blamelessly

Focus the review on how the system allowed the incident and what will change — controls, detections, runbooks — with owners and dates. See Postmortems.

Common Mistakes

Wiping Before Investigating

Rotating One Secret, Not All Exposed Ones

Coordinating on a Compromised Channel

Treating the Review as Optional

FAQ

What is the difference between a security incident and an IT incident?

An IT incident is any unplanned disruption, such as an outage. A security incident involves a threat to confidentiality, integrity, or availability from malicious or unauthorized activity. Security incidents share coordination practices with incident management but add evidence preservation, attacker awareness, and legal obligations.

What should we do first when we suspect a breach?

Start a timeline, appoint an incident commander, and take containment actions that preserve evidence — disabling compromised credentials, isolating affected systems. Then scope what was accessed and engage legal counsel if personal data or regulated systems may be involved.

Who do we have to notify, and how quickly?

It depends on the data, the jurisdiction, and your contracts. Under the GDPR, the supervisory authority must be notified within 72 hours of becoming aware of a reportable personal data breach, and individuals when the risk to them is high. Sector rules and customer contracts often add shorter deadlines. Identify these obligations before an incident.

Should we pay a ransomware demand?

Treat it as a legal and business decision, not a technical one, and involve counsel and law enforcement. Payment does not guarantee data recovery or deletion, may be illegal when the recipient is sanctioned, and funds further attacks. Tested, isolated backups are what make refusing to pay possible.

How do we practice incident response?

Run tabletop exercises on realistic scenarios, test runbooks in non-production environments, and review real incidents — including near misses. Measure how long detection, containment, and recovery take, and improve the slowest step.