Sample security incident response plan for small businesses - Executive Solutions blog thumbnail

Sample Security Incident Response Plan for Small Businesses

July 19, 2026

Looking for a sample security incident response plan you can actually use? Most small businesses and nonprofits do not need a 40-page enterprise binder. They need a clear playbook: who does what in the first hour, who decides, who talks to customers or donors, and how you recover without guessing under pressure.

This guide gives you a practical incident response plan sample structure written for owners, executive directors, and managers-not only IT. Use it as a starting outline, then fill in your real names, vendors, and systems.

Why a sample security incident response plan matters

Incidents are not only "hacker movie" events. For SMBs they often look like:

  • A ransomware note on a shared drive
  • A staffer who clicked a fake invoice and shared Microsoft 365 credentials
  • A lost laptop with customer or donor data
  • A vendor breach that exposes your records
  • Wire fraud instructions that almost moved money

Without a written plan, people freeze, duplicate work, or wipe systems before evidence is preserved. Insurers, banks, and enterprise customers increasingly ask whether you have a plan-and whether anyone has practiced it.

A plan does not replace tools. It organizes people and decisions when tools alone are not enough.

What your plan should include (SMB version)

Keep the document short enough that leadership will read it. Aim for clarity over completeness.

1. Purpose and scope

One paragraph: this plan covers suspected cyber incidents affecting company systems, cloud email, data, payments, and key vendors. It does not replace emergency services for physical safety.

2. Definitions (plain English)

  • Event - something odd that may or may not be an attack
  • Incident - confirmed or strongly suspected compromise, data exposure, or major service disruption from a security cause
  • Severity - High / Medium / Low based on business impact (money, data, downtime, safety, reputation)

3. Roles and contacts (fill this in)

  • Incident lead - usually owner, ED, or designated manager
  • Technical lead - internal IT or MSP primary contact (24/7 number)
  • Communications lead - who drafts staff/customer/donor messages
  • Finance / banking contact - for fraud freezes
  • Cyber insurance - policy number, claim phone, counsel panel if required
  • Legal / privacy counsel - if you have one on retainer
  • Law enforcement - local cyber crime unit or FBI IC3 path when appropriate

Update this page every time people or vendors change.

4. Severity guide (simple)

  • High - ransomware, confirmed data theft, wire fraud in progress, email admin takeover, multi-day outage of critical systems
  • Medium - single mailbox compromise contained, malware on one device, suspicious vendor access under review
  • Low - blocked phishing, failed login noise, minor policy violation with no data loss

5. First-hour checklist (the part people actually use)

  1. Protect people and money first - if fraud is active, call the bank; if safety is at risk, call emergency services.
  2. Notify the incident lead and technical lead - one thread (call + shared channel), not ten side chats.
  3. Contain without panic wiping - isolate affected devices/accounts; reset passwords and revoke sessions for compromised identities; disable risky inbox rules.
  4. Preserve evidence - screenshots of ransom notes, sender addresses, timelines; do not reimage the only infected machine before IT/MSP advises.
  5. Start a simple incident log - time, what happened, who was notified, actions taken.
  6. Decide severity - High incidents trigger insurance/legal review early.
  7. Pause public statements - no social posts until facts are checked.

6. Investigation and eradication (guided by technical lead)

  • Identify entry point (phishing, remote access, vulnerable service, insider mistake)
  • Check admin accounts, MFA status, forwarding rules, new devices on the tenant
  • Remove malware/persistence and close the hole
  • Validate backups before large restore decisions

7. Recovery

  • Restore clean systems from known-good backups
  • Re-enable access in stages
  • Monitor for reinfection or repeat phishing
  • Confirm critical business functions (email, billing, payroll, delivery)

8. Notification decisions

Who must be told-and when-depends on data types, contracts, and state breach laws. Do not improvise legal conclusions. High-severity incidents should loop insurance and counsel before broad external notice. Document what you knew and when.

9. Post-incident review (within two weeks)

  • What worked / what failed
  • Root cause in business language
  • Three permanent fixes with owners and dates
  • Update this plan and your risk roadmap

Sample security incident response plan outline (copy/adapt)

Use this as a skeleton for your internal document:

  1. Document control (owner, last review date, version)
  2. Purpose and scope
  3. Roles and 24/7 contact list
  4. Severity definitions
  5. Detection sources (staff report channel, MSP alerts, bank fraud alerts)
  6. First-hour checklist
  7. Containment playbooks (email compromise, ransomware, lost device, vendor breach)
  8. Evidence and logging rules
  9. External notification matrix (customers, donors, regulators, law enforcement)
  10. Recovery and business continuity links
  11. Communication templates (staff holding statement; customer/donor holding statement)
  12. Appendix: critical systems list, backup locations, insurance policy summary

That outline is a sample security incident response plan structure-not a substitute for tailoring names, systems, and legal duties to your organization.

Common mistakes to avoid

  • Plan lives only in IT - leadership cannot execute what they have never seen
  • No MSP or vendor numbers - after-hours chaos
  • Wipe first, ask later - destroys evidence and can worsen recovery
  • No severity levels - everything becomes either ignored or all-hands panic
  • Never tested - a 30-minute tabletop twice a year beats a perfect unread PDF

How this connects to risk assessment and leadership

An incident plan is one control. It works best after you know what is critical and where you are weak. That is why a cybersecurity risk assessment for small business pairs naturally with IR planning: assessment sets priorities; the plan tells people what to do when something breaks.

Someone still has to own updates, tabletop exercises, insurance questions, and vendor accountability. That ongoing ownership is the job of fractional cybersecurity leadership when you do not have a full-time CISO.

Key takeaways

  • A usable sample security incident response plan is short, role-based, and practiced-not a shelf document.
  • First-hour actions (contain, preserve, log, escalate) prevent most self-inflicted damage.
  • Fill real contacts: MSP, insurance, bank, leadership, communications.
  • Pair the plan with a risk baseline so fixes target real gaps.
  • Review after every incident and at least annually.

How Executive Solutions can help

Executive Solutions helps SMBs and nonprofits turn "we should have a plan" into a living process: baseline risk, prioritized roadmap, and practical incident readiness-without enterprise theater. Many clients start with assessment and continue through fractional cybersecurity leadership (vCISO) services so the plan, vendors, and board reporting stay owned.

Want a plan that matches your real systems and people? Visit our cybersecurity leadership page or schedule a free discovery call.

George Bakalov

George Bakalov

George Bakalov is the founder and CEO of Executive Solutions USA, LLC. With over 20+ years of experience in technology in different role, the last 7 of which in information Security, George has broad executive technologist experience and passion to help SMBs flourish by securing people, data and posture, affordably.

LinkedIn logo icon
Back to Blog