Incident Response

Introduction

Even good defences fail sometimes. A security incident is an event that harms, or threatens to harm, confidentiality, integrity or availability. What matters is how quickly and calmly you respond. Teams that plan ahead handle incidents far better than teams making it up under pressure.

The phases

The widely used NIST guide describes a cycle:

1. Preparation: plans, tools, training and contacts ready before anything happens.
2. Detection and analysis: noticing an incident and working out what it is.
3. Containment, eradication and recovery: stopping the spread, removing the cause, and returning to normal.
4. Post-incident activity: learning, and improving.

It is a cycle because lessons feed back into preparation.

Preparation

• A written plan that says what counts as an incident, who is in charge, and what to do first
• Roles: an incident lead, technical responders, someone for communication with staff and customers, and legal or management contacts
• A contact list that works when systems are down, including out-of-hours numbers
• Logging and monitoring so you can see what happened. Keep logs safe from tampering.
• Backups you have tested
• Practice: run tabletop exercises, where the team talks through a scenario

Detection and analysis

Signs include alerts from security tools, unusual logins, odd network traffic, reports from users or notices from outside parties. Then:

• Confirm it is real, and decide how serious it is.
• Record what you know, with times. Keep a log of your actions.
• Preserve evidence where appropriate. Do not wipe machines before you know what you need.
• Decide who to notify, including any legal duty to report breaches to regulators or affected people. These rules differ by country, so involve the right people.

Containment, eradication and recovery

• Contain: isolate affected machines or accounts, block malicious addresses, disable stolen credentials. Balance speed against the need to understand the attack.
• Eradicate: remove malware, close the way in, patch the flaw, rotate any exposed secrets.
• Recover: restore from clean backups, rebuild systems, return to service carefully, and monitor closely for signs the attacker is back.

Communication

Be honest and timely with people affected. Use clear facts, avoid guessing and blame, and give people steps they can take. Keep messages consistent by using one spokesperson.

After the incident

Hold a blameless post-incident review: what happened, what went well, what did not, and what to change. Focus on systems and processes, not on punishing people, so that people report problems early. Turn the findings into specific tasks with owners and dates.

Try it yourself

Write a one-page incident plan for a small organisation: how an incident is reported, who leads, the first three actions, and who must be contacted. Then walk through a scenario such as a stolen laptop or a phishing click.

Summary

• Incident response follows preparation, detection, containment and recovery, then review.
• Plans, roles, logs and tested backups make the response fast and calm.
• Hold blameless reviews and turn the lessons into concrete improvements.