Incident Response Plan for Small Business: How to Build One That Actually Fits Your Business

When I talk with a small business about incident response, especially a business operating in a regulated environment, I do not start by handing them a generic template and asking them to fill in a few names and phone numbers. A template can be useful because it gives us questions to work through, but the finished incident response plan needs to be built around the actual business.

I need to understand how the company operates, what technology it depends on, where its information lives, who has authority to make decisions, which vendors support critical systems, what insurance coverage exists, and which legal, regulatory, contractual, or customer requirements may apply. I also want to know what happens when the normal way of operating is no longer available. If Microsoft 365 is compromised, a computer is infected, the building cannot be accessed, equipment is stolen, or the company's normal email cannot be trusted, the response plan needs to account for those situations before people are trying to figure them out during an emergency.

That is why I do not believe a small business incident response plan should be one size fits all.

“A template can give you the questions. A real incident response plan needs your business's answers.” - SNL-Tech Services

What Is an Incident Response Plan for a Small Business?

An incident response plan establishes how a business will recognize, escalate, manage, document, communicate about, and recover from an incident. For a small business, the plan does not need to look like something written for a global company with a security operations center, internal attorneys, a communications department, and dozens of IT employees. It does need to answer the questions that matter to the business that will actually use it.

Who does an employee call when something looks wrong? Who makes the decision that something is serious enough to activate the plan? What is IT authorized to do? Who can take systems offline if doing so affects business operations? Who contacts the cyber insurance carrier? Who contacts legal counsel or a forensic specialist if one is needed? What information needs to be preserved? How will employees communicate if normal email is part of the incident? How does the business continue functioning while technical work is underway?

Those are the kinds of questions I want answered before an incident.

NIST's newest small business cybersecurity work supports this approach. Its April 2026 draft for non employer firms specifically recognizes that incident response needs to be adapted to the organization and recommends documenting who participates, their responsibilities and authority, and the legal, regulatory, contractual, or policy reporting obligations that apply.

That is much closer to how I think small business incident response should actually work.

Why Can't a Small Business Just Download an Incident Response Template?

A downloaded template does not know your business.

It does not know whether you use Microsoft 365 or Google Workspace. It does not know whether you have a physical server, a NAS, cloud applications, multiple offices, remote employees, managed laptops, personal devices, security cameras, an alarm company, segmented networks, or a line of business application that cannot be unavailable for more than an hour.

It also does not know the people.

If the owner normally makes every major decision, what happens when the owner is traveling and cannot be reached? Does the office manager have authority to approve emergency IT work? Can IT shut down a server without first obtaining approval? Who can call the insurance carrier? Who has access to the policy? If a forensic specialist needs to be brought in, who is authorized to engage them?

Those answers can be completely different from one ten person business to another.

This is one of the reasons good IT documentation matters so much. My Small Business IT Checklist and Systems Inventory is designed to help an owner understand what technology the business depends on and who controls it. If nobody knows where the firewall is managed, which devices are encrypted, where backups are stored, who controls Microsoft 365, or which vendor supports a critical application, incident response becomes considerably harder.

A generic template can start the discussion. It cannot finish it.

What Types of Incidents Should a Small Business Plan For?

Cybersecurity incidents are a major part of incident response planning, but I do not want a client thinking only about ransomware. The scenarios should reflect what could realistically interrupt that particular business.

For one company, a compromised Microsoft 365 account may be one of the most likely problems. Another business may be highly dependent on an on premises server. A company with employees constantly working from the field needs to think about lost devices. A company processing significant vendor payments needs a strong Business Email Compromise and fraud procedure.

Physical events matter too. If someone breaks into the office and steals equipment, the police may be the first call, but IT may need to become involved almost immediately. A natural disaster may damage equipment or make the building inaccessible. A long internet outage may effectively shut down a cloud dependent business even though nobody was hacked.

I usually want to work through scenarios such as these:

