Notifications
Clear all
Topic starter
02/08/2026 11:36 am
TL;DR: First-generation DSPM tools often stop at cloud discovery, leaving gaps in endpoint coverage, lineage, and enforcement as data moves toward unauthorized destinations, according to Cyberhaven. The practical shift is from static visibility to continuous control, especially where sensitive data flows into browsers, SaaS apps, and AI tools.
NHIMG editorial — based on content published by Cyberhaven: DSPM Buyer's Guide: 7 Criteria for Evaluating DSPM Tools
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams evaluate DSPM tools that claim to go beyond cloud discovery?
A: Teams should test whether the platform covers endpoints, browsers, SaaS apps, and unmanaged devices, not just cloud repositories.
Q: Why does data lineage matter more than static classification in DSPM?
A: Static classification tells you where sensitive data exists at a point in time.
Q: What breaks when DSPM cannot enforce policy in real time?
A: The gap between detection and action becomes the failure mode.
Practitioner guidance
- Validate endpoint and browser coverage Test whether the DSPM platform can see sensitive data on managed and unmanaged endpoints, then track it through browser uploads, local file copies, and SaaS transfers.
- Require lineage-based classification Confirm that sensitivity labels persist after copy-paste, rename, format change, and application transitions so data context does not reset at each hop.
- Test native enforcement before rollout Run scenarios where users attempt to upload sensitive content to personal cloud storage or unsanctioned AI tools and verify that policy can block the event in real time.
What's in the full article
Cyberhaven's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step evaluation criteria for endpoint data visibility and unmanaged device coverage
- Operational distinctions between DSPM, DLP, and lineage-based enforcement across SaaS and AI tools
- Examples of how provenance-aware classification reduces false positives in real environments
- Questions to ask about onboarding time, evidence storage, and long-term program control
👉 Read Cyberhaven's guide to evaluating next-generation DSPM tools →
DSPM beyond cloud scans: are your controls keeping up?
Explore further
02/08/2026 12:49 pm
Discovery without enforcement is not a control strategy. Static visibility still has value, but it cannot close the gap between seeing sensitive data and stopping its movement. In modern data environments, that gap is where most practical exposure occurs, especially when endpoints, SaaS, and browser-based workflows are in play. Practitioners should treat alerting-only DSPM as an inventory layer, not as a protection layer.
A question worth separating out:
Q: Should organisations treat DSPM as part of IAM or data security?
A: Organisations should treat DSPM as part of both, because sensitive data exposure depends on identity paths as much as data location. If IAM and DSPM stay separate, teams can classify data accurately while leaving excessive access untouched. The operational answer is one control model across access, classification, and review.
👉 Read our full editorial: DSPM is moving from discovery to enforcement across endpoints
