Follow Build versus buy is the decision about which threat detections a security team authors in-house and which it sources as ready-made detection content. The answer is almost never all build or all buy. Buy the commodity layer, build what is unique to your environment, and measure both sides by time-to-coverage: the elapsed time from a technique becoming public to a validated, firing detection running in your own stack.
Should my security team write our own detection rules or buy detection content?
Both. The split depends on four factors, not a preset ratio.
| Factor | Build indicator | Buy indicator |
|---|---|---|
| Telemetry uniqueness | Custom apps, proprietary protocols, environment-specific logic | Commodity TTPs against common platforms, mappable to MITRE ATT&CK techniques |
| Staffing | Detection engineers on staff with authoring and maintenance capacity | No detection-engineering FTE, or FTE consumed by other work |
| Validation capacity | Team can prove rules fire and produce audit evidence | No validation pipeline |
| Time-to-coverage target | Tolerable window measured in weeks | Window measured in hours or days |
Time-to-coverage is the factor the whole decision turns on. It measures the window between a technique becoming public and a validated, firing detection running in your environment. Every day inside that window is exposure the team chose to carry.
What does a detection engineer cost, fully loaded, and what does the backlog cost?
The answer is your own numbers. Every organization’s cost structure is different, and no external benchmark substitutes for your loaded cost, ramp timeline, or attrition rate. What matters is calculating it completely.
A fully loaded detection engineer costs more than a salary line. The total includes salary, benefits, tooling, training, and the management overhead a specialized hire carries.
Add the ramp period. A new engineer does not produce validated detections against your specific telemetry and SIEM configuration on day one, and the backlog grows while they ramp.
Add attrition. Detection engineers are scarce and mobile. Each departure restarts the ramp clock and takes environment-specific knowledge with it.
| Factor | Your figure | Notes |
|---|---|---|
| Loaded annual cost (salary + benefits + tooling + overhead) | ||
| Ramp time to productivity on your stack | Months before the hire writes production rules | |
| Annual attrition rate | Each departure restarts the ramp clock | |
| Backlog carrying cost | Risk carried while rules sit unwritten | |
| Rules authored per engineer per month | Validated, deployed rules only | |
| Platform count (SIEM, EDR, XDR targets) | Each target multiplies maintenance cost |
The backlog itself has a cost. Every rule that sits unwritten or unvalidated is a detection gap the environment runs with until someone writes, tests, and deploys it. Quantifying that carrying cost is difficult, which is why most teams skip it and why the gap persists. The worksheet at the end of this page provides the structure to calculate it.
How do small security teams keep detection rules current against new threats?
The constraint is time, not skill. Keeping hundreds or thousands of rules current while new techniques arrive continuously is a different workload from authoring them. A small team cannot do it at the speed new techniques emerge while also tuning rules, handling incidents, and maintaining the SIEM.
Three realities compound the problem:
- Technique volume exceeds authoring capacity. Threat-intelligence feeds publish new techniques continuously. A team of one or two detection engineers cannot keep pace while handling everything else the SOC demands
- Platform count multiplies build cost. Two SIEM or EDR platforms means every rule needs two implementations. Three platforms, three. Build cost scales linearly with targets.
- Validation is the bottleneck. A rule that parses is not a rule that fires. Proving it fires on real or emulated events, and that it produces audit-grade evidence, is where the time goes. Without validation capacity, bought or built content is equally unproven.
Portable detection content addresses the commodity layer directly. Rules authored in a vendor-agnostic format like Sigma and translated to each target platform give small teams continuously updated coverage without authoring and maintaining every rule from scratch.
The team’s own engineers then focus on detections that require knowledge of the environment: custom applications, internal telemetry sources, and business logic no external library can anticipate. Vendor-agnostic content narrows the window between technique publication and deployed detection for the commodity layer, freeing constrained engineering capacity for the work only that team can do.
SOC Prime’s Advanced Threat Detection library supplies curated behavior rules for emerging threats, centrally managed, deployable at scale, and stored as Detection as Code.
What factors should I consider when calculating the cost of hiring detection engineers versus buying solutions?
Seven factors, each a cell in the cost model. Fill in each from your own data. Estimates carry risk: underestimating any single factor makes the whole model unreliable.
| Factor | What to measure | Why it matters |
|---|---|---|
| Loaded cost per engineer | Salary, benefits, tooling, training, management overhead | Baseline unit economics of building in-house |
| Ramp time | Months from hire date to first validated production rule | Detection engineering is stack-specific |
| Attrition and re-hire cost | Turnover rate times ramp cost per replacement | Every departure resets the clock and reopens the backlog |
| Backlog carrying cost | Unwritten rules times assessed risk per gap | The cost paid while the queue does not move |
| Platform count | SIEM, EDR, XDR targets maintained | Each platform multiplies every build and every update |
| Evidence burden | Hours producing audit and regulatory documentation: log-source inventories, rule-deployment records, proof-of-firing evidence, dated coverage reports | Real cost whether content is built or bought |
| Time-to-coverage target | Hours or days from technique publication to validated deployed detection | Converts all the above into an operating requirement |
When the total cost of building exceeds the cost of buying the commodity layer plus the cost of building only what is unique, the decision has made itself. No universal salary figure or ratio applies. The answer depends on your numbers.
How can I justify the investment in detection content to the board or budget committee?
Frame it as what it is: converting a variable, hard-to-retain hiring problem into a predictable subscription line. The board funds coverage, speed, and risk reduction. Present detection content as the mechanism that delivers them.
Detection engineering talent is scarce, hiring cycles are long, and attrition resets the ramp. A subscription to vendor-agnostic detection content converts part of that variable cost into a fixed line item the board can plan against.
Three metrics a board recognizes:
- Time-to-coverage. The window between a technique becoming public and a validated, firing detection deployed in your environment. Buying the commodity layer compresses this window. Show the board the current window and the target.
- Validated coverage against MITRE ATT&CK. The share of relevant ATT&CK techniques for which you have a detection proven to fire. Measurable, auditable, and comparable across reporting periods. Boards approve what they can track.
- Avoided incremental hires. The engineering capacity that would need to be added to reach the same coverage and the same time-to-coverage through in-house authoring alone. Frame it as headcount you did not need to add
The ask is a subscription delivering measurable coverage gains at a speed the existing team cannot match, without adding headcount. Bought content augments capacity without replacing expertise: engineers stop re-authoring commodity rules that hundreds of other teams are writing independently and focus on investigation, tuning, incident response, and the detections only they can build.
What is the cost of the gap between technique publication and deployed detection?
The gap is the window during which a technique is known, published, and potentially in use, but your environment has no detection for it. The cost of that window is exposure: an attacker using a known technique can operate while no detection for that behavior is in place.
The gap has a shape:
| Step | What happens | What adds time |
|---|---|---|
| Technique publication | A new TTP appears in a threat report or ATT&CK update | Nothing. The clock starts. |
| Rule authoring | A detection engineer writes a rule for your stack | Complexity, queue depth, competing priorities |
| Translation | The rule is rewritten for each additional platform | Every extra SIEM, EDR, or XDR target |
| Validation | The rule is tested to confirm it fires and controls false positives | Emulation environment availability |
| Deployment | The validated rule reaches production | Change-management process |
Every step is sequential, so the gap is their sum. A backlog of unwritten rules means the gap for the next technique does not start at zero. It starts behind whatever is still waiting.
The gap compounds in three ways.
Incident response gets harder when initial detection was late. The attacker has had time to move laterally and establish persistence.
Audit and regulatory evidence suffers. The dated coverage report shows a gap for a technique that was publicly known.
Operational confidence erodes when the backlog grows faster than the team can work it. That signals a structural problem, not a temporary shortage.
Buying commodity detection content compresses the authoring and translation steps. It does not eliminate validation. The team still owns the last mile: confirming content fires in their environment and produces the evidence their auditors expect.
Shrinking the gap comes down to more authoring capacity or a content source that covers commodity techniques faster than the team can write and validate them in-house.
Where this does not hold
The buy side assumes commodity detection content exists for your platforms and that your environment accepts external content. Bought content substitutes for built content only within that boundary. Where the conditions fail, building is the only option.
Conditions where buying does not apply:
- Proprietary telemetry. Detection logic tied to custom application logs, proprietary protocols, or internal-only data sources. No external vendor has visibility into what only your environment produces.
- Classified or restricted environments. Environments requiring review and approval of external content before ingestion. The review process can negate the speed advantage.
- Platform coverage gaps. Vendor content that does not translate to your SIEM, EDR, or XDR platform is inaccessible.
- Sourcing and provenance constraints. Some compliance frameworks or internal policies require detection content authored by named, vetted individuals, or full provenance control over detection logic from authorship through deployment. Bought content carries the vendor’s provenance chain, and some audit frameworks treat that distinction as material. Verify whether your evidence requirements accept externally sourced content.
One case falls outside the decision entirely. A team without a functioning SIEM or a defined detection-engineering function is not ready for build versus buy at all. The question assumes a functioning detection program, so teams still establishing basic telemetry collection should address that first.
Buy the commodity layer where it works. Build what is unique, restricted, or unsupported. Measure both sides by time-to-coverage.
FAQ
Should my security team write our own detection rules or buy detection content?
Both. Buy the commodity layer of threat detections that cover widely shared TTPs against common platforms. Build the detections that require knowledge unique to your environment: custom applications, proprietary protocols, and internal telemetry sources. Measure the split by time-to-coverage.
How do small security teams keep their detection rules current against new threats?
With a source mix, a validation cadence, and a measured disclosure-to-detection window. Small teams cannot author and maintain commodity detections at the speed new techniques emerge while also handling incidents, tuning rules, and maintaining the SIEM. Sourcing the commodity layer as vendor-agnostic detection content frees constrained engineering capacity for the work only that team can do.
How can I justify the investment in detection content to the board or budget committee?
Present three metrics the board can track: time-to-coverage (technique publication to validated deployed detection), validated coverage against MITRE ATT&CK (the share of relevant techniques with proven detections), and avoided incremental hires (the capacity the team would need to add to reach equivalent coverage through in-house authoring alone).
What factors should I consider when calculating the cost of hiring detection engineers versus buying solutions?
Seven factors: loaded annual cost per engineer, ramp time to productivity on your stack, annual attrition rate and re-hire cost, backlog carrying cost, platform count (each SIEM, EDR, or XDR target multiplies build and maintenance cost), evidence burden (audit and regulatory documentation hours), and time-to-coverage target. Fill in each from your own data.
Does buying detection content replace the detection team?
Buying detection content changes what the team spends its time on. Engineers stop re-authoring commodity rules and focus on investigation, tuning, incident response, and detections that require environment-specific knowledge. Bought content augments capacity without replacing expertise.
Build-versus-buy worksheet
Use this worksheet to score your own environment. Fill in every cell from your own data. No cell should contain a guess. If you lack a number for a factor, that gap is itself a finding worth resolving before the decision.
Step 1: Inventory
| Item | Your answer |
|---|---|
| SIEM, EDR, and XDR platforms in production | |
| Detection engineers on staff (FTE) | |
| Rules authored and validated per month (current rate) | |
| Current backlog (unwritten or unvalidated rules) | |
| Time-to-coverage today (technique published to detection deployed) | |
| Time-to-coverage target | |
| Validated MITRE ATT&CK coverage today (share of relevant techniques) | |
| Validated MITRE ATT&CK coverage target |
Step 2: Cost to build (annual)
| Item | Your figure |
|---|---|
| Loaded annual cost per detection engineer | |
| Detection engineers required | |
| Ramp time per new hire (months) | |
| Annual attrition rate | |
| Re-hire and re-ramp cost per departure | |
| Backlog carrying cost (estimated annual) |
Step 3: Cost to buy (annual)
| Item | Your figure |
|---|---|
| Detection content subscription | |
| Platform translation and integration | |
| Internal tuning and validation labor |
Step 4: Decision factors
| Factor | Score (1 to 5) | Notes |
|---|---|---|
| Telemetry uniqueness (5 = highly unique, 1 = commodity) | ||
| Staffing sufficiency (5 = fully staffed, 1 = no detection engineers) | ||
| Validation capacity (5 = full pipeline, 1 = no validation process) | ||
| Time-to-coverage gap (5 = within target, 1 = weeks behind) | ||
| Platform complexity (5 = single platform, 1 = five or more) | ||
| Evidence burden (5 = minimal, 1 = heavy regulatory requirement) |
Step 5: Decision
Answer these from the totals and scores above:
- Does annual build cost exceed buy cost plus the cost of building only what is unique?
- Does current time-to-coverage exceed the target?
- Can the current team sustain the required authoring and validation cadence?
Then read the scores:
- Most factors score 1 to 2: buying commodity detection content addresses the capacity gap.
- Most factors score 4 to 5: the team has the capacity and uniqueness to build.
- Mixed scores: buy the commodity layer, build what is unique, and measure both by time-to-coverage.
No preset ratio applies. The worksheet produces your answer.
SOC Prime’s Architect, an AI agent designed to build detections, tune them to your SIEM language, research threats, develop hunts and many other tools detection engineers need.
