Cybersecurity glossary
What is Incident Response?
Learn what incident response is, how NIST-style handling phases work, what to prepare before a breach, and how playbooks, evidence, and communication limit damage.
Definition
Incident response is the coordinated process of detecting, triaging, containing, eradicating, and recovering from a cybersecurity incident, then capturing lessons so the same path is harder to reuse.
Why incidents punish the unprepared
Prevention reduces frequency. It does not eliminate surprise. Incident response is the difference between a contained credential theft and a week-long outage with no trustworthy timeline.
The work is mostly decided before the pager fires: telemetry, authority, contacts, and rehearsed containment.
The handling loop
Prepare
Plan, retainers, logging, isolation rights, and tabletop exercises while the network is still calm.
Detect and analyze
Confirm scope, severity, and attacker objectives using logs, EDR, identity, and business context.
Contain
Stop spread: isolate hosts, revoke tokens, block C2, disable abused accounts—without destroying needed evidence.
Eradicate and recover
Remove persistence, rebuild from known-good, restore services, and watch for re-entry.
Learn
Root cause, control gaps, detection debt, and legal reporting—then assign owners with dates.
What “ready” actually looks like
Authority and contacts
Named people who can isolate a server, disable an IdP app, or speak to customers without waiting for a meeting.
Playbooks with real tools
Steps that name the console, API, and evidence to capture—not generic “contain the threat” slides.
Evidence hygiene
Know what to snapshot, where forensic images go, and who must not log on to the patient host.
Comms tracks
Separate technical war-room chat from legal, exec, and customer messaging so speculation does not become a statement.
Decisions that go wrong under pressure
| Impulse | Why it hurts | Better default |
|---|---|---|
| Reimage immediately | Destroys memory, persistence clues, and sibling-host leads | Isolate, collect, then rebuild on a plan |
| Pay or negotiate in Slack | No legal cover, no logging, possible extra extortion | Use the pre-briefed decision path |
| Announce “all clear” | Attackers still hold a token or cloud key | Declare recovery only after hunting for re-entry |
| Keep it secret from IT | The people who can revoke access are missing | Need-to-know includes control owners |
- Write severity definitions that trigger IR, not every SIEM informational event.
- Pre-authorize containment actions (host isolate, session revoke, DNS sinkhole) with audit trails.
- Keep an out-of-band comms path if email and chat are themselves compromised.
- Preserve volatile evidence before running noisy “cleanup” scripts.
- Track affected identities, hosts, data stores, and business processes as living scope.
- Run at least one technical isolation drill per year on production-like systems.
- After action: one detection, one control fix, and one process fix with owners.
- Align legal notification clocks (regulators, customers) with the technical timeline.
The practical takeaway
Incident response is a rehearsed operating system for bad days. Build authority, telemetry, and playbooks in peacetime; during the incident, contain with evidence in mind, recover without declaring victory early, and convert the outage into detections and control changes.
Related security terms
Security Operations Center (SOC)
Often the first operators who detect and escalate incidents.
Forensic Analysis
Evidence work that supports containment decisions and later reporting.
Mean Time to Respond (MTTR)
Metric for how quickly response actions actually start and finish.
Blue Team
Defensive function that owns much of day-to-day IR capability.
Audit Log
Attributable records IR teams need before anyone has wiped a host.
Frequently asked questions
What is incident response in simple terms?
It is the practiced way an organization handles a security event: confirm it is real, stop the bleeding, remove the attacker, restore service, and fix what let it happen.
What counts as a security incident?
A violation or imminent threat of violation of security policy—ransomware, confirmed intrusion, insider data theft, destructive wiper activity, or a serious business email compromise, not every noisy alert.
What are the usual IR phases?
NIST SP 800-61 groups work as preparation; detection and analysis; containment, eradication, and recovery; then post-incident activity. Names vary; the loop does not.
Who should be on the IR team?
Security operations, IT/identity owners, legal, communications, and executive decision-makers with pre-agreed authority. Waiting to invent that list during ransomware is a failure of preparation.
Should you immediately wipe every alerted host?
Not always. Reckless wipes destroy evidence and miss persistence elsewhere. Contain first (isolate, revoke sessions), then eradicate with a scoped plan.
When do you call outside help or law enforcement?
When impact, legal duty, or capability gaps require it. Those triggers should be written in the plan, including who is allowed to call the retainer.
How do you know IR is improving?
Faster, cleaner handling of similar incidents, fewer repeats of the same root cause, and drills that actually exercise containment—not unread PDF plans.
References
Explore authoritative guidance and frameworks related to incident response.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.