Why do raw logs and repeated enrichment increase risk in Sentinel migrations?

Raw logs are expensive because Sentinel bills on ingested volume, so every duplicate field, noisy event, or repeated enrichment step adds recurring cost and unnecessary storage. Recomputing context inside the SIEM also wastes compute that could have been applied once upstream. Normalizing and enriching before ingestion lowers spend and improves consistency across detection, correlation, and compliance workflows.

Why raw logs become expensive in Sentinel migrations

Raw, minimally processed telemetry tends to create a migration penalty because the SIEM has to ingest every duplicate, noisy, and low-value event as if it were equally important. In Microsoft Sentinel, cost is driven by data volume, so the more you send and store unchanged, the more you pay for ingestion, retention, and later search across fields you may never use.

That matters because many source systems already emit overlapping records, repeated metadata, and verbose payloads. If the migration simply forwards those events without filtering or shaping them first, teams pay repeatedly for the same information while making incident queries slower and less consistent.

How repeated enrichment multiplies the same problem

Enrichment is valuable when it is done once at the right layer, but repeated enrichment inside the SIEM can turn one event into several more expensive processing steps. Each pass may add new fields, expand payload size, or recompute context that should have been joined upstream, increasing both ingestion footprint and operational overhead.

The practical issue is not enrichment itself, it is duplication of effort. If the same asset, owner, geo, or threat context is attached in multiple pipelines, the migration may produce inconsistent records, redundant storage, and more brittle detections because analysts are forced to reconcile several versions of “the same” event.

What changes when you normalize before ingestion

Normalization and upstream enrichment reduce risk by making the SIEM a consumer of prepared security data rather than a place where every transformation happens on demand. That usually lowers recurring spend, reduces schema drift, and improves the reliability of correlation rules because fields are shaped consistently before they enter detection workflows.

For migration planning, the key test is whether a field or enrichment step changes the detection decision. If it does not, it should usually be removed, deduplicated, or applied earlier in the pipeline. If it does, the goal is to preserve the signal once, not to recreate it every time the data is queried.

Risk and Threat Considerations

Excess raw logging and repeated enrichment create a compound exposure: higher spend, larger storage footprint, slower searches, and weaker control over what actually reaches the detection layer. The risk is especially visible during migrations, when teams often over-collect to avoid missing anything and then discover that volume growth makes investigation and retention harder to sustain.

Failure mechanism: Duplicate events, verbose source payloads, and repeated joins inflate ingestion volume and reprocess the same context multiple times, which raises cost and can obscure the most relevant telemetry.

Impact: Detections become more expensive to run, analysts lose time to noisy correlation, and retention or coverage decisions may be forced by budget rather than security need.

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	DE.CM-01 — Monitoring for anomalies and events	Raw log volume and repeated enrichment directly affect event monitoring quality and cost.
	GV.RM-01 — Risk management strategy established	Sentinel migration logging choices should be driven by explicit cost and detection risk tolerance.
Recommendation — Reduce telemetry duplication so monitoring remains actionable and affordable. Set collection and enrichment thresholds that match security and budget risk appetite.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Normalization and deduplication improve the usefulness of audit data for review and analysis.
Recommendation — Filter and structure audit data so analysts can review it without redundant noise.
CIS Controls v8	CIS-8 — Audit Log Management	The topic is about managing log volume, quality, and retention efficiency.
Recommendation — Centralize, filter, and retain logs so only useful telemetry reaches the SIEM.
ISO/IEC 27001:2022	A.8.15 — Logging	Sentinel migrations hinge on how logs are collected, normalized, and retained.
Recommendation — Define logging requirements that prevent unnecessary volume and preserve usable context.

Practitioner Guidance

What to prioritise: Identify the top log sources that drive Sentinel cost and classify each field as needed for detection, needed for investigation, or unnecessary at ingest time. That gives you a defensible cutoff for what should be dropped, summarized, or enriched upstream.

What to verify: Check whether an enrichment step is truly adding new security value or simply replaying the same lookup at multiple stages. A good migration design preserves context once, in a stable form, and avoids re-deriving it inside the SIEM unless the result materially changes the alert.

Practitioner takeaway: The migration win is not “more raw data in a new platform”, it is better signal economics, where every additional byte and transformation step can justify its ongoing cost.