How to Write a Simple Incident Response Plan for a Small Business

Published 2026-11-04

Intro: what a simple incident response plan should do

A simple incident response plan should tell a small business who to call, what to do first, how to contain the incident, and how to recover without guessing. That is the whole point of a documented, repeatable response process, which is exactly how CISA and NIST frame incident response, and it lines up with Google Cloud’s note that a template helps teams respond faster and reduce role confusion in a crisis (Google Cloud incident response template overview).

1. Define the scope in plain language

Keep the plan small and practical. Write it for the incidents most likely to hit a small business, not every cyber horror story ever posted to the internet.

Good starting points are:

• suspicious email compromise
• malware on a laptop or server
• a lost or stolen device
• accidental data exposure, like sending the wrong file to the wrong person

If a situation is more complex than the plan covers, the plan should still tell people to stop, preserve evidence, and escalate. That keeps the document usable instead of turning it into a cyber fantasy novel.

2. List the people and roles before anything goes wrong

Before an incident happens, name the humans and their jobs. Google Cloud’s template overview emphasizes role clarity, decision-making authority, and handoffs across technical and executive stakeholders (Google Cloud incident response template overview). For a small business, that can be simple:

• Incident lead: the person who coordinates the response and keeps decisions moving
• Technical helper: whoever can check accounts, devices, logs, backups, or hosting settings
• Customer or vendor communicator: the person who sends approved updates
• Approver: the owner or manager who can approve account resets, service shutdowns, or other disruptive steps
• External contact: legal counsel, accountant, insurance contact, or managed service provider, if the business uses one

Write down names, backup names, phone numbers, and email addresses. If the plan says “ask Sam,” but Sam is unreachable and the office is half on fire, the plan has failed.

3. Write the first-response checklist

This part should be short and readable under stress. Use plain words. No one wants to translate jargon while their inbox is impersonating a raccoon.

A simple first-response checklist can look like this:

1. Spot and report the issue. If someone sees strange login prompts, unexpected file changes, a lost laptop, or a weird email sent from a company account, they report it right away.

2. Write down what was noticed. Note the time, the account or device involved, and what seemed wrong.

3. Preserve evidence. Do not wipe the device, delete messages, or start “cleaning things up” before the basics are recorded. NIST’s incident response guidance stresses handling incidents in a structured way so evidence and actions are tracked, not guessed.

4. Stop further access if needed. If the incident may still be active, disconnect the affected device from the network, suspend the account, or block the obvious access path.

5. Tell the incident lead. The person in charge should decide what happens next, instead of five people making five different versions of the same bad day.

4. Add a containment and recovery section

Containment means limiting the damage. Recovery means getting back to normal safely. NIST’s incident response concepts separate these steps for a reason, because “turn it back on and hope” is not a plan.

Your plan should say, in plain language:

• isolate the affected account, device, or service
• reset passwords or revoke access where needed
• remove suspicious forwarding rules, recovery settings, or delegated access in email if that is part of the incident
• restore from known-good backups when that is appropriate
• check that the system is clean before reconnecting it
• verify that normal business work can resume safely

For small businesses, safe to resume should mean the account is secured, the device is scanned or reimaged, the backup is confirmed good, and the owner has signed off.

5. Include an external notification decision path

Do not bury this in legalese. Write a simple decision path that says when to involve outside help.

The plan should note when to contact:

• legal counsel, if the incident may involve customer data, contracts, or reporting obligations
• affected customers or vendors, if their information or service may be affected
• the bank or payment provider, if money movement, card data, or fraudulent transfers are involved
• the hosting provider or email provider, if the issue involves their platform or logs
• law enforcement, if there is theft, extortion, fraud, or another crime that warrants it

Keep the criteria high level, because exact deadlines and duties depend on the incident and jurisdiction. The goal here is to make sure the business does not spend three hours arguing with itself while the problem keeps getting more creative.

6. Add a documentation log template

A basic log helps the business review what happened and improve later. It also keeps the story straight when everyone’s memory starts doing improv.

Your log template can include:

• date and time the issue was noticed
• who noticed it
• what happened, in plain words
• which account, device, file, or service was affected
• what was done first
• what was contained or restored
• who was notified and when
• whether evidence was saved
• what follow-up actions are still open

You can keep this in a shared document, a printed form, or both. The point is to have one place where the facts live.

Worked example: a simple email-compromise incident plan for a small business

Here is how the plan might work in real life.

A staff member notices that their mailbox suddenly has a new forwarding rule they did not create. They also see a sent message they do not remember writing. That is enough to treat it as a possible email compromise.

Detection and first response

• The staff member reports the issue immediately.
• The incident lead writes down the time, the mailbox involved, and the suspicious changes.
• The technical helper preserves relevant messages and account details.
• The account is isolated so the attacker cannot keep using it.

Containment

• The forwarding rule is removed.
• Passwords are reset for the affected account.
• Any other sessions or connected access are reviewed and cut off if needed.
• If the same password was reused elsewhere, those accounts are checked too. The related page on what to do if your password has been leaked helps here because leaked or reused credentials often turn one mailbox problem into several.

Notification

• If customer data, billing, or vendor communication may have been exposed, the owner checks whether legal counsel or the affected parties need to be contacted.
• If the mailbox was tied to banking or payment activity, the bank is contacted.
• If the provider’s logs or account controls are needed, the email or hosting provider is contacted.

Recovery

• Access is restored only after the mailbox is confirmed clean.
• The owner verifies there are no suspicious forwarding rules, recovery changes, or unauthorized devices still attached.
• Business mail resumes, with a watchful eye on any odd replies or login prompts.

Post-incident review

• The incident log is completed.
• The business notes what made detection possible, what slowed the response, and what should change in the plan.
• If the issue started with a stolen password or exposed credentials, the business updates the response steps so the next person does not have to rediscover the obvious under pressure.

Optional closing note: keep the plan short and test it

A simple plan should be easy for the right people to find and use. Store it where the right people can grab it fast, and review it after each incident or practice run. That way, the plan stays a tool, not a decorative document living its best forgotten life in a folder somewhere.