# Building an Incident Response Plan for Small Teams

You don't need a security team to have a plan. A simple, written incident response plan turns a chaotic security event into a manageable one.

Many small teams and one-person businesses have no security staff and no incident plan, and that is exactly when an incident does the most damage. The technical severity of an incident is rarely what causes the biggest losses. The confusion, delay, and panic in the first hour are. A short, written plan turns a chaotic event into a manageable one, and you can write a useful first version in an afternoon.

## What counts as an "incident"?

An incident is any event that threatens the confidentiality (who can see your data), integrity (whether it can be changed without you knowing), or availability (whether you can use it) of your systems or data. Examples: a suspected malware[↗](/malware) infection, a lost or stolen laptop, a staff member who fell for a phishing[↗](/phishing) email, unauthorized access to an account, or an outage caused by an attack.

## The four things every plan needs

### 1. Who to contact, and in what order

Write down names and phone numbers, not just email addresses, because email may be part of the problem. Include the person who decides on IT and security, your IT or hosting provider, and your insurer and legal contact if you handle sensitive data. Keep a printed copy or one stored outside your main systems, since you may not be able to open them during an incident.

### 2. First steps for the common scenarios

You do not have to predict every incident, just have a first move for the usual ones:

| Scenario | First step | Next |
| --- | --- | --- |
| Suspected malware or ransomware↗ | Disconnect the device from the network (unplug the cable and turn off Wi-Fi), but do not switch it off yet | Call your IT contact; check whether backups are safe |
| Compromised account | From another device, change the password and sign out all active sessions | Turn on two-factor authentication↗; check for forwarding rules or new devices |
| Lost or stolen device | Lock or wipe it remotely, if you set that up in advance | Change passwords for accounts that were signed in on it |
| Suspicious payment request | Do not pay; phone the person on a number you already know | Tell your bank at once if money has moved |

[Recognizing and Preventing Malware InfectionsHow malware actually gets onto your devices, the warning signs of an infection, and the everyday habits that stop most attacks before they start.](/recognizing-and-preventing-malware-infections)

### 3. What to keep as evidence

Resist the urge to clean everything up immediately. Take screenshots, note the time, and keep the affected system's logs if you can. This matters for insurance claims, for understanding how it happened, and for any legal duty to report the incident.

### 4. A short review afterwards

When it is over, write down what happened, how you noticed, what worked, and what you will change, even in half a page. This is how a small team builds real security maturity without a dedicated analyst.

## A worked example

An employee at a six-person design studio clicks a link in an email and enters a password. Ten minutes later they realize it was fake and tell the owner right away. Because the plan exists, the owner opens the sheet and follows it: change the password from a phone, sign out other sessions, check the mailbox for new forwarding rules, and phone the bank to be careful about payment requests that day. The whole thing takes 30 minutes, and the review afterwards adds two-factor authentication for everyone.

## Practice before you need it

A plan that exists only on paper often falls apart under pressure. Once a year, walk through a realistic scenario with your team, or by yourself if you work alone, and ask: "If this happened right now, would I know what to do first?"

> An incident response[↗](/incident-response) plan does not need to be sophisticated to work. It needs to exist, be written down, and be somewhere you can find it when you are stressed.

## Related reading

[Incident Management and Security Logging in PracticeWhen an incident happens, the quality of your logs determines how quickly you understand what occurred, and how confidently you can say it's truly resolved.](/incident-management-and-security-logging-in-practice) [Back Up Your Important Files RegularlyPhotos, documents and memories can disappear in an instant. A simple approach to backing up your phone (Android/iPhone) and computer.](/back-up-your-important-files-regularly) [Inclusive Security Exercises: Testing Your Human DefensesTabletop exercises and simulations reveal gaps that policy documents never do, and they work best when they reflect the full diversity of the people who will actually respond.](/inclusive-security-exercises-testing-your-human-defenses)