How to Build an Incident Response Program With 5 People
How to build an incident response program with five people: who owns what, which products to buy, when to use MDR, and what to report to the board.
Loading...
How to build an incident response program with five people: who owns what, which products to buy, when to use MDR, and what to report to the board.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
Building an incident response program with five people sounds like a constraint. It is actually a forcing function, because small teams cannot afford redundancy, ceremony, or products that need a dedicated operator. Every decision has to carry weight.
Most response programs fail not because of headcount but because of design. They are built for the team someone wishes they had, not the team they actually have, and playbooks written for a 20-person SOC do not scale down. They collapse. What you need is a program built from the start around five people doing real work under real pressure.
This guide is about how to build that program, with specific role assignments, product decisions, vendor trade-offs and board reporting that work when your entire response capacity fits in one conference room.
See every Incident Response solution we list
The full Incident Response market, filtered by company size, deployment and NIST coverage.
The instinct when you have a small team is to apologize for it. Stop. A well-designed five-person response team will outperform a fifteen-person team built on bad assumptions, and the difference is clear ownership and less waste.
Every person on a five-person team needs a primary function and a secondary function. There is no room for generalists who do everything poorly or specialists so narrow they cannot cover a shift. The rule of thirds applies here: roughly one third detection and analysis, one third containment and recovery, one third communication and coordination. With five people that math gets uncomfortable fast, and you solve it with role overlap, not headcount.
The org design question is not "who does what". It is "what breaks first when someone is out", so map your single points of failure before you map your org chart.
Here is a working role model for a five-person response team. These are not job titles but responsibilities, which you can spread across whatever titles your HR system requires:
In practice, your detection lead and forensics person are often the same individual in the first 48 hours, and your recovery coordinator and communications lead may share a person if one of them has a strong feel for the business. The point is that all five functions exist and have a named owner, not that you have five separate people for five separate lanes.
Document the backup owner for each function. If your containment engineer is unreachable at 2am, who has the access and the authority to act? That answer needs to exist before the incident, not during it.
The vendor pitch for every security product assumes you have someone whose full-time job is running it. You do not. With five people, every product you buy is also a tax on your team's time, so judge each product by what it costs you in operating effort every week as much as by how well it detects.
Prioritize products that produce usable output without constant tuning. A SIEM that generates 10,000 alerts a day and needs a dedicated analyst to manage the noise is a distraction for your team, which needs signal rather than volume.
These are the capabilities a five-person team has to own outright, with no gaps:
Vendor total cost of ownership calculators usually leave out integration costs, tuning time, and the two weeks your best analyst spends onboarding every new platform. Add those in yourself before you sign.
Most playbooks are written to be thorough, but yours need to be fast. When five people are working an active incident, nobody reads a 40-step document. They're looking for the three decisions that matter in the next 20 minutes.
So build playbooks around decision points instead of task lists. Each one should answer what you do right now, who you notify, and what triggers an escalation, and everything else goes in an appendix as reference.
Start with your top five incident types by likelihood, not by severity. For most mid-market companies (100 to 999 employees), that list looks like this:
Build tight, tested playbooks for those five before you write anything else. A playbook you've run in a tabletop exercise twice is worth more than ten that have never been run.
Review the playbooks after every real incident and every tabletop, not once a year. Small teams learn fast when every event feeds the next improvement.
With five people, you'll have gaps in coverage: nights, weekends, holidays and incidents that happen at the same time. You have to close those gaps, and the real choice is whether you do it with headcount or with a managed service.
MDR services have matured a lot. The better ones give you 24/7 SOC coverage, threat hunting, and an escalation to your team when something real happens. The price depends on the size of your environment and the depth of service. Get quotes and compare them with the full cost of the hires you would need to cover the same hours.
The trade-off is control. An MDR provider follows its own playbooks unless you put time into customizing them, and it escalates on its own thresholds instead of your risk tolerance. So before you sign, get specific answers to these questions:
If a provider can't answer those with specifics, it's selling you a service level agreement rather than a response capability. Compare providers on the MDR shortlist.
Compare Incident Response solutions side by side
Features, integrations, NIST coverage and deployment for every Incident Response solution we list, in one table.
Your board doesn't care about mean time to detect. It cares whether a breach would hurt the business in a material way, and your job is to translate the program's performance into that language.
Three metrics work at board level for a response program:
Keep metrics that need security expertise to read, such as alert volume, false positive rates and MITRE ATT&CK coverage scores, for internal use. At board level they're noise, so give your board three numbers it can track quarter over quarter and ask good questions about.
When the board asks how you measure the return on response spending, point to containment time, coverage and cost avoided rather than a feature list. If you build your reporting around those three, every quarterly review gets easier. There's more on this in the security metrics your board cares about.
Response programs decay. Playbooks go stale, integrations break without anyone noticing, and the analyst who knew the forensics product leaves without anyone realizing until the next incident. That slow decay is the biggest threat to a small team's program over time.
Put a quarterly health check in the calendar. It isn't a full audit, just a 90-minute structured review of four things: whether playbooks are current, whether integrations still work, where coverage has gaps, and where the team has skill gaps. Give every finding an owner and track it.
These are the warning signs to watch for in a five-person team:
Small teams are exposed to single points of knowledge, not only single points of failure. Document everything as if your best person is leaving next month, because one day they will.
At some point your five-person team will hit a real capacity ceiling. The mistake most security leaders make is asking for headcount based on workload, which executives hear as a staffing complaint. What they respond to is a clear statement of risk.
So frame the ask around a specific gap and a specific consequence. For example: "We have no coverage between 6pm and 6am on weekdays and none on weekends. We don't know our detection time in those windows because we can't see anything. A ransomware attack that starts on a Friday night gets a 60-hour head start before anyone notices." That's a risk statement, and it can be funded.
The options you put on the table matter as much as the ask. Give leadership three choices: hire a sixth person at a stated cost, add MDR coverage at a stated cost, or accept the documented risk. Asking them to choose works better than making a request, because the conversation moves from "do we have budget" to "which option fits our risk tolerance", and that's a conversation you can win.
Check a vendor before you sign
Mandos tracks funding, acquisitions, hiring and news for security companies. Look up any vendor on your shortlist before the renewal.
A five-person response program is a specific design problem with specific answers, and the teams that do well at this size stop trying to copy what a large enterprise SOC does and build for the limits they actually have.
That means clear ownership of every role, products chosen for low operating effort over long feature lists, playbooks built for speed, and metrics that translate into business risk for the board. Build it on purpose, test it often, and use every real incident to improve the next round.
For a mid-market company (100 to 999 employees), the budget covers people, core products and MDR coverage if you go that way. The biggest variable is whether you run 24/7 coverage yourself or buy it. If you try to staff nights and weekends with five people, you either burn out your team or leave gaps. So budget for MDR as a line item from the start and present it as a coverage decision.
A minimum viable program takes three to six months with a focused team. That means documented playbooks for your top five incident types, the products in place, and at least one tabletop done. The mistake is trying to build everything before you call the program live, so finish the top five playbooks, run a tabletop and improve from there. A tested program with five playbooks beats an untested one with fifty.
Use three metrics: containment time for confirmed incidents, coverage across your environment, and estimated cost avoided based on incident outcomes. Show the trend quarter over quarter and tell it as a business risk story rather than a technical scorecard. If your board is asking about specific products or frameworks, you've lost the thread, so keep it at "here's what we can stop, here's what we can't, and here's what it would take to close the gap".
If you can't staff real 24/7 coverage with your current headcount without burning people out, buy MDR. One person can't cover nights and weekends alone. Price an MDR service against the full cost of the hires you'd need for round-the-clock cover. A good one gives you a full SOC on call. The trade-off is customization and context, which you manage with a strong onboarding process and clear escalation rules.
Buying products that need a dedicated operator. Every platform that needs daily tuning, weekly reports or a certified specialist to read its output is a hidden headcount cost, so judge products on operating effort per week rather than feature depth. A product your team uses at 70% of its capability is worth more than one that sits idle because nobody has time to learn it.
Agree a retainer with at least one outside incident response firm before you need it. A retainer buys you priority access and pre-agreed hourly rates during a crisis. Without one, you're negotiating a contract in the middle of a breach, which is a bad position to be in, so treat the retainer as insurance and include it in your base budget from year one.