An Incident Response Maturity Model for Companies Without a Security Team

Small and mid-sized businesses aren't collateral damage in a threat landscape built for enterprise targets. Verizon's 2025 Data Breach Investigations Report puts confirmed breaches at SMBs at roughly four times the rate of large organizations, and ransomware shows up in 88% of those breaches, compared to 39% at bigger firms. That gap is arithmetic, not misfortune: attackers go where the payoff-to-effort ratio is best, and a company with no security staff, no monitoring, and no incident response plan is a much easier calculation than a company with a SOC.

Only about 8% of small businesses budget for cybersecurity at all, and most don't have a written incident response plan. That's the starting condition this piece is built around, not an edge case. Breaches routinely go undetected for months, and a small business with no logging or monitoring usually finds out only once something visibly breaks: files encrypted, a vendor calling about a fraudulent invoice, a customer asking why their data showed up somewhere it shouldn't. Verizon's 2024 DBIR puts realistic per-incident costs for SMBs between $120,000 and $1.24 million depending on scale and response maturity, and in 2025, 37% of attacked small businesses lost more than $500,000 in a single incident. Most maturity advice written for this audience is generic to the point of uselessness, built for readers who already have a security budget and a team to run it. That's the actual subject of this piece: a five-tier model, translated from frameworks that already exist, built for a founder with no security background who needs to act this week, not study.

What a maturity model actually is, and why generic frameworks don't translate for lean teams

A maturity model describes how effective a security program is, from ad hoc and reactive at one end to proactive and optimized at the other. Reaching the top tier isn't the point, and treating it as the point is where most of this advice goes wrong. Knowing, honestly, which rung a company is standing on right now, and what specific thing has to happen to reach the next one, is the whole exercise.

A maturity assessment is not a risk assessment, and conflating the two is where lean teams waste the most time. Risk assessment is tactical: it answers a narrow question at a single point in time, something like "what's our exposure if this vendor gets breached." Maturity is strategic and longitudinal, tracking capability over months and years. Blur the two together and a company ends up with neither: a risk assessment run once and mistaken for a program, or a maturity framework read cover to cover and never converted into a single task on a list.

Even organizations with dedicated security staff struggle here. Cisco's 2024 Cybersecurity Readiness Report found that only 5% of organizations globally had reached the highest maturity tier, counting companies with security teams and budgets built for the job. CREST's own IR maturity guidance is explicit that a small retail company shouldn't aim for the same maturity level as a major bank. Appropriate maturity scales with size and resources, and any framework implying otherwise is pointing lean teams at the wrong target.

That's the real failure of NIST CSF 2.0, CIS Controls v8.1, and CREST's model: they were written by security professionals for security professionals to interpret inside their own organizations. None of them speaks directly to a founder or an IT generalist making a first decision on a Tuesday afternoon with no security background and no budget for a consultant. NIST CSF 2.0, released in February 2024, made real progress with a Small Business Quick-Start Guide, and the April 2025 update to its incident response guidance (SP 800-61 rev. 3) breaks the framework into specific action items. It's the closest any major framework has come to closing the lean-team gap. What follows is a plain-language translation of that thinking into five tiers, each with an entry condition, a set of actions, and a clear line marking when it's done.

Tier 0: The unaware baseline, recognizing what "no program" actually looks like

Tier 0 isn't a hypothetical starting line. It's where most lean-team companies already are. Roughly 47% of businesses have no incident response plan, and only about 8% budget for cybersecurity at all, which means the majority of the population this model addresses starts here, not at some gentler stage that needs its own name.

A few signs mark it clearly. No documented inventory of devices, systems, or SaaS tools. No multi-factor authentication, and passwords that get shared or reused across accounts. Backups that are either absent or have never been tested for restoration. No logging turned on anywhere. No one assigned to own security decisions, and no written guidance telling employees what to do if something looks wrong. If most of these describe a company, that company is at Tier 0, whatever its revenue or headcount says about how mature it "should" be.

Adoption numbers for even basic controls make the picture concrete: about 18% of companies run web vulnerability scanning and 10% use encryption. That's most of the SMB population operating with none of the standard defensive tooling in place, not a niche gap affecting a few laggards.

The risk at Tier 0 isn't a nation-state actor showing up with a zero-day. It's a commodity attack: stolen credentials, an opportunistic phishing email, an unpatched piece of software, succeeding because there's zero friction stopping it. Roughly 63% of employees reuse passwords across accounts, and in a company with no password policy, that single habit is the entire attack surface. Naming Tier 0 honestly, before offering any fix, matters because a company can't climb out of a hole it won't admit it's standing in.

