Small Business Incident Response Plan: What to Prepare Before a Cyberattack

A cybersecurity incident is one of the worst times to decide who is responsible, where backups are stored, which vendor to call, or how customers should be updated.

That work should happen before the incident.

A practical small-business incident response plan does not need to be a hundred-page manual. It needs to help the right people make coordinated decisions, protect business operations, communicate clearly, and recover in a controlled way.

SMART Solutions provides Cybersecurity Protection focused on devices, access, networks, and practical risk reduction. A Network & Security Assessment can also help identify gaps that should be addressed before an emergency.

Quick answer: what should a small-business incident response plan include?

At minimum, document:

• How employees report suspicious activity
• Who leads the response and who can make urgent decisions
• IT, cybersecurity, vendor, insurance, legal, and leadership contacts
• Critical systems, accounts, data, and business dependencies
• How the business will preserve useful incident information
• Which backups exist and how recovery is prioritized
• How customers, employees, partners, and authorities are contacted when appropriate
• How the business returns systems to service safely
• How lessons learned become security improvements

NIST’s current incident-response guidance, SP 800-61 Revision 3, treats incident response as part of broader cybersecurity risk management rather than a separate emergency-only activity.

Source: NIST — Incident Response Recommendations and Considerations for Cybersecurity Risk Management.

1. Define what employees should report

Employees need a simple reporting rule.

Examples may include:

• A suspicious login alert
• A stolen laptop or phone
• Malware or ransomware warning
• Unexpected MFA prompts
• A compromised mailbox
• A fraudulent payment request
• A business application behaving abnormally
• Sensitive information sent to the wrong person
• A vendor reporting a breach that may affect your company

Not every alert becomes a major incident, but employees should not be expected to investigate alone.

Create one clear path for reporting that still works if normal email is unavailable.

2. Assign decision makers before the emergency

A technical incident can quickly become an operations, customer-service, legal, insurance, and leadership issue.

Document roles such as:

• Incident lead
• IT or cybersecurity lead
• Executive decision maker
• Communications owner
• Legal or privacy contact when appropriate
• Insurance or broker contact
• Critical vendor contacts
• Backup decision maker if the primary person is unavailable

The goal is to make responsibility clear before pressure is high.

3. Keep an independently accessible contact list

If the business’s email or cloud platform is affected, a plan stored only in that same system may be difficult to reach.

Maintain an approved emergency contact list through a separate controlled method.

Include important technology providers, internet service contacts, backup vendors, cyber insurance contacts, legal counsel when applicable, and critical application vendors.

Review the list periodically so an emergency does not begin with disconnected phone numbers and former employees.

4. Identify the systems that matter most

Incident response becomes faster when the business already understands its critical technology.

Start with the IT asset inventory and identify which assets support essential operations.

Typical priorities may include:

1. Identity and email
2. Line-of-business applications
3. Servers and storage
4. Backups
5. Accounting or payment systems
6. Customer records
7. Internet and network infrastructure
8. Phone systems
9. Website, DNS, and domain administration
10. Network-connected security systems

Priority varies by business. A dental practice, contractor, law office, and retail operation will not recover systems in the same order.

5. Plan how incident information will be preserved

A useful response record can include:

• What was first observed
• Who reported it
• Important timestamps
• Affected users or systems
• Relevant screenshots or messages
• Actions approved by the response lead
• Vendors or specialists contacted
• Business impact observed
• Recovery decisions

For serious incidents, qualified incident-response professionals, legal counsel, insurers, or law enforcement may provide additional guidance on evidence handling.

The important preparation step is to make sure the business knows who owns documentation and where it will be maintained.

6. Include identity and email incidents

Many incidents begin with an account rather than a damaged computer.

The response plan should cover common identity scenarios such as suspicious sign-ins, unexpected MFA prompts, compromised email, administrator-access concerns, or fraudulent password-reset activity.

Our password-manager rollout guide and user access review checklist explain how stronger identity practices can reduce confusion during a response.

