How to Create a Small-Business Incident Response Plan

A cyber incident response plan sounds like something only large enterprises need. In practice, it is just as useful for small businesses, agencies, freelancers, and online stores.

If a WordPress admin account is hijacked, a staff Google account is compromised, or customer records may have been exposed, the first challenge is usually not technical. It is operational. Who decides whether this is a real incident? Who isolates affected systems? Who talks to customers, your hosting provider, or an external IT partner? What happens if your main email or chat tools are also affected?

CISA says an incident response plan should be a written document, formally approved by senior leadership, that helps an organization before, during, and after a confirmed or suspected security incident. It should clarify roles, responsibilities, and key contacts. NIST’s current guidance, published in April 2025, places incident response inside broader cybersecurity risk management, with the goal of reducing both the number and impact of incidents while improving detection, response, and recovery efficiency.

For small teams, that means one thing: decide your process before you need it.

What a small-business incident response plan should cover

You do not need a 50-page manual. A practical plan can be short, as long as it answers the right questions.

Plan section	What to define
What counts as an incident	Examples such as account compromise, malware, unauthorized access, suspicious file sharing, or possible personal data exposure
Response team	Who leads, who handles technical containment, and who manages communications
Escalation path	How staff report issues and when to escalate to decision-makers or outside support
First-hour actions	Immediate steps to confirm, contain, document, and preserve evidence
Notification workflow	Who may need updates internally, externally, and where privacy rules may apply
Recovery	How to restore systems safely and monitor for repeat compromise
Lessons learned	How the team reviews what happened and updates the plan

This structure is a practical synthesis of CISA, FTC, and NIST guidance rather than an official one-size-fits-all template.

Build a minimum viable response team

CISA recommends assigning at least three roles in advance:

Incident Manager to coordinate response and the flow of information
Tech Manager to lead technical investigation and containment
Communications Manager to handle stakeholder and external updates

In a small business, one person may hold more than one role. For example:

The owner or operations lead may act as Incident Manager.
Your in-house admin, outsourced IT provider, or managed service provider may act as Tech Manager.
A business partner, marketing lead, or office manager may handle communications.

You can also add contact details for your hosting provider, domain registrar, outside technical specialist, legal counsel, or privacy lead where applicable. CISA also recommends keeping printed copies of the plan and contact list in case normal systems are unavailable.

What to do in the first 60 minutes

The early stage of an incident is where confusion costs time. FTC guidance says businesses should move quickly to secure operations, stop additional data loss, preserve evidence, investigate scope, fix vulnerabilities, and notify the right parties. That makes a simple first-hour checklist especially valuable.

First-hour checklist

Confirm the alert. Decide whether the event is a false alarm, suspicious activity, or a likely incident.
Start an incident log. Record times, systems affected, accounts involved, and actions taken.
Escalate immediately. Notify the incident manager and technical lead using your defined process.
Contain where necessary. Isolate affected devices, websites, user accounts, or cloud sessions if doing so will reduce further damage.
Protect credentials. If accounts may be compromised, change passwords or revoke access where appropriate.
Preserve evidence. Save logs, emails, screenshots, timestamps, and system details. Do not wipe devices too early.
Switch communications if needed. If email or chat may be compromised, move to your backup channel.
Call outside help. If you rely on a hosting provider, MSP, or forensic specialist, contact them early.

Hypothetical example: a small e-commerce store notices unusual activity in a payment-related plugin. The response plan should already say who can take the site into maintenance mode, who contacts the host, who checks logs, and who prepares a plain-language update if customers may be affected.

Training matters as much as the document

A plan no one knows how to use is not much of a plan. CISA recommends training staff to report suspicious events, reviewing the plan quarterly, and running tabletop exercises. A tabletop exercise can be simple: walk the team through a scenario such as a hijacked admin account or shared client files from a compromised cloud account, then ask what each person would do first.

This is often where weak points appear. Maybe nobody knows who can disable a user account after business hours. Maybe all contacts are stored in the same cloud system that could be unavailable during the incident. Small fixes found in practice are usually cheaper than improvising during a real attack.

Philippines-specific point: incident response and breach reporting are not the same thing

This is especially important for Philippine organizations.

Under the Implementing Rules and Regulations of the Data Privacy Act of 2012, the National Privacy Commission and affected data subjects must be notified within 72 hours after knowledge of, or reasonable belief in, a personal data breach that requires notification. The IRR says notification is required when relevant personal data is reasonably believed to have been acquired by an unauthorized person and the breach is likely to create a real risk of serious harm.

That does not mean every security incident is automatically a reportable personal data breach. Your plan should therefore include a decision point: was personal data involved, and does the incident appear to meet the threshold for notification?

NPC breach reporting guidance adds useful operational detail. If a complete report is not yet possible, organizations should still submit available information, and the full report is due within five days unless the NPC grants more time. The guidance also says data subject notification is generally individual, though alternative means may be approved.

For practical planning, the takeaway is simple: technical containment and privacy assessment may need to run in parallel.

Recovery and the post-incident review

Once the immediate crisis is under control, the work is not finished. Recovery should include restoring systems safely, checking that vulnerabilities were fixed, and watching for signs of repeat access or persistence.

CISA also recommends a formal retrospective or postmortem after the incident. Ideally, this review is blameless so the team can speak openly about what worked, what failed, and what should change. Your final output from any incident should include updates to the plan, access controls, backups, monitoring, and staff training.

A simple starting point for small teams

If you have no incident response plan today, start with one page. Define your incident types, three core roles, reporting path, backup communications method, first-hour checklist, and basic notification decision process. Then test it.

The goal is not perfection. The goal is to avoid wasting the first critical hour asking who should do what.

Sources