Scenario	Questions the Plan Needs to Answer
Suspicious or compromised computer	Who does the employee contact? What should they do while waiting? Who determines whether the machine is isolated, powered down, or preserved?
Microsoft 365 account compromise	Who contacts IT? Who has authority to block access? What sign in, mailbox, audit, and security information needs to be reviewed or preserved?
Business Email Compromise or payment fraud	Was an account compromised or impersonated? Was money transferred? Who contacts the bank? Who handles the technical investigation?
Ransomware	Who leads the response? What systems are affected? What should be isolated? Who contacts insurance, legal, forensic, or law enforcement resources when appropriate?
Lost or stolen device	Which device is missing? Was it encrypted and centrally managed? What company information could it access? Can access be revoked?
Physical break in	Who contacts police, the owner, IT, building management, and the alarm provider? Were devices or network equipment accessed? Is security footage available?
Natural disaster or building loss	Can employees safely access the location? What infrastructure was damaged? Can the business operate elsewhere?
Internet or infrastructure outage	Who contacts the ISP? Is the problem local or provider related? Is failover available? What business processes are affected?
Critical server or application failure	What needs to come back first? Where are backups? Who coordinates the different vendors?

That matrix is not the finished incident response plan. It helps us determine which playbooks the business actually needs.

Who Is in Charge During a Cybersecurity Incident?

This is one of the first questions I want answered.

Small businesses frequently depend on informal decision making because that works well during normal operations. The owner is ten feet away, everyone knows one another, and problems get handled as they come up. During an incident, that informality can create confusion.

The plan should identify the person responsible for coordinating the business response and who takes that responsibility if the primary person is unavailable. It should also establish the authority attached to each role. The person leading the response may not be the same person performing the technical investigation, contacting insurance, or communicating with employees.

Depending on the business and the incident, people involved may include:

• Business owner or executive decision maker

• Manager or designated backup decision maker

• IT provider or internal technical contact

• Cyber insurance carrier or broker

• Legal counsel

• Compliance professional

• Digital forensics and incident response specialist

• Financial institution

• Law enforcement

• Critical software or technology vendors

• Building management or alarm company

• Communications or public relations resources when appropriate

Not every incident requires all of those people.

The plan needs to help the business determine who becomes involved and who is responsible for contacting them.

What Happens if the Incident Occurs After Hours?

An incident response plan should not assume that every emergency will happen between 8:00 AM and 5:00 PM.

For the clients I support, I establish an emergency escalation procedure. If a serious emergency occurs outside normal business hours and I do not answer the initial phone call, they know to text me 911. That tells me immediately that the message is not a normal support request that can wait. If I have not responded within 15 minutes, they know to call me again.

That is my procedure with my clients. It is not a universal incident response requirement, and another provider or business may have a completely different process. What matters is that the process is defined.

The business should know which communication method to use, what qualifies as an emergency, how long someone waits for a response, and what the next escalation step is. That same thinking should apply to the business itself. If the owner does not answer, who is next? If company email cannot be trusted, how will the response team communicate? If the building cannot be accessed, where can the contact information be found?

Simply writing “call IT” is not enough.

What Should IT Actually Do When an Incident Is Reported?

This is another area where generic plans often stop too soon.

An employee reports a possible compromise. The plan says to contact IT.

Then what?

IT needs clearly defined responsibilities and authority too. Depending on the environment and the situation, that could involve reviewing an endpoint security alert, investigating Microsoft 365 sign in activity, checking a firewall, revoking account access, isolating a device, protecting backups, reviewing network activity, documenting evidence, or coordinating with another specialist.

The important part is that those decisions should not be made blindly.

There can be a significant difference between an employee receiving a suspicious email and an attacker actively controlling a computer. A Microsoft 365 identity compromise can require different containment from ransomware spreading across a network. A financial fraud event can require immediate action with the bank while the technical investigation happens at the same time.

The incident response plan defines who makes the decisions and what IT is authorized to do. The technical runbooks underneath that plan document how the company's actual systems are handled.

That distinction is important. The plan describes responsibility and escalation. The runbook provides the technical procedures.

Should You Shut Down a Computer if You Think It Has Been Hacked?

There is no universal answer that is correct for every cybersecurity incident.

People often want a simple instruction such as “shut it down immediately” or “never shut it down.” I do not think either statement should be applied blindly.

A device may need to be isolated from the network quickly to prevent additional activity or spread. In some situations, preserving the running state may be important because information in memory or other volatile evidence can disappear when power is removed. In another situation, shutting the system down may be the appropriate decision after the circumstances have been evaluated.

