How should security teams decide which logs deserve SIEM ingestion in Microsoft Sentinel?

How to choose the logs that belong in Microsoft Sentinel first

The right test is whether a log source helps an analyst decide faster, prove or disprove an intrusion, or reconstruct a timeline after the fact. In practice, that means prioritising identity, privilege, boundary, and high-signal threat telemetry before less actionable background data. Sentinel is most valuable when it receives the records that change an investigation, not every record that exists.

That ordering also helps separate detection value from storage value. A source can be important for compliance, troubleshooting, or long-term forensics without being the best candidate for immediate SIEM ingestion. If a log rarely changes triage, enrichment, correlation, or incident scoping, it is usually better treated as cheaper retained telemetry than as first-line Sentinel input.

One useful way to think about this is by decision impact. Authentication logs, privileged actions, admin-plane activity, and external boundary events often answer the questions analysts ask first: who acted, from where, with what privilege, and against which asset. Routine heartbeats, noisy health checks, and low-context application chatter usually matter only after a case has already been opened. For a broader ingestion strategy, the SIEM Guide covers use cases, log onboarding, and retention trade-offs.

Why volume is a poor proxy for security value

High-volume logging can make a platform look well instrumented while reducing the quality of actual investigation. When every source competes for the same SIEM budget, the result is often slower searches, noisier alerts, weaker retention economics, and less room for the telemetry that matters most during an incident. The better question is not “can we ingest it?” but “what investigation decision does this record support?”

Security teams should be wary of ingesting logs simply because they are available or easy to connect. The easiest sources to onboard are often the least discriminating. A log source deserves Sentinel ingestion when it materially improves one of three outcomes: detection fidelity, incident scoping, or reconstruction of attacker behaviour. If it does none of those, the same data may still have value, but not necessarily at SIEM price points.

Security data pipeline design matters here because filtering, normalisation, and routing should happen before the SIEM, not inside it. That keeps Sentinel focused on the data that drives detections and investigations while preserving other telemetry in a cheaper tier for targeted retrieval.

What should stay in Sentinel, and what should not

The strongest candidates for Sentinel ingestion are logs that show authentication attempts, privileged changes, service or automation actions that can affect security posture, external attack surface events, and telemetry already tied to common detection logic. These sources often support correlation across users, devices, cloud control planes, and applications, which is where SIEM value is highest.

Lower-priority sources are usually repetitive operational logs, routine application chatter, or records that rarely change response decisions. Those can still matter, especially for compliance or deep forensics, but they do not always justify immediate SIEM ingestion. In many environments, the right answer is selective ingestion plus longer-term retention elsewhere, so that analysts can query the data when needed without paying to index every event up front.

Microsoft Sentinel-specific design choices also matter. The Microsoft Sentinel Guide explains the platform’s roles, analytics rules, data tiers, connectors, and playbooks, which are the pieces that determine whether a source belongs in fast-path detection or in a cheaper retention path. That distinction is central to avoiding “ingest everything” sprawl.

Risk and Threat Considerations

Over-ingestion creates a hidden security risk because it dilutes attention and budget. If low-value telemetry crowds out identity, privilege, and boundary logs, analysts lose the records most likely to expose account misuse, lateral movement, or early compromise. Under-ingestion creates the opposite problem, where critical events are missing from the investigative record and incident reconstruction becomes guesswork.

Failure mechanism: Teams either over-index on source availability or under-rank logs by investigative value, so Sentinel fills with expensive noise while the telemetry needed to confirm compromise arrives too late or not at all.

Impact: Triage slows, alerts become harder to trust, and response quality drops because the SIEM no longer contains the records that show who did what, when, and from where.

Practitioner Guidance

What to prioritise: Start with sources that help answer the first questions in an investigation, especially authentication, privileged access, admin actions, and boundary telemetry. Those sources usually repay SIEM cost fastest because they support both alerting and reconstruction.

Decision rule: If a log source cannot plausibly change a triage decision, a scoping decision, or a post-incident timeline, route it away from premium Sentinel ingestion and keep it in a lower-cost retention layer instead.

What to measure: Track how often each ingested source contributes to detections, investigations, or confirmed incident timelines. Sources that are rarely queried, rarely correlated, or never decisive are strong candidates for demotion.

Practitioner takeaway: The right ingestion model is selective by design, because Sentinel should be fed with the logs that change security decisions, not the logs that merely increase storage volume.

Related resources from NHI Mgmt Group

• Microsoft Sentinel
• How should security teams decide between custom tables and native schema mapping when sending logs to Microsoft Sentinel?
• How should security teams control ingestion costs when migrating logs into Microsoft Sentinel?
• How should security teams decide which logs belong in a SIEM analytics tier?