A quick, plain-language answer for anyone building their first response plan, evaluating a provider, or trying to understand what happens after "we've been breached."
Incident response is the structured process of detecting, containing, and recovering from a security compromise — then learning from it so the same gap doesn't get exploited the same way twice.
It's deliberately structured rather than improvised, because a chaotic, ad-hoc reaction to a live compromise tends to make things worse: evidence gets destroyed accidentally, containment steps miss affected systems, and communication breaks down at exactly the moment it matters most.
A response typically moves through four phases, though real incidents rarely respect clean boundaries between them. Activation and triage happens first, assessing scope and severity fast enough to make good decisions without full information.
Containment follows, stopping the spread without destroying evidence, then eradication and recovery, removing the threat and restoring normal operations. The process closes with a post-incident review that looks at root cause and produces a concrete hardening plan.
A response usually involves more than just the technical response team. Depending on severity, that can include legal counsel, insurance carriers, communications or PR support, and sometimes regulators, alongside whoever is actually doing the technical containment and investigation work.
It depends on severity and internal expertise. Many businesses use outside response support either to lead the effort or to work alongside whatever internal team or IT provider they already have, rather than treating it as an either-or choice.
It varies enormously by scope and severity — a contained, quickly-detected incident might resolve in days, while a widespread compromise with extensive lateral movement can take weeks to fully remediate.
The response itself is reactive by definition, but the post-incident review phase is explicitly forward-looking — its whole purpose is preventing a repeat.