CISA's ransomware guidance specifically discusses isolating affected devices, including physically disconnecting network cables or removing devices from WiFi when necessary to contain ransomware. That is useful ransomware guidance, but I would not turn it into a universal instruction for every possible incident.

The first technical action needs to match what is actually occurring.

“The first technical action should be deliberate. Every change made to a potentially compromised system can affect what we are able to learn about the incident afterward.” - SNL-Tech Services

That is also why I do not want employees randomly deleting suspicious files, clearing logs, uninstalling programs, resetting everything they can find, or wiping a computer before the situation has been evaluated.

Containment matters. So does understanding what happened.

What Information Should Be Documented During an Incident?

Documentation should start when the incident starts.

I want to know when the first unusual activity was observed, what the employee saw, when they reported it, who they contacted, what technical information was available, and what actions were taken afterward. I also want the chronology of those actions because sequence can matter when someone later tries to reconstruct what happened.

Depending on the incident, the record may include:

• Date and time the issue was first observed

• Name of the person who reported it

• What the person observed

• Date and time the issue was reported

• Screenshots or photographs

• Security alerts

• Relevant Microsoft 365 sign in information

• IP addresses

• Risky User or Risky Sign In information when available

• Mailbox forwarding or suspicious rules

• Endpoint protection information

• Firewall or network events

• Devices or accounts believed to be involved

• Technical actions taken

• Who performed each action

• When each action occurred

• Who authorized major actions

• Outside parties contacted

• Physical media or equipment preserved

• Recovery actions

• Follow up findings

The exact list will vary, which is another reason the plan needs to reflect the actual systems in use.

If a cyber insurer, attorney, forensic specialist, regulator, law enforcement agency, customer, or another outside party becomes involved later, I want to be able to explain what occurred before they arrived and what changes had already been made.

Why Can Evidence Preservation Matter?

I have dealt with a client incident where preserving the original storage media became part of my technical response.

In that situation, I ultimately removed the compromised drive from the affected computer. Instead of wiping it or reusing it, I sealed the drive in a bag and documented the date and time it was removed, along with my signature, name, business name, and contact information. I returned the preserved drive to the client so the original media remained available if it was needed later.

I also documented the incident itself, including timestamps from the initial phone call and text message, when I connected to the device, when I determined that the system was compromised, and the actions that followed.

At the same time, the client still needed a working computer. I installed a new drive, rebuilt and configured the machine, and returned the working system to the client the following morning.

Those were the decisions I made for that particular incident. I am not presenting them as a universal recipe for every compromised computer, and I am not describing my work as a formal digital forensic examination or claiming that I established a legally sufficient forensic chain of custody.

My role was technical response, documentation, preservation of the original media, recovery of the computer, and maintaining information that could be useful if another specialist needed it.

That experience is also why I think incident response and business recovery have to be considered together. The business may need to preserve information about what happened while also getting employees safely operational again.

What Happens if Microsoft 365 Is Compromised?

A Microsoft 365 compromise deserves its own technical runbook because changing a password is not the same thing as completing an investigation.

Microsoft's current compromised account guidance includes reviewing and revoking active access, examining authentication methods, checking applications with user consent, reviewing administrative roles, inspecting forwarding, and examining Inbox rules including hidden rules. Microsoft's guidance also specifically identifies suspicious rules that move messages into folders such as RSS Subscriptions as a potential sign of compromise.

Depending on the environment, licensing, and available evidence, I may also need to look at sign in history, Risky Users or risk detections, device information, email activity, audit information, Microsoft Defender alerts, SharePoint or OneDrive access, and other resources associated with the identity.

A Risky User detection does not automatically mean the user was compromised. I have seen false flags. I would still rather have the visibility, investigate it, and determine whether the activity makes sense than have no indication that something unusual occurred.

If you want a deeper look at the signs that something may already be wrong, I recently refreshed 7 Warning Signs Your Small Business Might Be Hacked. I also explain the broader Microsoft environment in my Microsoft 365 Audit and Microsoft 365 Tenant Security Review.

How Should a Business Respond to Business Email Compromise and Payment Fraud?

Business Email Compromise, commonly called BEC, needs special attention in an incident response plan because it can create a technical incident and a financial emergency at the same time.

