IT & Technology Guide

Published: 2026-10-30 · Reviewed: 2026-11-04

Incident Response Basics

Something has gone wrong with your technology. The website is down. A laptop is showing ransomware warnings. Customer data may have been exposed. Everyone is looking at you, and your first instinct is to start clicking things.

Don’t. The difference between a bad incident and a catastrophe is usually not the technology, it’s the first hour of response. Businesses that handle incidents well aren’t smarter; they just have a basic plan they follow instead of improvising under pressure.

Why This Matters

Incidents are expensive in direct ways (downtime, lost sales, recovery costs) and indirect ways (customer trust, reputation, regulatory attention). The cost multiplies with confusion: every hour spent arguing about what to do is an hour the incident spreads.

A basic incident response approach does three things. It contains the damage quickly, disconnect the affected machine, take the compromised page offline. It preserves information you’ll need later, what happened, when, in what order. And it gets the right people involved fast, instead of discovering at 5pm that nobody told the person who could have fixed it at 10am.

You don’t need a security operations centre. You need a plan that fits on two pages and a form everyone knows how to find.

Key Concepts

Incident vs event. An event is anything notable, a failed login, a slow server. An incident is an event with actual or potential negative impact: data exposed, systems down, malware confirmed. The distinction matters because incidents trigger your response process. When in doubt, treat it as an incident, you can always stand down.

The response phases. Every incident follows the same shape: detect (notice something’s wrong), contain (stop it spreading), investigate (understand what happened), recover (restore normal service), and review (learn from it). You don’t need to memorise this, but knowing the shape stops you from skipping straight to recovery before you’ve contained the problem.

Severity levels. Not every incident deserves the same response. A simple three-level scale works: high (data breach, ransomware, major outage, drop everything), medium (one system down, suspicious activity, handle today), low (minor issue, no customer impact, handle in the normal queue). Severity decides who gets woken up and how fast you move.

Communication. During an incident, tell people what’s happening, staff, and customers if they’re affected. Silence breeds rumours, and rumours are worse than bad news. Prepare a simple outage notice template in advance so you’re not writing from scratch under pressure.

The incident record. Write down everything as it happens: time, what was observed, what was done, by whom. Memory is unreliable in a crisis. The record is how you reconstruct the incident later, and it’s what you’ll need if the incident has legal or insurance implications.

Practical Steps

1. Prepare before anything happens. Create your incident report form and your outage notice template now, while everything is calm. Decide who the response team is, even if it’s just two people, and make sure everyone knows how to reach them. Store contact details somewhere accessible if systems are down (a printed list isn’t old-fashioned, it’s resilient).

2. Detect and report. Make it easy for anyone to report something suspicious: a single email address, a phone number, a simple rule, “if it looks wrong, report it, no penalty for false alarms.” Most incidents are first noticed by ordinary staff, not by monitoring tools.

3. Assess severity immediately. When a report comes in, the first job is triage: how bad is this? Use your three-level scale. High severity means the response team convenes now, not after lunch.

4. Contain first, investigate second. The instinct is to understand before acting. Resist it for high-severity incidents. If a machine is infected, disconnect it from the network first, ask questions later. If credentials are compromised, reset them first. Containment buys you the time to investigate properly.

5. Document as you go. Start the incident record the moment you begin responding. Times, actions, decisions, who was involved. It feels like extra work during a crisis; it’s the most valuable thing you’ll produce, because the post-incident review depends on it.

6. Communicate on a schedule. For anything customer-facing, decide on update intervals, every hour for high severity, every few hours for medium, and stick to them. Even “still working on it, next update at 3pm” is better than silence. Use your pre-written outage notice template.

7. Recover carefully, then review honestly. Don’t declare victory at the first sign of normal service, verify systems are clean and stable. Then, within a week, hold a short review: what happened, what worked in our response, what didn’t, what do we change. Write it down. An incident you don’t learn from is an incident you’ll repeat.

Common Mistakes

No plan until the incident. Designing your response during the crisis is how incidents become disasters. The plan doesn’t need to be long, but it needs to exist before you need it.

Skipping containment. Jumping to fixes before stopping the spread is the classic error. Cleaning malware off a machine that’s still connected to the network. Restoring a website without closing the vulnerability that took it down. Contain first.

Poor communication. Telling nobody (staff guess, customers assume the worst) or telling everyone everything (panic, conflicting stories). Decide in advance who communicates, to whom, and how often.

Deleting evidence. In the rush to recover, people wipe logs, reimage machines, and delete the very information needed to understand what happened. Preserve first, copy logs, photograph screens, then clean up.

Blaming the reporter. If the person who reports an incident gets punished or mocked, reports stop coming and incidents get discovered late. Every false alarm is cheap; every missed incident is expensive. Thank people for reporting.

Treating recovery as the end. The incident isn’t over when service is restored, it’s over when you’ve reviewed what happened and fixed the root cause. The review is where the real value is. Skip it and you’ll be back here in six months with the same incident.

One person knows the plan. If only the IT lead knows the response process and they’re on holiday, you have no process. Make sure at least two people can run the response, and that everyone knows the reporting route.

Relevant Templates