Building a Detect Program With a Team of 5

Most detection programs are designed by people who assume you have 20 analysts, a mature SOC, and a SIEM that someone actually tuned. You probably have five people, a backlog that never shrinks, and a board that wants to know why you need more headcount before you've proven the current team works.

Five is not a small team. Five is a forcing function. It forces you to make decisions that larger teams avoid: what you will not monitor, which alerts you will not chase, and which detections are worth building versus buying. Those decisions are the actual work of detection engineering. Most programs skip them entirely and wonder why their analysts are burned out and their MTTD is measured in weeks.

This article is about building a detection program that produces real outcomes with a team of five. Not a roadmap. Not a maturity model. A set of decisions you need to make, in order, with the tradeoffs named clearly. If you are a CISO or VP who owns this function, this is what you actually need to think through.

Most teams conflate detection with alerting. They are not the same thing. Alerting is a SIEM firing on a rule. Detection is a program that reliably identifies adversary behavior within an acceptable time window, with enough context to act. One is a feature. The other is a capability.

Before you scope tooling or headcount, define your detection objective in business terms. Something like: 'We will identify credential-based lateral movement within 4 hours, 90% of the time, across our cloud and endpoint environments.' That sentence tells you what data you need, what coverage gaps matter, and what success looks like when you report to the board.

Without that definition, your team will spend cycles tuning rules that serve no stated objective. Your vendors will sell you coverage you cannot operationalize. And your board will keep asking the same question: 'Are we detecting threats?' You will keep answering with tool counts instead of outcomes.

A five-person detection team needs three functional roles, not five job titles. One person owns detection engineering: building, tuning, and retiring detections. One person owns triage and response: working the queue, escalating, and closing. The third role is the one most small teams skip entirely: someone who translates detection outcomes into business risk language for leadership and compliance.

In practice, you will not have clean thirds. One person may cover engineering and part of triage. Your risk translator may be you, the CISO, doing it in board prep every quarter. That is fine. The point is that all three functions must exist somewhere. If they do not, your program will produce alerts nobody acts on, or actions nobody can explain to an auditor.

The single biggest structural mistake in small detection teams is making everyone a generalist. Generalists are efficient until something breaks. Then nobody owns the fix. Assign primary ownership for each function, even if people overlap.

Coverage decisions are risk decisions. Treat them that way. Map your environment to your threat model, then score each coverage area by two variables: likelihood of adversary activity and business impact if missed. That gives you a 2x2. Fund the top-right quadrant first. Defer the bottom-left indefinitely.

For a team of five, a realistic coverage model covers three to four domains well rather than eight domains poorly. Most organizations in the $50M to $500M revenue range should prioritize: identity and authentication, endpoint behavior, cloud control plane activity, and email. Everything else is a stretch goal until you have the capacity to operationalize it.

Document what you are not monitoring. This sounds counterintuitive, but it is one of the most important artifacts your program produces. When a board member asks 'could we have detected this?' after an incident, you want a documented risk acceptance, not a gap you never acknowledged.

Detection content is the rules, queries, and behavioral models that generate alerts. You have three sources: build it yourself, buy it from a vendor, or borrow it from open-source frameworks like Sigma or the Elastic detection rules repository. Each has a different cost structure and a different maintenance burden.

Vendor-supplied content is fast to deploy and slow to tune. Most SIEM and EDR vendors ship hundreds of out-of-the-box detections. In a five-person team, you cannot maintain all of them. Pick 20 to 30 that map directly to your threat model and disable the rest. An alert your team cannot act on is not a detection. It is noise with a timestamp.

Build custom detections only for gaps that matter and that no vendor covers adequately. Custom content is expensive: it requires data pipeline knowledge, adversary tradecraft understanding, and ongoing maintenance as your environment changes. Reserve it for your highest-priority coverage areas. Borrow from Sigma and community repositories for everything else, then tune aggressively.

Your SIEM is the most expensive line item in your detection budget and the one with the most hidden costs. The license is the visible number. The real costs are: data ingestion at scale, storage for retention requirements, engineering time to build and maintain pipelines, and the analyst time to work the queue the SIEM generates.

Most organizations ingest far more data than they need to. A team of five cannot operationalize 500GB per day of logs. They can operationalize 50GB of the right logs. Before your next renewal, audit what you are ingesting against your coverage model. Cut sources that do not map to a detection objective. That conversation with your SIEM vendor will be uncomfortable. Have it anyway.

The market has shifted. Cloud-native SIEMs, detection-as-a-service platforms, and co-managed SOC options have changed the build-vs-buy calculus significantly. A five-person team in 2024 has options that did not exist three years ago. Evaluate them against your actual workload, not a vendor's reference architecture built for a 50-person team.

Most detection metrics are vanity metrics. Alert volume, rule count, and 'threats blocked' tell you nothing about whether your program is working. The metrics that matter are: mean time to detect (MTTD) for your priority threat scenarios, false positive rate by detection source, and coverage percentage against your defined threat model.

Run purple team exercises or tabletop simulations against your top three threat scenarios every quarter. Not annually. Quarterly. Each exercise gives you a data point: did we detect this, how long did it take, and what would the business impact have been if we had not. That is the data your board actually needs, even if they do not know to ask for it.

Report detection performance as a trend, not a snapshot. A MTTD of 6 hours is meaningless without context. A MTTD that dropped from 18 hours to 6 hours over two quarters tells a story about program investment and team execution. That story is what justifies next year's budget.

Alert fatigue is not a morale problem. It is a program design problem. If your team is drowning in alerts, the answer is not resilience training or better shift scheduling. The answer is fewer, higher-fidelity detections. Every alert your team works that does not lead to a meaningful finding is a tax on their capacity and their judgment.

Set a false positive budget. If a detection fires more than 10 times per week with a false positive rate above 80%, it gets tuned or disabled. No exceptions. This policy will feel aggressive the first time you apply it. It will feel like good engineering six months later.

Rotation matters more than headcount. A five-person team where two people are on-call every week will burn out in 18 months. Build a rotation that gives each person at least two weeks between on-call cycles. If your alert volume makes that impossible, you have a detection content problem, not a staffing problem.

Managed detection and response (MDR) is not an admission of failure. For a five-person team, it is often the right architectural decision. The question is not whether to use an MDR provider. The question is which functions you retain internally and which you hand off.

Keep in-house: threat model ownership, detection content decisions, escalation criteria, and the relationship between detection findings and business risk. These require organizational context that no external provider can replicate. Hand off: 24x7 monitoring coverage, initial triage on commodity threats, and threat intelligence operationalization at scale.

When evaluating MDR providers, ask for their false positive rate on your specific environment type, their average MTTD on their last 50 engagements, and their escalation SLA in writing. Most vendors will give you marketing numbers. Push for contractual commitments. The gap between those two figures tells you everything about how they actually operate.

A five-person detection program is not a compromise. It is a set of deliberate choices about where you will invest attention and where you will accept risk. The teams that build effective detection programs at this scale are not the ones with the best tools. They are the ones that defined their objective clearly, made hard coverage decisions early, and measured outcomes instead of activity. Start with your threat model. Build your coverage model from there. Tune everything that does not serve it. Report in business terms. That is the program.