They assume full ingestion automatically equals full visibility. In practice, unrestricted ingestion often creates higher cost, slower searches, and more noise, which can push teams to exclude entire sources. A better model is selective, policy-driven telemetry management that protects the highest-value evidence and routes everything else appropriately.
Why This Matters for Security Teams
The mistake is treating SIEM as a storage destination instead of a decision-support system. Once every log source is ingested without a governance model, teams often trade visibility for volume: costs rise, search performance degrades, and alert fidelity drops. The result is predictable. Analysts stop trusting noisy detections, and high-value evidence gets buried in low-value telemetry.
This matters because attackers do not need every log to operate effectively, but defenders often need the right logs at the right time to reconstruct identity abuse, lateral movement, or secret misuse. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a stronger signal than raw log volume when the goal is control, not accumulation. The better framing aligns with the NIST Cybersecurity Framework 2.0: identify what must be protected, measure what is most useful, and route evidence according to risk and operational need.
In practice, many security teams discover they have collected too much to investigate efficiently only after a real incident has already forced a search across an overloaded SIEM.
How It Works in Practice
Selecting telemetry is not the same as suppressing visibility. A mature program starts by classifying logs into three operational buckets: security-critical evidence, investigative context, and routine operational noise. Security-critical evidence includes authentication events, privilege changes, secret access, agent or service-account actions, cloud control-plane activity, and administrative commands. Investigative context supports correlation but may not need full-fidelity retention in the SIEM itself.
Current guidance suggests routing data by purpose rather than ingesting everything into one index. For example, high-value identity and secret-related events can flow into the SIEM with strict normalization and alerting, while verbose application traces may go to a lower-cost data lake with query access on demand. That approach preserves search performance and allows retention to match evidentiary value. NHI Mgmt Group’s Ultimate Guide to NHIs highlights how common NHI exposure is, which is why service-account and API-key telemetry should be prioritized over generic noise.
Practical controls usually include:
- Defining log tiers by use case, such as detection, forensics, compliance, and troubleshooting.
- Applying field-level filtering so identifiers, timestamps, and action types remain searchable even when payloads are archived elsewhere.
- Using normalization standards to keep different sources comparable before they enter the SIEM.
- Setting retention separately for active analysis and cold storage rather than applying one blanket rule.
- Reviewing exclusions regularly so “temporary” omissions do not become permanent blind spots.
That model supports the outcomes expected by NIST Cybersecurity Framework 2.0: better governance, stronger detection, and more defensible response. These controls tend to break down in highly distributed environments with SaaS sprawl and unmanaged machine identities because source ownership, schema consistency, and retention responsibility are fragmented.
Common Variations and Edge Cases
Tighter log control often increases governance overhead, requiring organisations to balance investigative depth against budget, storage, and analyst time. That tradeoff becomes harder in environments with regulatory retention demands, multiple business units, or rapidly changing cloud services.
One common exception is compliance-led logging, where teams must retain specific records even if they are low value for detection. Another is incident response, where some sources that are normally archived may need temporary full ingestion during an active investigation. Best practice is evolving on how much of that should be automated, but there is no universal standard for this yet; policy-as-code and routing rules are usually more defensible than ad hoc analyst decisions.
Another edge case is NHI-heavy infrastructure, where service accounts, API keys, and automation pipelines generate far more machine activity than human activity. In those environments, the real question is not whether to ingest everything, but whether the SIEM can distinguish meaningful identity events from routine job execution. That is why governance around secrets, offboarding, and visibility remains central in the Ultimate Guide to NHIs, especially when teams assume raw volume equals security coverage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Log monitoring and event analysis depend on useful telemetry, not raw volume. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Telemetry gaps around service accounts and API keys are core NHI visibility failures. |
| NIST AI RMF | Risk-based logging decisions should align with AI RMF governance and monitoring practices. |
Map machine-identity logging to NHI-05 and ensure NHI actions remain searchable for detection and forensics.
