TL;DR: The gap is cohesion: most organisations already have DSPM and DLP capabilities, but risk insights stay in dashboards while enforcement lives elsewhere, creating delays when data moves across cloud, endpoint, SaaS, and AI environments, according to Cyberhaven. That fragmentation now matters more because data is increasingly mobile and GenAI usage is expanding.
At a glance
What this is: This is an analysis of why stitched-together DSPM and DLP tooling leaves data security teams with visibility but limited operational control.
Why it matters: It matters because IAM, data security, and platform teams increasingly need policy decisions to follow data and users across endpoints, cloud, SaaS, and AI workflows.
By the numbers:
- 62% of organizations are experimenting with AI agents, and 82% of the top 100 most-used GenAI SaaS applications are medium, high, or critical risk.
- 40% of data breaches involve data spread across multiple environments, including public clouds, private clouds, and on-premises infrastructure.
- By 2026, over 20% of businesses will prioritize DSPM technologies to discover and secure their known and unknown data repositories.
👉 Read Cyberhaven's analysis of unified DSPM and DLP for data security
Context
Data security breaks down when discovery, classification, and enforcement operate as separate controls instead of one continuous workflow. That is the core issue in this article, and it is also why the data security problem increasingly intersects with identity governance, because access decisions, endpoint behaviour, and user context all shape where sensitive data goes next.
The vendor frames this as a platform cohesion problem rather than a tooling shortage. For security teams, the practical question is not whether they have DSPM or DLP, but whether policy can follow the data across cloud, endpoint, SaaS, and AI environments without losing context or slowing response.
Key questions
Q: How should security teams combine DSPM and DLP in modern data environments?
A: Use DSPM to discover and classify sensitive data, map who can access it, and identify exposure that policy may not see. Use DLP to enforce rules at the point of movement. The strongest programmes connect the two so discovery informs control decisions and enforcement feeds back into prioritisation.
Q: Why do data security controls fail when data moves from cloud to endpoint?
A: Because many programmes still assume the repository is the control boundary. Once data is downloaded, copied, or forwarded, the original system no longer has enough context to govern its use. Controls fail when they cannot preserve data classification, lineage, and policy enforcement across that movement.
Q: What do security teams get wrong about unified cloud security platforms?
A: Teams often assume consolidation alone solves cloud risk. In practice, a unified platform only helps if it preserves context across development, deployment, and runtime, and if it can map risk to the correct owner. Without that, the organisation just centralises noise in one console.
Q: How do teams know if identity security controls are actually working?
A: Identity security controls are working when teams can show a current view of high-risk entitlements, detect privilege drift quickly, and remove access before exposure spreads. A useful sign is reduced time between entitlement change and policy review. Another is fewer unresolved conflicts between approved access and actual production permissions.
Technical breakdown
Why DSPM and DLP fail when policy context is split
DSPM is designed to discover, classify, and assess sensitive data at rest, while DLP enforces controls as data moves or is shared. When those functions are separated across tools, the policy engine and the enforcement point no longer share enough context to make timely decisions. That creates false confidence, because the team can see risk without being able to act on it where the data is actually moving. The failure is architectural: visibility is not the same as control, and control is not durable when it depends on manual handoffs.
Practical implication: define one policy model that both discovery and enforcement consume, or the security workflow will keep breaking at the tool boundary.
Data lineage and endpoint control as a governance problem
The article’s endpoint-first framing reflects a broader reality: once sensitive content is copied, emailed, synced, or downloaded to unmanaged devices, the data security boundary has already expanded beyond the original repository. Data lineage means tracking where a file was created, where it moved, who accessed it, and what risk state it is in. That is not just a technical traceability problem. It is a governance problem because teams need to distinguish normal collaboration from risky exfiltration across human, device, and application contexts.
Practical implication: prioritise lineage-aware controls for the endpoint and collaboration layer, where the highest-risk data movement usually occurs.
Why AI platforms increase the pressure on unified data controls
AI adoption changes data exposure patterns because users place sensitive material into SaaS applications, copilots, and agent-driven workflows that can copy or transform it quickly. Once data enters those channels, classic repository-based controls lose precision unless they understand the current location and use of the data. In governance terms, this is a context-loss problem. The more AI and SaaS usage expands, the more security teams need policies that travel with the data rather than staying fixed to storage locations.
Practical implication: extend data controls into AI and SaaS workflows before those systems become uncontrolled data transfer paths.
NHI Mgmt Group analysis
The real problem is not the absence of data security tools, but the absence of a shared control plane. Discovery tools without enforcement produce alerts that teams cannot act on fast enough, while enforcement tools without discovery miss what should be protected in the first place. That split weakens both governance and response. For practitioners, the takeaway is that cohesion matters more than inventory.
Data lineage is becoming the governance layer that traditional data security programmes never fully built. If teams cannot trace how sensitive content moved from repository to endpoint to collaboration tool, they cannot reliably separate approved use from exposure. That matters even more in environments with human users, shared workspaces, and AI-assisted workflows. Practitioners should treat lineage as an operational control, not a reporting feature.
AI usage turns data security into a context-preservation problem. The article’s figures on AI experimentation and GenAI SaaS risk show that the perimeter is no longer just where data sits, but where it can be copied, transformed, or reused. That broadens the governance challenge for IAM-adjacent teams because access, device trust, and session context now influence whether data stays controlled. Practitioners need policies that survive movement across systems, not just approval at rest.
Unified data security is where governance and response begin to merge. Organisations increasingly need security decisions to be made in workflow, not after the fact in dashboards. That does not eliminate specialist tools, but it does force them into one operating model. Practitioners should expect platform architecture, not isolated capability, to become the deciding factor in mature data security programmes.
What this signals
A unified data security programme will increasingly be judged by whether policy can travel with content across endpoints, collaboration tools, and AI-assisted workflows. That means the operational question is no longer how many tools exist, but whether the control path remains intact when the file leaves the original repository.
For identity and data-governance teams, the lesson is that access context, device context, and data context are converging. The organisations that treat lineage and enforcement as one control problem will be better positioned to manage sensitive data in motion without relying on manual escalation paths.
For practitioners
- Define one data policy model Map classification, access conditions, and enforcement actions to a single policy schema so teams do not translate rules manually between DSPM and DLP. This reduces drift between discovery and response.
- Prioritise endpoint and collaboration controls Focus on the places where data is copied, emailed, downloaded, or shared into unmanaged environments, because that is where context is most often lost. Endpoint DLP and collaboration coverage should be evaluated together, not separately.
- Track data lineage for sensitive content Record where sensitive files originated, how they moved, who touched them, and where they currently reside so analysts can distinguish expected work from suspicious relocation. Lineage should support real-time decisions, not just after-action review.
- Extend controls into AI and SaaS workflows Review whether GenAI and collaboration platforms can ingest or expose sensitive data outside the policy paths your current controls understand. If they cannot, treat them as active data movement surfaces, not just productivity tools.
Key takeaways
- Most data security programmes fail at the handoff between visibility and enforcement, not at discovery itself.
- GenAI, SaaS, and endpoint movement make context preservation a core control requirement for sensitive data.
- Teams should design for one policy model, one lineage view, and one enforcement path across the data lifecycle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Unified data protection is directly about protecting data across states and locations. |
| NIST SP 800-53 Rev 5 | AC-6 | Least-privilege access is central when data follows users across endpoints and SaaS. |
| MITRE ATT&CK | TA0009 , Collection; TA0010 , Exfiltration | The article's risk model is about sensitive data collection and movement across environments. |
| CIS Controls v8 | CIS-3 , Data Protection | CIS data protection controls align with the need to classify and govern sensitive content everywhere. |
Map risky file movement and copying behaviour to collection and exfiltration tactics for detection and response.
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.
- DSPM: Data Security Posture Management is the discipline of finding, classifying, and protecting sensitive data across storage systems and workflows. In AI environments, DSPM helps teams understand what data exists, where it lives, and whether AI systems can access it appropriately.
- DLP Monitoring: DLP monitoring is the continuous observation of how sensitive data is stored, moved, and used. It combines content awareness with policy enforcement so organisations can spot unauthorised sharing, risky transfers, and abnormal access before data leaves approved boundaries.
- Data as the control plane: A governance model that treats data classification, lineage, retention, and usage rights as the main control surface for AI systems. For agentic environments, it means the data layer determines what the system can safely see, transform, and write back across workflows.
What's in the full article
Cyberhaven's full article covers the operational detail this post intentionally leaves for the source:
- How its combined DSPM and DLP workflow is intended to reduce translation gaps between discovery and enforcement
- Examples of endpoint-first data tracking across cloud, SaaS, email, and personal devices
- The specific way lineage is used to decide whether a file move is risky or routine
- Why the vendor frames unified data security as a platform operating model rather than a stitched integration layer
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, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity control to broader security operations and governance.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org