TL;DR: Integrating DSPM into CNAPP closes a critical data visibility gap by unifying protection, compliance assurance, and attack-surface visibility, according to SentinelOne. Related research notes AI-specific secrets grew by roughly 140% year over year and verified exploit paths now link exposed keys to critical workloads, making data-centric control the practical centre of cloud defence, not a bolt-on.
Editorial analysis by NHI Mgmt Group, based on content published by SentinelOne: “451 Research Report: Completing CNAPP with DSPM”.
Key questions
Q: What breaks when CNAPP is used without DSPM for cloud data governance?
A: CNAPP can show that a workload or account is exposed, but without DSPM it often cannot show whether sensitive data is actually at risk.
Q: Why do exposed cloud secrets become a data access problem so quickly?
A: Because secrets often belong to service accounts or workloads that already have direct paths to storage, APIs, and downstream services.
Q: How do security teams know if public cloud storage controls are working?
A: Measure how quickly changes to bucket policies and ACLs are detected, and track how many identities can alter public access without approval.
Practitioner guidance
- Map sensitive data to reachable identities Correlate cloud data locations with the service accounts, tokens, and workload identities that can access them, then remove unnecessary paths.
- Classify data before you triage posture Use data classification to separate high-impact exposures from routine misconfigurations so remediation follows business sensitivity, not alert volume.
- Inventory AI-specific secrets and API keys Track exposed cloud secrets, AI API keys, and application credentials as first-class cloud exposure objects, not only as secrets-management events.
Bottom line: CNAPP alone can surface cloud posture issues, but DSPM is what turns those findings into data-aware risk decisions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
CNAPP without DSPM leaves a blind spot at the point that matters most: data reachability. Cloud teams have spent years improving posture and workload detection, but those controls stop short of answering whether an exposed system contains sensitive data that changes the risk calculus. Once a dataset is discovered, the governance question shifts from generic exposure to controllable blast radius. Practitioners should treat data visibility as a core part of cloud security architecture, not an adjacent reporting function.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations treat NHI governance and cloud data security as the same problem?
A: They are distinct disciplines, but in cloud environments they frequently converge on the same failure path. A service account, token, or API key is only dangerous in context of the data it can reach, so governance should join identity inventory with data classification. Separate teams can operate them, but separate risk views should not.
👉 Read our full editorial: Completing CNAPP with DSPM closes the cloud data visibility gap