Incident Response Plan for Small Business: A Working Guide

Most small organisations meet their first serious incident without a plan, and the first hour goes on finding phone numbers. An incident response plan for small business fixes that. It does not need to be long. It needs to say who leads, who decides, who to call, which records exist and what to do first.

This guide builds that plan from free public sources: NIST's 2025 revision of its incident response guide, the UK NCSC's small business guidance and CISA's advice for small firms. Log retention figures come from Microsoft's and Google's own documentation. It is written for in-house IT staff and for the providers who run security for several small clients.

What NIST SP 800-61 Rev. 3 changed

NIST published SP 800-61 Rev. 3 in April 2025. Its full title is "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile". It supersedes Revision 2, the 2012 Computer Security Incident Handling Guide that many older plans still cite.

The new edition is much lighter on procedure. Its scope section says detailed how-to material changes so often that "it is no longer feasible to capture and maintain that information in a single static publication". Instead it points readers to an online project page and to NIST's reference tool, which maps each outcome to other standards.

The document itself has three main sections. Section 1 defines terms. Section 2 covers the life cycle, roles and policies. Section 3 is the Community Profile, split into two tables: one for preparation and lessons learned, one for incident response.

Each row in those tables is a CSF 2.0 outcome with a priority of High, Medium or Low. Beneath it sit numbered items marked R for recommendation, C for consideration and N for note. An identifier such as RS.MA-01.C1 therefore points at one specific piece of advice.

The biggest change is the life cycle. The 2012 model was a circle of four phases. NIST now says that model suited a time when response "was usually completed within a day or two", whereas recovery today "often takes weeks or months".

In the new model, Govern, Identify and Protect are preparation. NIST says they are "not part of the incident response itself" but support it. Detect, Respond and Recover are the response. Lessons feed the Improvement category, ID.IM, at any point, rather than waiting for a review at the end.

NIST does not insist on its own model. The executive summary says organisations "should use the incident response life cycle framework or model that suits them best". A small firm can keep a four-step plan, provided preparation and lessons learned are not treated as optional. The CSF 2.0 link also ties the plan to the security frameworks a small business can adopt.

What an incident response plan for small business must cover

NIST separates the policy from the plan and its procedures. Section 2.3 lists what most incident response policies contain:

• A statement of management commitment.
• Purpose, objectives and scope.
• Definitions of event, incident and related terms.
• Roles, responsibilities and authorities, "such as which roles have the authority to confiscate, disconnect, or shut down technology assets".
• Guidelines for prioritising incidents and estimating severity.
• Performance measures.

For a ten-person firm these can sit on one page above the plan. The authority line matters most. If nobody is named as allowed to take the accounts system offline, that decision waits for whoever can be reached.

The NCSC's Small Business Guide: Response & Recovery is written for organisations of this size. It defines an incident as "unauthorised access (or attempted access)" to IT systems, and counts accidents such as fire, flood or theft. Its first step, preparing for incidents, asks you to identify critical information, systems and processes, and record where each is stored.

The same step asks for "trigger points": the moments when ownership of a decision passes from one person to another, and when senior management steps in. CISA's cyber guidance for small businesses adds that the plan should involve "leaders from across the organization, not just the security and IT functions". It gives the chief executive the job of approving it.

NIST also asks for written procedures for the most common incident types. A small firm's list will often start with a compromised mailbox, ransomware on a laptop or file server, and a fraudulent payment request. NIST adds procedures for urgent rebuilds, giving the example of "redeploying the organization's primary authentication platform".

Roles, deputies and the contact sheet

NIST's section 2.2 lists eight kinds of role: leadership, incident handlers, technology professionals, legal, public affairs and media relations, human resources, physical security and facilities, and asset owners. In a small organisation one person may hold three of them. What matters is that each is written down.

Incident handlers, in NIST's words, can be "on staff", "on contract" (for example an outsourced security operations centre) or "available when needed" from a provider or partner. Many organisations mix these. The profile also suggests naming an incident lead for each incident, so one person owns the log and the routine decisions.

The last column is a suggestion; fit it to your own staff. The NCSC asks for each responsibility to be shared with a second person, so cover exists when someone is away. CISA asks for "an address book for use should the network be down during an incident". Both point at the same failure: contact details that live only in the mailbox under attack.

Per the NCSC's first step, the contact sheet should list web hosts, IT support and cloud providers, with what each contract covers. It should also list key customers and suppliers by incident type, and the insurer with its policy number. The NCSC suggests checking these lists every couple of months. Keep one printed copy and one on a phone that does not depend on company accounts.

Which logs to keep, and for how long

