Default centralisation often creates avoidable cost, slower troubleshooting, and excess noise in the SIEM. It also pushes workloads that only need local access into a central pipeline they do not benefit from, which can obscure useful operational signals. The failure is architectural, not just financial.
Why default centralisation turns security data into a bottleneck
Default centralisation treats every telemetry source as if it should pay the same collection, transport, storage, and correlation cost. That is rarely true. Some data needs central correlation for detection and investigation, while other data is only useful locally for fast troubleshooting, resilience, or short retention. When teams centralise by default, they often convert an operational design choice into a permanent tax on performance and analyst time.
The architectural issue is that central pipelines create a single path for ingestion, parsing, enrichment, and indexing. That path can become a choke point, especially when the organisation keeps adding log volume without first asking whether the data improves detection or response. The result is not just higher spend, but slower feedback loops for the teams that need near-real-time visibility.
A better mental model is to classify security data by purpose before deciding where it lives. Centralise what benefits from cross-system correlation, shared detection logic, or enterprise retention. Keep local what is only valuable on the host, workload, application, or control plane that produced it. That is often the difference between meaningful observability and an overfilled NIST Cybersecurity Framework 2.0 monitoring pipeline.
What gets lost when everything is pushed into the SIEM
Once all security data is forced into a SIEM, teams tend to optimise for ingestion completeness instead of operational usefulness. High-volume but low-value sources can drown out the signal that actually supports incident triage. The practical cost is alert fatigue, noisier searches, and longer time to isolate the few records that matter.
Not every data source needs enterprise-wide retention or cross-domain correlation. Local diagnostics, component-level audit trails, and workload-specific traces often answer the first troubleshooting question faster than a central platform can. When those signals are stripped of context, normal operational variation can look like a security event, and real security events can look like routine noise.
This is also where teams lose agility. If engineers have to wait for central ingestion or SIEM indexing before they can answer a basic question, troubleshooting slows down even when the issue is not security related. The central platform becomes the only place people trust, which is a governance problem as much as a tooling problem.
That is why CISA’s Secure by Design guidance aligns with the broader lesson here: design defaults should reduce avoidable burden, not force every system into the same collection pattern.
How to decide what should stay local and what should be central
The useful test is simple: if the data is needed for enterprise correlation, cross-team hunting, compliance retention, or shared incident response, centralisation can be justified. If the data mainly supports the local operator, the local control owner, or a narrow workload boundary, keep it close to the source and forward only the summary, exception, or security-relevant subset.
That decision should account for volume, latency, retention, and who actually consumes the data. Centralisation makes sense when the organisational value increases with aggregation. It works badly when the same pipeline is asked to serve investigation, compliance, and day-to-day operations for every asset in the estate.
Practitioners should also be careful not to confuse “available centrally” with “useful centrally.” A field that is technically ingestible may still be operationally expensive, redundant, or too delayed to help. The right question is not whether data can be centralised, but whether centralisation materially improves detection, investigation, or governance for that specific source.
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, CIS Controls v8 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 | DE.CM-01 — Continuous Monitoring | Centralised telemetry must support ongoing monitoring and detection value. |
| ID.RA-01 — Asset Vulnerabilities Identified and Documented | Choosing what to centralise depends on understanding source value and operational exposure. | |
| Recommendation — Map central feeds to monitoring outcomes and exclude sources that do not improve detection or response. Document which logs and traces justify central collection versus local retention. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The question is about log collection scope, retention, and operational usefulness. |
| Recommendation — Define which logs are centralized, which remain local, and how long each is retained. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Log centralisation decisions depend on selecting audit events that are actually needed. |
| Recommendation — Select audit events that support real monitoring needs instead of forwarding everything by default. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Centralising security data directly affects how logging is designed and operated. |
| Recommendation — Design logging so collection scope matches the operational and security value of each source. | ||
Practitioner Guidance
What to prioritise: Classify sources by investigative value before routing them to the SIEM. Start with the logs and traces that support detection or cross-system correlation, then separate the local diagnostic data that mainly helps the workload owner or on-call engineer.
What to verify: Check whether each central feed has a clear consumer, a defined retention need, and a measurable use case. If a source cannot answer who uses it and what decision it improves, it is probably centralised by habit rather than by design.
Common mistake: Teams often assume more central data means better security. In practice, the opposite can happen when useful context is stripped away and analysts spend more time filtering noise than investigating incidents.
Practitioner takeaway: The best architecture is not “centralise everything,” but “centralise only the data whose security value increases when shared.”