Why Your MDR Won't Cover the Custom Detections You Built

Detection engineers tend to keep the detections they write in their own SIEM rather than route them to a Managed Detection and Response (MDR) provider. Those rules are built for one environment's specific threats, and the alerts they generate land back on the internal team to investigate. The reasons are structural, and so is the cost.

Why mature teams build their own detections

Custom detections are the rules a team writes for its own environment: logic that catches abuse of an internal application, an access pattern that only makes sense against the organization's identity model, a data movement that is routine elsewhere and a problem here. Most large organizations run at least some; far fewer back them with a disciplined detection-engineering program of ownership, tuning, and testing. These custom detection rules earn their place by covering ground vendor detections cannot: the crown jewels, the business logic, the unusual identity patterns, the custom applications specific to the organization. The measure that matters is which incidents a team would miss without them, not what share of the queue they fill.

Those alerts are also the hardest to judge. A vendor detection firing on a known-bad hash is quick to adjudicate; a custom rule firing on a subtle deviation is not, because judging it means knowing why the rule exists and what normal looks like around it. That context sits with the SecOps engineer who wrote it.

Why custom detections sit outside an MDR's scope

Managed detection and response is a standardized service. A provider runs its own detection library across hundreds of customers, and the economics depend on content that generalizes. The service covers that library and the tier-1 triage of the alerts it generates. The rules a single team wrote sit outside that scope, or move a buyer into a higher tier that often ingests the rule as another alert source without investigating its output with depth. These are MDR limitations of a shared-service model, not of any one vendor: MDRs investigate the detections they ship, not the ones the customer wrote, so the alerts from custom detections stay the in-house team's responsibility.

{{ebook-cta}}

The cost of covering the rest yourself

Those alerts do not stop firing at night or on weekends, and they cannot be safely bulk-closed, because a custom rule firing is the case where a fast close is most dangerous. An MDR sells around-the-clock coverage of its own library, which is much of why teams buy it; the custom-detection cohort needs the same attention, and it is now the internal team's to provide. In a mature enterprise that cohort can run 10 to 30 percent of alert volume, a meaningful, high-context share rather than an edge case.

Around-the-clock coverage does not scale down. One hire cannot staff nights, weekends, and days; continuous human coverage of a single seat takes four to six people once shifts and turnover are counted. Headcount is only half of it: an overnight analyst, in-house or outsourced, can read a custom-rule alert but not the intent behind it, which still lives with the engineer who wrote the rule. Teams adopt an MDR partly to avoid building a 24/7 investigation function; their custom detections push them right back toward it.

How an AI SOC platform covers these alerts

An AI SOC platform covers those alerts directly, at any hour, without adding headcount. Rather than running a fixed playbook, it investigates each one against the specific environment: it queries the connected data sources, including the SIEM, EDR, identity provider, and cloud, gathers the context the alert depends on, and follows the evidence as a senior analyst would. A custom-rule alert gets the same depth as any other, with a documented trail from query to evidence to verdict an analyst can confirm rather than rebuild.

It runs on the team's terms. The team sets which assets and detections are critical and how particular situations should be handled, including the reasoning behind a given rule, and the platform applies that guidance with human approval gates where required. It can also surface which rules are noisy and where MITRE ATT&CK coverage has gaps, so a team's engineers handle detection tuning from evidence, the kind of detection engineering we cover separately. In one side-by-side against a customer's own analysts, the platform matched their determinations on 99.8 percent of more than 12,000 investigations.

A custom detection firing is usually a real signal about something specific to your environment, and it is the kind of alert you cannot afford to leave in a queue until someone is back at a desk. These are the alerts that most deserve a full, context-rich investigation the moment they arrive. An AI SOC platform delivers exactly that, on every one of them and at any hour, so the cohort your MDR leaves behind is no longer the part of your coverage that waits. If the custom detections in your SIEM are the coverage you most want eyes on, the next step is to see what a complete investigation of their alerts looks like in your own environment.

For the bigger picture, our comparison of MDR and an AI SOC platform and our criteria for evaluating MDR providers go into more depth.