No. The article’s key operational point is that investigation value can come from connectors and learned relationships without forcing a full data-lake programme first. The better question is whether the platform can preserve useful pivots across the systems you already run.
Why Centralising First Is Usually the Wrong Question
The practical issue is not whether every security signal lives in one place. It is whether investigators can move quickly across alerts, identities, assets, and events without losing context. A cross-system investigation graph is meant to preserve those pivots, so forcing a separate data-lake programme often adds cost and delay before the workflow is actually better.
That distinction matters because many investigation tasks are relationship problems, not warehouse problems. If the graph can already link a user, host, process, ticket, or cloud resource into one chain of evidence, the operational value comes from correlation and traversal, not from a single central repository.
What a Cross-System Investigation Graph Should Preserve
A useful investigation graph keeps the relationships that analysts repeatedly need: who touched what, which event led to which alert, what asset was involved, and which identity or service account bridged the systems. The graph does not need to replace source systems to be valuable; it needs to preserve high-signal joins and enough metadata to pivot without manual re-querying.
In practice, that means connector quality often matters more than platform consolidation. If the ingestion layer can maintain stable IDs, timestamps, ownership, and provenance across tools, teams can investigate distributed telemetry without flattening everything into one schema first. For cloud and identity-heavy environments, that is often the difference between a usable graph and a dashboard that only looks integrated.
Centralisation becomes useful when the investigation problem is really about long-term retention, uniform enrichment, or enterprise-wide analytics at scale. But for day-to-day triage and incident response, the graph should reduce friction in the current toolchain, not demand a wholesale redesign of it. The platform should answer: can an analyst start from one alert and reliably follow the chain across systems?
When Consolidation Helps, and When It Slows You Down
There are cases where a central store is justified. Teams may need one place for regulated retention, broad hunting, or deep historical analysis across multiple data producers. A lake can also help when upstream systems are inconsistent enough that relationships cannot be trusted until data is normalised. Even then, the question is whether that investment materially improves investigation speed and fidelity, not whether centralisation sounds architecturally neat.
The main trade-off is between completeness and operability. A full data-lake programme can improve coverage, but it also introduces schema work, pipeline maintenance, latency, and governance overhead. If those costs delay detection or make routine investigations harder to use, the organisation may end up with more data and less decision speed.
That is why many teams get better value from a federated model first: keep the authoritative system where it belongs, expose the relationships needed for investigation, and centralise only the data that is genuinely reused across workflows. This keeps the programme aligned to actual analyst behaviour instead of forcing every use case through the same storage pattern.
Risk and Threat Considerations
Centralising security data can create concentration risk, enlarge the blast radius of a compromise, and slow adoption when teams wait for the “perfect” platform before improving investigation quality. A graph that preserves cross-system pivots can reduce that exposure, but only if its connectors, permissions, and provenance are trustworthy.
Failure mechanism: Investigation quality degrades when relationships are broken, stale, or over-normalised, or when access to the central store becomes a bottleneck for triage and hunting.
Impact: Analysts lose speed, miss key pivots, or over-rely on incomplete views, while a central repository can become a high-value target if it aggregates sensitive operational data.
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 CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Cross-system investigation graphs serve security operations across existing systems. |
| ID.RA-01 — Asset Vulnerabilities Are Identified and Documented | Graph value depends on understanding which assets, identities, and events must be correlated. | |
| DE.CM-01 — Network and System Monitoring | The graph supports monitoring and investigation across distributed security data sources. | |
| Recommendation — Define investigation priorities around the systems and telemetry analysts actually use. Identify the assets and relationships that investigators need to traverse. Correlate monitoring data without waiting for full centralisation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-system investigation data still requires controlled access and least exposure. |
| Recommendation — Limit access to investigative data to authorised roles and workflows. | ||
| CSA Cloud Controls Matrix | LOG — Logging and Monitoring | Investigation graphs depend on usable logging and event relationships across systems. |
| Recommendation — Preserve log provenance and correlation paths across source systems. | ||
Practitioner Guidance
What to verify: Test whether the graph preserves the exact pivots analysts use most often, such as identity-to-host, alert-to-process, and ticket-to-event lineage. If those joins are reliable across your current systems, the case for a forced centralisation programme is weak.
Decision rule: If the platform improves investigation speed without first building a full data warehouse, adopt the graph-first model and centralise only the datasets that deliver clear reuse, retention, or governance value. If the required joins cannot be trusted, then the data-quality problem comes first, not the storage architecture.
Practitioner takeaway: The right measure is not how much security data you centralise, but whether investigators can preserve context and move across systems with confidence and low friction.
Related resources from NHI Mgmt Group
- What should security teams check before using ReBAC for regulated data?
- How should security teams validate training data before using it in generative AI systems?
- How should security teams use a graph data model to improve threat detection and investigation?
- How should security teams ensure data quality and observability before using a warehouse or lake for AI and analytics?