Cyber incident response is the organised way a business reacts when its security fails: detecting what's happening, stopping it from spreading, removing the attacker, restoring normal work, and learning enough to prevent the repeat. Done well, it's what turns a breach into a bad day instead of a bad year.
Picture the moment it becomes real. It's 07:40 on a Monday and someone notices the files won't open, or a login alert has fired from a country where nobody works. What happens in the next hour, who gets called, what gets disconnected, what gets written down, will shape the next six months more than anything your security budget ever bought.
That hour is also when an organisation discovers which kind of plan it has. Some have a rehearsed routine: people know their roles, the right systems get isolated, a timeline starts being kept from the first minute. Most have a document somebody wrote for a compliance questionnaire, and they spend the hour improvising while the problem spreads.
The encouraging part is that this is a craft with a settled shape. The phases are agreed, the roles can be named in advance, and the plan can be written this quarter, because incident response, despite its name, mostly happens before anything goes wrong.
The six phases of incident response
Nearly every serious framework, including NIST's incident response guidance, describes the same lifecycle. Six phases, in order:
- Preparation. The plan, the roles, the contact lists, the practice runs. This phase decides how all the others go.
- Identification. Spotting that something is wrong and judging how serious it is: a triggered alert, a user report, a system behaving strangely.
- Containment. Stopping the spread, by isolating affected machines and accounts, without destroying the evidence you'll need.
- Eradication. Removing the attacker's access and whatever they left behind: malware, created accounts, changed settings.
- Recovery. Bringing systems back carefully, watching for signs the intruder is still there.
- Lessons learned. The honest review afterwards: what happened, what worked, what changes, written down while memories are fresh.
The phases look tidy on paper. In a live incident they overlap and loop, which is exactly why the first one matters most: a team that has rehearsed the sequence can bend it under pressure, while a team meeting the phases for the first time mid-crisis can only follow the attacker's schedule.
The first hour, done right
When the 07:40 moment arrives, a handful of actions set up everything that follows. Isolate affected machines from the network, but don't power them off or wipe them, because memory and logs are evidence you will badly want later. Call the named incident lead, not a group chat, and move the response conversation to a channel the attacker can't read if email might be compromised. Start a timeline immediately: who noticed what, when, and what was done, in plain notes with times. And resist the two instincts that cause the most damage, quietly fixing things before understanding the intrusion, and announcing it widely before knowing the facts.
The clock isn't only operational, it's legal. Under GDPR, a personal data breach must be reported to the regulator within 72 hours of discovery. NIS2 goes further for organisations in scope: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72. Those deadlines are hard to hit if the first day is chaos, which is one more reason the plan has to exist before the incident does.
Speed decides the cost
Here's the arithmetic behind all this discipline. IBM's 2025 breach research puts the average time to identify and contain a breach at 241 days, and its numbers show what you'd expect: the faster a breach is found and contained, the less it costs, in every industry, every year. Attackers do their damage in the gap between arrival and eviction. Everything incident response asks of you, the rehearsals, the contact tree, the practised first hour, exists to shrink that gap, and the organisations that shrink it are consistently the ones that prepared rather than the ones that spent the most.
What belongs in the plan?
A usable incident response plan is short enough to be read during an emergency and specific enough to answer the panicked questions. It should contain:
- Who leads, and who decides. One named incident lead with a deputy, and clarity on who has authority to take a system offline or approve outside help.
- The contact tree. Internal roles, plus the external numbers you don't want to be searching for at midnight: your insurer's hotline, legal counsel, forensic support, the regulator.
- Severity levels. Plain definitions of what counts as minor, serious and critical, so the response can be sized without a debate.
- Communication rules. Who tells staff, customers and the press, with pre-drafted holding statements, and which channel the team uses if normal systems are suspect.
- Evidence basics. What to preserve and what never to delete or power off.
- A review date. Plans age like risk assessments do; an untested plan is a guess.
Notice what's not on the list: products. Tools matter in detection and they speed up analysis, but the ranking pages for this topic are written by the companies selling them, which is why they end in software. When an incident actually lands, the deciding factor is whether people know what to do first.
Expect that an audit will test your plan, not just file it: auditors increasingly ask when the plan was last exercised
People first, tools second
An incident response capability is a small cast: an incident lead who coordinates and decides, technical responders who investigate and contain, someone who owns communication, and access to legal advice for the regulatory clocks. In a small company these are hats, not jobs, and that's fine, provided the hats are assigned before the fire and not during it. The cheapest, highest-value exercise in all of security is a tabletop run-through: two hours, one invented scenario, the real people talking through what they'd actually do. Every gap it exposes is a gap found for free.
Training the responders
The skills are learnable and they map to recognised certifications. CySA+ builds the analyst who can read the signals and work an investigation. SC-200 does the same specifically for Microsoft environments, where Defender and Sentinel are the responder's instruments. CISM covers the management side, and incident management is one of its four exam domains, which makes it the natural fit for whoever leads. For the deeper practice layer, our guide to improving incident response skills through advanced training covers labs, preparation and how to retain what you learn. All of these courses sit inside Unlimited Security Training, one subscription across the security catalogue, which is the practical route when you're training a rota rather than a person.
Frequently asked questions
What's the difference between an event, an incident and a breach?
An event is anything observable on your systems, and most are harmless. An incident is an event that threatens confidentiality, integrity or availability, an actual security problem. A breach usually means data was confirmed to be accessed or taken, which is what triggers legal reporting duties.
How quickly do incidents have to be reported in Europe?
Under GDPR, a personal data breach goes to the regulator within 72 hours of discovery. Organisations covered by NIS2 must send an early warning within 24 hours of becoming aware of a significant incident and a notification within 72. Contracts and insurers often add their own clocks on top.
Do small companies really need an incident response plan?
Yes, and arguably more than large ones, because a small company has no security department to improvise with. A two-page plan naming who leads, who to call and what not to touch puts a small business ahead of most of its peers.
Is incident response the same as disaster recovery?
No. Incident response deals with the security emergency itself: finding, containing and evicting an attacker. Disaster recovery is about restoring IT operations after any major disruption, cyber or otherwise. They connect during the recovery phase, but they're separate plans with separate owners.
The 07:40 moment arrives for most organisations sooner or later, and it's the one meeting you can't reschedule. What you control is everything before it: the plan, the names, the practice. Get those in place, and the worst Monday of the year becomes a procedure instead of a panic.