Tier 1: Basic hygiene, the controls that stop most attacks before any response is needed

CIS Controls v8.1 has an Implementation Group built specifically for organizations with limited IT and security expertise: IG1, made up of 56 safeguards that form the floor under any security program, lean or otherwise.

Several controls at this tier close most of the attack surface by themselves, and none require a security hire. Multi-factor authentication on every account, especially email and anything with administrative access, since attackers overwhelmingly log in with stolen credentials rather than break in through some exotic exploit. Automated, tested backups, stored separately from the systems they protect, which is the single most important control for surviving ransomware without paying anyone. A business password manager, replacing whatever spreadsheet or sticky-note system was standing in for one before.

Three written policies need to exist alongside the technical controls, before Tier 2 is even worth attempting: acceptable use, password requirements, and a plain instruction for what an employee does the moment they suspect something's wrong. That last one carries more weight than it sounds like it should. About 95% of cybersecurity incidents at small businesses involve human error somewhere in the chain, and employees at SMBs face social engineering attempts at roughly 3.5 times the rate seen at large enterprises. Waiting to train people until some later, more mature stage means leaving the biggest hole in the wall open the longest. Any consultant who tells a lean team to buy a fancier tool before training the front line has the sequence backwards, and the sequence is the whole point of a tiered model.

Insurance carriers have become an informal enforcement mechanism here. Many now require proof of MFA, employee training, and regular backups before they'll write a cyber policy at all, so Tier 1 controls double as the minimum bar for insurability, not just for security. The exit condition for this tier is straightforward: all five controls in place, someone named as the owner of each, and at least one written policy documented. At that point the company has stopped being an easy target for commodity attacks and can start building an actual response capability instead of just blocking the obvious ones.

Tier 2: A written incident response plan, defining what "respond" means before an incident forces the question

The core document at this tier is a Cybersecurity Incident Response Plan, or CSIRP. It isn't a policy statement about taking security seriously, and treating it as one is the most common way companies waste this tier. A CSIRP is a procedures document that tells specific named people exactly what to do in the first hours after something goes wrong.

A workable CSIRP needs a handful of pieces. Named roles with contact information: who decides, who calls legal, who talks to customers or the press if it comes to that. Clear criteria for what counts as an incident versus a nuisance, and who has the authority to make that call. A severity scale, low, medium, high or its equivalent, with a different response track for each level. Step-by-step procedures for the two or three incident types most likely to actually happen: ransomware, credential compromise, business email compromise. And notification protocols spelling out who gets told, when, and through what channel, including a communication path that doesn't run through email in case email itself is what's compromised.

NIST CSF 2.0's six functions map onto this almost directly. Govern, Identify, and Protect cover everything that happens before an incident; Detect, Respond, and Recover cover the incident itself. A plan that only addresses the "respond" moment and skips the other five functions isn't a smaller version of a real plan. It's an incomplete plan wearing a complete plan's name, and it fails exactly where it was never built to hold.

Detection basics belong here too, not assumed to already exist from Tier 1. Email alerts for failed logins, unexpected system changes, unusual account activity. A minimum review cadence for whatever logs are being collected, monthly at the least. Business email compromise deserves specific mention in the plan rather than a general nod, given its scale: there were 21,442 BEC complaints in 2024, totaling $2.77 billion in losses. A written procedure for verifying any unusual payment request, out loud, on the phone, belongs at Tier 2. It is not an advanced control to be saved for later; by the time a company is mature enough to "afford" it on paper, the wire has already gone out. The exit condition here is a plan that's written down, accessible even if the network is down, has named owners attached to every role, and has actually been read by everyone listed in it.

Tier 3: Testing the plan, what tabletop exercises reveal that documentation cannot

A written plan that has never been tested is a guess with good formatting. A tabletop exercise is a facilitated conversation walking through a realistic incident scenario, step by step, with no systems actually touched. It costs almost nothing to run: a full cross-functional session takes roughly two to three hours.

Everyone with a stake needs a seat at the table, not just IT. Executive leadership, legal, communications, HR, and operations all have decisions to make during a real incident, and an exercise that leaves them out only proves the plan works on paper, for an audience that was never going to be the one running it.

A basic ransomware scenario works well for this. An employee flags a suspicious alert on the file server. Reports start coming in from multiple departments that files are inaccessible. An executive asks whether customers need to be told. Then the group has to decide, with the clock running, whether to restore from backup or explore other options, and who actually has the authority to make that call.

