Incident response

An incident is something that harms, or threatens, the confidentiality, integrity or availability of systems or data: an account takeover, ransomware, a lost unencrypted laptop. Incident response is the planned way of handling one, so people aren't making it up under pressure.

A common way to split the work is six phases. Preparation: a written plan, who to call (including legal and leadership), contact details that work if email is down, logging, backups and practice runs. Detection and analysis: confirm it's real, work out what's affected and how bad it is. Containment: stop it spreading. Eradication: remove the cause. Recovery: bring systems back and watch them. Lessons learned: what went well, what didn't, and what changes.

Containment comes before cleanup. Disconnect an infected machine from the network, disable a stolen account and end its sessions, block an attacker's address. Think before switching a machine off: memory holds evidence (running programs, connections) that's lost on shutdown, so isolating it from the network is often better.

Keep evidence and a timeline. Write down what you saw and did, with times. Copy logs before they roll over. Don't wipe a machine until you know how the attacker got in, or they'll come back the same way. Large or legal cases bring in forensics specialists.

Many incidents come with duties: personal data breaches often must be reported to a regulator or the people affected within a set time (under GDPR in Europe, within 72 hours of finding out, where it's likely to put people at risk). Who decides and who speaks for the company should already be in the plan.

Afterwards, hold a blameless review. The goal is to fix the gaps (a missing patch, no MFA on one system, an alert nobody saw) rather than punish whoever clicked, so people keep reporting quickly next time.