Because enrichment is multiplicative, not additive. Every extra field is copied across every event, then indexed, stored, queried, and retained at scale. When identity and asset metadata are added broadly, the cost grows faster than the security value unless the organisation is selectively enriching only the events that need it.
Why This Matters for Security Teams
Enrichment is often treated as a low-risk improvement because adding user, host, application, or cloud context seems useful everywhere. The operational reality is harsher: each extra field increases ingestion size, indexing load, search latency, storage consumption, and retention cost. That matters most in SOC environments where NIST SP 800-53 Rev 5 Security and Privacy Controls expects logging to support accountability, yet does not require every event to carry every possible attribute.
The mistake many teams make is assuming that more context automatically means better detection. In practice, the value only materialises when the field is consistently populated, trusted, and actually used in triage or correlation. Otherwise, enriched logs become an expensive archive of data that analysts rarely inspect and tooling still has to process. Identity data can be especially costly when it is duplicated across every event instead of joined only where needed for investigation or policy enforcement.
Security teams also underestimate downstream effects. SIEM rules, SOAR playbooks, data lake pipelines, and compliance retention all inherit the larger payload. That can increase licensing, force storage tier changes, and slow incident review during high-volume periods. In practice, many security teams encounter the cost problem only after a retention extension, a cloud migration, or a sudden log-volume spike has already exposed it.
How It Works in Practice
Enrichment becomes expensive because the same context is handled repeatedly at multiple stages of the logging pipeline. A single IP address or identity attribute may be resolved at collection time, copied into a transport stream, parsed into the SIEM, indexed for search, retained for compliance, and replayed into analytics. That is why the cost curve is multiplicative rather than linear.
Good practice is to enrich selectively and define a purpose for each field before deployment. Teams typically get better results when they enrich only high-value events, such as authentication failures, privilege changes, admin actions, endpoint detections, and cloud control-plane activity. That approach preserves investigative context without forcing every telemetry source to carry the same payload.
- Enrich at the point where the data will be used, not everywhere the event travels.
- Prefer stable identifiers, such as account or asset IDs, over repeated descriptive text.
- Apply different enrichment levels for hot, warm, and cold retention tiers.
- Use joins or lookup tables where the platform supports them instead of flattening all context into the event.
- Validate that each enriched field improves detection, investigation, or compliance reporting.
Operationally, this should be tied to logging policy and data minimisation. If identity metadata is added, teams should confirm who owns the source of truth, how often it changes, and whether the field is required for a control objective. For control mapping, logging and monitoring expectations from CISA logging best practices are useful, but they still require local judgement about scope and cost.
These controls tend to break down when legacy collectors, rigid SIEM schemas, and always-on high-volume sources force every event into a fully enriched format because the platform cannot support selective enrichment or late binding.
Common Variations and Edge Cases
Tighter enrichment often increases operational overhead, requiring organisations to balance richer investigations against storage, licensing, and pipeline complexity.
There is no universal standard for how much enrichment is enough. For fraud monitoring, identity and device context may be worth the extra cost because precision matters. For packet-heavy, machine-generated, or high-frequency telemetry, broad enrichment often provides little marginal value and can crowd out the signals analysts actually need. Current guidance suggests aligning enrichment depth to use case rather than enforcing a single organisation-wide standard.
Edge cases matter. In cloud-native environments, tags and labels can drift quickly, so enrichment may be stale by the time an event is queried. In federated identity environments, user attributes can change between event creation and investigation, which makes over-reliance on copied fields risky. In regulated environments, privacy and retention requirements can also limit how much identity detail can be stored in clear text, so some teams should prefer tokenised references or delayed lookups.
The practical test is simple: if a field is not used in a detection, investigation, or reporting workflow within a defined time window, it is usually a cost centre rather than a control. Teams should also review whether the same context can be derived at query time from identity, CMDB, or cloud inventory sources instead of being embedded into every event. For systems with autonomous agents or AI-driven operations, the same discipline applies to agent identity and action logs: preserve what is needed for accountability, not every available attribute.
Where enrichment is tied to compliance evidence, teams should validate that the retained format still supports review and audit. For privacy-sensitive datasets, the right answer is often a narrower log schema plus controlled enrichment on demand, not maximal enrichment everywhere.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Logging and monitoring depend on usable telemetry without excessive cost. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit events should be selected to meet accountability needs without over-logging. |
Choose audit fields and event types that support control objectives, not every possible attribute.