What surfaces during these exercises is almost never in the document itself. Logs that were dutifully turned on but that nobody actually knows how to read under pressure. Contacts listed in the plan who changed roles or left the company a year ago. Gaps in authority, where a decision clearly needs making but no one is assigned to make it. Recovery steps that look fine on paper but were never tested against a real backup restoration. None of this shows up until people are forced to talk through it out loud, which is the entire argument for running the exercise instead of just filing the plan away.

Whoever runs the exercise has to set a blameless tone from the first minute: the goal is finding weak spots in the plan and the controls, not assigning blame for who clicked what. Behavioral research on security awareness suggests real, measurable change in how people respond takes somewhere in the range of 6 to 12 months of sustained effort. One exercise starts that clock; it's the repetition, not the single session, that builds the muscle. The exit condition is one completed tabletop, findings written down, and the plan actually revised to reflect what broke.

Tier 4: Continuous monitoring and managed response, what lean teams can buy instead of staff

The detection gap running through Tiers 0 through 2 is structural, not a matter of bad luck. Without any monitoring, incidents get discovered only once the damage is visible, and IBM's 2024 data put the average time to identify and contain a breach at 258 days. Tier 4 exists to compress that number, hard, and it's the one tier where buying a capability beats building one, no exceptions.

Continuous monitoring does things a monthly log review simply can't. It flags anomalous login behavior, lateral movement, and privilege escalation close to real time. Endpoint detection catches threats before they spread from one machine to the rest of the network. And identity-layer visibility catches session-based attacks that go around MFA entirely, a technique that has become increasingly common.

CREST's maturity model draws a useful line here: organizations with high IR maturity often run monitoring in-house, while organizations with lower maturity lean on third parties. For a lean team, that's the correct model, full stop, not a workaround or a consolation prize. Treating in-house monitoring as the more serious choice is the mistake that has quietly bankrupted more than one under-resourced IT department's roadmap, chewing through budget on tooling nobody has the headcount to watch at 2 a.m. A company with no security staff was never going to build a 24/7 monitoring capability internally, and pretending otherwise just delays getting real coverage in place.

Consolidation matters as much as raw capability. A lean team can't reasonably run five separate security tools from five separate vendors with five separate dashboards. Something built to combine device management, endpoint protection, identity monitoring, and compliance tracking into one place cuts the operational load down to something a single owner can manage part-time.

Whatever monitoring or managed detection option gets picked should clear a few practical bars: deployment in days or weeks, not months; alerts that point to something actionable without requiring security expertise to translate them; coverage across endpoints, identity, and SaaS applications, not just the network edge; and automatic enforcement of the Tier 1 hygiene controls rather than reliance on someone remembering to check. The exit condition at Tier 4 isn't really an exit, it's ongoing: monitoring in place and reviewed on a set schedule, the plan tested at least once a year, and every real incident or near-miss feeding back into an update. The model becomes a living benchmark, not a box checked once and forgotten.

How to move through the tiers without a security team running the program

The order here isn't optional, and skipping ahead is the single most common mistake lean teams make with this model. Tier 1 controls have to exist before a Tier 2 plan means anything, because a plan built on top of shared passwords and no backups is a plan for a company that's already lost. A Tier 2 plan has to exist before a Tier 3 exercise is worth running, since there's nothing to stress-test without it. And Tier 4 monitoring only pays off once Tier 2 procedures exist to act on whatever it finds. Buying monitoring tools before writing the plan, the instinct at most under-resourced shops because software feels like progress and a document doesn't, produces expensive noise instead of a program. That instinct is the wrong one, and it's the one worth naming plainly: a dashboard nobody has a procedure to act on is a very expensive screensaver.

Ownership has to get assigned before anything else on this list happens. Incident response with no named decision-maker defaults to chaos the moment something actually goes wrong, and one person needs to hold this even if that person is already juggling fifteen other jobs.

CIS Controls v8.1's Implementation Group 1 is built for small and mid-sized organizations and turns this into a structured set of safeguards rather than an abstract project. Following it turns "get better at security" into a list of discrete tasks with a start and an end.

Timelines here aren't arbitrary. A Tier 1 baseline, MFA, backups, basic policy, is achievable with focused effort over a realistic near-term window. A working Tier 2 plan with detection basics takes additional focused effort, depending on how tangled the environment already is. Embedded awareness and the behavioral change that comes with regular Tier 3 exercises and Tier 4 monitoring takes longer, somewhere in the 6-to-12-month range for measurable improvement, with real cultural change stretching past that. None of it requires a security team. It requires sequence, ownership, and the discipline not to skip a tier just because the next one looks more interesting.