# Your Threat Intelligence Is Useless Because Your Org Chart Says So

I spent an hour last week with a detection engineer at a Fortune 500 company. Brilliant person. Deep technical skills. Her team identifies threat actor behaviors, writes comprehensive intelligence reports, documents exactly what needs to be detected. Then she waits for the same attack to happen again before building the detection rule.

"We need ammo," she told me. "If it only happens once, we can't get the detection team's attention."

At Stripe—one of the most sophisticated security organizations in technology—the detection team can deploy a maximum of five rules per week. Not because of technical limitations in their SIEM. Because SOC analysts don't have enough context to trust new alerts. The bottleneck isn't computing power. It's organizational design.

This isn't an isolated problem. It's the pattern I'm seeing everywhere in enterprise security right now.

## The Pattern: Intelligence Without Execution

The security professionals I talk to every week describe the same frustration from different angles. Threat intelligence teams operate with one set of metrics—reports published, IOCs catalogued, research requests fulfilled. Detection engineering teams answer to completely different numbers—false positive rates, mean time to detect, alert accuracy.

In small security teams, this problem doesn't exist. When you have five people, the person who finds the threat writes the detection rule and deploys it themselves. But as companies scale past fifteen or twenty security staff, the organizational divide appears. Intelligence sits in one silo. Detection engineering in another. The SOC in a third.

One security leader described it perfectly: "The pipeline only exists when the team is very small because you'll write it and just deploy it. But as a company grows larger, the detection team has their own priorities, their own issues, their own metrics. The intelligence team has their own metrics. The gap between them is where threats live."

Kroll tried to solve this by building a detection engineering team positioned explicitly between incident response and the SOC. The team's job was to take case data from actual incidents, build detections, and deploy them into the SOC platform. Even with that intentional organizational design, the initiative struggled to deliver consistent results.

## The Data: Measuring the Gap

The numbers confirm what the conversations reveal. Research from enterprise security operations shows the average time from threat intelligence report to deployed detection rule runs 2-3 weeks in most organizations. Manual processes, approval workflows, and context handoffs create delays measured in weeks while threat actors operate in hours.

The organizational structure data is revealing. According to recent analysis of enterprise security teams, 58% of detection engineering functions report to SecOps leadership rather than sitting within threat intelligence. This separation creates the competing priorities that security professionals describe—different leadership chains, different quarterly objectives, different success metrics.

The metrics themselves tell the story. Threat intelligence teams measure output: number of reports published, intelligence requests fulfilled, indicators of compromise disseminated. Detection teams measure accuracy and operational impact: rule precision, false positive rates, mean time to detect. A threat intelligence analyst gets credit for publishing a detailed report. A detection engineer gets penalized if that report becomes a rule that generates noisy alerts.

The trust problem runs deeper than organizational charts. A 2025 survey of SOC analysts found only 34% trust AI-generated or automated detection rules without manual review. The primary reason isn't skepticism about the technology—it's lack of context. When a new detection rule appears in the queue without the surrounding story of why it matters, what behaviors it's targeting, or what investigation findings led to its creation, analysts can't distinguish signal from noise.

The few organizations that have solved this problem did it through radical co-location rather than better tools. Companies like Palantir and Netflix embedded detection engineers directly within threat intelligence teams with shared metrics and leadership. Their deployment time dropped to under 48 hours—not because they bought different security platforms, but because they eliminated the organizational handoff where context dies and urgency evaporates.

The time from identifying a threat to deploying protection against it isn't a technical problem. It's not a tooling gap that vendors can solve with better integration APIs. It's an organizational design failure that creates exactly the conditions where enterprises get breached by known TTPs while their threat intelligence reports sit on a shelf waiting for attacks to happen twice. ## What This Means for Your Career

If you're in detection engineering or threat intelligence right now, you're sitting in one of two positions—and it matters which one.

Detection engineers who can demonstrate deployed detections that caught real threats are increasingly valuable. Not the number of rules you've written. Not the sophistication of your queries. Deployed detections that produced investigations that mattered. If your current role doesn't give you that metric, you're building a resume that looks identical to every other detection engineer who spent their time tweaking SIEM configurations. The people getting hired into senior detection roles right now can walk into interviews with stories about the pipeline they built from intelligence to deployment, not just the technical artifacts they created.

For threat intelligence analysts, the gap is your opportunity. The organizations that will pay premium compensation in the next two years aren't looking for people who write better reports. They're looking for intelligence professionals who understand how to work backward from what SOC analysts actually need. That means learning enough about detection engineering to translate your intelligence into actionable queries, understanding the operational constraints that make your current reports sit on shelves, and being able to articulate the business impact of faster deployment cycles. The hybrid intelligence-engineering role is already emerging at companies that are serious about this problem.

The timing advantage matters more than people realize. Companies that just went through reductions are measuring everything right now. Every tool, every team, every process gets scrutinized when budgets tighten. That scrutiny creates two outcomes: teams that can't demonstrate impact get cut deeper in the next round, and teams that solve expensive problems get resourced even in down markets. The intelligence-to-detection gap is expensive. It shows up in breach post-mortems as "we had intelligence about this TTP but hadn't deployed detection coverage yet." If you can position yourself as the person who closes that gap, you become much harder to cut.

## What to Watch For

Pay attention to how detection engineering roles are being positioned in job descriptions over the next six months. If you start seeing requirements that combine threat intelligence experience with detection deployment metrics, that's your signal that enterprises are trying to solve this structurally. Those hybrid roles will command significant premiums because they're rare.

Watch for reorganizations that move detection engineering closer to or into threat intelligence teams. The companies figuring this out aren't buying new tools—they're redrawing org charts. If your company announces that kind of structural change, that's either your opportunity to step into the gap or your signal that you're on the wrong side of a team that's about to become less relevant.

The other signal: if your security leadership starts asking about time-to-deployment metrics for detections instead of just asking about report volume or alert accuracy, someone in your organization has figured out what the actual problem is. That conversation creates opportunities for people who've been frustrated by the current structure.

## The Real Cost

The organizational divide between finding threats and stopping them isn't just an operational inefficiency. It's the reason security professionals describe feeling like they're constantly behind despite working in well-resourced programs at sophisticated companies. The detection engineer waiting for attacks to happen twice before she can get attention isn't failing at her job. She's succeeding within a system designed to slow down the exact thing security teams exist to do.

The companies that fix this won't do it by buying better threat intelligence platforms or more advanced SIEM capabilities. They'll do it by putting the person who identifies the threat in the same room—reporting to the same leader, measured by the same metrics—as the person who deploys the detection. Everything else is security theater with better tooling.