Standing Up an Incident Response Program From Scratch

Standing up an incident response program from scratch is not a technology project. It's a decision-making project, and the decisions have to get made before anyone is under pressure to make them. The gap between how much risk small and mid-sized businesses face and how prepared they are to respond to it has widened sharply over the past several years, and that gap is now the central liability facing lean teams that never expected to need a security function at all.

The gap between risk and readiness is not a big-company problem

The share of companies reporting material risk of a cyberattack climbed from 65% in 2021 to 87% in 2024, according to one annual CISO survey, which puts the exposure at something close to universal. Preparedness has not kept pace. CompTIA's 2024 State of Cybersecurity report found that only 37% of US companies have incident detection and response practices in place. The shortfall concentrates at the bottom of the size distribution: the UK government's Cyber Security Breaches Survey 2025-2026 found that just 21% of micro businesses have a formal incident response plan, compared with 76% of large organizations.

That gap has a price tag. Companies without a formal, tested incident response plan paid 58% more per breach in 2024 than companies with one. The average attack costs a small business somewhere between $120,000 and $1.24 million, depending on scope and industry, and 60% of small businesses close within six months of a major cyber incident. That last figure is the one that matters most, because it reframes the entire exercise. This isn't a security question. It's a continuity question, and it belongs on the same planning shelf as fire drills and business insurance.

Brookside ENT & Hearing Center in Battle Creek, Michigan, shows what the failure mode actually looks like. Ransomware encrypted the practice's patient records, including the backups, and the attackers demanded $6,500. The two doctors who ran the practice refused to pay and found there was no recovery path left. They shut the practice down permanently. The attack itself wasn't what killed the business. What killed it was the absence of a plan: no backups isolated from the network, no pre-agreed decision framework for whether to pay, no route back to operating. Everything that follows in this piece exists to prevent that exact sequence of events from playing out somewhere else.

Speed compounds the readiness problem. The median time between initial compromise and data exfiltration fell from 9 days in 2022 to 2 days by 2024. Security teams had roughly 79 minutes to act after the first signs of an attack in 2022; a year later that window had narrowed to 62 minutes. Improvising a response in real time, inside that window, is not a strategy available to anyone. The decisions have to already be made.

What lean teams are actually defending against, the threats most likely to trigger a response

Phishing is the front door. It accounts for 33.8% of all breaches against small businesses, and the Comcast Business Cybersecurity Threat Report puts phishing's role even higher, initiating somewhere between 80% and 95% of all human-associated breaches. AI-generated phishing has made this worse in a specific, measurable way: open rates on AI-generated phishing emails run between 54% and 78%, against roughly 12% for traditional phishing attempts. The emails read better now, so people click them more, and training that worked against clumsy phishing five years ago doesn't transfer cleanly to this generation of attempts. Keepnet Labs' 2025 data found that 68% of SMB phishing breaches trace back to a single untrained employee. An incident response plan that only accounts for technical indicators and ignores the human vector is building around half the problem.

Ransomware is the severity threat, the one most likely to actually shut a business down. Verizon's 2025 Data Breach Investigations Report found ransomware involved in a large majority of SMB breaches, against 39% of large-organization breaches. That disproportion is the whole story: attackers know smaller targets have less leverage, thinner backups, and more incentive to just pay and move on. Ransomware was a factor in 44% of all data breaches in 2025, up from 32% the year before, and total recorded attacks rose sharply, from 6,395 in 2024 to 9,251 in 2025. Ransomware-as-a-service has lowered the technical bar to entry substantially, so the attacker on the other end doesn't need to be sophisticated anymore, just persistent. The FBI's guidance is not ambiguous: don't pay. Payment doesn't guarantee recovery of the data, and it funds the same criminal infrastructure that will target the next business. Response planning should center entirely on recovery from clean backups, not on negotiation. FBI reporting has flagged active variants including AKIRA, Qilin, INC./Lynx/Sinobi, and BianLian, with at least 63 new variants identified in the most recent reporting year alone.

Compromised credentials round out the picture, accounting for 22% of breaches. Phishing as an initial vector averages $4.8 million per incident, the costliest entry method of any measured. SQ Magazine's 2025 data found only a small fraction of small businesses run security training on a quarterly basis, which suggests the vulnerability here is structural rather than a series of one-off mistakes. A response plan doesn't need to anticipate every conceivable attack pattern. It needs to handle ransomware and phishing-driven credential compromise extremely well, because those two scenarios cover most of what a lean team will actually face. That's what should drive which playbooks get written and which escalation paths get built.

