DSPM maturity models expose the gap between data visibility and control

At a glance

What this is: This is a guide to assessing DSPM maturity, with the key finding that many programs still overestimate how much sensitive data they can actually see and control.

Why it matters: It matters to IAM and security teams because data exposure now depends on identity, access, and movement across endpoints, SaaS, and AI tools, not just on storage location.

By the numbers:

• More than 80% of data consists of fragments: pieces of strategic plans, customer records, and acquisition details moving through browsers and collaboration tools without triggering file-based controls.

👉 Read Cyberhaven's DSPM maturity model for data visibility, lineage, and enforcement

Context

DSPM maturity models are an answer to a basic governance problem: many organisations know where some sensitive data lives, but not where it moves, who touches it, or which identities can expose it. In practice, cloud scanning and periodic audits miss the data fragments that now flow through browsers, collaboration tools, endpoints, and AI applications.

The primary gap is not storage discovery alone, but control over data movement across identity-driven work paths. That makes DSPM relevant to IAM practitioners, because access policy, user behaviour, and data posture now intersect in the same workflows, especially where SaaS sharing and AI-assisted work create unmanaged copies.

Key questions

Q: What breaks when DSPM only covers static data stores?

A: When DSPM stops at static repositories, it misses the highest-risk part of AI use: data in motion through prompts, outputs, and training flows. That leaves over-permissioned access, untracked reuse, and policy violations invisible until after the fact. In practice, the programme can look compliant while AI users are still exposing sensitive material.

Q: Why do identity and access controls matter to DSPM maturity?

A: Because the same user, service account, or application that can move data can also expose it. If IAM and data governance are not joined up, organisations may know a file is sensitive but still be unable to explain which identities replicated it, where it went, or whether access should now be revoked.

Q: What do teams get wrong about DPI or DLP versus DSPM?

A: They often treat DLP as the substitute for data posture. In reality, DSPM identifies sensitive content, where it lives, and how it moves, while DLP enforces policy when risk appears. If posture is weak, DLP becomes reactive containment rather than a control built on accurate visibility.

Q: How should organisations govern access to data used by AI systems?

A: Treat AI data access as an identity governance problem, not just a data storage problem. Define who or what can use each dataset, what purpose is allowed, and what runtime restrictions apply. Then review humans, service accounts, and AI agents separately so entitlement scope matches actual behaviour rather than a generic AI policy.

Technical breakdown

What a DSPM maturity model measures

A DSPM maturity model measures how well an organisation discovers, classifies, monitors, and controls sensitive data across its environment. The important distinction is between point-in-time inventory and continuous posture management. Early-stage programs may find structured cloud data, but they miss unstructured content, endpoint copies, SaaS replicas, and AI-generated fragments. Mature programs combine semantic classification, provenance tracking, and policy enforcement so that data risk can be assessed in motion, not only at rest.

Practical implication: assess whether your program can answer where data moved, not only where it was stored.

Why endpoint and SaaS coverage change the model

Endpoint and SaaS coverage matter because they are now primary creation and transfer points for sensitive data. A cloud-only DSPM model can report what sits in repositories, but not what users copy into chats, browser sessions, collaboration tools, or external AI services. That leaves a blind spot between access and exfiltration. Continuous discovery and lineage close that gap by linking the source, the user, the destination, and the resulting exposure state.

Practical implication: treat endpoint and SaaS visibility as part of data governance, not as optional add-ons.

How policy-driven enforcement differs from scanning

Scanning tells you a sensitive item exists. Policy-driven enforcement changes what happens when that item is found or moved. At higher maturity levels, DSPM findings can trigger quarantine, access revocation, DLP updates, or insider-risk workflows automatically. That shifts the programme from descriptive reporting to operational control. For AI surfaces, the same logic extends to prompts and outputs, where sensitive fragments can appear without any file object ever being created.

Practical implication: connect DSPM findings to enforcement actions so classification becomes operational, not merely informational.

Threat narrative

Attacker objective: The attacker objective is to collect sensitive fragments from uncontrolled work paths and turn ordinary collaboration into a durable data exposure channel.

1. Entry occurs when sensitive fragments are copied into unmanaged endpoints, SaaS tools, or AI applications outside the controlled data store.
2. Escalation follows when those fragments are replicated, shared, or reprocessed by identities that were never intended to hold persistent access to them.
3. Impact is realised when the organisation loses track of provenance and cannot reliably prove where the sensitive data travelled or who exposed it.

NHI Mgmt Group analysis

Data security posture is now an identity problem as much as a storage problem. When users move sensitive fragments through browsers, SaaS tools, and AI applications, access control and data control become the same governance challenge. DSPM maturity therefore needs to be measured against identity paths, not just repository coverage. Practitioners should treat data movement as an identity-governed control surface.

