If you asked ten small business owners if they have an incident response plan, many would say, “We’ll figure it out if something happens.” That’s not a plan. It’s hope, and hope isn’t a strategy when your data, systems, or business are at risk.

This guide explains how to create one, avoid common mistakes, and keep it effective when you need it most.

Why a One-Page Incident Response Plan Beats a Long One

Cybersecurity consultants sometimes push elaborate incident response frameworks modelled on enterprise standards like NIST SP 800-61. To be clear, those frameworks aren’t wrong. However, these solutions are built for organizations with dedicated security teams, not small businesses.

When an incident happens, maintaining business continuity is crucial, and three things are usually true:

• Someone is panicking. Maybe it’s the office manager who just watched a ransomware note pop up on a shared drive. In these moments, effective management of the situation is crucial. Maybe it’s you.

• Nobody has time to read a long document. Under stress, people skim. If your team has to scroll through pages of policy to find who to call, they’ll skip your incident response plan.

• The first 60 minutes matter more than the next 60 days. Early decisions, like what to disconnect, who to notify, and what not to touch, can determine the outcome.

As a result, a one-page plan works because it’s usable in the moment that counts. Think of it as a quick-reference card, not a policy document.

Short incident response plans encourage action, while long ones often go unread. A one-page document feels easy to complete. An owner or office manager can complete the plan in an afternoon and know it’s ready when they need it. A 40-page framework feels like a project that requires a consultant, a budget, and a kickoff meeting, so teams keep pushing it to “next quarter.” Businesses with a plan usually chose practicality over perfection.

It’s worth being honest about what a one-page plan is not. It doesn’t replace a full incident response program for regulated industries or the detailed documentation required by some cyber insurance policies, but it does strengthen your initial response. What it is, is the minimum viable version that ensures a small business isn’t starting from zero when something goes wrong. For most organizations with fewer than 50 employees, that minimum viable version is also the most practical option because teams rarely maintain anything more elaborate.

What Belongs on Your One-Page Incident Response Plan

A strong incident response plan, incorporating risk assessment and thorough analysis, answers six questions. Your team needs nothing more to get through the critical first hour, and nothing less will prepare them for it.

1. What counts as an incident?

Give your team a short list of triggers so nobody must guess. For example: ransomware messages, suspicious logins, missing or encrypted files, a vendor alert about a breach, or an employee who clicked a suspicious link and noticed something odd happen afterward. The goal isn’t to cover every scenario. Instead, it’s to lower the bar for reporting, since most breaches get worse because someone assumed it wasn’t “serious enough” to mention.

It helps to phrase these triggers in plain, observable language rather than technical jargon. Use plain language like “The screen shows a message demanding payment” because employees will identify and report it faster than a term like “ransomware encryption event.” Similarly, “an employee received a password reset email they didn’t request” is more actionable than “potential credential compromise indicator.” Remember, the person reading this plan in the moment may not be your most technical staff member. Write it for the office manager, not for the IT consultant.

It’s also worth explicitly naming the “grey area” incidents that people are most likely to talk themselves out of reporting: a slightly unusual login location, a file that looks renamed, a printer that started behaving strangely, an invoice that seems almost right but not quite. These marginal cases are exactly where early detection makes the biggest difference, because they often represent the earliest visible stage of an attack, well before ransomware notes or mass encryption appear.

2. Who gets called, and in what order?

List names and direct phone numbers, not job titles or departments. After all, “contact IT” is useless in a real incident if IT is one person who’s out sick that day. Your call list should include:

Build in redundancy and training wherever you can to ensure business continuity. If your internal point of contact is unreachable, who’s the backup? A single point of failure in your call list defeats the purpose of having one. List a secondary phone number for each contact because incidents don’t wait for business hours..

Keep the call list current. A name and number that were accurate two years ago but haven’t been checked since are almost as bad as no list at all, because they create false confidence. Review your contact list quarterly to ensure every number still reaches the right person.

3. What should be disconnected, and what should NOT be touched?

Most small businesses get this step wrong. The instinct is to start shutting things down or, worse, start “fixing” the problem before anyone documents it. Instead, your incident response plan should say plainly: disconnect the affected device from the network, but do not power it off, do not run antivirus scans, and do not delete anything. Powering off a compromised machine can destroy the very evidence needed to understand what happened, and in a ransomware case, it can even affect your recovery options.

There’s a reason this distinction matters so much: disconnecting a device (unplugging the ethernet cable or disabling Wi-Fi) stops an active threat from spreading further across the network, while powering the device off wipes volatile memory that investigators often need to understand how the attacker got in and what they touched. Some ransomware variants also behave differently, or worse, when a machine is abruptly powered down mid-encryption. Keep it simple: isolate it, don’t touch it, and call the number on the plan.

It’s worth adding a note about what to do with physical evidence too, if applicable. Set aside and photograph sticky notes, ransom notes, or suspicious USB drives. Don’t throw them away or handle them unnecessarily.

4. Who’s authorised to make the big calls?

Stakeholders should ensure that someone has the authority to approve a ransom payment, notify customers, or issue a public statement. Name the decision-maker before an incident happens.