Choosing a framework to build from without getting lost in framework complexity

Writing an incident response plan from a blank page is slower and leaves more gaps than adapting an established framework, and it's also a harder sell to auditors, insurers, and enterprise partners asking whether a documented process exists. Frameworks solve a compliance problem too: documented IR capability aligned to NIST or ISO satisfies requirements under CMMC 2.0, NIST SP 800-171, HIPAA, and PCI DSS v4.0.

A few options exist, each suited to a different kind of organization. NIST SP 800-61r3, released in April 2025, is the primary practical reference for most organizations, and NIST CSF 2.0's February 2024 update broadened its audience explicitly beyond critical infrastructure operators to organizations of every size. It organizes response around four lifecycle phases: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. SANS offers a more granular approach, treating containment, eradication, and recovery as distinct phases rather than grouping them, better suited to organizations with more IR capacity to spend on process. ISO/IEC 27035 is a voluntary international standard substantively similar to NIST in its phased structure, and worth choosing when international compliance or an enterprise partner's requirements make ISO alignment specifically valuable. CISA's framework was built for the public sector and includes a coordination step with CISA itself, which matters for government contractors and doesn't apply much beyond that group.

For a lean team, NIST SP 800-61r3 is the sensible anchor. It's the most widely cited framework, it applies cleanly to organizations of any size, and its most recent update integrates with CSF 2.0's six functions: Govern, Identify, Protect, Detect, Respond, Recover. Its four-phase structure also happens to map directly onto the operational sections that follow here. Treat it as a checklist and a decision guide, not a document to recite for an auditor.

Defining what counts as an incident before the first alert fires

Without a written definition of what qualifies as an incident, every suspicious event turns into a debate about whether it's worth escalating, and that debate burns exactly the time a lean team doesn't have. NIST SP 800-61 treats this as a foundational requirement, not boilerplate: the IR policy has to specify, in advance, what constitutes a security incident.

Start with the distinction between an event and an incident. A security event is anything observed, most of which are noise. A security incident is something that threatens the confidentiality, integrity, or availability of data or systems. A single failed login is an event. Several failed attempts followed by a successful login from an unfamiliar IP address is an incident. That distinction alone eliminates most of the false alarms that would otherwise eat up a lean team's attention.

From there, build severity tiers. Minor incidents are contained and low-impact. Major incidents involve operational disruption or data genuinely at risk. Critical incidents mean active exfiltration or a regulatory notification threshold has been crossed. The tier assigned to an event should determine, automatically, who gets called and how fast, without requiring a fresh judgment call each time. Per NIST SP 800-61, the written policy should also specify when an incident escalates to senior leadership, an external vendor, or law enforcement; how incidents involving a third-party vendor or partner get handled, since a supply chain compromise runs through different escalation paths than an internal one; and a pre-agreed decision framework for the hardest calls, including whether the organization would ever negotiate with a ransomware operator or shut systems down entirely. Leadership needs a stance on that question decided in a calm room, not during an active attack. Regulatory notification thresholds should be built directly into the severity tiers, so a critical-tier incident automatically triggers the clock on required disclosures.

The output of this exercise should be a one-page document. Not a policy manual, not a slide deck: a page that says what an incident is, what the tiers mean, and who gets called at each tier.

Assigning roles when you don't have a security team

NIST guidance recommends that organizations without the headcount for a dedicated security team build a virtual team out of part-time staff, but give that team full authority and responsibility over incident response. That single structural choice, giving real authority to people who only do this work part of the time, closes most of the gap between a large security operations center and a five-person IT department.

The failure mode here is rarely understaffing. It's undefined authority. When nobody knows who has the standing to isolate a system or notify the CEO, the attacker gets more time while the team argues about jurisdiction.

Five functions need coverage regardless of how small the organization is. Leadership owns the call to escalate, to shut systems down, to bring in law enforcement, and to decide on ransom demands, typically the founder, COO, or the most senior operations leader in the building. Investigation needs someone technically capable of examining logs, spotting indicators of compromise, and scoping the breach, which might be an internal IT generalist or an external digital forensics and incident response (DFIR) retainer. Communications manages internal notifications and external messaging to customers, regulators, and press, and needs pre-approved templates sitting ready before anything happens, not drafted mid-crisis. Documentation records the timeline, the actions taken, and the evidence chain, which matters enormously for insurance claims and regulatory reporting later. Legal means a named contact familiar with breach notification law, not necessarily a full-time hire, but a relationship that already exists before it's needed.