A criminal may compromise an actual mailbox, impersonate the owner, spoof an email address, register a lookalike domain, compromise a vendor, or insert fraudulent payment instructions into what appears to be a legitimate business conversation. The result may be a request to change banking information, redirect an invoice payment, alter payroll, or send a wire transfer.

If money has already moved, the financial response should not wait for the technical investigation to finish. Current FBI guidance tells BEC victims to contact the financial institution immediately and request that it contact the institution where the transfer was sent. The FBI also directs victims to report BEC to its Internet Crime Complaint Center.

At the same time, IT needs to determine what actually happened.

Was one of our Microsoft 365 accounts compromised?

Was the vendor compromised?

Was our domain spoofed?

Was a lookalike domain used?

Were malicious Inbox rules or forwarding created?

Did the attacker have access to an existing email conversation?

What could the affected account access?

What information needs to be preserved?

This is why the incident response plan should have both a financial fraud escalation path and a technical investigation path.

BEC Responsibility	What Needs to Be Decided Ahead of Time
Employee	Who should be contacted when a payment request or banking change seems suspicious?
Manager or owner	Who can stop or delay a payment while it is verified?
Bank or financial institution	Who has authority to contact the fraud department immediately if money has already moved?
IT	Who investigates whether an account, device, or email environment was compromised?
Insurance	What does the actual cyber policy require after a fraud or suspected compromise?
Law enforcement	Who handles IC3 or other appropriate reporting?
Legal or compliance resources	Does the event create privacy, contractual, regulatory, or notification issues?
Customer or vendor	Who communicates with the legitimate outside party using trusted contact information?

BEC is also why I like businesses to establish an independent verification procedure for significant payment or bank account changes. Technology can help, but employees should know how to verify a financial change using contact information the company already trusts rather than simply replying to the same email that delivered the request.

I cover the Microsoft 365 and impersonation side of this problem more deeply in Microsoft 365 Email Security for Law Firms and Business Email Compromise.

What Happens After a Break In or Stolen Computer?

A physical break in can become an IT incident very quickly.

The immediate priorities may involve physical safety and law enforcement, but once that is addressed, I want the business thinking about what equipment or information may have been accessed.

Which computers are missing?

Who used them?

Were they encrypted?

Were they enrolled in centralized device management?

Could they access Microsoft 365, Google Workspace, accounting systems, cloud storage, or other company applications?

Are browser sessions still active?

Can access be revoked?

Could anyone have accessed servers or network equipment?

Is security camera footage available?

Should alarm records or building access records be preserved?

Who contacts the alarm provider?

Does insurance need to become involved?

This is where an accurate asset inventory, encryption, centralized device management, access controls, security cameras, network documentation, and clearly assigned responsibilities become useful very quickly.

A business that knows exactly which laptop was stolen and how it was protected starts its response in a very different place from a business that cannot identify the device or determine what information was on it.

What if a Natural Disaster or the Building Itself Is the Problem?

Not every serious technology incident begins with a hacker.

A storm, fire, flood, electrical event, or other physical incident can damage the equipment a business relies on or make the location unavailable. Employee safety and emergency services obviously come first, but there is still an IT and operational response once the immediate emergency is addressed.

Who determines whether servers, network switches, firewalls, wireless access points, computers, storage systems, or other equipment were damaged? Who contacts the ISP? Can employees work remotely? Are cloud systems available? Are backups intact? What equipment has to be replaced? Who handles the technology vendors? Who documents damaged equipment for the insurance process?

I have dealt with a client situation where a severe storm damaged a building and technology had to be relocated while temporary operations were established. Situations like that are why I do not think incident planning can exist separately from disaster recovery and business continuity.

The plan should reflect how the actual business can continue when the normal location or systems are unavailable.

What Is the Difference Between Incident Response, Disaster Recovery, and Business Continuity?

These terms overlap, but they answer different questions.

Plan	Primary Question
Incident Response	What happened, who responds, how is it contained and investigated, what needs to be documented or preserved, and who needs to be notified?
Disaster Recovery	How do we safely restore affected technology, applications, systems, and data?
Business Continuity	How does the business continue performing critical work while normal systems or locations are unavailable?

A ransomware attack could activate all three. So could a major physical disaster.

The incident response process deals with the event itself. Disaster recovery deals with rebuilding or restoring technology. Business continuity deals with keeping the company functioning while those activities are underway.

