They should keep it as close to the source as throughput and governance allow. Centralising everything in the SIEM increases cost and delays context, while source-adjacent enrichment gives the pipeline enough information to route, tier, and retain data intelligently.
Why Source-Adjacent Enrichment Usually Wins
Enrichment is most effective when it happens near the system that first sees the event, record, or request. That is where the raw context still exists, so you can attach routing data, confidence, ownership, tenant, policy, and retention hints before those signals are flattened or lost. A central platform still has value, but it should receive enriched events, not become the only place where meaning is added.
Pushing every enrichment decision into a SIEM or other central pipeline usually turns a context problem into a throughput and cost problem. You end up paying to move, store, and reprocess large volumes of low-value data, while incident responders wait longer for the fields that would have helped sort noise from priority.
What Changes When Enrichment Is Close to the Source
Source-adjacent enrichment improves the quality of downstream decisions. It lets pipelines classify early, apply retention rules sooner, suppress duplicate noise, and route higher-value events to the right destination without forcing every consumer to reinvent the same lookups. This is especially useful when the original system already knows business context that downstream tooling does not.
The trade-off is that enrichment logic becomes part of the application, collector, or processing edge, so ownership and change control matter. If the source-side rules are wrong, stale, or inconsistent, the error propagates quickly. That is why the question is not “centralise or decentralise” in the abstract, but “where does the signal become useful earliest with the least operational drag?”
How to Decide Where Each Enrichment Step Belongs
Keep enrichment close to the source when the data is cheap to interpret there, the context is local, and the result affects routing, filtering, or retention. Centralise only the parts that require shared policy, global correlation, or uniform governance across many producers. In practice, the best pattern is often layered enrichment: basic context at the edge, normalisation and policy enforcement in the pipeline, and correlation in the central analytics layer.
That layered model maps well to modern detection and data-engineering practice. For example, teams can attach event ownership, environment, asset tier, and trust zone early, then let the SIEM or data lake handle cross-source correlation. When enrichment touches trust boundaries or access decisions, treat it as governed logic rather than convenience code, because bad enrichment can create blind spots or misroute sensitive data.
Risk and Threat Considerations
Centralising all enrichment creates a concentration point for cost, latency, and failure. It also increases the chance that poor or delayed context will affect alerting, retention, or investigation quality across the whole program. When enrichment includes access decisions or sensitive metadata, a weak central control plane can also become an attractive target for tampering or abuse.
Failure mechanism: The pipeline depends on a small number of central services to add meaning after ingestion, so any outage, schema drift, lookup failure, or policy bug affects many producers at once. Attackers and internal errors alike can exploit that dependency by forcing the system to process data before it is properly classified or routed.
Impact: Analysts get noisier queues, expensive storage grows faster than it should, and the organization may miss the chance to drop, tier, or protect data while it is still close to the source. In the worst case, a bad central enrichment layer turns into a single point of failure for visibility and governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-11 — Integrity Checking Mechanisms | Source-adjacent enrichment affects the integrity of downstream data handling. |
| PR.AA-05 — Identity and Access Management | Enrichment often carries ownership or trust context that shapes access and routing. | |
| GV.PO-01 — Policies, Processes, and Procedures | The centralisation choice is a governance and operating-model decision. | |
| Recommendation — Validate enriched event data early so downstream systems can trust routing and retention decisions. Apply access and trust rules where enriched context is produced, not only at the SIEM. Define which enrichment steps are local, which are shared, and who owns each change. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Enrichment is closely tied to what gets recorded and how events are made useful. |
| CM-2 — Baseline Configuration | Distributed enrichment logic needs controlled baselines and versioning. | |
| Recommendation — Specify source-side event fields so logs arrive with the context analysts need. Baseline enrichment schemas and processing rules to prevent drift across sources. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | The question is partly about where logging context is added for later analysis. |
| A.8.16 — Monitoring activities | Enrichment determines how quickly monitored events become actionable signals. | |
| Recommendation — Capture operationally useful context as early as possible in the logging path. Feed monitoring systems with enriched events that already include routing and priority context. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Placement of enrichment changes the value and usability of audit logs. |
| Recommendation — Ensure audit logs retain source context before central collection and analysis. | ||
Practitioner Guidance
What to prioritise: Put the enrichment fields that drive immediate routing, retention, or access decisions as close to the producer as possible, then centralise only the shared policy and correlation layers. That gives you the biggest reduction in latency and rework without scattering governance everywhere.
What to verify: Confirm that every source-enriched field has an owner, a schema, and a clear fallback path when the lookup fails. If a field is important enough to steer processing, it is important enough to version and test like production logic.
Common mistake: Teams often move enrichment into the SIEM because it feels simpler, then discover they have created a costly bottleneck that delays triage and weakens data quality. The better test is whether the information is already known at ingest time and materially changes what should happen next.
Practitioner takeaway: Centralise policy, not every enrichment decision. Keep the earliest useful context near the source, and reserve the central platform for cross-source correlation and governance that truly needs a broader view.
Related resources from NHI Mgmt Group
- How do security and data teams decide when to centralise processing versus keep checks close to the source?
- Should teams centralise authorization logic in one engine or keep it close to the application?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?