Incident Response Plan Template for Small Business

November 9, 2026 · Lizzard Solutions

incident response plancybersecuritysmall businesstemplatedata breachZZPL

By Nemanja Vukmirović, Lizzard Solutions. Last updated 9 November 2026.

When ransomware locks your laptops or a staff email account starts sending fake invoices, the first hour decides how bad the damage gets. Most small businesses lose that hour asking “who do we call?” and “should we switch everything off?”.

This incident response plan template fixes that. You get eight fill-in sections, a severity table, a worked example and a 30-minute test you can run this week. Copy it into a document, fill in the blanks, and print one copy so it still works when your systems do not.

---

What Is an Incident Response Plan?

An incident response plan (IRP) is a written document that tells your team exactly how to detect, contain, recover from and learn from a cybersecurity incident. It names the people in charge, lists the phone numbers you will need, defines what counts as serious, and gives step-by-step actions so nobody improvises under pressure.

Large companies follow frameworks like NIST SP 800-61 Rev. 3, which places incident response inside the NIST Cybersecurity Framework 2.0 and covers preparing, detecting, responding and recovering. A small business does not need a 100-page version. It needs two to four pages that people actually read.

Action for today: decide where the printed copy will live, for example in the office drawer and in the owner’s car.

---

What Counts as an Incident? Use a Simple Severity Scale

Not every strange email is an emergency. A severity scale stops panic over small things and makes sure big things get escalated fast. Adjust these three levels to your business:

Action for today: write two examples from your own business into each row. Real examples make the scale easier to use.

---

The Incident Response Plan Template: 8 Sections to Fill In

Copy each block below into your own document and replace the hints with your answers. Keep the whole thing under four pages.

1. Purpose and scope

• Covers: which systems: email, website, accounting software, laptops, phones, cloud storage
• Owner of the plan: name, and how often it is reviewed (for example every six months)
• Last tested: date of the last practice run

2. Roles and responsibilities

• Incident lead: one person who makes decisions, usually the owner or manager
• Technical lead: your IT person or outsourced provider
• Communications: who speaks to customers, staff and media
• Backup for each role: in case the first person is on holiday

3. Emergency contacts

• Internal: phone numbers for the lead, technical lead and backups (on paper, not only in the phone)
• External: IT provider, hosting company, domain registrar, bank fraud line, lawyer, cyber insurer if you have one
• Authorities: the data protection Commissioner and the National CERT of Serbia for Serbian businesses

4. Detection and first report

• How staff report: one channel, for example “call the incident lead, do not only email”
• What to note: time, what they saw, which device, what they clicked
• Golden rule: do not delete evidence and do not try to “clean” the device yourself

5. Containment

• Disconnect: unplug the network cable or turn off Wi-Fi on the affected device; do not power it off unless the technical lead says so
• Accounts: reset passwords and sign out all sessions for affected accounts; turn on two-factor authentication
• Website: put up a maintenance page and change admin and hosting passwords

6. Recovery

• Restore from: which backups, where they are, and who can restore them
• Order of priority: for example email first, then invoicing, then website
• Checks before going live: patched software, new passwords, malware scan

7. Communication

• Customers: pre-written short notice: what happened, what data, what you are doing, what they should do
• Staff: what they can and cannot say publicly
• Legal: whether a personal data breach report is needed (see the Serbian section below)

8. Lessons learned

• Within two weeks: a 30-minute review: what happened, what worked, what failed
• Fixes: who changes what, and by which date
• Update: revise this plan and record the date

Recovery depends on backups you have actually tested. If you are not sure yours work, follow our 3-2-1 data backup guide for small businesses before you finish section 6.

---

Worked Example: A Hacked Email Account

Here is how the plan runs in a common case. An accountant at a 12-person firm enters her password on a fake login page. Two hours later, customers start receiving “updated bank details” emails from her real address.

1. Detect: a customer calls to ask about the new bank account. The person who takes the call phones the incident lead, as section 4 says.
2. Classify: a mailbox sending fraud is High on the severity table, so the owner, IT provider and lawyer are told at once.
3. Contain: the IT provider resets the password, signs out all sessions, removes a forwarding rule the attacker added, and turns on two-factor authentication.
4. Communicate: the team sends the pre-written notice to all customers: ignore the fake bank details and confirm any payment change by phone.
5. Assess legal duties: the attacker could read emails containing customer names and invoice data, so the firm checks whether this is a reportable personal data breach.
6. Learn: the review leads to two fixes, two-factor authentication on every mailbox and a rule that bank changes are always confirmed by phone.

---

Serbian and EU Rules You Must Plan For

If an incident exposes personal data, the law adds deadlines. Under Articles 52 and 53 of the Law on Personal Data Protection (ZZPL), the controller must notify the Commissioner without undue delay and, where possible, within 72 hours of becoming aware of a breach that may create a risk to people’s rights. If the risk is high, you must also tell the affected people without undue delay.

The notice must describe the breach, the types and approximate number of people and records affected, a contact person, the likely consequences, and the measures taken. ZZPL also requires you to document every breach, even ones you do not report, so section 8 of your plan doubles as that record. Our guide to Serbia’s data protection law for websites explains the rest of ZZPL in plain terms.

Businesses serving EU customers face the same 72-hour logic under the GDPR. For general preparation, CISA’s cyber guidance for small businesses offers free checklists worth reading. This section is general information, not legal advice.

Action for today: add “Is personal data involved? If yes, call the lawyer and start the 72-hour clock” to section 7.

---

Test the Plan in 30 Minutes

A plan nobody has practised will fail on the first real incident. Run a short tabletop exercise, a meeting where you talk through a fake incident step by step:

1. Pick a scenario, for example “the website shows a hacker’s message on Monday morning”.
2. Ask each role what they would do first, using only the printed plan.
3. Call one external number from section 3 to check it still works.
4. Write down every gap, such as missing passwords, unknown hosting login or no tested backup.
5. Fix the gaps and set the next test in six months.

Many gaps show up on the website side: forgotten admin accounts, outdated plugins, missing security headers. A free website security check finds those before an attacker does, and our cybersecurity guide for small businesses covers the prevention side.

---

Frequently Asked Questions

Does a small business really need an incident response plan?

Yes. Small businesses have fewer people and less time to improvise, so a written plan matters more, not less. Two to four pages naming roles, contacts, severity levels and first steps can cut confusion in the first hour, when most damage from ransomware, fraud emails or a hacked website happens.

What should be in an incident response plan template?

At minimum: purpose and scope, roles, emergency contacts, a severity scale, how to detect and report, containment steps, recovery from backups, communication with customers and authorities, and a lessons-learned review. Each section should be short and filled in with real names, numbers and systems.

How often should we update the plan?

Review it at least every six months and after every real incident or test. Also update it whenever key people, your IT provider, your hosting company or your main software changes, because outdated phone numbers and logins are the most common reason plans fail.

Do we have to report a cyber incident in Serbia?

If personal data is affected and the breach may create a risk to people, ZZPL requires notifying the Commissioner without undue delay, where possible within 72 hours, and telling affected people if the risk is high. You can also report incidents to the National CERT. Confirm your specific obligations with a lawyer.