Start by routing authentication, cloud control-plane, endpoint, and network telemetry into one searchable layer before building detections. If identity, action, and outcome live in separate tools, investigators lose the timeline that turns an alert into evidence. Centralisation is the prerequisite for correlation, retention, and consistent triage.
How to build one investigation-ready security log layer
Centralisation works best when teams treat logs as an investigation substrate, not a collection problem. Authentication, cloud control-plane, endpoint, and network telemetry should land in one searchable layer with shared time sync, stable fields, and enough retention to reconstruct who did what, where, and with which subject or session. The point is to preserve a usable timeline, not simply to copy events into a bigger bucket.
A practical design choice is to normalise around a few high-value pivots: identity, source host, resource, action, result, and timestamp. If those fields are inconsistent across tools, investigators end up manually correlating records that should already line up. When teams standardise the event schema early, they make later detections, case review, and escalation far more reliable.
That usually means preserving raw events for fidelity while also indexing a canonical view for search. Raw records help when analysts need vendor-specific detail or audit evidence, while the canonical layer keeps day-to-day triage fast. Identity Security Programme Guide is useful here because central logging is really a programme decision about scope, ownership, and operating model, not only a SIEM tuning exercise.
Why identity-driven investigations depend on correlation, not just collection
Identity-driven investigations answer a sequence of questions: which principal authenticated, what they accessed, what changed, and whether the action fits the normal pattern for that identity. If authentication logs live in one tool, cloud events in another, and endpoint evidence in a third, the analyst must bridge gaps manually. That breaks the chain of evidence and slows both detection and response.
Centralisation matters because the same identity may appear through multiple control points, especially when a session starts in one system and later touches cloud services or endpoints. A single searchable layer lets teams connect login events, privilege use, process activity, and resource access without relying on memory or screenshots. For workload and service identities, that correlation is even more important because the “who” is often a non-human principal acting at machine speed. Ultimate Guide to NHIs helps frame why identity evidence must be collected across the full execution path, not just at the point of authentication.
Teams also need to keep investigative context attached to the event stream. A login failure without source, device, or geographic context is less useful than a normalised event that includes those fields by default. The best central layers are therefore built for pivoting, grouping, and time-based reconstruction, not for passive storage alone.
What good central logging looks like in practice
A mature setup gives analysts a small number of dependable habits. They can search one place, filter on the same core fields, and move from identity event to resource event to endpoint signal without changing tools. Retention policies are explicit, access to the log platform is tightly controlled, and raw versus enriched data is separated so investigators can trust both speed and fidelity.
The most useful operational pattern is to start with the sources that most often anchor an investigation, then expand coverage. Authentication, cloud control-plane, endpoint, and network logs are the minimum set for most identity-led cases, but the value comes from making them readable together. Identity Security Posture Management (ISPM) Guide is a strong companion reference because posture and investigation both fail when visibility is fragmented or when critical identity signals are missing.
One overlooked detail is ownership. Each log source needs a named owner for collection health, parsing quality, retention, and break-glass access. Without that accountability, centralisation degrades into a partial archive where the most important telemetry is either missing or unusable during an incident.
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 — Monitoring for Anomalies and Events | Centralised logs enable continuous monitoring and event correlation across identity-driven activity. |
| Recommendation — Consolidate telemetry so analysts can monitor and correlate identity events from one detection layer. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The question is about collecting the right security telemetry for investigations. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Centralisation exists to make logs searchable and useful for review and analysis. | |
| AU-11 — Audit Record Retention | Identity-driven investigations depend on retaining events long enough to reconstruct timelines. | |
| Recommendation — Define required event sources and logging detail for investigation-ready coverage. Route logs into a searchable platform that supports timely review and correlation. Set retention periods that preserve evidence for investigation and response needs. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Central log collection directly maps to logging control expectations in the ISMS. |
| A.8.16 — Monitoring activities | Identity-driven investigations require correlated monitoring across multiple telemetry sources. | |
| Recommendation — Standardise logging so critical identity events are captured and reviewable. Correlate logs across systems so suspicious identity activity can be detected and investigated. | ||
Practitioner Guidance
What to prioritise: Centralise the log sources that let an analyst reconstruct identity, action, and outcome in one timeline, then verify that the fields needed for correlation are actually present and consistent. If a source cannot support that workflow, it is not yet investigation-ready even if it is being collected.
What to verify: Test a real incident path end to end, from authentication through privilege use to resource impact. If the investigation requires switching tools to answer basic questions, the central layer is still too fragmented.
Common mistake: Treating log centralisation as a storage project. The better test is whether an analyst can prove or disprove suspicious identity activity quickly, with enough context to defend the conclusion.
Practitioner takeaway: Centralisation only pays off when it turns separate telemetry streams into one defensible investigation timeline, so design the log layer around correlation quality, not ingest volume.
Related resources from NHI Mgmt Group
- How should security teams normalize cloud logs for identity investigations?
- What breaks when security teams rely only on process, file, and identity logs to investigate an agent-driven incident?
- How should security teams design AI-driven SOC investigations when network telemetry is fragmented compared with endpoint or identity data?
- What do security teams get wrong when they rely only on SIEM logs for identity investigations?