Logs answer the questions every incident raises: who signed in, from where, and what they did. The NCSC's introduction to logging calls logging "the foundation on which security monitoring and situational awareness are built". It recommends holding logs that answer those questions "for a minimum of 6 months", synchronised to an accurate clock and protected from tampering.

The cloud services a small firm runs on set their own defaults, and these vary by licence.

Microsoft's auditing overview says Audit (Standard) is on by default and keeps records for 180 days. That figure rose from 90 days for logs generated on or after 17 October 2023. The Purview service description lists Audit (Standard) in Business Basic, Standard and Premium. It lists Audit (Premium) in the E5 plans and in a Purview Suite add-on for Business Premium.

Retention follows the user, not the tenant. Microsoft's retention policy page says the one-year default applies only to activity by users with an E5-level licence. Records for other users and for guests stay for 180 days.

The shortest window is in identity. Microsoft Entra data retention gives seven days for sign-in logs on the free tier and 30 days on P1 or P2. Microsoft notes these logs are separate from the unified audit log, and that upgrading does not bring back expired data. Routing them to an Azure storage account through Azure Monitor keeps them longer.

Google's data retention page gives six months for most audit events. It adds that administrators "cannot delete log event data or change the length of time". Set against the NCSC's six-month minimum, Microsoft's 180 days roughly fits. Entra sign-in logs do not, which is a reason to export them before they are needed.

Detection sources a small team already has

Few small firms run a security operations centre. Most already have alerting built into the services they pay for, and the plan should say who reads it.

Microsoft's default alert policies include several aimed at account takeover:

• User restricted from sending email (High), listed for Business Basic, Standard and Premium.
• Suspicious email forwarding activity (High).
• Suspicious email sending patterns detected (Medium).
• Creation of forwarding/redirect rule (Informational).
• Elevation of Exchange admin privilege (Low).

Microsoft's table lists the last four against its Enterprise plans and does not name the Business plans beside them. Check the Alert policy page in your own tenant to see which are active.

Other sources a small team can name in its plan:

• Endpoint protection alerts on laptops and servers; see endpoint security for small businesses.
• Risky sign-in reports and multi-factor prompts a user did not start; see multi-factor authentication for small businesses.
• Phishing reports from staff, and mail authentication reports; see the business email security guide.
• Calls from customers or suppliers about odd invoices or messages.

NIST's profile notes that a service provider "may detect malicious activity sooner" because it can correlate events across customers. That only helps if the provider's alerts reach a named person, not a shared inbox nobody owns.

Patching sits upstream of the plan

Many incidents start with a flaw that was already known and already fixed. Prioritising patches belongs to NIST's preparation Functions, not to the response itself, so it gets a short section here.

CISA's Known Exploited Vulnerabilities (KEV) catalog is the shortest free answer to what to patch first. Its due dates bind US federal civilian agencies only, but the list works for anyone. How small IT teams can use the CISA KEV catalog sets out a weekly routine. One of its steps links straight back to this plan: if a matched system was exposed before the fix, check it for compromise before closing the ticket.

The first hours: contain, preserve, communicate

NIST describes containment as "preventing the expansion of an incident" and notes that "most incidents require some form of containment". In the first hour, a small team has jobs that pull against each other. It must stop the spread, keep the evidence and tell the right people.

Contain. For a compromised Microsoft 365 mailbox, Microsoft's response guide gives an order. Disable the account if you can; otherwise reset the password, and do not send the new one by email. Then revoke active sessions, remove unknown multi-factor methods, and review consented apps, admin roles, forwarding and inbox rules, including hidden ones. For a device, NIST gives the example of moving a compromised endpoint to an isolated network.

Preserve. NIST accepts that formal chain-of-custody handling "might not be performed for every incident", noting that most malware cases never reach court. It still treats collected data as evidence. In practice, export the relevant audit and sign-in logs before they age out. Photograph ransom notes, and do not wipe a machine until someone has decided whether it needs imaging.

Record. NIST says actions can be recorded by means as simple as "a paper logbook". Write down every action with the time and the person who took it. Insurers, police and regulators may all ask for that timeline later.

Communicate. Tell people through a channel the attacker cannot read. If the mailbox or chat system is in doubt, use phones and the printed contact sheet. NIST's RS.CO-02 says notifications should follow procedures that set "what must be reported to whom and at what times".

Notification law sets hard clocks, some measured in hours. They are covered in data breach notification deadlines by jurisdiction. The plan only needs to name who decides when the organisation became aware, because that is when the clock usually starts.

Before restoring, NIST asks you to check backups for "indicators of compromise, file corruption, and other integrity issues". Restoring a backup that carries the same malware restarts the incident. The small business backup strategy guide covers how to keep a copy an attacker cannot reach.

