What Should Be In Your Incident Response Plan?

Most small businesses do not panic about cyber incidents until one happens. Then a single ransomware note, a wire fraud email, or a credential alert turns a normal Tuesday into a 48-hour scramble. The teams that come out of those days in good shape are not the ones with the biggest tools budget. They are the ones who already wrote down what to do, who decides, and who calls whom. That document is your incident response plan.

This post walks through what an incident response plan actually contains, the phases it should cover, who needs to be on the response team, and how often you should test it. It is written for owners and operators of Treasure Coast small and mid-sized businesses who do not have a full-time security team, but who still need a clear playbook when something goes wrong.

What Is an Incident Response Plan?

An incident response plan is a written document that tells your team how to handle a security event from the moment someone notices it through the post-incident review. It defines what counts as an incident, who is on the response team, how decisions get made, who talks to customers and regulators, and how you preserve evidence so a forensic investigation or insurance claim can stand up later.

It is not the same as a disaster recovery plan and it is not the same as a business continuity plan. The recovery side of a disaster recovery and business continuity plan deals with restoring systems and keeping the business running when something breaks. An incident response plan focuses on the active handling of a security event: containment, eradication, communication, and lessons learned. The two plans connect but they answer different questions.

For a small business in Stuart or Port St. Lucie, your incident response plan does not need to be a 60-page binder modeled on a Fortune 500 SOC runbook. It needs to be specific enough that someone in your office at 9:00 PM on a Saturday knows exactly which three numbers to call and what not to touch.

What Should Be In Your Incident Response Plan?

A workable plan for a small business has eight components. If any one of these is missing, the plan will fail in the first hour of a real incident.

• Definitions and severity levels. Spell out what you treat as an incident versus a routine alert. Severity 1 is something like an active ransomware encryption or a confirmed wire transfer to a fraudulent account. Severity 3 is a single phishing email reported by an employee. Different severities trigger different response paths.
• The response team and roles. List the incident commander, the technical lead, the communications lead, the legal and insurance contact, and the executive sponsor. Use names, titles, mobile numbers, and a backup person for each role.
• Detection sources. Document where alerts come from: endpoint protection, email security, server monitoring, your managed IT provider, employees who report suspicious activity, dark web monitoring, or your bank’s fraud team. The plan should reference each source so the team knows where to look first.
• Containment steps. Pre-decide actions like isolating an infected machine from the network, disabling a compromised user account, rotating passwords, blocking a sender domain, or freezing a wire. Containment buys you time to investigate without making the situation worse.
• Communication plan. Internal communication, customer communication, and regulator or law-enforcement communication are three different tracks. Pre-write template language for each so you are not drafting a customer notice while the incident is still active.
• Evidence preservation. Logs, email headers, disk images, and screenshots all matter for insurance claims and forensic work. The plan should say what to capture, where to store it, and who is allowed to touch the affected system.
• Recovery and validation. Once the threat is contained, how do you confirm the environment is clean before going back to normal operations? This usually involves restoring from a known-good backup, resetting credentials, and running additional scans.
• Post-incident review. A short written debrief within seven days that captures what happened, what worked, what failed, and what changes are required. This is what turns one bad day into a stronger program.

Most cyber insurance carriers now ask whether you have a written plan and whether you test it. If you maintain coverage, the requirements that show up on your application or renewal often align almost exactly with these eight components. Reviewing the latest cyber insurance underwriting requirements before you write the plan saves a round of rework when renewal time comes.

How Detailed Should the Plan Be?

Detail matters in two places: the contact tree and the containment steps. Everywhere else, plain English wins. If a junior employee opens the plan during an incident, they should be able to read it once and act. Long paragraphs of policy language slow that down. Short bullet lists, decision trees, and pre-filled templates work better than narrative.

What Are the Phases of Incident Response?

The framework most teams use comes from NIST Special Publication 800-61. It defines six phases that your plan should follow in order, even on a small scale.

• Preparation. Everything you do before an incident: writing the plan, training the team, deploying logging, setting up backups, and running tabletop drills. Most of the value of a plan lives in this phase.
• Detection and analysis. Identifying that something is wrong and determining the scope. This is where alert fatigue and unclear severity definitions hurt small teams the most. A clear severity matrix shortens this phase.
• Containment. Stopping the spread or active damage. Short-term containment isolates the immediate threat. Long-term containment puts a temporary fix in place while you plan permanent eradication.
• Eradication. Removing the cause. That might mean wiping a compromised endpoint, removing a malicious mailbox rule, terminating an attacker session, or revoking a stolen API key.
• Recovery. Bringing systems back online and validating that they are clean. This phase often runs in parallel with the recovery work that lives in your backup and recovery configuration.
• Lessons learned. The post-incident review. The plan should require this step in writing within a defined window so it does not get skipped when the team is exhausted.

Mapping a real incident against these phases is what makes the framework practical. For example, in a credential exposure event surfaced by monitoring for compromised business credentials, detection happens through the alert feed, containment is rotating the password and revoking active sessions, eradication confirms no malicious mailbox rules or forwarding addresses were created, and recovery restores normal access with stronger controls. Without a plan, those steps tend to happen out of order, and the eradication piece often gets skipped, which is why the same account gets re-compromised weeks later.

Who Should Be On a Small Business Incident Response Team?

A small business does not need a dedicated security operations team. It does need named people for five roles, even if one person fills more than one role.

