Cheap storage removes one constraint, but it does not remove governance failures. If teams broaden access to compensate for easier retention, they can expose sensitive telemetry, increase blast radius, and lose accountability over who queried what. The risk moves from storage cost to permission design and investigation control.
Why This Matters for Security Teams
A low-cost data lake can tempt teams to keep everything, connect everything, and grant broad access so analytics are not delayed. That changes the risk profile from retention cost to governance failure. Sensitive logs, customer records, API responses, and operational telemetry often land together, which means a single permissive policy can expose far more than intended. The issue is not the lake itself, but the absence of clear classification, access boundaries, and query accountability.
For security teams, this matters because the same lake that supports detection and response can also become a convenient exfiltration target. Under NIST Cybersecurity Framework 2.0, the governance and protect functions are not optional wrappers around data platforms; they are the control layer that determines whether retained data remains usable without becoming overexposed. In practice, many security teams encounter lake risk only after a sensitive dataset has already been shared broadly, rather than through intentional data classification and access design.
How It Works in Practice
Cheap storage often changes behaviour before it changes architecture. Teams stop deleting raw logs, keep duplicate datasets for convenience, and layer ad hoc access on top of object storage or warehouse integrations. That creates several security problems at once: entitlement sprawl, weak separation between environments, and poor visibility into who queried what. The more teams rely on shared analytical access, the harder it becomes to prove whether a user, service account, or automation job accessed regulated or sensitive records.
Good practice is to treat the lake as a governed data platform, not a filing cabinet. Current guidance suggests applying classification, encryption, and policy enforcement before data is broadly searchable. Security teams should:
- Classify data at ingestion so sensitive fields can be tagged and restricted early.
- Use role-based access control and, where needed, attribute-based controls for narrower query access.
- Separate raw, curated, and investigative zones so analysts do not need raw access by default.
- Log data access events in a SIEM and retain query records for investigations and auditability.
- Review service account and NHI permissions, especially where pipelines, schedulers, or agents can read and transform data automatically.
This also means limiting how data moves between the lake and downstream tools. Export, copy, and federation paths often become the weakest point because they bypass the original control intent. Where AI pipelines consume lake data, model training and retrieval workflows should be checked for prompt leakage, overbroad retrieval scopes, and unintended inclusion of secrets or personal data. These controls tend to break down in multi-tenant analytics environments because shared access patterns and inconsistent tagging make policy enforcement unreliable.
For practical control mapping, NIST Cybersecurity Framework 2.0 is useful for structuring governance, access control, and monitoring expectations, while investigation teams should validate that alerts are tied to actual data objects and not just infrastructure events.
Common Variations and Edge Cases
Tighter data controls often increase analyst friction and operational overhead, so organisations have to balance investigation speed against exposure reduction. That tradeoff is especially visible in incident response, where teams want broad access to reconstruct events but still need to avoid making the lake a shared secrets repository.
There is no universal standard for this yet, but current guidance suggests creating tiered access models for different data classes, rather than giving everyone one large permission set. Edge cases usually appear when:
- data is collected for security monitoring but later reused for product analytics;
- third-party tools ingest lake data without inheriting the same policy rules;
- machine learning workflows copy data into training stores with weaker controls;
- service accounts accumulate rights over time and no one reviews them as identities.
Identity governance becomes especially important when non-human identities move data between systems. A cheap lake can hide the true access surface because storage is inexpensive, but accountability is not. If the organisation cannot answer who queried what, when, and under which entitlement, the lake has already become a security liability rather than a control asset. For teams handling personal or regulated data, the operational baseline should also align with auditability expectations reflected in NIST Cybersecurity Framework 2.0.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-1 | Data lake risk stems from weak governance, not storage cost. |
Set policy for data classification, retention, and access before broad lake onboarding.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
