Should organisations keep routing logic inside the SIEM or move it upstream?

Why upstream routing usually beats SIEM-native routing

routing logic belongs as close as possible to the telemetry source, because that is where organisations can normalise formats, enrich events, and apply transport decisions before the data is locked into a single analytics platform. Once routing is embedded in the SIEM, source design becomes coupled to one tool, which makes future SIEM changes slower, more expensive, and easier to break.

Upstream routing also gives security teams a cleaner separation between event collection, event shaping, and detection. That separation matters when log sources have different retention needs, schema requirements, or destinations, because the SIEM should receive the data it needs without becoming the place where every integration rule lives.

In practice, this is the difference between using the SIEM as a consumer of prepared telemetry and using it as the control plane for telemetry architecture. The first model preserves portability; the second often creates hidden technical debt that only shows up during migrations, mergers, or tool replacement.

What changes operationally when routing moves upstream

Upstream routing changes more than implementation location. It changes who owns the logic, how changes are tested, and how much blast radius a platform switch creates. If routing decisions are made in a collector, gateway, or pipeline layer, teams can standardise rules once and deliver the same output to multiple destinations, which is useful when security, observability, and compliance teams do not share identical downstream requirements.

It also improves schema stability. A routing layer can preserve raw events, branch them by use case, and apply transformations consistently before the SIEM sees them. That reduces the risk that one detection team quietly changes parsing or enrichment in a way that breaks another team's searches, dashboards, or alerts.

This approach is especially practical when telemetry volumes are high or when organisations expect to change vendors over time. The more expensive the SIEM, the more valuable it is to keep source logic vendor-neutral and avoid embedding business rules where they are hardest to extract.

Where SIEM-native routing still makes sense

Keeping routing inside the SIEM is still defensible when the routing logic is lightweight, the environment is small, and the organisation genuinely expects the SIEM to remain stable for the long term. In those cases, the convenience of a single operational surface may outweigh the cost of tighter coupling.

It can also be reasonable when the SIEM is the only place where analysts can easily inspect the effects of routing decisions and the routing rules are tightly bound to detection content rather than source plumbing. Even then, the team should be clear that the SIEM is serving both as analytics platform and as an integration layer, which raises the maintenance burden.

Sumo Logic breach 2023 is a useful reminder that log platforms depend heavily on credential hygiene and stable integration design, so any routing model should minimise the number of places where keys, tokens, and access paths have to be maintained.

Risk and Threat Considerations

Routing logic inside the SIEM can create concentration risk, because a single platform then controls both data handling and detection visibility. If the SIEM changes, fails, or is migrated poorly, organisations can lose telemetry consistency, miss detections, or create blind spots in downstream monitoring.

Failure mechanism: Routing rules, parsers, and enrichers become tightly coupled to one vendor's data model or pipeline behaviour, so a platform change or source update breaks event delivery or alters what gets analysed.

Impact: Detection fidelity drops, migration projects become riskier, and organisations may keep legacy integrations longer than planned because the routing logic is too expensive to recreate elsewhere.

Practitioner Guidance

What to prioritise: Keep transformation and routing decisions upstream when they affect multiple sinks, multiple teams, or future SIEM portability. Treat the SIEM as the place to detect and investigate, not the only place where telemetry can be shaped.

What to verify: Confirm that routing rules are version-controlled, testable, and observable outside the SIEM, and that raw telemetry can still be recovered if the downstream destination changes. If a rule cannot survive a platform swap, it is probably too deeply embedded.

Practitioner takeaway: The key decision is not where routing is easiest today, but where it is cheapest to change safely later, because telemetry architecture should outlast any single SIEM product.

Related resources from NHI Mgmt Group

• Should organisations keep expensive retention in the SIEM or move it elsewhere?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?