For the businesses I work with, I want those plans to support one another rather than exist as completely disconnected documents.

How Do Cyber Insurance Requirements Affect Incident Response?

Cyber insurance needs to be part of the planning conversation before an incident happens.

I want the business to know who its carrier and broker are, where the current policy is stored, what the claims or emergency contact procedure is, and what the actual policy says about incident response.

This matters because insurers can have their own response procedures. Current insurer guidance provides examples where policyholders are instructed to notify the carrier quickly and, in some cases, before independently engaging outside incident response vendors. Insurers may have breach counsel, digital forensic firms, notification providers, or other approved resources available through the policy.

That does not mean every policy works the same way.

The business should know what its own policy requires rather than relying on a generic article or another company's insurance experience.

I discuss the technical questions surrounding insurance in Cyber Insurance Requirements for Small Businesses. Incident response planning is one of the areas I want businesses to address before an application or renewal becomes an actual claim.

Does a Small Business Have to Report a Cybersecurity Incident?

Sometimes, but there is no single reporting rule that applies to every small business or every security event.

The answer can depend on what happened, what information was involved, where affected individuals live, which regulations apply to the business, what contracts it has signed, whether it performs work for the government, and what its insurance policy requires.

For a Maryland business, the Maryland Personal Information Protection Act can create investigation and notification obligations following certain breaches involving Maryland residents' personal information.

A healthcare provider or business associate may have obligations under HIPAA.

Certain financial institutions subject to the FTC Safeguards Rule may have federal notification obligations after a qualifying event.

A Department of Defense contractor with the applicable DFARS cyber incident reporting clause can have specific reporting and evidence preservation requirements.

A customer contract, Business Associate Agreement, insurance policy, subcontract, or other agreement can create still more responsibilities.

That is why I do not want the IT provider making a legal conclusion and announcing that something is or is not a reportable breach. My role is to investigate and document the technical environment, implement appropriate containment and remediation within my scope, preserve technical information, and provide accurate technical information to the professionals who need it.

Legal counsel, the insurer, a compliance professional, assessor, regulator, or another qualified specialist may need to determine the organization's legal or contractual notification requirements.

Is Every Security Alert a Data Breach?

No. A suspicious sign in, Defender alert, malware detection, Risky User alert, phishing email, or unusual device behavior is information that needs to be evaluated. It does not automatically establish that data was acquired or that a legally reportable breach occurred.

The investigation helps determine what happened.

That distinction is important because businesses can make two opposite mistakes. They can overreact to an alert and make conclusions they do not yet have evidence to support, or they can dismiss something because they have not yet proven that information was stolen.

I would rather investigate and establish the facts.

What Changes for Regulated Businesses?

The incident response plan becomes even more important when the business operates under legal, regulatory, contractual, or customer security requirements.

The technical plan still needs to fit the company, but now we also need to understand what specific documentation, reporting, evidence preservation, response, or recovery obligations apply.

Healthcare is a good current example. HHS OCR has continued ransomware enforcement activity throughout 2026, including settlements involving risk analysis, policies and procedures, breach notification, audit controls, and other HIPAA Security Rule concerns.

For covered financial institutions, the FTC Safeguards Rule includes specific notification requirements for qualifying security events.

For certain DoD contractors, DFARS 252.204-7012 contains cyber incident reporting and media preservation requirements when that clause applies.

These are different requirements for different businesses. They should not be blended together into a generic “compliance checklist.”

When I work with a regulated client, I want the company's actual requirements identified and then reflected in the response plan and technical runbooks. My role is the technical implementation, management, documentation, and response work within my scope. Where a compliance consultant, assessor, attorney, insurance professional, or another specialist is needed, their role remains separate.

Does a Sole Proprietor Really Need an Incident Response Plan?

Being the only person in the business does not make cybersecurity incidents disappear.

In fact, NIST's newest small business cybersecurity draft released in April 2026 is specifically aimed at non employer firms, including sole proprietors, freelancers, single member LLCs, and other very small businesses.

A sole proprietor obviously does not need to build an enterprise incident response department.

They still need answers.

• Who do I call if my Microsoft 365 account is compromised?

• What happens if the only laptop I use for work is encrypted by ransomware?