This section should also account for what happens if that person is unreachable during the incident itself, which, given how these things tend to happen, is more common than you’d expect. Name a backup decision-maker, and be explicit about what authority transfers to them and what doesn’t. For example, a backup might be authorized to approve emergency IT spending up to a set dollar amount but not to approve a ransom payment without the primary decision-maker’s sign-off.

It’s also worth deciding, in calmer moments, roughly where your business stands on paying a ransom at all. Law enforcement advises against paying a ransom because it funds crime and doesn’t guarantee data recovery. Having even a loose, pre-agreed position, “we will only consider this after consulting legal counsel and our insurance carrier,” takes some of the weight off a decision made in a moment of crisis.

5. What are your legal notification obligations?

A data breach may trigger mandatory notification deadlines, some as short as 72 hours, depending on your industry and location. Include notification requirements in your plan so they’re ready when you need them.

Notification requirements vary considerably depending on what data was involved, whose data it was, and where those individuals live, which may not be the same state your business operates in. Healthcare-adjacent businesses may also have HIPAA-related obligations layered on top of state breach notification laws, and businesses that handle payment card data may have separate contractual notification requirements tied to their merchant agreement. This is exactly the kind of question that benefits from a five-minute conversation with legal counsel before an incident occurs, so that the plan can simply say “contact [attorney name]” rather than trying to pre-answer a question that depends on the specifics of what happened.

6. Where are the backups, and who confirms they’re clean?

If ransomware is involved, your recovery path depends entirely on whether your backups are intact and uninfected. Note where backups live and who has the authority to initiate a restore.

Be specific here. “We have backups” is not the same as “we have backups that are isolated from the production network, tested within the last 90 days, and retained far enough back that we can restore to a point before the infection began.” Ransomware can sit dormant for weeks before encrypting, so yesterday’s backup may already be compromised. Keep a printed copy and a digital backup outside your primary network.

Your Incident Response Plan Is Only as Good as the Practice

A one-page format removes the excuse of “we didn’t have time to write something long.” Even so, it still needs to be tested. Run a training tabletop exercise once or twice a year. Just 30 minutes can uncover outdated contacts, untested backups, and response gaps.

A tabletop exercise doesn’t need to be elaborate to be useful. Gather the stakeholders named in your plan, describe a realistic scenario (a suspicious login on the payroll system on a Friday afternoon is a good one, since it combines urgency with limited availability of help), and simply talk through what each person would do, in order, using only the plan as a reference. Find the gaps in a tabletop exercise, not during a real incident.

Common Mistakes That Undermine an Incident Response Plan

A few patterns show up again and again in businesses that thought they were prepared:

• The plan lives in one place only. If it’s a file on the same network that gets encrypted, or in an inbox on the same email account that gets locked out, it’s not accessible when you need it. Keep a printed copy and a digital backup outside your primary network.

• The plan names roles instead of people. “The IT manager” is not a substitute for a name and a cell number, especially at a small business where that role might be one contractor who doesn’t check email on weekends.

• Nobody owns keeping it updated. Plans go stale the moment a phone number changes, an employee leaves, or a vendor relationship ends. Assign one person to review and refresh it on a set schedule, not “whenever someone remembers.”

• The plan assumes the “worst case” won’t happen to a business this small. Attackers increasingly target small businesses precisely because they expect weaker defenses and a lower chance of being reported or investigated. Size is not protection.

How Prima Secure Can Help With Your Incident Response Plan

Building the plan is easy. Keeping it updated is what matters. The harder part is having the right people, tools, and processes in place when an incident occurs. That’s where Prima Secure comes in.

• Endpoint detection and response (EDR/XDR): The fastest way to shrink your “first hour” problem is to detect the incident before it spreads. Prima Secure’s endpoint protection identifies suspicious behavior in real time, so you’re not relying on an employee noticing a ransom note.

• Managed detection and response (MDR): For businesses without a dedicated security team, our MDR service puts trained analysts behind your incident response plan around the clock. When something triggers, you’re not the only line of defense, because we’re already looking at it.

• Incident response readiness support: Prima Secure works with clients to build and pressure-test their incident response plans, including tabletop exercises, so your team knows exactly what to do before an actual incident forces the question.

• Backup and recovery guidance: We help clients verify that backups are properly isolated from production systems and regularly tested, the detail that determines whether “we have backups” is true when it matters.

• Rapid incident support: If an incident does occur, Prima Secure can be part of your call list directly, providing hands-on containment and recovery support rather than leaving you to coordinate multiple vendors mid-crisis.

Prima Secure’s partnership with SentinelOne adds another layer to this readiness.

Through SentinelOne’s Singularity platform, clients get access to incident response as a service, meaning that when an incident is confirmed, a team is available to step in and manage containment, investigation, and recovery directly, not just detection. For a small business, this closes the exact gap a one-page plan is designed to expose: the moment when detection has done its job and someone still needs to actually run the response. Pairing Prima Secure’s MDR oversight with SentinelOne’s incident response capabilities means your plan isn’t just a document naming who to call, it’s backed by a team that’s already positioned to answer.

A one-page incident response plan won’t prevent every attack. When an incident does happen, you’ll respond with clarity instead of chaos backed by a partner who’s already part of the plan.

Want help building your incident response plan or testing whether your current one would hold up? Prima Secure to talk through your specific setup.