Business email compromise should also be part of the plan because it can create payment fraud or customer impersonation without a traditional malware event.

See our business email compromise prevention guide for a dedicated prevention checklist.

7. Protect the recovery path

Backups are especially important when ransomware or destructive changes are involved.

CISA’s current ransomware guidance recommends maintaining backups and protecting the recovery path. Recovery planning should also include testing, not only successful backup-job status.

Source: CISA — #StopRansomware Guide.

Before an incident, document:

• What is backed up
• Where backups are stored
• Who is responsible for them
• How failures are reported
• When restores were last tested
• Which systems should be recovered first
• What dependencies are needed for recovery

Our business backup and recovery testing guide provides a deeper recovery checklist.

8. Prepare communications before they are needed

Cyber incidents create uncertainty.

Employees may wonder whether to keep working. Customers may experience service disruption. Vendors may need to help. Leadership may need status updates.

Prepare simple communication templates for:

• Internal employee instructions
• Customer service disruptions
• Vendor escalation
• Executive updates
• Website or phone notices when operations are affected

Do not make public claims about the cause, scope, or data impact before facts are established.

Legal, contractual, insurance, regulatory, and breach-notification obligations vary. Qualified counsel should guide notification decisions when those obligations may apply.

9. Know when outside help is needed

A small business may not have internal specialists for forensic review, legal analysis, insurance coordination, or large-scale recovery.

The plan should identify which situations trigger outside escalation.

Examples may include ransomware, suspected data theft, administrator compromise, financial fraud, loss of critical operations, a third-party breach affecting company data, or an incident with possible legal or regulatory implications.

Pre-identifying contacts is easier than searching for help while the business is already disrupted.

10. Restore carefully, not only quickly

Recovery is not complete because a device or server is powered back on.

A controlled return to service should verify that:

1. The affected systems and business impact are understood.
2. The known problem has been addressed as far as possible.
3. Important access and authentication settings have been reviewed.
4. Required updates or configuration changes are completed.
5. Recovery uses trusted data and documented priorities.
6. Applications, permissions, and business workflows are tested.
7. Monitoring is increased for signs of recurrence.

Our network monitoring guide can help businesses decide which infrastructure and security events deserve ongoing visibility after recovery.

11. Perform a post-incident review

NIST’s SP 800-61r3 emphasizes learning from incidents as part of cybersecurity risk management.

After operations stabilize, document:

• What happened
• How it was detected
• What worked
• What created delays
• Which contacts or records were missing
• Which controls limited impact
• Which recovery steps were difficult
• What should change

Then assign owners and deadlines to the improvements.

A lessons-learned meeting without follow-through does not reduce future risk.

Incident response FAQ

Does a small business really need a written incident response plan?

Yes. The plan can be concise, but documenting contacts, responsibilities, critical systems, recovery priorities, and communications reduces avoidable confusion during an emergency.

Is incident response the same as disaster recovery?

No. Incident response focuses on managing the security event. Disaster recovery focuses on restoring technology and business capabilities. The two processes should connect.

Does a backup replace an incident response plan?

No. Backups support recovery, but an incident plan also addresses decision making, communications, vendors, identity, business priorities, and safe restoration.

Can SMART Solutions help with incident readiness?

SMART Solutions can help businesses review devices, networks, access, security gaps, monitoring, and recovery-related technology through Cybersecurity Protection and a Network & Security Assessment.

Authoritative sources

• NIST — SP 800-61r3 Incident Response Recommendations
• NIST — Cybersecurity Framework 2.0
• CISA — #StopRansomware Guide

Build the plan before the alert arrives

A useful incident response plan gives the business a starting point when pressure is high.

Document the people, systems, recovery paths, communication channels, and outside contacts that matter. Test the plan with realistic scenarios, update it when technology changes, and connect it with backup, access, monitoring, and continuity practices.

For help reviewing the technology side of incident readiness, contact SMART Solutions.