Why does collecting everything make security operations harder?

Why collecting everything makes operations slower, not safer

Security operations depend on signal, not raw volume. When every event is collected, analysts spend more time filtering noise, storage and query costs rise, and investigation paths get longer because the useful evidence is buried inside low-value telemetry. A larger data lake only helps if the added data actually supports detection, triage, or case work.

In practice, “collect everything” shifts the operating problem from deciding what to investigate to deciding what to ignore. That creates backlog, weakens alert-to-evidence correlation, and makes it harder to prove whether a control is working because the team is measuring volume instead of coverage.

The better model is to define collection around use cases: what threats you want to detect, what investigations you must support, what retention you truly need, and what sources produce actionable context. That keeps telemetry tied to decisions, rather than turning observability into an undifferentiated archive.

Where the operational drag comes from

The first cost is search efficiency. When analysts have to query across far more records, each question takes longer, and the chance of missing the relevant event rises because the signal is diluted by unrelated activity. SANS Security Resources is useful here because SOC and detection work depends on practical filtering, triage, and investigation discipline, not unlimited intake.

The second cost is storage and pipeline load. More ingest means more indexing, more retention overhead, and more tuning work for parsers, normalisation, and correlation logic. If the telemetry is not mapped to a detection rule, model feature, or case workflow, it becomes expensive inventory rather than operational evidence.

The third cost is decision fatigue. Large telemetry sets tend to create too many possible leads, which encourages shallow analysis and delayed closure. That is why collection strategy should be tied to incident handling and hunting questions, not to the idea that more data is automatically better.

What good telemetry strategy looks like

Good collection is selective, risk-driven, and reviewable. It captures the events that support your highest-value detections, your likely investigation paths, and your reporting obligations, while dropping redundant or low-yield sources that do not improve outcomes. NCSC UK Advice and Guidance is a strong reference point for operationally grounded security guidance, especially where logging, monitoring, and response need to stay practical.

That means three things should be explicit: the use case for the data, the retention period, and the person or team who can explain why it exists. If a source cannot support detection, incident response, forensics, or governance, it should be challenged before it becomes permanent overhead.

It also means reviewing whether low-value collection is masking missing high-value sources. Teams often overcollect from easy-to-enable systems while undercollecting the assets that would actually help explain compromise, privilege abuse, or lateral movement. Relevance should beat convenience.

Practitioner Guidance

What to prioritise: Start by inventorying the telemetry that directly supports top incident scenarios and the data that is merely “nice to have”. Preserve the former, question the latter, and retire sources that do not improve a rule, model, investigation step, or governance need.

What to measure: Track time-to-triage, query latency, alert-to-evidence ratio, and the percentage of collected fields that are actually used in detections or cases. If those metrics worsen as volume rises, the collection model is too broad.

Common mistake: Treating more logging as equivalent to better visibility. Visibility is only useful when analysts can search it quickly, trust it, and connect it to a specific operational decision.

Practitioner takeaway: Collect for decision support, not for accumulation. The right telemetry set is the smallest set that still lets the team detect, investigate, and explain meaningful security events with speed.

Related resources from NHI Mgmt Group

• Why does centralising findings sometimes make security operations harder?
• Why do air gapped environments increase security, but also make application operations harder?
• Why does a lack of integration between security tools and teams make SOC operations harder to sustain?
• Why do high alert volumes make it harder for security operations teams to detect real incidents quickly?