TL;DR: Modern DSPM must move beyond storage-centric visibility because sensitive content now flows across SaaS, endpoints, code repositories, and generative AI tools, leaving sampling, API limits, and weak lineage as core evaluation risks, according to Cyberhaven research. The decisive shift is from knowing where data sits to proving how it moved and whether controls followed it.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cyberhaven's blog post: DSPM built around storage scanning misses the way sensitive data now moves across SaaS, endpoints, collaboration tools, code repositories, and AI platforms.
Why it matters: It matters because IAM, DLP, and data security teams need provenance and movement context to enforce controls where exposure actually occurs, not just where data is stored.
Context
Modern DSPM has to answer a different question than legacy file-server tooling did. In distributed work environments, data risk is not defined only by where a sensitive file lives, but by how it is copied, transformed, and reused across cloud services, endpoints, and AI workflows. Cyberhaven’s comparison frames that shift clearly: storage visibility alone no longer explains exposure.
That creates a governance problem for both security and identity programmes. Once data moves across SaaS, collaboration tools, and generative AI systems, control effectiveness depends on whether the platform can preserve provenance and enforce policy at the point of use. Without that lineage, teams are left correlating disconnected logs after the fact, which is typical for older DSPM approaches but inadequate for modern incidents.
Key questions
A: Security teams should look for unified DSPM and DLP, not discovery alone. The platform should classify sensitive data, understand sharing and permissions, and take inline action such as redaction, revoke, label, quarantine, delete, or block. The best test is whether it can reduce exposure in the systems where employees actually work, including collaboration apps, cloud storage, browsers, and GenAI tools.
Q: What breaks when DSPM only scans cloud storage?
A: When DSPM only scans cloud storage, it loses sight of how data moves after discovery. That means copying, pasting, sharing, browser use, endpoint transfer, and AI prompts can all sit outside the control boundary. Security teams then know where sensitive data lives, but not where it went or whether it was prevented from leaving.
Q: How do teams know whether data lineage is actually improving control?
A: Look for whether the platform can trace a real incident from source to destination and show the policy decision at each step. If analysts still have to pivot across multiple tools to reconstruct movement, lineage is not operationalised. Useful lineage reduces investigation time, preserves context across systems, and supports enforcement at the point of use.
Q: What does data lineage change for DLP and insider risk programmes?
A: It moves those programmes from static content detection to context-aware enforcement. DLP can recognise that a copied or transformed artifact still belongs to a sensitive dataset, while insider risk analytics can use origin and movement history rather than relying only on file names or patterns. That produces stronger evidence and fewer false assumptions about where exposure occurred.
Technical breakdown
Why storage-centric DSPM misses the full data path
Storage-centric DSPM starts with repositories and scans for sensitive content at rest. That works when the main question is which buckets, file shares, or databases contain regulated data. It breaks down when the same content is copied into tickets, chats, downloads, browser sessions, or AI prompts. At that point, the security problem is no longer discovery alone. It is provenance, transformation, and propagation across systems. A platform that cannot carry context forward loses the ability to show how a document changed hands or whether a control should have followed it. This is why post-incident heatmaps are weaker than chain-of-custody evidence.
Practical implication: evaluate whether DSPM can preserve content lineage beyond the original repository.
How lineage changes DLP and detection
Data lineage turns DLP from static pattern matching into context-aware enforcement. Instead of treating each file or message in isolation, the control can recognise that a renamed, compressed, or partially copied artifact still originated from a protected dataset. That matters because modern leakage often happens through intermediate handling, not direct export from a source system. With lineage, detection can reason about origin, movement history, and policy inheritance across endpoints and SaaS applications. Without it, teams repeatedly rediscover the same data under different names and formats, which increases alert noise and weakens confidence in enforcement. The architectural question is whether controls consume provenance natively or rely on stitched-together integrations.
Practical implication: favour controls that can apply policy based on data origin, not only file content or location.
Why AI workflows raise the bar for data governance
Generative AI changes the data-governance problem because prompts, outputs, and copied context can all carry sensitive material outside the original storage boundary. If a platform only knows what exists in a repository, it cannot judge whether the same content was exposed through a browser, ticket, or AI assistant. That creates blind spots for insider risk and for accidental disclosure. Lineage is therefore not just a classification enhancement. It becomes the mechanism for tracing whether sensitive data entered an AI workflow and whether control decisions stayed attached to it. For governance teams, the practical issue is evidentiary continuity from source to use.
Practical implication: treat AI exposure as a lineage and enforcement problem, not only a classification problem.
NHI Mgmt Group analysis
Data lineage is now the differentiator between visibility and control. Storage maps answer where sensitive data exists, but they do not explain how that data moved, who handled it, or where enforcement should have followed. In modern environments, those questions matter more than repository coverage because exposure often occurs after the first access event. For practitioners, the real evaluation standard is whether the platform can preserve policy context end to end.
Endpoint and SaaS activity have become first-class data-security surfaces. The article shows why assumptions built around file servers no longer hold once content is copied into collaboration tools, browsers, and AI systems. That expands the governance problem from data discovery to data behaviour. For identity and security teams, the implication is that control coverage must extend to usage context, not just storage estate.
Lineage creates a more defensible audit story than snapshot scanning. If a platform can reconstruct origin, movement, and enforcement at the time of exposure, it can support investigations that older DSPM tools struggle to explain. That does not eliminate the need for cloud posture controls, but it changes what evidence is considered credible. Practitioners should prefer architectures that can prove chain of custody over ones that only count sensitive objects.
Modern DSPM increasingly behaves like a governance layer, not a reporting layer. Once policy can follow content across systems, the platform becomes part of the enforcement path rather than a retrospective inventory tool. That distinction matters for programme design, because teams need to decide whether they are buying a map or a control plane. The right question is whether the platform can intervene when movement crosses a boundary, not whether it can enumerate assets.
From our research library:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
What this signals
Data lineage is becoming the control plane for modern DSPM. Teams that still judge platforms by repository coverage will miss the harder question of whether policy survives movement into SaaS, endpoints, browsers, and AI tools. The operational requirement is now provenance-aware enforcement, not just better inventory.
28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks. That is a useful proxy for the broader problem Cyberhaven highlights: sensitive content increasingly escapes through collaborative workflows rather than traditional storage locations, so incident models must follow the data path.
For identity and data teams, the next evaluation filter is evidentiary continuity. If a platform cannot reconstruct origin, movement, and control action in one sequence, it will remain a visibility tool rather than a governance control. The strongest programmes will prefer architectures that can prove why an exposure happened, not only where data was found.
For practitioners
- Validate lineage coverage across all material data paths Test whether the platform can trace a sensitive file from source system to SaaS, endpoint, browser, and AI workflow without losing context.
- Compare enforcement at discovery time and use time Check whether policy decisions can follow content when it is renamed, copied, compressed, or partially pasted into another application.
- Assess incident reconstruction quality Ask analysts to rebuild one real exposure event and confirm they can see origin, movement history, and control actions in one workflow.
- Review AI data-handling controls for provenance gaps Confirm whether prompts, outputs, and browser-mediated interactions inherit the same sensitivity logic as source repositories.
Key takeaways
- Storage-first DSPM leaves a gap because modern data exposure often happens after content leaves the original repository and moves through operational workflows.
- A lineage-driven model gives security teams better evidence by connecting origin, movement, and enforcement across SaaS, endpoints, and AI systems.
- Practitioners should test whether DSPM can preserve policy context through copying, renaming, and browser-mediated handling before they treat it as a control plane.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | Data movement and exposure across workflows map to collection and exfiltration behaviour. |
| Recommendation — Map risky data paths to TA0009 and TA0010, then detect where content leaves approved handling boundaries. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity of Data | Lineage preserves the integrity of data handling context across systems. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on whether access and enforcement follow content as it moves. | |
| Recommendation — Use PR.DS-10 to ensure sensitive data retains provenance and handling context across environments. Apply PR.AA-05 to verify that authorizations and controls remain aligned when data shifts between systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | Cross-system data movement often depends on identity and access paths that need governance. |
| Recommendation — Review account and access pathways under CIS-5 where data movement crosses business applications. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article critiques incomplete visibility into data assets and flows across platforms. |
| Recommendation — Use API9 to inventory data-touching surfaces and close gaps in cross-application visibility. | ||
Key terms
- Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
- Provenance-Aware Enforcement: Provenance-aware enforcement means applying security policy using knowledge of a data item’s origin and journey, not just its current location or label. It is useful when content is copied, renamed, or repackaged across collaboration tools, endpoints, and AI workflows.
- Snapshot Visibility: Snapshot visibility is the ability to clearly see what backup snapshots exist, where they are stored, and whether they are protected and compliant. Strong visibility helps teams prove backup coverage, enforce consistent policy, and restore data faster because they can locate the right recovery point quickly.
- Chain of custody: A documented record that preserves the integrity of evidence from the moment an event is detected through investigation and response. In identity and data protection workflows, it helps prove what happened, when it happened, and which actor or session was involved.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, to connect identity governance with the control decisions your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org