Yes, when the environment has multiple data sources and several downstream security tools. Pipeline teams should own normalization, enrichment, and routing, while detection teams should focus on analytic logic. That separation reduces duplication and makes tool replacement less disruptive.
Why the split works when telemetry is a shared service
Telemetry engineering and detection engineering solve different problems. Telemetry engineering turns raw events into usable, trustworthy data by handling collection, parsing, normalization, enrichment, routing, and retention. Detection engineering consumes that data to write and maintain analytic logic, tune signals, and validate whether a pattern is actually worth alerting on. When one team owns the pipeline and another owns the logic, each can optimise for its own outcome without constantly trading off the other.
The separation becomes more valuable as the environment grows. Multiple sources, multiple log schemas, and multiple downstream tools create a data product problem before they create a detection problem. A SANS Security Resources approach is useful here because it reflects the operational reality that detection work depends on stable upstream telemetry quality and on people who can iterate quickly on analytic content.
It also helps preserve a clean ownership boundary. Telemetry teams can standardise field naming, parsing rules, enrichment logic, and transport decisions so that detections are not rewritten every time a source changes. Detection teams can then focus on the question that actually matters: does this analytic meaningfully represent malicious or risky behaviour, and does it still hold after tuning, suppression, or a product replacement?
What changes in practice when the functions are separated
With separate ownership, the telemetry layer becomes a shared platform and the detection layer becomes a consumer of that platform. That changes how work is prioritised. Pipeline work is judged by data completeness, latency, normalization consistency, schema stability, and routing correctness. Detection work is judged by analytic fidelity, coverage, precision, and response value. Those are related, but they are not the same success criteria.
This split also reduces hidden coupling. If a detection author must personally fix parsing, map fields, and maintain enrichments, analytic quality usually suffers because the work becomes brittle and expensive. If telemetry engineers are not responsible for detection outcomes, they can make changes with better change control and a clearer view of downstream blast radius. That makes MITRE D3FEND a useful mental model for the defensive side, because it encourages practitioners to think in terms of distinct defensive functions rather than one blended “security engineering” activity.
The practical upside is portability. When telemetry is well abstracted, teams can replace a SIEM, add a lakehouse, or shift alerting engines without redoing every detection from scratch. Detection logic still needs translation, but the costly part, producing consistent and trustworthy event structure, stays insulated from the tool change.
Where teams get the boundary wrong
The main failure mode is treating telemetry engineering as a back-office logging task and detection engineering as an isolated content-writing function. In that model, telemetry never gets enough attention for data quality, and detections never get enough context for analytic design. The result is duplicated parsing, inconsistent field mapping, and alerts that break whenever a source, parser, or vendor changes.
A second failure mode is over-centralising detection logic inside the pipeline team. That usually produces strong plumbing but weak analytic ownership, because the people closest to the data are not always the people best placed to judge behavioral significance. The opposite problem also appears when detection teams directly edit every ingest rule and enrichment path. That creates bottlenecks, slows response to source changes, and makes the detection stack harder to govern.
Teams should also watch for false certainty. Clean telemetry does not automatically mean good detections, and good detections do not automatically mean the underlying data is trustworthy. A useful operating rule is to make telemetry changes versioned and testable, then validate detections against the specific normalized fields they depend on, not against raw source output that may never reach production unchanged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Separating telemetry and detection depends on clear service and ownership boundaries. |
| ID.AM-01 — Physical Devices and Systems Inventory | Telemetry engineering relies on knowing which sources and systems feed the pipeline. | |
| DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Detection engineering depends on trustworthy monitoring data and coverage from many sources. | |
| Recommendation — Define telemetry and detection as distinct operational services with explicit ownership and interfaces. Maintain an accurate inventory of log-producing systems and data sources before scaling detections. Use normalized telemetry to support continuous monitoring and detection content validation. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The split hinges on collecting and managing events before detection logic is applied. |
| AU-6 — Audit Review, Analysis, and Reporting | Detection engineering is about analyzing logged data for security-relevant patterns. | |
| Recommendation — Define event logging requirements separately from analytic use cases. Assign alert logic and review expectations to the detection function, not the ingest function. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Telemetry engineering is the control layer that collects, normalizes, and preserves audit data. |
| Recommendation — Centralize log collection and normalization before building content on top of it. | ||
| MITRE ATT&CK | Adversary Tactics, Techniques, and Procedures | Detection engineering is usually built around ATT&CK-aligned adversary behavior. |
| Recommendation — Map analytics to attacker techniques and use that mapping to validate coverage gaps. | ||
Practitioner Guidance
What to prioritise: Separate the ownership boundary where the work diverges, not where the org chart is convenient. Telemetry engineering should own ingestion contracts, normalization, enrichment, and routing; detection engineering should own analytic intent, tuning, and validation.
What to verify: Confirm that every high-value detection depends on documented fields, stable source mappings, and a known data contract. If a detection cannot survive a parser or platform change without manual heroics, the boundary is not yet mature.
Common mistake: Do not let every analyst edit the pipeline and every pipeline engineer author detections. Shared understanding is good; shared ownership of every layer usually produces ambiguity, slower change, and weaker accountability.
Practitioner takeaway: Separate the functions when telemetry is reused by multiple sources or tools, because the best detection programme is usually built on a stable data product, not on repeated one-off fixes.
Related resources from NHI Mgmt Group
- What do security teams get wrong about IOC-led detection engineering?
- How should security teams separate detection from remediation in AI-assisted security operations?
- How should security teams improve detection engineering for AI-accelerated attacks?
- How should security teams govern telemetry schema drift in AI-driven detection pipelines?