• Where are my backups?

• How do I reach my IT provider if company email is unavailable?

• Who is my cyber insurance contact?

• Do I possess customer or regulated information that creates reporting obligations?

• Who helps me determine whether legal or regulatory notification is necessary?

• How do I keep the business running if my primary device is unavailable?

For a one person company, many members of the response team may be outside professionals rather than employees. That makes documenting those contacts and relationships even more important.

What Should Be Included in a Small Business Incident Response Plan?

The exact document will vary, but these are the areas I generally want the planning process to address:

Planning Area	What the Business Needs to Establish
Realistic scenarios	Which incidents could realistically affect this business?
Incident leadership	Who leads the response and who is the backup?
Employee reporting	Who does an employee contact when something looks wrong?
Emergency escalation	What happens after hours or when the first contact does not respond?
Authority	Who can authorize account blocks, isolation, outages, outside specialists, and other significant actions?
IT responsibilities	What is IT expected and authorized to do?
Technical runbooks	How are the company's actual systems handled during different scenarios?
Evidence and documentation	Who maintains the timeline and preserves relevant technical information?
Financial fraud	Who contacts the bank and who investigates the email or account side?
Cyber insurance	Where is the policy, who is the contact, and what response process does it require?
Legal and compliance	Who determines reporting, privacy, contractual, or regulatory obligations?
Forensic escalation	Who is authorized to engage a forensic specialist and how is information handed off?
Law enforcement	Who makes the contact when appropriate?
Employee communication	Who tells employees what is happening and what systems they can use?
Customer or vendor communication	Who handles outside communication if needed?
Disaster recovery	How will affected systems and data be restored?
Business continuity	How will critical business functions continue?
Post incident review	What did we learn and what needs to change?

The completed plan needs the business's actual answers in those areas.

How Does Good IT Documentation Help During an Incident?

An incident response plan can only be as useful as the information supporting it.

If nobody knows which computers exist, who owns the Microsoft 365 tenant, where DNS is hosted, how the firewall is configured, where backups are stored, which systems are on which network segments, what vendors support critical applications, or who has administrative access, the response team spends valuable time rediscovering the environment while simultaneously trying to manage the incident.

That is one reason the SNL-Tech Services IT Baseline Assessment and current technical documentation fit so naturally into incident response readiness.

Depending on the environment, I may want current information about:

• Microsoft 365 or Google Workspace

• Administrative and emergency access

• Computers and mobile devices

• RMM and device management

• Endpoint security

• Servers

• Firewalls and switches

• VLANs and network segmentation

• Wireless networks

• NAS devices and storage

• Backups

• Cloud applications

• Line of business applications

• Security cameras

• Alarm and physical access systems

• Internet providers

• Domains and DNS

• Important vendors

• Regulatory or contractual technology requirements

You cannot respond efficiently to a system nobody knew existed.

How Often Should a Small Business Test Its Incident Response Plan?

I like scenario based testing because it exposes assumptions that are difficult to see while reading a document.

Imagine it is Saturday night and an employee realizes that their Microsoft 365 account is sending messages they did not create.

• Who do they call?

• What if that person does not answer?

• How does the emergency escalation work?

• Can IT access Microsoft 365?

• Who can authorize blocking the account?

• Where is the cyber insurance information?

• Should company email still be used to discuss the incident?

• Now change the scenario.

• It is Monday morning and someone discovers that the office was broken into over the weekend. Two laptops are missing.

• Who calls the police?

• Who calls IT?

• Can we identify the laptops?

• Were they encrypted?

• Were they centrally managed?

• Can access be revoked?

• Is there camera footage?

• Who preserves it?

• Who contacts the alarm company?

• Does insurance need to be involved?

Those conversations tend to expose gaps very quickly.

The plan also needs to be reviewed when meaningful parts of the business change. New employees, leadership changes, a new IT provider, different cloud systems, a new office, new vendors, new cyber insurance, regulatory requirements, or infrastructure changes can all make parts of an old plan inaccurate.

A plan is useful only if it still describes the business that actually exists.

What Should Happen After the Incident Is Over?

Returning the business to operation does not mean the work is necessarily finished.

