Why do organisations often limit log ingestion in SIEM programmes?

A common reason is pricing pressure, especially when costs rise with each additional gigabyte of data. Teams then reduce ingestion to protect budgets, but that can create blind spots in cloud and identity telemetry. The practical risk is that security operations become cheaper to run while becoming less effective at spotting suspicious activity.

Why This Matters for Security Teams

Limiting log ingestion is often treated as a cost-control decision, but it is really a detection-design choice. Once a SIEM stops receiving high-value telemetry, analysts lose the evidence needed to detect brute-force activity, privilege escalation, anomalous API use, and lateral movement across identity and cloud layers. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that audit logging is not optional decoration; it supports accountability, incident response, and forensic reconstruction.

The common mistake is to treat ingestion caps as a technical tuning issue rather than a governance issue. If the SIEM is only ingesting what is cheapest or easiest to collect, then the programme is optimising storage economics instead of security outcomes. That creates an uneven control surface where endpoint, cloud, IAM, and identity provider logs are not treated with the same value.

This is especially important where identities are the primary attack path. Attackers rarely need to break the perimeter if they can abuse credentials, tokens, or over-privileged accounts. In practice, many security teams encounter the weakness only after a suspicious login, API misuse, or cloud breach has already occurred, rather than through intentional telemetry design.

How It Works in Practice

Most SIEM programmes ingest logs through tiered pipelines, filtering, sampling, or source-based allowlists. The intent is usually sensible: reduce noise, control storage growth, and avoid overwhelming analysts with low-value events. The problem is that these decisions are often made before the team has defined which logs are essential for detection engineering, threat hunting, and retention obligations.

A better model is to classify telemetry by operational value. Authentication logs, privileged access events, cloud control plane activity, endpoint detections, and identity provider audit trails usually deserve priority because they support the highest-yield detections. Security teams also need to preserve sequence and context, not just isolated events, because correlation is what turns raw data into actionable signals.

• Keep high-fidelity identity logs, especially sign-ins, MFA events, session changes, and admin actions.
• Prioritise cloud audit and control plane logs where attack paths cross infrastructure and identities.
• Use filtering carefully so that low-value noise is reduced without discarding rare but critical events.
• Validate that retention periods support investigations, insider risk cases, and regulatory review.
• Test detections against real attack techniques rather than assuming coverage from ingestion volume alone.

This approach aligns with the spirit of the NIST control family and also with the detection logic in MITRE ATT&CK, which helps teams map log sources to specific adversary behaviours. For cloud-heavy environments, teams often pair SIEM decisions with CIS Critical Security Controls to ensure critical telemetry is not filtered away by cost-saving defaults.

These controls tend to break down when organisations centralise logs from hybrid estates with inconsistent schemas and then apply blanket ingestion limits because parsing, enrichment, and correlation become too expensive to sustain.

Common Variations and Edge Cases

Tighter ingestion control often reduces platform cost, but it also increases the risk of missing weak signals, so organisations have to balance budget discipline against detection depth. That tradeoff becomes sharper in environments with high event volumes, such as container platforms, remote work estates, or large identity systems with frequent machine-to-machine authentication.

There is no universal standard for the exact amount of telemetry a SIEM should ingest. Best practice is evolving toward risk-based selection, where teams keep the logs that support the most important use cases and accept reduction only where there is little investigative value. Some organisations also move low-value, high-volume data to cheaper storage while keeping search-ready access for critical events.

The edge case is regulated or high-consequence environments. Financial services, critical infrastructure, and identity-centric platforms often cannot justify aggressive log suppression because the investigative and compliance cost of missing an event is higher than the storage bill. In those settings, limited ingestion should be reviewed alongside retention, immutability, and access controls rather than as a standalone cost lever.

Current guidance suggests that cost controls are acceptable only when they do not weaken the organisation’s ability to detect, investigate, and prove what happened. Where identity, cloud, and endpoint telemetry are all relevant to the same incident path, the safest choice is often to ingest less low-value data rather than lose the audit trail that matters.

Related resources from NHI Mgmt Group

• When should organisations enrich telemetry before SIEM ingestion?
• How should security teams make SIEM ingestion reliable across different log sources?
• How should organisations prepare their NHI programmes for Agentic AI adoption?
• How can organisations prepare identity programmes for AI-enabled access?