• Incident commander. Usually the operations lead or owner. Has authority to make decisions about taking systems offline, contacting customers, and engaging outside help.
• Technical lead. The person who actually executes containment and recovery actions. For most small businesses, this is the managed IT provider’s on-call engineer rather than an internal hire.
• Communications lead. Drafts internal updates, customer notifications, and any required regulatory disclosures. In a small office, this is often the same person who owns marketing or client relationships.
• Legal and insurance liaison. Engages outside counsel and the cyber insurance carrier early. Many policies require notification within 72 hours of discovery, and waiting too long can void coverage.
• Executive sponsor. The owner or CEO who signs off on customer communication, ransom decisions, and any spending outside normal authority.

For a 25-person company in Palm City or Vero Beach, those five roles often map to three people. That is fine. What is not fine is leaving a role unnamed. If no one is the named incident commander, three people will all assume the other two are handling it, and an hour of containment time will disappear before anyone calls the help desk.

Where Should You Store the Plan?

Two copies. One in your normal document system so it is easy to update. One offline copy, either printed or stored on a separate device, in case the incident takes down the system that holds the plan. A ransomware event that encrypts your file server should not also encrypt the document that tells you what to do about it.

How Often Should You Test Your Incident Response Plan?

A plan that has never been tested is a draft. The first real exposure of gaps almost always happens during a live incident, which is the worst possible time. The fix is regular tabletop exercises.

A tabletop exercise is a 60 to 90 minute facilitated walkthrough of a realistic scenario. The team sits in a conference room or on a video call, the facilitator reads a scenario one beat at a time, and the team works through what they would do at each step. Nothing is actually executed against production systems. The point is to surface unclear roles, missing contacts, and policy gaps in a low-stakes setting.

• Run a full tabletop at least once a year. Twice a year is better.
• Pick a different scenario each time: ransomware, business email compromise, lost laptop, insider data theft, vendor breach, cloud account takeover.
• Invite the actual response team, not just IT. The communications lead and the executive sponsor need the practice as much as the technical lead.
• Capture every gap in writing during the exercise and assign owners and due dates before the meeting ends.
• Treat tested fixes as the deliverable, not the exercise itself. A plan that was practiced in February but never updated is not really tested.

For most Treasure Coast small businesses, an outside facilitator runs better tabletop exercises than internal staff. The facilitator can challenge assumptions, role-play the attacker or the press, and keep the exercise from drifting into a status meeting. If your managed IT provider does not offer this, an annual session through a cybersecurity and compliance program is a reasonable add-on.

What Triggers an Update to the Plan?

Calendar reviews are not enough. Update the plan whenever a key role changes hands, a new business system goes live, a new regulatory requirement applies, after every real incident, and after every tabletop exercise. The version date and the change history should live on the cover page so anyone opening it knows whether they are looking at current guidance.

Frequently Asked Questions

What is the difference between an incident response plan and a disaster recovery plan?

An incident response plan covers how you handle the active security event: detection, containment, communication, and the post-incident review. A disaster recovery plan covers how you bring systems and data back online after disruption, whether that disruption was a cyber incident, a hardware failure, or a hurricane. The two plans share inputs and the recovery phase often overlaps, but they answer different questions and need to be maintained as separate documents.

Who should be on a small business incident response team?

At minimum, name an incident commander, a technical lead, a communications lead, a legal and insurance liaison, and an executive sponsor. In a small business those five roles often consolidate to three people. The important thing is that each role has a named primary and a named backup with current mobile numbers.

What counts as a security incident?

Anything that compromises the confidentiality, integrity, or availability of business data or systems. Examples include a confirmed phishing click that exposed credentials, a ransomware encryption event, an unauthorized wire transfer, a lost or stolen device with company data, an unexpected admin account creation, and a data exposure from a third-party vendor. Your plan should define severity levels so the team knows which events trigger a full response and which are handled as routine alerts.

How long does it take to develop an incident response plan?

For a small business with a managed IT provider, a usable first version takes two to four working sessions of about 90 minutes each. The longest piece is gathering current contact information, vendor numbers, and insurance policy details. The shortest is the actual document, because the eight components map cleanly to a template. Plan for a follow-up tabletop exercise within 60 days of finishing the first draft.

Do small businesses really need a written incident response plan?

Yes. Most cyber insurance carriers now require one as a condition of coverage. State and federal regulators in healthcare, finance, and certain government contracting categories require one explicitly. Even when no regulator or insurer is asking, a written plan reduces the cost and downtime of a real incident significantly. The plan does not need to be elaborate to be useful.

What is the first thing to do during a security incident?

Call the named incident commander, even if you are not sure the event is severe. The commander triggers the plan, assigns roles, and decides what containment actions to take. Do not power off affected machines unless your plan specifically directs it, because shutting down a system can destroy volatile evidence that forensics will need later. Disconnect from the network instead, and document what you saw before any action was taken.

Where should you store your incident response plan?

In two places. One copy in your normal document management system so it is easy to update and easy for the team to find. A second copy offline, either printed or on a separate device that is not connected to the same network. A ransomware event that encrypts your primary file storage should not also encrypt the document that tells you what to do about it.

Where Should You Start?

If your business does not have a current written incident response plan, or has one that has never been tested, that is a fixable gap. O&O Systems works with Treasure Coast small and mid-sized businesses to draft, document, and exercise plans that fit the way you actually operate. Reach out through the contact page to start the conversation.