Once the immediate response and recovery are complete, I want to understand what we learned. What caused or contributed to the incident? Did the escalation process work? Was the right contact information available? Did IT have the access and documentation it needed? Were backups usable? Did network segmentation work as expected? Did employees know what to do? Did we discover a system or vendor nobody had documented?

Then the documentation, technical environment, runbooks, and incident response plan can be updated based on what actually happened.

NIST's current incident response approach specifically incorporates lessons learned back into ongoing cybersecurity risk management. I think that is especially valuable for small businesses because each real incident or tabletop exercise gives us information we can use to make the next response better.

Frequently Asked Questions About Small Business Incident Response

What Should an Employee Do First if They Think the Business Has Been Hacked?

The employee should follow the company's established incident reporting process and explain exactly what they observed. They should avoid experimenting with fixes or making unnecessary changes while waiting for direction. The correct technical response depends on what has actually occurred.

Who Should a Small Business Call First After a Cyberattack?

There is no single call order that applies to every business and incident. The incident response plan should establish who leads the response and when IT, cyber insurance, legal counsel, forensic specialists, law enforcement, financial institutions, or other parties should be contacted.

Should We Contact Cyber Insurance Before Calling a Forensic Company?

Check the actual policy and response procedure. Some current cyber insurers instruct policyholders to notify them before independently engaging outside incident response vendors so the insurer can coordinate approved resources. Policies differ, which is why this should be established before an incident.

Should We Shut Down a Computer That May Be Compromised?

Not automatically. Isolation may be appropriate, but powering off a device can affect evidence available for investigation. The correct action depends on the incident and should be determined deliberately by the people responsible for the technical response.

Should We Immediately Change Every Password?

Credential changes and access revocation can be important containment measures, but widespread changes should not substitute for understanding what happened. A compromised Microsoft 365 identity, endpoint infection, stolen device, or broader network intrusion can each require different investigation and remediation.

What Should We Do if We Sent Money Because of a Fraudulent Email?

Contact the financial institution immediately rather than waiting for the entire technical investigation to finish. The FBI also directs BEC victims to report through IC3. At the same time, activate the technical response process to determine whether an account was compromised, a vendor was compromised, the business was spoofed, or another form of impersonation was involved.

Do We Need a Forensic Expert for Every Cyber Incident?

No. The need for a digital forensic specialist depends on the circumstances, potential impact, legal or regulatory issues, cyber insurance requirements, and type of investigation needed. The response plan should establish how a forensic resource would be engaged if the situation requires one.

Who Decides Whether Customers Have to Be Notified?

That can involve legal and regulatory analysis beyond the role of the IT provider. Notification obligations may depend on applicable law, regulations, contracts, the information involved, and the results of the investigation. IT can provide the technical evidence and documentation needed by the appropriate decision makers.

Is a Cybersecurity Incident the Same as a Data Breach?

Not necessarily. A suspicious security event or confirmed security incident does not automatically establish that protected or personal information was acquired in a way that triggers legal breach notification. The facts of the incident and the applicable requirements need to be evaluated.

Does a Five Person Business Need the Same Incident Response Plan as a Large Company?

No. The plan should be proportionate to the business and reflect its actual systems, resources, risk, industry, and obligations. A small business still needs clearly established roles, contacts, technical procedures, escalation paths, and recovery plans, but those do not need to imitate a large enterprise structure.

Can I Just Download an Incident Response Plan Template?

You can use a template to identify topics and questions, but I would not consider it a finished incident response plan until it has been customized around the business's actual people, systems, vendors, insurance, responsibilities, regulatory requirements, and response procedures.

Build the Plan Before You Need It

The worst time to determine who is in charge, how to reach IT, where the cyber insurance policy is stored, who can contact a forensic specialist, what a stolen laptop could access, or how the company will work without its normal systems is while an incident is already unfolding.

That is why my approach to incident response planning starts with the business itself.

I want to understand how the company operates, which systems matter, what information it handles, who has authority to make decisions, how emergencies are escalated, what IT is responsible for, which outside parties may need to become involved, and how the company continues operating while the technical problem is being addressed.

For some businesses, that process also exposes a broader IT documentation issue. If you are not sure what systems your business depends on or who controls them, the Small Business IT Checklist and Systems Inventory and an IT Baseline Assessment can help establish the environment before we try to build detailed response runbooks around it.

