Writing a Simple Incident Checklist for a Small Team

Why a short checklist helps

When something goes wrong, such as a lost laptop, a misdirected email full of customer details, an employee clicking a bad link, or files that suddenly will not open, people tend to improvise. Improvising under stress leads to delays, duplicated effort, and avoidable mistakes. Large organizations have security departments and long procedures. A small team usually has neither, but it can still write one page that says who does what and in what order.

A checklist will not prevent incidents, and it will not cover every situation. Its job is to reduce confusion in the first hour, when decisions matter and time feels scarce.

What counts as an incident

Define it loosely and in plain words, so people report things early. For a small team, an incident might be any event where information or systems may have been lost, exposed, changed, or made unavailable without permission. Examples:

• A device is lost or stolen.
• An account may have been accessed by someone else.
• Someone sent information to the wrong recipient.
• A phishing email was opened, or a password entered on a suspicious page.
• Files were deleted, overwritten, or encrypted by malicious software.
• A shared folder was open to far more people than intended.
• A tool or service the team depends on is down or has had a breach.

Encourage a “report it even if unsure” culture. People who fear blame hide problems, and hidden problems grow.

What to put on the page

Keep it to one page, in plain language, and readable by someone who is stressed. A good outline has six parts.

1. Who to tell and who decides

Name an incident lead and a backup, since one person will be on holiday when it matters. List how to reach them, including a phone number, not only chat or email, which may be the thing that is compromised. If outside people may need to be called, list them too, such as an IT provider, your insurer if you have one, and a legal or professional adviser. Keep this contact list somewhere reachable without your main systems.

2. First response steps

Short, ordered, and concrete. For example:

1. Stop and note the time and what you noticed.
2. Do not delete anything that might serve as evidence.
3. Contain the problem: disconnect an affected device from the network, sign out sessions, or disable the account.
4. Tell the incident lead right away.
5. Write down what happened as you go.

3. Common scenarios

A few mini-lists for the likeliest cases save time. Link each to the relevant good practice:

• Suspected account takeover: change passwords from a clean device, end sessions, check two-factor authentication and recovery details, and look for forwarding rules.
• Lost or stolen device: use remote lock, change passwords for signed-in accounts, and decide on a wipe.
• Phishing click: disconnect, change the password, and warn others, using what you know about phishing emails.
• Wrong recipient: ask the recipient to delete the message, and assess what was exposed.
• Ransomware or data loss: isolate the device, do not pay or negotiate on impulse, and begin recovery from backups.
• Departure under difficult circumstances: remove access in a planned order.

Each scenario needs only three or four lines. Detailed guides can sit elsewhere in your team wiki.

4. Where the essentials live

List the things people will need fast: where backups are and how to restore them, who administers each important tool, how to reach the provider’s support, and where recovery codes and credentials are stored securely. A password manager with shared access can hold some of this, but make sure there is a way in when the primary device is gone.

5. Communication

Decide in advance how the team will talk if normal channels are suspect, such as a phone group or alternate address. Decide who speaks to customers, and when. If customer data may be involved, remember there can be legal or contractual duties to notify people, and these vary by place and situation, so identify an adviser to ask, rather than guessing. Honest, factual, and prompt messages tend to serve customers better than silence, but wording should be considered carefully.

6. After the incident

Plan a short review within a week or so, held without blame:

• What happened, and what was the timeline?
• What worked, and what slowed us down?
• What change would make this less likely or less damaging?
• Who owns each follow-up, and by when?

Record the findings, update the checklist, and share lessons with the team.

Practical tips for writing it

• Use verbs and short sentences. “Disconnect the device” beats “consider network isolation.”
• Test it on paper. Walk through a scenario, say a lost phone, in a ten-minute team discussion, and see where people hesitate.
• Store copies in more than one place, including one that does not depend on your main accounts, and a printed copy if appropriate.
• Assign a reviewer and a review date. Check it every six months or when the team or tools change. Stale phone numbers are a classic failure.
• Match it to your size. A solo freelancer’s checklist may be five lines. Better a short list people actually use than a long one nobody opens.

Fit it into everyday habits

An incident plan works best alongside prevention. Basics such as sensible sharing permissions, regular backups, restore testing, and a general focus on data security reduce how often you need the page at all. Mention the checklist when onboarding new people, so everyone knows it exists and that reporting early is welcome.

No plan can promise that an incident will be handled perfectly. A simple checklist makes a calm, coordinated response more likely, and gives a small team a head start when it counts.