IR Program Maturity Models for SMB Client Portfolios

Small and midsize businesses aren't just getting hit by ransomware at the same rate as large enterprises; they're getting hit far more. The 2025 Verizon Data Breach Investigations Report, drawing on more than 22,000 incidents and 12,195 confirmed breaches, found ransomware present in 88% of SMB breaches, compared to 39% at large enterprises. That gap is the whole story. This piece walks through a maturity model built for lean teams, tier by tier, and what it actually takes to climb from one level to the next.

The reason the gap exists is structural, not moral. According to Guardz's 2025 SMB Cybersecurity Report, 52% of SMBs still rely on an untrained internal staff member or the business owner to manage security. In a third of cases, it's the owner personally fielding the alerts. There's no dedicated security headcount, no incident response team, no on-call rotation to fall back on. The instinct-based response that gets a ten-person shop through a phishing scare starts to fail at forty employees, and it fails badly during an actual ransomware event, one of the reasons more than 60% of SMBs find themselves temporarily unable to operate after an attack. A maturity model isn't paperwork for its own sake. It's the mechanism that moves an organization from "whoever picks up the phone handles it" to a process that works no matter who's on shift.

The confidence-readiness gap that makes self-assessment unreliable

Start with a number that should trouble anyone reading it closely. Devolutions' State of IT Security Report 2025 found that 71% of SMBs feel confident handling a major incident, yet only 22% report having an advanced security posture. Confident, in this context, is doing a lot of work for a group where three-quarters have no incident response plan at all.

The trend line makes it worse, not better. Per Swif.ai's SMB Cybersecurity Statistics, only 38.4% of small business leaders felt very prepared for a cyberattack in 2025, down from 56.5% the year before. That's a steep drop in a single year. And yet, confidence in handling incidents stayed high even as preparedness fell, which tells you the two numbers aren't measuring the same thing. Meanwhile, MFA adoption, about as basic a control as exists, actually declined from 33.6% in 2024 to 27.2% in 2025. Confidence went one direction. Actual control implementation went the other.

The lesson here isn't subtle: self-reported readiness is not a usable proxy for incident response capability. Organizations need an external yardstick, something observable and structured, rather than a gut feeling about how the team would perform under pressure. That's precisely the gap a maturity model closes. It replaces "we think we're okay" with a description of where an organization actually sits, tier by tier, and what evidence supports that placement.

Before any of that is useful, though, it helps to know which frameworks exist and which of them were actually built with a five-person IT team in mind.

What the standard frameworks were built for — and where they leave SMBs short

NIST SP 800-61 Revision 3, released in April 2025, is now the operative standard. NIST withdrew Revision 2 entirely and rebuilt the guidance around CSF 2.0's six functions: Govern, Identify, Protect, Detect, Respond, Recover. The key change in Rev 3 is philosophical as much as structural. Incident response stops being a standalone four-phase lifecycle that starts when something goes wrong and ends when it's fixed. Instead, it becomes an ongoing practice woven through the whole security program, a matter of continuous learning rather than event-triggered scrambling.

For a lean team, that shift sounds bigger than it needs to feel. Most SMBs can keep running their existing four-phase playbooks and simply map the language onto CSF 2.0's categories for governance and compliance documentation. The operational logic underneath doesn't change. Rev 3 also recommends formatting procedures into playbooks, pointing to examples like CISA's Cybersecurity Incident and Vulnerability Response Playbook, so that response is reproducible regardless of who's running it. That's useful direction even for a two-person IT department working off a laptop.

The academic record backs up what practitioners already sense. A 2026 systematic literature review identified a final set of eight incident response maturity models published between 2013 and 2025, most built on staged, capability-maturity-model structures influenced by ISO/IEC 27035 and NIST SP 800-61. The same review found that existing models offer little explicit support for small and midsize organizations, and even less help translating an assessment score into a prioritized list of what to fix first. That's not a hunch; it's a documented gap in the literature itself. The review flagged specific capabilities left underaddressed across the board: coordination between organizations, automation-enabled response, dynamic threat intelligence, and improvement roadmaps that go beyond a scorecard.