Fragmented data creates a posture gap that traditional scanning cannot close. The article’s own framing around fragments is the right one, because unlabelled content rarely behaves like a neat file in a fixed location. A program that only scans known repositories will always understate its exposure. Fragment visibility gap: this is the specific failure mode where sensitive content exists in plain sight but outside the rules that monitoring systems expect. Practitioners should design for continuous lineage and semantic discovery.

AI-aware DSPM is becoming a governance baseline, not a future feature. Once employees and AI systems can generate, rewrite, and redistribute sensitive context at runtime, static DLP assumptions stop holding. That extends the governance scope from documented repositories to generated outputs and delegated workflows. The relevant question is no longer whether data exists, but whether the organisation can prove how it was transformed and by which identities. Practitioners should connect DSPM to AI policy and access governance now.

DSPM maturity should be judged by enforceability, not inventory completeness. Mature programmes do not stop at reporting where data sits. They can intervene when exposure is detected, including through access revocation, blocking, and behavioural review. That is where DSPM starts to overlap with broader NIST CSF control objectives and with identity governance. Practitioners should prioritise response workflows that change exposure outcomes, not dashboards that simply describe them.

What this signals

Fragment-aware DSPM will become a baseline expectation for data programmes. If your visibility model still assumes sensitive information stays inside files or databases, your programme will miss the way people actually work. The practical shift is toward lineage, continuous classification, and policy enforcement across endpoints, SaaS, and AI tools, with identity controls attached to each movement event.

AI surfaces are collapsing the separation between data governance and access governance. When prompts, outputs, and delegated workflows can carry sensitive context, the boundary between data loss and misuse becomes much thinner. Practitioners should expect audit questions to focus less on whether a tool is approved and more on whether the organisation can prove who moved what, where, and under which policy.

Our research on secrets sprawl shows how fast hidden exposure accumulates once data and credentials leave controlled systems. That is why DSPM programmes need to pair visibility with response, especially where the 52 NHI breaches Report shows how unmanaged access paths amplify downstream risk.

For practitioners

• Map data movement by identity path Trace how sensitive data moves from origin to endpoint, SaaS, and AI tools, and identify which users or service accounts are creating unmanaged copies. Focus on the workflows where fragments leave controlled repositories and are hardest to reconstruct later.
• Extend discovery beyond cloud repositories Include endpoints, collaboration tools, and browser-based workflows in continuous discovery so the programme does not stop at storage scanning. This is where sensitive fragments are most often created, shared, and repurposed.
• Connect DSPM findings to enforcement Make classification trigger operational actions such as access revocation, blocking, quarantine, or insider-risk review instead of leaving results in reports. Link the policy response to the exposure condition so the control changes outcomes.
• Include AI prompts and outputs in scope Treat generative and agentic AI workflows as data movement channels and monitor both user inputs and AI-generated outputs for sensitive content. This is the point where traditional file-centric controls stop being sufficient.

Key takeaways

• DSPM maturity is really about whether an organisation can see and control sensitive data as it moves, not just where it is stored.
• Fragmented content, endpoint copying, SaaS sharing, and AI-generated outputs are the main reasons posture and reality diverge.
• The next maturity jump is enforcement, where discovery results trigger access control, blocking, or risk review instead of reporting alone.

Key terms

• DSPM Maturity Model: A DSPM maturity model is a structured way to assess how effectively an organisation discovers, classifies, monitors, and controls sensitive data. It moves the conversation from whether a tool exists to whether the programme can continuously reduce exposure across real work environments.
• 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.
• Policy-Based Enforcement: Policy-based enforcement is a control model that evaluates whether an action is allowed based on context, not just static role membership. For agents, that means checking the requested action, resource, device state, and trust signals before execution is permitted.
• Fragmented Data: Fragmented data is sensitive information broken into pieces that move through browsers, collaboration tools, endpoints, and AI workflows rather than remaining in a single file or repository. These fragments are difficult to classify with traditional rules and often escape file-based controls.

What's in the full article

Cyberhaven's full article covers the operational detail this post intentionally leaves for the source:

• How to assess your current DSPM level using the article's operational questions and scoring logic
• The five-stage maturity progression from reactive inventory to continuous AI-aware data security
• How Cyberhaven links data lineage, AI security, and DLP enforcement into one posture model
• Why endpoint coverage changes the maturity assessment and where cloud-only scanning falls short

👉 Cyberhaven's full post covers the five maturity levels, assessment questions, and AI-aware control model

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity controls to the broader exposure patterns that data programmes now depend on.