Incident Response Plan Steps: A Practical Guide for Small Businesses

An incident response plan comes down to four steps: prepare, detect and analyze, contain and recover, then learn from what happened. Some frameworks split these into six steps (preparation, identification, containment, eradication, recovery, lessons learned), but the work is the same. What matters for a small or mid-sized business is that each step has a named owner, a written checklist and a contact list that works when email and file servers do not.

This guide walks through each step in order, shows how the four-phase and six-step models line up, and covers the details smaller companies tend to miss: evidence, communication and practice.

TL;DR

• The classic NIST model has four phases: preparation; detection and analysis; containment, eradication and recovery; post-incident activity. The six-step model splits the third phase into three.
• Most of the work happens before anything goes wrong: roles, contacts, logs, backups and a rehearsed plan.
• During an incident, verify it is real, rank its urgency, contain it, preserve evidence, and only then remove the cause and restore systems.
• Afterward, hold a blameless review and update the plan while the details are fresh.
• Review the plan at least quarterly and run a tabletop exercise so the first real test is not the real thing.

Table of Contents

• What an incident response plan is
• Four phases or six steps: how the models fit together
• Step 1: Preparation
• Step 2: Identification (detection and analysis)
• Step 3: Containment
• Step 4: Eradication
• Step 5: Recovery
• Step 6: Lessons learned (post-incident activity)
• Communications: write the first statement before you need it
• Perspective
• How Axio Networks supports each step
• FAQ
• Sources

What an incident response plan is

CISA describes an incident response plan as a written document, approved by senior leadership, that clarifies roles and responsibilities and guides an organization before, during and after a confirmed or suspected security incident (CISA, Incident Response Plan Basics). Two parts of that definition matter. It is written, so people can follow it under stress. And leadership approves it, so the person who has to shut down the accounting system at 2 a.m. has the authority to do so.

A plan is different from a policy and from a runbook. The policy says you will respond to incidents. The plan says who does what. Runbooks are the detailed technical procedures for specific scenarios, such as a ransomware infection or a compromised email account.

Four phases or six steps: how the models fit together

Search results show both models, and readers often wonder which one is right. Both are. NIST’s traditional model has four phases and is cyclical, so lessons learned feed back into preparation. SANS uses six steps, which separate the pieces NIST groups together (Canadian Centre for Cyber Security).

For a company without a security team, the six-step version is often easier to turn into a checklist because containment, eradication and recovery are different jobs, often done by different people. The rest of this guide uses the six steps, with the NIST phase noted for each.

Step 1: Preparation

Preparation is the longest step and the only one you can finish before the pressure starts. CISA’s guidance lists the actions to take before an incident: train staff, review the plan with an attorney, meet local law enforcement, print the plan and contact list, develop a staffing and stakeholder plan, review the plan quarterly, prepare press responses, select an outside technical resource, and run a tabletop exercise (CISA).

Turn that list into concrete deliverables:

• Roles. Name an incident lead, a technical lead, a communications lead and an executive decision-maker, each with a backup. In a 40-person company one person may hold two roles. That is fine as long as it is written down.
• Contact list, on paper. Include your outside IT provider, your attorney, your cyber insurance carrier, your bank, and key staff cell numbers. Print it. If ransomware takes down your file server, the digital copy of the plan may be locked too.
• Critical assets. The Secret Service advises deciding which data, assets and services deserve the greatest protection and prioritizing security effort on mission-critical needs (U.S. Secret Service). For most businesses that means email, the line-of-business application, customer records, payroll and backups.
• Staff awareness. NIST advises telling staff how to recognize common attacks and how to report suspicious activity (NIST CSF 2.0 Small Business Quick-Start Guide). A one-line reporting path, such as a shared mailbox or a phone number, beats a long policy nobody remembers.
• An outside technical resource. Decide before the incident who you will call for forensics and recovery. Negotiating a contract during an outage costs hours.

Get logs and network information in order

Evidence preservation starts before an incident is detected, according to the Secret Service, which says procedures for preserving logs and data should be set up in advance. It also recommends keeping server logs (firewall, event, Active Directory) for at least one year and maintaining an up-to-date network map to speed identification and investigation (U.S. Secret Service).

