Ownership should sit with security leaders who can balance detection needs, cost, and analyst capacity, not with engineering alone. The decision affects incident readiness, retention policy, and visibility across identity, cloud, and application telemetry, so it needs joint accountability from SOC and platform teams.
Why This Matters for Security Teams
Filtering logs before they reach Microsoft Sentinel is not just a storage decision. It changes what the SOC can detect, how quickly analysts can investigate, and whether evidence remains available for incident response and compliance. If the wrong data is dropped, security teams can lose context for lateral movement, privilege abuse, or identity-driven attacks that only become visible when multiple telemetry sources are correlated. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that logging and monitoring must support accountability, not just collection volume.
The real challenge is that filtering decisions sit between security, platform, and finance. Engineering teams may optimise for ingestion cost or noise reduction, while security teams need retention, fidelity, and investigative depth. That tradeoff becomes sharper in environments with identity-heavy risk, because access misuse often appears ordinary until a broader timeline is reconstructed. In practice, many security teams encounter missing evidence only after they need to confirm an incident, rather than through intentional logging design.
How It Works in Practice
Ownership should be assigned to a security leader with SOC responsibility, with platform and application teams accountable for implementation details. That owner should define what is safe to filter, what must be retained, and which fields are required for detection engineering, forensics, and compliance. The practical test is simple: if a log source could help answer who acted, what changed, when it happened, and whether privilege was involved, it should not be removed without explicit review.
Security teams usually separate filtering into three layers. First is source-level reduction, where obviously low-value debug noise is dropped. Second is transformation, where fields are normalised, masked, or selectively enriched. Third is routing, where high-value events are sent to Sentinel and lower-value events may go to cheaper storage or shorter retention. That approach helps manage ingestion costs without collapsing visibility. Microsoft’s own Microsoft Sentinel documentation is useful for understanding ingestion, analytics, and data connector behaviour, but it does not replace a local decision model for risk-based filtering.
- Classify log sources by investigative value, regulatory requirement, and alert dependency.
- Protect identity, authentication, privilege, admin action, and application audit trails from aggressive filtering.
- Use suppression rules for repeated noise, not for events that preserve attacker context.
- Review filtering changes with SOC use cases, not only with platform cost owners.
For stronger governance, many organisations align log filtering to broader control expectations in the CIS Controls v8 and to retention and monitoring requirements in security policy. The most effective operating model is a change-controlled review process that treats filtering as a detection design decision, not a storage optimisation task. These controls tend to break down when multiple teams can alter pipelines independently, because the resulting gaps are hard to detect until an investigation needs the missing fields.
Common Variations and Edge Cases
Tighter filtering often reduces cost and analyst fatigue, but it also increases the risk of blind spots, so organisations must balance operational efficiency against forensic completeness. There is no universal standard for the exact fields every Sentinel deployment must keep, because requirements vary by threat model, sector, and regulatory pressure. Current guidance suggests the safest approach is to preserve high-signal security telemetry and only filter low-value repetition after validation.
Some environments need stricter retention than others. Financial services, critical infrastructure, and identity-heavy SaaS platforms often need more conservative filtering because auditability and incident reconstruction matter more than savings. In hybrid or multi-tenant environments, filtering can also be complicated by shared pipelines, duplicate events, and inconsistent schema quality. Where identity and privilege are central to risk, security teams should be especially cautious with authentication logs, role changes, and admin activity. If those events are compressed too early, correlation across cloud, endpoint, and identity sources becomes unreliable. For additional control mapping, CIS Controls v8 provides a practical baseline for logging and monitoring discipline.
The edge case that most often creates trouble is a fast-moving incident response environment where filtering rules were approved for day-to-day noise reduction but never revisited after the threat landscape changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 | Logging visibility underpins continuous monitoring and detection coverage. |
| MITRE ATT&CK | T1078 | Valid account abuse often depends on identity logs that teams may filter out. |
Preserve telemetry that supports continuous monitoring before optimizing ingestion costs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
