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

Start with investigative value, not source availability. Route authentication, privileged access, boundary, and high-confidence threat telemetry into Sentinel first, then push routine or low-value background logs to cheaper retention. The goal is to preserve the data most likely to change triage or incident reconstruction. If every log enters the SIEM, cost rises faster than detection quality.

Why This Matters for Security Teams

Sentinel ingestion decisions shape both detection quality and operating cost. If teams ingest every available stream, they often bury high-signal events under low-value noise, slow down investigations, and create expensive retention they rarely query. NIST SP 800-53 Rev 5 Security and Privacy Controls frames logging and monitoring as a control objective, but current guidance suggests the real challenge is selecting telemetry that can actually change a triage decision.

This matters most where secrets, service accounts, and automation are in play. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which means many teams are deciding what to ingest without first knowing which identities matter most. That pattern shows up in incidents like the Microsoft Midnight Blizzard breach, where identity activity and access paths were central to reconstruction. In practice, many security teams discover they needed better evidence after an incident has already forced them to reconstruct it.

How It Works in Practice

The practical test is not “is this log available?” but “would this log help prove, disprove, or prioritise an incident?” For microsoft sentinel, that usually means prioritising telemetry tied to authentication, privilege, boundary movement, and confirmed attack chains. Identity provider sign-ins, privileged role changes, conditional access failures, key vault access, firewall accepts or denies, and endpoint alerts often deserve higher ingestion priority than routine success logs or repetitive application health noise.

A useful approach is to score each source against four questions: does it expose privileged action, does it show cross-boundary movement, does it support high-confidence detections, and will it help reconstruct an incident timeline? If the answer is yes to at least one of those, it likely belongs in the SIEM. If the source is mostly operational, store it in cheaper retention unless a specific detection or investigation requires it.

• Ingest the smallest set of logs that still covers identity, privilege, and lateral movement.
• Keep long-tail or verbose application telemetry in low-cost storage with defined retrieval paths.
• Use Sentinel for sources that support correlation, not just collection.
• Review ingestion quarterly as attack paths, cloud services, and automation change.

For identity-heavy environments, the question often mirrors NHI governance: a lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging. That is why logs tied to service accounts, API keys, and OAuth app activity deserve special attention. These controls tend to break down when log schemas are inconsistent across cloud tenants and only a small subset of events can be reliably correlated in Sentinel.

Common Variations and Edge Cases

Tighter ingestion filtering often reduces cost, but it also increases the risk of under-instrumenting a new attack path, so organisations need to balance savings against investigative coverage. The tradeoff is especially sharp in hybrid estates, regulated environments, and agentic or automation-heavy platforms where behaviour changes quickly.

There is no universal standard for this yet, but current guidance suggests treating high-value log selection as a detection engineering exercise rather than a storage problem. For example, OAuth token misuse, privileged automation, and cloud control plane activity often merit ingestion even when the source volume is low, because the blast radius is high. By contrast, verbose success logs from stable business applications may be better kept outside the SIEM unless a known use case demands them.

Two practical exceptions matter. First, some low-frequency sources should still be ingested because they are uniquely evidential, such as admin audit trails or key management events. Second, some high-volume sources should be sampled or filtered at the edge, but only if the loss does not weaken alert fidelity. NIST’s logging controls support this risk-based approach, and NHI-focused incident patterns such as Code Formatting Tools Credential Leaks show why seemingly routine telemetry can become critical when secrets are exposed.

Related resources from NHI Mgmt Group

• How should security teams decide between custom tables and native schema mapping when sending logs to Microsoft Sentinel?
• How should security teams decide which logs belong in a SIEM analytics tier?
• How should security teams decide which SIEM logs stay in hot storage?
• How should security teams decide what identity data belongs in a hybrid SIEM?