Many small businesses discover during an incident that logs only go back a few days, or that nobody knows which devices are on the network. If you run an online store, the stakes are higher because customer payment and account data sit on the same systems you are trying to protect. A short read on cybersecurity for e-commerce businesses shows why this groundwork pays off.

Back up in a way that survives an attack

Recovery depends on backups that the attacker could not reach. Keep at least one copy offline or otherwise isolated, and test restores on a schedule. Our guide to building a data backup and disaster recovery plan covers the details, and the difference between backup and disaster recovery explains why you need both.

Practice with a tabletop exercise

A tabletop exercise is a discussion-based simulation: someone reads a scenario (“Monday morning, every file has a new extension and a ransom note”), and the team talks through what it would do. CISA recommends reviewing the plan quarterly and running an attack simulation, though it does not set how often to run exercises (CISA). Many small businesses start with one exercise a year and add more once the plan matures.

Step 2: Identification (detection and analysis)

Incidents are found by automated tools or by reports from people, inside or outside the organization: an employee who clicked a strange link, a customer who got a odd invoice, a vendor who noticed unusual logins. The Canadian Centre for Cyber Security advises verifying that the alert is a true positive, analyzing the incident’s type, origin and extent of damage, and classifying its urgency to triage the response (Canadian Centre for Cyber Security).

In practice, ask five questions quickly and write down the answers with timestamps:

1. What exactly was seen, by whom, and when?
2. Which systems, accounts and data are involved?
3. Is it still happening?
4. How severe is it, using the levels defined in your plan?
5. Who has to be told, and by when?

NIST’s small business guidance adds that organizations should assess severity, what happened and the root cause, and list the communication and reporting duties set by laws, regulations, contracts or policies (NIST). That last point is where attorneys earn their fee: breach-notification rules, client contracts and insurance policies can each carry their own deadlines, and the plan should say who checks them.

A simple severity scale

Pick a scale your team can apply in a minute. For example:

The levels are illustrative. Adjust them to your business, then put them in the plan.

Continuous monitoring shortens this step. Around-the-clock SOC monitoring and managed detection and response puts analysts on alerts when nobody in your office is awake, and endpoint detection and response shows what a threat did on a specific device.

Step 3: Containment

Containment stops the incident from spreading while you keep the evidence intact. Typical short-term actions include isolating affected devices from the network, disabling compromised accounts, blocking malicious addresses and, when needed, taking a system offline.

Two cautions apply:

• Isolate, do not wipe. Pulling a network cable or using your endpoint tool’s isolation function stops spread. Reimaging the machine destroys what an investigator needs.
• Keep a log of every action. Record who did what and when. It protects you in later insurance and legal conversations.

Preserve evidence while you contain

CISA’s federal response playbooks advise collecting data from the perimeter, the internal network and the endpoint, including audit, transaction, intrusion, connection and user activity logs, and capturing a memory and disk image when an endpoint needs forensic analysis (CISA incident and vulnerability response playbooks). Those playbooks are written for federal agencies, but the principle scales down: capture before you change. For a small business, that usually means your outside technical resource images the affected machine and exports the relevant logs before anyone starts cleaning.

If the incident may be criminal, such as fraud, extortion or theft of data, the Secret Service page above is a good starting point for how to engage law enforcement, and your attorney should be part of that decision.

Step 4: Eradication

Eradication removes the cause, not just the symptoms. That can mean deleting malware, closing the vulnerability that let the attacker in, removing unauthorized accounts and forwarding rules, and resetting every credential the attacker could have touched.

The common mistake is declaring victory after the first cleanup. If you do not know how the attacker got in, they may be back tomorrow. Identify the root cause, whether a phished password without multi-factor authentication, an unpatched server or an exposed remote desktop port, and fix it before restoring.

After a ransomware or malware event, a specialist malware and ransomware recovery engagement can confirm the environment is clean before you bring it back online.

Step 5: Recovery

Recovery restores affected systems and returns them to normal operation. The Canadian Centre for Cyber Security advises making sure malware is removed before restoring from backups, then testing, verifying, monitoring and validating the restored systems (Canadian Centre for Cyber Security).

A sensible order:

1. Restore the most critical systems first, using the priority list from your preparation step.
2. Restore from a backup taken before the compromise, and confirm it is clean.
3. Change passwords and tokens before reconnecting systems.
4. Watch the restored systems closely for several days for signs of the attacker returning.
5. Tell staff and customers what is working again and what is not.

How quickly you can do this depends on how well you prepared. Businesses with tested backup and disaster recovery can usually decide to restore instead of negotiating, and that is a better position than any alternative.

Step 6: Lessons learned (post-incident activity)

The last step is the one most often skipped, because everyone is tired and wants to get back to work. CISA advises a blameless retrospective: review the known timeline and response, identify improvements, update policies and procedures, and communicate findings to staff (CISA).

Hold the review within a couple of weeks while memories are fresh. Questions worth asking:

• How did we find out, and could we have found out sooner?
• Which step of the plan worked, and which one did we ignore or improvise?
• Was the contact list correct? Did people have the authority they needed?
• What single change would have most reduced the damage?

Then change the plan, assign each fix an owner and a due date, and loop back to step one. This is the cyclical nature of the NIST model in practice.

Communications: write the first statement before you need it

CISA advises preparing press responses in advance, including a “holding statement” (CISA). A holding statement is a few sentences saying you are aware of an issue, you are investigating and you will share more when you can. Draft versions for customers, employees and the press, and have your attorney review them. Decide who is allowed to speak, and tell everyone else to refer questions to that person.

Perspective

We see the same pattern in the Phoenix-area businesses we support: the companies that recover fastest are not the ones with the thickest binder. They are the ones where someone has already answered three questions. Who makes the call? Which systems come back first? Who do we phone?

That is why we build security into every service we deliver instead of treating incident response as a separate product. Monitoring, endpoint protection, backups and a plan are parts of one system. If the pieces are bought from different vendors, the gaps between them are where incidents get worse.

A flat monthly fee matters here too. When response and recovery work is already part of the agreement, nobody hesitates to call at the first sign of trouble because of what the call might cost. We aim to respond in under 30 minutes on average, and a local team means we know your office, your network and your people before the bad day arrives.

Jim O’Connell

How Axio Networks supports each step

If you do not have an in-house IT team, you do not need to build all of this alone. Axio Networks provides managed IT services with security designed in, plus cybersecurity services that cover monitoring, endpoint and email protection, risk and vulnerability assessments and security awareness training for small and mid-sized businesses in the Phoenix metro area. Our services are offered on fixed monthly pricing, so the cost of preparation is known up front.

To see where your plan stands today, contact our team through the Axio Networks site and ask for a review of your current response readiness.

FAQ

How many steps are in an incident response plan?

The NIST model has four phases, and the SANS model has six steps. Both cover the same work: preparation, detection and analysis, containment, eradication, recovery, and a post-incident review. Choose the one your team finds easiest to follow and use it consistently.

What is the difference between the incident response process and the lifecycle?

In most guides the terms are used interchangeably. The lifecycle emphasizes that the steps form a loop, because lessons learned feed back into preparation. The process is the same set of steps seen as a sequence of tasks during one incident.

How often should we review our incident response plan?

CISA advises reviewing the plan quarterly and conducting a tabletop exercise, though it does not set a frequency for exercises. Also update the plan after any real incident, and whenever you change key systems, vendors or staff in critical roles.

Do we need an attorney involved in the plan?

CISA advises reviewing the plan with an attorney. Counsel can check notification duties under laws and contracts, and can direct the investigation in a way that helps protect privileged communications. Name your attorney in the contact list before you need one.

Sources

• CISA: Incident Response Plan (IRP) Basics
• Canadian Centre for Cyber Security: Improving cyber security resilience through emergency preparedness planning
• U.S. Secret Service: Preparing for a Cyber Incident
• NIST SP 1300: Cybersecurity Framework 2.0 Small Business Quick-Start Guide
• CISA: Cybersecurity Incident and Vulnerability Response Playbooks
• 7 Key Reasons Cybersecurity Matters for E-Commerce Success

Recommended

• What to Do in Case of a Cyberattack (Step by Step)
• Ransomware Recovery Plan: 5 Steps IT Leaders Need in the First Hour