ENISA's SME Cyber Resilience Maturity Assessment Model, published in July 2026, adds sharper detail. Surveying 194 organizations across 31 countries, the study found company size was the single strongest predictor of readiness: medium-sized firms scored a full point higher than microenterprises across every domain measured. Incident response and product lifecycle management came out as the weakest areas overall, and the smallest respondents fared worst of all. That confirms something specific: the deficit is in incident response capability itself, not general security awareness.

The frameworks aren't broken. They're just incomplete for this audience, and the adaptation work, tier by tier, is what the rest of this piece supplies.

The financial case for moving up the maturity curve

Unpreparedness has a price tag, and it's a specific one. Among the 75% of SMBs without an incident response plan, the average breach lifecycle runs 258 days, versus 189 days for organizations that have one. That's 69 extra days of active exposure, every one of them a day attackers can keep moving through the network.

The 2024 IBM Cost of a Data Breach Report found that organizations with a regularly tested incident response plan contained breaches an average of 54 days faster than those without one. Speed translates directly into cost. The same report found that mature incident response programs had breach costs averaging $1.49 million lower than organizations still in early IR development. Companies with structured, tested response protocols paid 58% less per breach overall. Guardz's 2025 report adds a cleaner way to say the same thing: 80% of SMBs with a formal incident response plan avoided major damage during an attack. Preparedness, not attacker sophistication, is the variable doing most of the work in that outcome.

Set the investment against that backdrop. Structured managed protection for an SMB typically costs somewhere between $5 and $30 per user per month. The average small business breach, meanwhile, cost $164,000 in direct losses in 2025. Only 34% of SMB owners have a formal incident response or continuity plan built with a cybersecurity professional, and 27% carry no cyber insurance at all, two exposures that compound each other. A scoping review published in ScienceDirect noted that cyber insurance is particularly valuable at lower maturity tiers, where internal capability is thin and the insurer's resources fill a real gap.

With the return on investment established, the operative question becomes simple: where is a given organization right now, and what does it take to move up one level?

Tier 0 to Tier 1: getting off zero with a plan that exists on paper

Tier 0 is the default state for most SMBs, and it's worth describing plainly. There's no documented plan. Response quality depends entirely on who happens to be reachable that day, and the business owner is the incident responder by default, whether or not that was ever the intention. Given that 75% of SMBs have no incident response plan, this isn't an edge case. It's the starting point for most of the market.

Tier 1 doesn't require much, but it requires the right things. A written policy needs to name who's responsible for what, even if "the team" is two people wearing four hats. There should be a defined escalation path: who gets called first, second, third, and at what hour of the night that stops mattering. A contact list needs to sit somewhere accessible, covering legal counsel, the cyber insurer, any external incident response support, and key vendors. And there needs to be, at minimum, a phishing and ransomware response checklist, not a full playbook, just a decision tree that exists before the event starts rather than getting written during it. This lines up with what NIST Rev 3 recommends about formatting procedures for reproducibility; a one-page checklist satisfies that spirit just fine.

A few mistakes show up again and again at this stage. Plans get written to satisfy a compliance checkbox and then get filed somewhere nobody can find during an actual incident. Roles get assigned to people who were never told they had them. And notification requirements from the cyber insurer get left out entirely, which matters more than it sounds: late notification can void coverage outright.

None of this needs to be long. A two-to-three page document is enough to move an organization from Tier 0 to Tier 1. The goal is existence and accessibility, not comprehensiveness. Tabletop exercises, dedicated tooling, external retainers, all of that comes later. Tier 1 just needs to get something real onto paper.

Tier 1 to Tier 2: making the plan real through testing and role clarity

A plan nobody has run through is a hypothesis, not a capability. Data from buildingsecurity.com puts the number of organizations that regularly test their incident response plan at just 30%. Most discover the gaps in their plan for the first time during a real emergency, which is the worst possible moment to learn that the "backup" contact hasn't worked there in a year.

Tier 2 means testing that hypothesis. At minimum, this looks like one tabletop exercise per year, a discussion-format walkthrough of a simulated incident that doesn't require anyone to actually execute technical steps. Tabletops are useful precisely because they surface the three things that fail most often in a real incident: plan logic that doesn't hold up, confusion about who owns which decision, and communication procedures that break down under pressure. Roles need named backups, too. What happens when the one person who "handles security" is on a plane? Basic scenario-specific playbooks matter here as well, phishing and ransomware at minimum, given that ransomware shows up in 88% of SMB breaches. After every exercise, even a short one, someone should write down what didn't work.

