Because the organisation pays for ingestion volume even when much of the data has little security value. That creates pressure to centralise everything, which increases cost, lock-in, and operational dependency on a fragile path. Governance has to decide what is worth retaining at full fidelity and what is not.
What SIEM-centric pipelines change in governance
SIEM-centric pipelines are not just a logging architecture, they become a governance model for what the organisation chooses to observe, retain, and pay for. Once ingestion cost is tied to volume, the easy answer is often “send everything,” even when the data adds little decision value. That shifts governance from evidence quality to storage appetite and makes the pipeline itself a policy-making mechanism.
A useful way to think about this is that the NIST Cybersecurity Framework 2.0 asks the organisation to govern security outcomes, not merely log accumulation. If the log stream is treated as the control objective, the result can be retention bias: more data, weaker signal, and less clarity about what evidence actually supports detection, investigation, or assurance.
That is why the hidden risk is governance drift. The team starts optimising for ingestion completeness, but the business is really funding a continuing decision about relevance, fidelity, and retention period. Over time, the platform can also become a dependency that is hard to unwind because every new source feels “too important to remove,” even when it is low-value for security operations.
Why centralised ingestion creates cost, lock-in, and dependency pressure
Centralising all telemetry into one pipeline usually feels safer because it appears to improve coverage and simplify monitoring. In practice, it can create a single commercial and operational choke point. The organisation may end up paying to move, index, and store data that only rarely supports an investigation, while also making future changes harder because downstream detections, dashboards, and retention assumptions have been built around that pipeline.
This is especially visible where the pipeline includes identity and access evidence, secrets-related events, or service-to-service activity. The relevant control question is not whether the data exists, but whether it remains proportionate to the risk being monitored. Controls such as NIST SP 800-53 Rev. 5 Security and Privacy Controls support that judgement by tying logging, accountability, and access management to specific security outcomes rather than to indiscriminate collection.
When teams refuse to discriminate between high-value and low-value telemetry, the platform becomes operationally fragile. Costs rise with scale, tuning gets harder, and the security function may become dependent on a vendor or architecture choice that is no longer easy to negotiate. The hidden dependency is not just technical, it is also procedural, because policy begins to follow what the platform can cheaply ingest instead of what the organisation actually needs.
How to decide what stays, what moves, and what is dropped
The practical test is to classify data by decision value, not by habit. High-fidelity retention should be reserved for sources that materially support detection, incident response, forensics, auditability, or a known abuse path. Lower-value feeds can often be summarised, sampled, or kept for a shorter period without weakening security governance. That approach aligns with the logic of governance, risk, and monitoring under CSF 2.0, where measurement and decision-making should be proportional to the risk being managed.
Practitioners should also remember that telemetry is part of a control design, not a data lake by default. If a log source does not help answer a concrete question such as “who did what, when, from where, and with what authority,” its full-fidelity ingestion should be challenged. Where the answer is “we keep it because we have always kept it,” the pipeline is already shaping governance in a way the business may not have approved explicitly.
For teams dealing with cloud, endpoint, or privileged activity, the same principle applies: keep the evidence that supports meaningful investigations, and do not preserve volume simply because collection is easy. The objective is not minimal logging, it is defensible logging.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of Cybersecurity Risk Management | Governance of logging and retention choices affects risk oversight. |
| DE.CM-01 — Networks and Functions Monitored to Find Anomalous Behavior | SIEM pipelines exist to support monitoring and anomaly detection. | |
| Recommendation — Define oversight criteria for which telemetry is retained at full fidelity. Prioritise monitored sources that materially improve detection coverage. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Log source selection determines what events are recorded for accountability. |
| AU-11 — Audit Record Retention | Retention decisions are central to the cost and governance risk described. | |
| Recommendation — Specify event logging requirements by investigative and assurance need. Set retention periods based on evidence value and legal need. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging control design must balance coverage, cost, and operational usefulness. |
| A.5.9 — Inventory of information and other associated assets | Knowing what telemetry assets exist is necessary before curation or reduction. | |
| Recommendation — Define logging scope and retention rules that match business risk. Inventory telemetry sources and assign ownership for each feed. | ||
Practitioner Guidance
What to prioritise: Separate “security-relevant” from “monitoring-convenient.” Build a retention tiering model that explicitly marks sources as investigation-critical, compliance-critical, or low-value noise, then review the expensive tier first.
What to verify: Ask whether each retained source has a named consumer, a detection use case, or an incident-response use case. If none exists, the source is a candidate for reduction, aggregation, or removal.
Common mistake: Treating centralisation as a governance win. In reality, centralisation without curation often shifts judgment from the security team to the ingestion platform and the budget it consumes.
Practitioner takeaway: A good SIEM programme measures how much evidence it truly needs, not how much telemetry it can afford to ingest.