Three structural models cover most organizations. Fully internal only works where real technical depth already exists, which rules it out for most lean teams. Fully outsourced, through a managed security services provider or an MDR provider, delivers round-the-clock monitoring but requires close attention to the contract terms around response time and scope. Hybrid tends to fit lean teams best: in-house generalists own leadership and communications, since they know the business, while an external DFIR retainer covers investigation and the deeper technical response.

NIST also recommends naming one team member as the designated law enforcement contact, someone who understands reporting procedures for the relevant agencies, and avoiding parallel outreach to multiple agencies at once, since jurisdictional overlap slows everything down rather than speeding it up.

One more piece of preparation gets skipped constantly: an out-of-band communication channel. If the main network is compromised, email and internal chat might be inaccessible, or worse, monitored by whoever is inside. A secondary encrypted messaging app, a pre-established call bridge, or a set of dedicated mobile devices all work. The specific tool matters less than the fact that every team member already knows to switch to it and already has credentials stored somewhere offline.

Detection and containment: the first two hours when everything is moving fast

Detection for a team without a security operations center usually comes from one of a few sources: an endpoint tool flagging anomalous behavior, an employee reporting a suspicious email or a folder full of locked files, a login from a geography nobody recognizes, or a notification from a third party. The first job is triage, not response. Confirm whether the event actually meets the incident definition written into the policy, and let the severity tier do the work of deciding urgency. Evidence collection starts here too, before any containment action, since some responses can destroy the very evidence needed later: screenshots, log exports, timestamps, all captured at first contact rather than after the fact.

Containment decisions need to happen fast, and they need a pre-assigned owner. Short-term containment usually means isolating the affected system from the network without powering it down, which preserves forensic evidence while stopping the attacker from moving laterally. Who actually has the authority to pull a machine offline, disable an account, or block an IP address? That has to be settled in advance. An undecided authority question at this exact moment is time the attacker gets to keep working.

Ransomware calls for a specific version of this response. If encrypted files start appearing, disconnect the affected systems immediately, don't attempt to decrypt anything in place, and confirm backup integrity before any recovery attempt begins.

Eradication comes after containment, and skipping straight to recovery is one of the more common mistakes lean teams make under pressure. Malicious files, persistence mechanisms, and compromised credentials all have to be removed completely, because attackers routinely leave backdoors behind. Recovering to a baseline that's still infected just restarts the incident from a worse position. This step is usually where a lean team needs outside technical help most, and it's exactly where a DFIR retainer earns its cost.

The 62-minute window from earlier is the argument for all of this being decided ahead of time. That's not enough time to draft a policy, figure out who's in charge, or locate a vendor's contract. It's only enough time to execute decisions that already exist on paper.

Communication protocols: what to say, to whom

Communication during an incident splits into two audiences that need different information at different speeds: the people inside the organization and the people outside it. Internally, employees need to know what's happened in enough detail to change their behavior, without so much detail that rumor and speculation outrun the facts. A short, factual internal notice, sent through the pre-established out-of-band channel if the primary network is compromised, does more good than silence followed by a long explanation days later.

Externally, the stakes are higher and the timelines are often set by law rather than by preference. Customers, regulators, insurers, and in some cases the press all need to hear something, and what they hear has to be accurate the first time, since walking back an early statement damages trust more than a delayed but correct one does. This is why pre-approved templates matter so much: drafting a breach notification from scratch, under legal review, during an active incident, adds hours the response timeline doesn't have. Regulatory notification obligations vary by industry and jurisdiction, but the severity tiers defined earlier should already flag which tier triggers a mandatory disclosure clock, so nobody is researching the requirement while the clock is running.

Law enforcement communication follows the plan set out earlier: one designated contact, one agency, no parallel outreach that creates jurisdictional confusion. Insurance carriers belong in this loop early too, since regulatory notification requirements may impose strict timing obligations, and finding that clause in the policy for the first time mid-incident is its own kind of failure.

The throughline across every piece of this, from defining an incident to deciding who talks to a reporter, is the same: none of it should be a first-time decision. A lean team's advantage was never going to be speed of execution under fire. It's going to be the fact that the decisions were already made, calmly, long before the alert ever fired.