None of this needs to be elaborate. A realistic phishing-to-credential-compromise scenario is plenty for a first exercise, and a 90-minute session is the right scale; full-day simulations are an enterprise habit that doesn't fit a five-person operations team. Bringing in outside facilitation, from an MSSP or an IR consultant, often surfaces blind spots the internal team simply can't see from inside its own process.

What changes at Tier 2 is subtle but real: the organization stops discovering its own gaps for the first time mid-incident. And the signal that it's time to move to Tier 3 usually shows up in the tabletop itself, when the exercise reveals detection and escalation gaps that no checklist can close on its own. At that point, tooling and outside coverage become the actual bottleneck.

Tier 2 to Tier 3: adding detection capability and external coverage

Tier 3 is where tooling stops being optional. Endpoint detection and response, EDR, is the baseline; managed detection and response, MDR, becomes necessary for any organization without genuine 24/7 internal coverage. Escalation paths need to tie to actual detection events rather than staying theoretical: when EDR fires a specific alert, a specific person does a specific thing within a specific window. An external incident response retainer needs to be in place before anything happens, since negotiating retainer terms during an active ransomware event is not something any organization wants to attempt.

Access control matters here too. More than half of SMBs, 52%, still manage privileged access manually, through spreadsheets, shared vaults, or no system at all. Privileged access management at Tier 3 removes one of the biggest enablers of lateral movement once an attacker is already inside. Identity protection also needs to connect with device management directly, treating CSF 2.0's Protect and Respond functions as interdependent rather than sequential steps. A scoping review published in ScienceDirect flagged this exact point: Protect and Respond are equally critical under CSF 2.0, but very few organizations, even at the SME level, manage to build both at once. Tier 3 is the stage where that gap actually gets closed.

The cost math still holds here. Managed protection running $5 to $30 per user per month is the layer that shifts breach economics in an organization's favor, the same layer behind that $1.49 million cost difference IBM found between mature and immature IR programs.

Platform sprawl works against all of this. A fragmented stack, separate MDR, a separate identity tool, a separate compliance tracker, creates alert routing problems and coverage gaps that undercut everything Tier 3 is trying to build. Consolidated platforms that combine device management, endpoint security, and identity protection in one console cut down the coordination overhead a lean team simply doesn't have the staff to absorb. Platforms built for lean teams, like Zip, deploy a full security program without requiring dedicated in-house expertise to stand it up. Deployment speed matters too: a platform that takes two months to configure delays Tier 3 by two months, while options built for two-week deployment get an organization to that state faster.

NIST SP 800-61 Rev 3 has become the de facto benchmark cyber insurers and regulators use to judge IR maturity, so alignment with CSF 2.0 documentation at this tier does double duty, strengthening both insurance negotiations and compliance posture. What Tier 3 looks like in practice: a ransomware alert fires at two in the morning on a Saturday, and a defined process runs, not because someone happened to be awake, but because the coverage and escalation paths were built to work without anyone being awake.

Tier 4: continuous improvement as an operational habit, not a project

Tier 4 isn't a finish line. It's a habit, and the thing that separates it from Tier 3 is that improvement becomes systematic instead of reactive.

Every significant incident gets a structured post-incident review, one that produces written action items rather than a hallway conversation that everyone forgets by Monday. Tabletop scenarios get rewritten to reflect real incidents and emerging threats, instead of running the same phishing script every year out of habit. Threat intelligence gets folded in too, tracking which attack patterns are actively hitting companies of similar size and sector, rather than only reacting to what's already happened once.

Metrics start getting tracked over time: mean time to detect, mean time to contain, the ratio of incidents escalated versus auto-resolved. Even basic tracking creates the feedback loop that drives the whole tier forward. Where volume justifies it, automated response comes into play, though for most SMBs that means specific automated actions, isolating a compromised endpoint, disabling a compromised account, rather than a full SOAR platform deployment that a five-person team has no bandwidth to run.

That 2026 systematic literature review flagged automation as one of the clearest gaps left in existing maturity models, the same gap Tier 4 exists to close. Getting to Tier 4 doesn't mean an organization has finished. It means the organization has built a process that keeps improving on its own, which, for a business without a dedicated security team, is the entire point.