How to Build a Detection Program With a Team of 5
How to build a detection program with five people: scope it to your threat model, split the roles, pick products, track the right metrics, brief the board.
Loading...
How to build a detection program with five people: scope it to your threat model, split the roles, pick products, track the right metrics, brief 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 a detection program with five people sounds like a constraint, but it is really a forcing function. Small teams cannot afford redundancy, ceremony or products that need a dedicated operator, so every decision has to count.
Most detection programs fail because of scope creep, not headcount. Teams try to detect everything, alert on everything and respond to everything. What they get is a queue nobody trusts, analysts who are burned out by month three, and an expensive SIEM that mostly produces noise. Five people cannot run that program, and they should not try.
What five people can do is build a detection program that is scoped to your actual threat model, tuned to your environment, and built to keep working when someone is out sick or on vacation. That takes different thinking than most detection frameworks assume.
Browse the Full Cybersecurity Market. Every Category.
Every category on CybersecTools, from AI Security and Cloud Security to Threat Intelligence and Offensive Security. Filter by use case, industry, or company size.
Every major detection framework, MITRE ATT&CK included, was built to describe the full range of attacker behavior. It was not built to tell a five-person team what to detect first. If you use ATT&CK as your detection backlog, you end up with hundreds of open detection tickets and almost none finished.
Before you write a single rule, answer three questions. Who actually targets organizations like yours? What do they do after initial access? And which data sources do you already have that would show that activity? The answers narrow your scope from hundreds of techniques to the 20 to 30 that matter in your environment.
Your threat model does not need to be a 60-page document. A one-page matrix that maps attacker profiles to your crown jewels and to the telemetry you already collect is enough to set priorities. It also works well in board meetings, when you need to explain why you are not detecting everything.
A five-person team needs three functions covered, not five job titles. Think in thirds: detection engineering, alert triage and response, and program management. You will not get a perfect split and someone will wear two hats, so the goal is simply that no function goes uncovered. The rule of thirds guide covers the model in more depth.
The split that works in practice looks like this:
The program lead is the role most small teams skip. They hire five analysts and then wonder why the board never understands what the team does. Someone has to turn detection coverage into business risk language, and that is not a part-time job you can add to an engineer's plate.
Depth-first detection means highly tuned, low-noise detections for a narrow set of techniques. Breadth-first means covering more techniques and accepting more false positives. Small teams need coverage-first thinking with one twist: you only cover the techniques that map to your threat model.
A practical coverage model for five people has three tiers:
Tier 3 is where most teams waste analyst time, because they alert on everything they can see. A five-person team cannot keep that up. Log it, index it and pull it when you need it, which is a deliberate design choice and not a gap in your program.
Every product in your detection stack has to answer one question before you buy it: who runs this when your best engineer is on vacation? If the answer is nobody, you have bought a single point of failure.
At this size, lean toward platforms over point products. A SIEM that needs a dedicated content engineer to stay tuned is a liability for five people. Managed detection and response, cloud-native security products with built-in detections, and SOAR platforms with ready-made playbooks all reduce the daily workload without cutting coverage.
Total cost of ownership matters here, and vendor TCO calculators usually leave out the time your team spends keeping their integration alive. So add a line for operational overhead when you compare products. For example, if a product costs $80K a year and takes 20% of an engineer's time to maintain, and that time is worth about $30K, the real cost is closer to $110K. That math can change the decision.
Compare How to Build a Detection Program With a Team of 5 solutions side by side
Features, integrations, NIST coverage and deployment for every How to Build a Detection Program With a Team of 5 solution we list, in one table.
Compare How to Build a Detection Program With a Team of 5 solutions →
Mean time to detect and mean time to respond are the metrics your board has heard of. They are also the easiest to game. A team that closes alerts without investigating them will post great MTTD and MTTR numbers while detecting nothing.
The metrics that show whether your program works are harder to collect but closer to the truth:
Detection age is the one that catches decay. Environments change, so a detection written for your old Active Directory may stop firing after you move to Microsoft Entra ID (formerly Azure AD). Reviewing detection age every quarter is how you catch that drift before it turns into a gap.
Five people cannot triage 200 alerts a day by hand and also write new detections, respond to incidents and report to the board. Something gets dropped, and without automation it is usually detection engineering and reporting. Your coverage then stalls and leadership loses visibility.
The automation that pays off fastest for small teams is alert enrichment, not more alert generation. If asset context, user risk and threat intelligence land on the alert before an analyst opens it, triage gets much faster. Measure your own triage time before and after, so you know what the enrichment actually saves.
SOAR is worth buying at this size, but only if you start with three to five playbooks and finish them before you add more. Many teams buy a platform, build half a playbook and move on. A half-built playbook saves no analyst time and adds one more thing to maintain.
At some point your board will ask why an attacker used a technique you did not detect. The wrong answer is a technical explanation of why that technique is hard to catch. The right answer explains why you put other techniques first, based on risk.
Present your detection program as a portfolio rather than a checklist. You invested on purpose in the most likely attack paths against your environment, and you accepted some risk on less likely techniques because covering them would cost more than the expected loss. That is a business decision, and you can defend it as one.
Bring a one-page coverage map to board meetings. Show which attacker profiles you cover, which techniques you detect at each stage of the attack, and what your plan is for closing the gaps. Boards do not need to understand MITRE ATT&CK, but they do need to see that you have a plan and that you are working through it.
A five-person team has no redundancy by default. One person out sick during an incident cuts your capacity by 20%, and two people out is a crisis. So resilience has to be designed in from the start.
Runbooks are your main defense here. Every Tier 1 detection needs a runbook that a competent analyst can follow without calling the engineer who wrote the rule. If a runbook only works with tribal knowledge, it is really just notes.
Cross-training is the second layer. Each analyst should be able to query raw logs, change an existing rule and onboard a new data source, and each engineer should be able to triage and close a Tier 1 alert without escalating. You are building a team that can cover for each other when it matters, not a set of specialists.
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 detection program is not a smaller copy of a 20-person program. It is a different kind of program, built on tight scope, automation and resilience you plan for in advance. The teams that succeed at this size resist the pressure to detect everything and build reliable coverage against the threats that matter to their business instead.
That is a harder argument to win internally than buying more products. It is also the one that gives you a program your team can keep running. For the other functions, see how to build a Govern program and a Respond program with a small team.
People will be most of the cost, and salaries vary too much by market to quote one number. Price your five roles locally, then get quotes for SIEM, EDR, threat intelligence and SOAR. If product spend starts to rival what you pay your people, you are probably carrying more products than five people can run.
Plan on three to six months for a working Tier 1 program, meaning 10 to 15 high-confidence detections with runbooks and a triage process. Most teams underestimate this because they count the time to write rules but not data source onboarding, tuning cycles and runbook writing. Expect about six months before you have something you would be comfortable showing a board.
It does not have to be one or the other. Many five-person teams use an MDR provider for 24x7 coverage and after-hours response while keeping detection engineering and program management in-house. The provider carries the operational load and your team owns the strategy. MDR pricing depends on your environment size, so get quotes from two or three providers. Your team will still spend time on integration and tuning.
Turn coverage into business risk. Instead of saying you have 47 active detection rules, say you have coverage against the top three attacker profiles targeting your industry, from initial access through lateral movement. Boards understand risk portfolios, so show them which risks you accepted, which you reduced and how you plan to close the gaps.
If your detection program depends on one person's knowledge of how the rules work, that person is a single point of failure. Runbook coverage, written detection logic and cross-training are what stop a resignation from becoming a crisis. Treat knowledge transfer as a program requirement and check it every quarter, the same way you check detection coverage.
Separate the work by design. Rotate one analyst each week as the incident handler, and keep that person off detection engineering for the week. Engineers stay on the roadmap unless an incident needs their specific skills. Without this split, incidents always crowd out engineering work and your coverage stalls.
I wrote this guide from my own work running security programs and buying security products. Category and glossary links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.