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.
What Makes a Log Worth Paying Sentinel to Ingest?
Log selection should be driven by whether the data can materially improve detection, triage, or reconstruction. For microsoft sentinel, the strongest candidates are logs that show authentication events, privileged activity, boundary crossings, and high-confidence threat signals because those records often answer the first questions during an investigation: who acted, from where, with what privilege, and what changed. That aligns with the broader control expectation to collect evidence that supports monitoring, accountability, and incident handling, rather than retaining everything by default. NIST SP 800-53 Rev 5 Security and Privacy Controls
Teams often mistake source importance for investigative value, but a noisy source that rarely changes decisions is usually a better candidate for cheaper retention than for full siem ingestion. The practical question is not whether a log is technically available, but whether it is likely to change analyst action, shorten containment, or improve confidence in what happened. In practice, many security teams discover the value gap only after they have already paid to ingest years of low-signal telemetry.
How Sentinel Ingestion Decisions Work in Practice
A useful way to decide is to separate logs into three buckets. First, ingest continuously when the stream is central to detection or response, such as sign-in events, privileged role activity, conditional access outcomes, endpoint detections, and perimeter or ingress-egress telemetry. Second, retain outside the SIEM when the log is mainly needed for occasional forensic lookups, compliance evidence, or trend analysis, especially if it is high volume and low actionability. Third, exclude or sample data that duplicates stronger telemetry or adds little investigative context.
- Prioritise logs that let analysts confirm identity, privilege, time, and path of execution.
- Promote boundary and control-plane logs when they reveal trust transitions or policy enforcement.
- Defer routine informational logs that rarely contribute to an alert, case, or timeline.
- Use lower-cost storage for records needed for audit, reconstruction, or rare deep dives.
The hardest part is not classification, but proving that a log’s marginal value exceeds its ingestion cost. Sentinel works best when teams map each source to a specific analytic or investigative use case, then challenge any source that cannot support at least one of those uses. That keeps ingestion aligned to outcomes instead of vendor default templates. Where teams monitor cloud, identity, and endpoint estates together, the most valuable logs are often those that connect one trust boundary to another, because they let an analyst reconstruct an attack path rather than inspect isolated events. This guidance breaks down when organisations cannot define their top incidents or cannot preserve enough detail outside the SIEM to reconstruct them later.
When More Logging Creates Less Useful Security
Tighter SIEM ingestion discipline often increases governance effort, requiring organisations to balance detection depth against cost, parsing overhead, and analyst attention. That trade-off matters most for repetitive operational logs, verbose application traces, and sources that duplicate signals already captured elsewhere. The consensus is clear on one point: more data does not automatically mean better visibility, and in some environments it can slow detections by burying higher-value events under noise.
Edge cases arise when a log is weak on its own but becomes valuable only in correlation. For example, some control-plane or application logs look mundane until they are joined with identity or endpoint activity. In those cases, the right answer is not always full ingestion, but it is also not automatic exclusion. Teams should treat correlation value as a real criterion, then decide whether the join requires SIEM ingestion or can be handled through targeted collection and shorter retention. Another common exception is regulatory or audit-driven telemetry, where the operational value is limited but the evidence value is high; those logs may belong in governed retention rather than expensive analytic indexing. Guidance-vs-consensus note: there is broad agreement that high-signal security telemetry belongs in the SIEM, but there is no universal threshold for what qualifies as high-signal. That threshold depends on the organisation’s incident profile, environment size, and alternative retention strategy.
Risk and Threat Considerations
The main risk is not just storage cost. If Sentinel ingests too little of the right telemetry, security teams lose the ability to reconstruct identity abuse, privilege misuse, lateral movement, or boundary-crossing activity in time to respond effectively.
Failure mechanism: High-value events are either dropped because the source looks noisy, or drowned in a volume of low-value logs that delays correlation and analyst review. In both cases, the control failure is the same: the organisation assumes visibility exists because data is collected somewhere, but the data is not available in the place where detection and triage actually happen.
Impact: Alert fidelity drops, investigations become slower and less complete, and some attacks remain ambiguous because the timeline cannot be reconstructed from the retained evidence. That can turn a recoverable incident into a prolonged compromise or an unresolved trust failure.
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, CIS Controls v8 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 — Monitoring and Detection | Log ingestion supports ongoing monitoring of events and anomalies. |
| DE.AE-3 — Anomalous Events | High-value logs help detect and correlate anomalous activity. | |
| RS.AN-1 — Analysis | Investigative logs directly affect incident analysis and reconstruction. | |
| Recommendation — Prioritise logs that strengthen continuous monitoring and alert validation. Ingest telemetry that improves anomaly correlation and investigation. Keep logs that materially improve incident analysis and timeline reconstruction. | ||
| CIS Controls v8 | 8 — Audit Log Management | The question is fundamentally about which logs to collect and retain. |
| 13 — Network Monitoring and Defense | Boundary and threat telemetry are key candidates for SIEM ingestion. | |
| 17 — Incident Response Management | Retention choices affect triage speed and incident reconstruction. | |
| Recommendation — Define log collection criteria around audit value and operational necessity. Route boundary and threat-detection telemetry into central monitoring first. Retain telemetry that shortens containment and supports case reconstruction. | ||
| NIST IR 8596 | Incident Response Logging and Evidence Handling | Evidence usefulness depends on preserving logs needed for response and forensics. |
| Recommendation — Preserve the records your responders will need to reconstruct events. | ||
Practitioner Guidance
What to prioritise: Start with the log sources that support your most common investigations, not the noisiest systems. Authentication, privilege, boundary, and cloud control-plane events usually deserve the earliest ingestion because they anchor attribution and timeline reconstruction.
Decision rule: If a log source cannot credibly change triage, escalation, containment, or post-incident reconstruction, keep it out of expensive SIEM ingestion unless a specific compliance need overrides that choice.
What to verify: Confirm that every retained source maps to a named use case and that a cheaper retention tier still preserves the fields needed for later correlation. If a team cannot explain how it will use a log, it is usually over-collecting it.
Practitioner takeaway: The best ingestion strategy is selective by design: preserve the few streams that improve decisions, and treat the rest as evidence to retain, not data to index.
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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