When to call insurers, responders and the police

Write the triggers into the plan in advance. NIST says law enforcement and regulators should be notified "based on criteria in the incident response plan and management approval". Without criteria, the decision gets made under pressure.

Cyber insurer. The NCSC's cyber insurance guidance says some insurers "may put your organisation in touch with a Cyber Incident Response (CIR) organisation", with forensic, legal and public relations help. Read your policy's notification steps before you need them. The NCSC is plain that insurance "will not instantly solve all of your cyber security issues".

Outside responders. NIST's profile advises contacting your incident response service provider "if appropriate". Reasonable triggers are an incident beyond your staff's skills, many systems affected at once, or evidence that may be needed in court. If an insurer is involved, ask early whether it expects you to use a firm it chooses.

Police in the UK. The NCSC's small business guide says that during a live attack you should "call 0300 123 2040 immediately". The line runs around the clock, and reports pass to the Report Fraud Analysis Service, which may refer them to a police force. For a significant attack, the NCSC asks organisations to report to it first, through report.ncsc.gov.uk. Report Fraud is the service that replaced Action Fraud from 4 December 2025, so update older plans that still name Action Fraud.

Police and the FBI in the US. The FBI's Internet Crime Complaint Center accepts complaints from "anyone who believes they are affected by a cyber-enabled crime". Its FAQ says it "does not conduct investigations" and that time-sensitive matters should go to local police. For business email compromise, its BEC page puts the bank first: "Contact the originating Financial Institution as soon as fraud is recognized" and ask for a recall. Then file a detailed complaint. CISA's small business guidance links to its own reporting form and says reporting can bring assistance.

Rehearsing with a tabletop exercise

A plan nobody has read tends to fail on first use. NIST rates exercises as a high priority, saying they "prepare staff and involved third parties" for real incidents. A tabletop exercise is the cheapest form: people around a table talk through a scenario, step by step.

The NCSC's Exercise in a Box is "completely free" and lists small and medium-sized enterprises among its users. It says "you don't have to be an expert to use it". It offers short micro exercises and longer tabletop exercises, 20 in all across 12 topics, including ransomware, phishing and supply chain.

CISA's tabletop exercise packages are aimed at a wider audience but include ransomware, insider threat and phishing scenarios. Each package is "customizable", with objectives, discussion questions and an after-action report template. CISA says they are designed to help organisations run "their own exercises".

CISA's small business guidance suggests quarterly tabletop exercises and a plan review "quarterly and after every security incident or 'near miss'". If that pace is out of reach, set a fixed date at least once a year and keep it. CISA also says to "invoke the IRP even when you suspect a false alarm", which doubles as practice.

Invite the IT provider and anyone else on the contact sheet. NIST's profile names exercises run with suppliers and third parties as a source of improvement. The NCSC's larger incident management collection makes the same point more broadly: "only one thing can help you deal well with a cyber incident - good preparation".

Splitting the work with a managed service provider

Many small organisations outsource IT, and with it much of the response. NIST calls this "a shared responsibility model" and says responsibilities "should be clearly defined in a contract". That includes the provider's "authority to act on behalf of the organization". NIST also warns that providers "often have privileged access", so a compromised provider is a risk in its own right.

The NCSC's guidance on choosing a managed service provider, published in November 2025, turns this into questions. A provider should have "clear steps on how they will respond to any incidents and how they will engage with you". The contract should "specify how and when security incidents are notified", including incidents at the provider itself.

What a provider covers varies by contract, so no single split is standard. Whatever the contract says, NIST places high-impact calls, such as shutting down or rebuilding critical services, with leadership. The provider can advise; the owner decides.

A one-page plan outline

The outline below fits on one side of paper. Each line maps to a source quoted above.

1. Scope and authority. What counts as an incident, and who may disconnect or shut down systems.
2. Roles and deputies. Incident lead, decision-maker, technical responder, communications and legal, with a second name for each.
3. Contact sheet. IT provider, cloud and web hosts, insurer and policy number, bank fraud line, key customers and suppliers, and the police or IC3 route. Printed and kept off the network.
4. Critical systems and data. What they are and where they live.
5. Detection. Which alerts exist and who reads them.
6. Logs. What is kept, for how long, and where exports go.
7. First-hour actions. Contain, preserve, record and communicate, for the three most likely incidents.
8. Escalation triggers. When to call the insurer, outside responders, police and regulators.
9. Recovery. Where backups are, the integrity check before any restore, and who signs off.
10. Review. Exercise date, review after every incident or near miss, and the document's owner.

More on running security day to day is collected under security operations. How these sources were read, and what a desk-research label means, is set out on the methodology page.