If you are still trying to determine who should be responsible for IT in the first place, my guide to IT Support for Small Business explains the different ways managed IT, hourly support, specialized management, projects, and shared responsibility can work.

An incident response template can help identify the questions.

The finished plan should make sure your business already knows the answers.

ADDITIONAL RESOURCES

National Institute of Standards and Technology: Small Business Cybersecurity, Non Employer Firms, CSWP 50 Initial Public Draft, April 2026

This is NIST's newest small business cybersecurity publication and is specifically written for very small businesses and sole proprietors. The Respond and Recover material emphasizes customizing the response plan to the business and documenting contacts, responsibilities, authority, reporting requirements, recovery, and lessons learned. This document is still an Initial Public Draft, not a final standard. NIST CSWP 50

National Institute of Standards and Technology: SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management

The current final NIST incident response publication and the broader technical foundation for integrating incident response with Cybersecurity Framework 2.0.NIST SP 800-61 Revision 3

Federal Trade Commission: Cybersecurity for Small Business

FTC guidance distinguishes incident response, disaster recovery, and business continuity, and emphasizes planning and testing before an incident. FTC Cybersecurity for Small Business

Federal Trade Commission: Data Breach Response, A Guide for Business

FTC guidance addressing investigation, securing operations, preservation of evidence, forensic resources, legal counsel, communications, and notification after a breach. FTC Data Breach Response Guide

CISA: StopRansomware Guide

CISA's ransomware response guidance covers determining affected systems, isolating systems, protecting critical operations, evidence collection, and coordinated response. CISA StopRansomware Guide

Microsoft Learn: Respond to a Compromised Email Account in Microsoft 365

Microsoft's guidance was updated July 17, 2026 and covers revoking access, reviewing MFA methods, application consent, administrative roles, forwarding, hidden Inbox rules, audit information, and other areas involved in a Microsoft 365 account investigation. Microsoft Compromised Account Response Guidance

Federal Bureau of Investigation: Business Email Compromise

Current FBI guidance for identifying and responding to BEC. The FBI advises victims to contact their financial institution immediately when a fraudulent transfer has occurred and to report BEC through IC3. FBI Business Email Compromise Guidance

Federal Bureau of Investigation: 2025 Internet Crime Report

Released in 2026, the latest IC3 report includes current cybercrime and fraud trends, including the use of AI in Business Email Compromise and other scams. FBI 2025 Internet Crime Report

Maryland General Assembly: Maryland Personal Information Protection Act, Commercial Law §14-3504

Current Maryland law requires qualifying businesses to investigate certain breaches involving Maryland residents' personal information and establishes notification requirements and timeframes depending on the business's relationship to the information. Maryland Commercial Law §14-3504

Federal Trade Commission: Safeguards Rule

Covered financial institutions have specific requirements under the Safeguards Rule, including FTC notification for qualifying events involving at least 500 consumers, generally within 30 days after discovery. FTC Safeguards Rule Guidance

U.S. Department of Health and Human Services Office for Civil Rights: 2026 HIPAA Ransomware Enforcement

OCR has continued active ransomware and risk analysis enforcement in 2026, including settlements announced in April, June, and July. The July 2026 settlement included findings involving risk analysis and timely breach notification. HHS OCR July 2026 Ransomware Settlement

Defense Federal Acquisition Regulation Supplement: DFARS 252.204-7012

When this clause applies, covered contractors have specific DoD cyber incident requirements. The current clause defines rapid reporting as within 72 hours of discovery and includes requirements to preserve affected system images and relevant monitoring or packet capture data for at least 90 days after submission of the cyber incident report. DFARS 252.204-7012

Travelers: Cyber Breach Response and Incident Response Vendors

Current Travelers guidance illustrates why businesses should understand their actual cyber insurance response procedure before an incident. Travelers advises certain policyholders to report a potential claim before engaging outside vendors and describes the roles of breach counsel, forensic providers, and notification services. This is an example of one carrier's process, not a universal requirement for every cyber policy. Travelers Cyber Incident Response Guidance

Coalition: Cyber Incident Response and Panel Providers

Coalition's current 2026 guidance provides another example of an insurer coordinating breach counsel and digital forensic response providers after a policyholder reports an incident. Coalition Cyber Incident Response