Use a scope test: the source should support a current or near-term detection use case, meet a compliance requirement, or represent a high-value asset in the threat model. If it satisfies none of those, it should not be ingested just because the pipeline can accept it.
What belongs in the central log store?
Teams should treat the central store as a curated detection and compliance asset, not a dumping ground. The decision is usually driven by whether a log source helps answer an active threat question, supports a mandated retention need, or materially improves visibility on a high-value system. If it does not improve one of those outcomes, local retention is usually enough.
The practical test is whether the source gives analysts something they would actually investigate, correlate, or audit later. Authentication events, administrative actions, security control telemetry, and logs from crown-jewel systems usually clear that bar because they help reconstruct access, privilege use, and suspicious change. Low-value application chatter rarely does unless it feeds a known alert or investigation path.
High-volume is not the same as high-value. Centralization costs money, increases query noise, and can weaken signal quality if teams ingest too much by default. A better rule is to start from use case, then ask whether the source improves detection coverage, supports a compliance obligation, or closes a blind spot that would matter during incident response. That keeps the store useful enough to search at speed.
How to separate useful telemetry from noise
A source usually belongs in the central store when at least one of three conditions is true: it supports a current or near-term detection use case, it is required for audit or legal retention, or it records activity on systems that would cause material harm if abused or misconfigured. Logs that cannot be tied to one of those purposes should be kept closer to the system, sampled, or discarded according to policy.
One useful way to think about this is evidence value. Security teams need logs that preserve sequence, attribution, and scope. For example, logs that show who authenticated, what changed, and which resource was touched are far more valuable than repeated status messages. The central store should therefore privilege event types that can reconstruct an attack path or confirm a control worked as intended.
Classification should also account for operational reality. Some logs look unimportant in isolation but become critical when they are the only record of a control boundary, a failed authorization, or a privilege elevation. In that case, the ingestion decision is not about volume alone, it is about whether the source is the authoritative record for a security-relevant event.
What should guide the ingestion decision?
In practice, teams make the decision by mapping each source to a concrete consumer. If no analyst, auditor, or response workflow can name a use for the log, it probably does not need central storage. If the source feeds correlation rules, forensic reconstruction, or mandatory reporting, it usually does. That keeps the central store aligned to decision-making rather than infrastructure convenience.
Sources with short-lived investigative value are often the best candidates. Security device alerts, privileged access activity, identity events, configuration changes, and logs tied to sensitive data paths usually justify ingestion because they help establish what happened, when, and by whom. By contrast, verbose debug output or routine success messages should be ingested only when they are known to support a defined detection or troubleshooting need.
Scope also matters at scale. The more systems, teams, or vendors a source covers, the more important it is to decide whether the data is stable, normalized, and searchable enough to justify central placement. Teams should prefer curated ingestion over broad collection because uncontrolled growth eventually reduces retention quality, increases cost, and makes meaningful alerts harder to find.
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 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Source selection for central logs supports ongoing monitoring and event detection. |
| GV.RM-01 — Risk management objectives are established and agreed to by organizational stakeholders | Log ingestion should follow agreed detection, compliance, and asset-risk objectives. | |
| Recommendation — Ingest sources that materially improve continuous monitoring and alerting coverage. Define log-retention scope against approved risk and monitoring objectives. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | This question is fundamentally about which events should be logged and centrally retained. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Central logs exist to support review, analysis, and incident reconstruction. | |
| AU-11 — Audit Record Retention | Central store decisions are tied to how long records must be retained for audit and response. | |
| Recommendation — Select events for logging based on investigative, compliance, and operational value. Retain logs that support review, correlation, and incident analysis. Keep only the records needed to satisfy retention and investigative needs. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | The question concerns which events and sources should be logged and retained centrally. |
| A.8.16 — Monitoring activities | Centralized logs are used to detect and investigate suspicious activity. | |
| Recommendation — Define logging scope by security, audit, and investigation need. Retain telemetry that supports monitoring and incident investigation. | ||
Practitioner Guidance
What to prioritise: Start with the sources that support identity, privilege, security control, and sensitive system investigations, because those are the records most likely to matter during detection and response. If a source cannot improve a query, a hunt, or an audit outcome, it is a candidate for local-only retention.
Decision rule: If the log source is needed for a defined detection use case, a compliance obligation, or the protection of a high-value asset, ingest it centrally; if not, keep it out of the main store even when the pipeline can technically accept it.
What good looks like: The central store contains the smallest set of sources that still lets teams answer who acted, what changed, what was accessed, and whether a control fired. Everything else is either summarized, sampled, or retained elsewhere with a clear purpose.
Practitioner takeaway: Central logging is a security design choice, not a storage decision. The best programs ingest for investigation value and accountability first, then expand only when the source clearly adds measurable detection, response, or compliance value.
Related resources from NHI Mgmt Group
- How should security teams decide which logs belong in a SIEM analytics tier?
- How should security teams decide which user actions belong in audit logs versus analytics or debug logs?
- How should teams decide which Kubernetes logs belong in hot storage?
- How should security teams prioritise NHI remediation in cloud environments?