Most organisations cannot say where all their sensitive data lives, who can reach it or whether it is protected, because data now spreads across cloud storage, databases, SaaS, data lakes and AI pipelines faster than any manual inventory can follow. Data security posture management (DSPM) is the discipline, and the tool category, that answers those questions continuously: it discovers data stores, classifies the sensitive data inside them, maps who and what can access it, and flags exposures such as public storage, over-broad access, missing encryption and copies in places they should not be. This guide explains what DSPM does, how it differs from data loss prevention (DLP) and cloud security posture management (CSPM), the main use cases including AI, and its limits. It is for security architects, data protection teams and buyers. Step-by-step rollout is covered in the DSPM Implementation Playbook, and tool selection in the DSPM Buyer's Guide.
Key takeaways
- DSPM starts from the data, not the infrastructure. CSPM asks whether a bucket is misconfigured; DSPM asks what is in the bucket, how sensitive it is and who can reach it, then prioritises by that.
- It is posture, not enforcement. DSPM finds and prioritises risk at rest; DLP blocks data in motion and in use. Most programmes need both, fed by the same classification.
- Shadow data is the core problem it solves. Forgotten snapshots, test copies of production, exports, logs and training sets are where sensitive data turns up unprotected.
- Access mapping matters as much as classification. The useful finding is "customer records readable by a service account with an unused key", not just "personal data found".
- Value comes from remediation, not discovery. Without data owners, a triage process and automated fixes for common issues, DSPM produces a long list of findings and little change.
What DSPM does
Product scope varies, but most DSPM tools perform the same five functions, usually agentlessly through cloud and SaaS APIs:
- Discover data stores: enumerate object storage, managed databases, data warehouses, file shares, SaaS repositories and, increasingly, AI training and retrieval data, including stores nobody registered.
- Classify contents: sample or scan data to identify sensitive types (personal data, payment card data, health data, credentials, intellectual property) with pattern matching, dictionaries and machine learning, and assign a sensitivity level.
- Map access: resolve which human and non-human identities, roles, groups, external accounts and public links can read or change each store, and whether that access is used.
- Assess posture: check encryption, public exposure, cross-account sharing, logging, retention, data residency and replication against policy, and track data movement and copies.
- Prioritise and remediate: score findings by sensitivity times exposure, route them to data owners, and open tickets or apply fixes (remove public access, revoke a link, apply a label or DLP policy).
The cloud providers' native services illustrate the range. They are listed alphabetically; the order is not a ranking, and NHI Mgmt Group does not recommend products.
| Service | Discovery and classification | Posture and access insight | Integration and action |
|---|---|---|---|
| Amazon Macie | Automated sensitive data discovery samples representative S3 objects continually; discovery jobs give deeper targeted scans; managed and custom data identifiers cover personal, financial and credential data | Maintains an S3 bucket inventory and raises policy findings, for example a bucket becoming publicly accessible or shared with other accounts, with public access and encryption breakdowns | Publishes findings to Amazon EventBridge and AWS Security Hub; central management through AWS Organizations |
| Google Cloud Sensitive Data Protection discovery | Continuous data profiles for BigQuery, Cloud SQL, Cloud Storage and Vertex AI training data, plus Amazon S3 and Azure Blob Storage at bucket or container level; predicted infoTypes | Each profile carries calculated data risk and sensitivity levels; reprofiling on a schedule or when schemas or templates change; secrets detected in Cloud Run environment variables | Sends profiles to Security Command Center and Knowledge Catalog; Pub/Sub notifications when sensitivity changes |
| Microsoft Purview DSPM | Scans for sensitive data across Microsoft 365, Azure and Fabric, with third-party sources including Google Cloud, Snowflake and Databricks and partner integrations | Consolidates insights from DLP, Insider Risk Management and sensitivity labels into one view of risk and policy coverage; covers AI apps and agents and their sensitive interactions | Recommends and automates actions such as removing public sharing links or applying DLP policies; guided data security objectives |
Availability notes: Amazon Macie has no minimum commitment and a 30-day free trial that excludes discovery jobs. For Google Cloud Sensitive Data Protection discovery, Google lists exclusions such as BigQuery Omni tables and rows over 128 MB. Microsoft refers to the Purview service description for licensing, and getting started requires the Compliance Administrator role or equivalent role group. Independent DSPM products typically aim to cover several clouds, SaaS and databases in one inventory; evaluate them with the DSPM Buyer's Guide.
DSPM vs DLP vs CSPM and related tools
| Category | Core question | Primary object | Typical action | Blind spot on its own |
|---|---|---|---|---|
| DSPM | Where is sensitive data, who can access it, is it protected? | Data stores and their contents | Find, prioritise, route or fix exposure at rest | Does not stop data leaving in real time |
| DLP | Is sensitive data leaving or being misused right now? | Data in motion and in use (email, web, endpoint, SaaS) | Block, warn, encrypt, log | Only sees channels it sits on; needs good classification |
| CSPM | Is cloud infrastructure configured securely? | Cloud resources and settings | Flag and fix misconfiguration against benchmarks | Treats an empty bucket and a bucket of patient records the same |
| Data classification tools | What sensitivity label does this item carry? | Files and records | Label, often user-driven or rule-driven | Little view of infrastructure exposure or access |
| Data access governance and IGA | Who should have access, and is it reviewed? | Entitlements and identities | Certify, revoke, approve | May not know which resources hold sensitive data |
- Choose DSPM first when the main risk is unknown data in the cloud and SaaS estate: post-merger estates, fast-growing data platforms, AI programmes.
- Choose DLP first when the main risk is staff sending data out through email, web upload or endpoints. See the Data Loss Prevention (DLP) Guide.
- Use CSPM findings with DSPM context: a public bucket finding from CSPM becomes a critical incident when DSPM says it holds payment data. See the Cloud Security Posture Management (CSPM) Guide.
- Platforms are converging: cloud-native application protection platforms and data security platforms increasingly bundle DSPM, so compare capabilities rather than labels. See the Data Security Platform Buyer's Guide.
Use cases that justify DSPM
- Shadow data discovery: finding unmanaged copies such as database snapshots shared across accounts, CSV exports in personal buckets, test environments loaded with production data and logs that captured tokens. The DeepSeek database exposure showed how a log store, reachable without authentication, can hold chat histories and API keys that nobody classified as sensitive.
- Regulatory scope and records: producing an evidence-based inventory of where personal data is processed to support GDPR Article 30 records and Article 32 security measures, PCI DSS cardholder data environment scoping and data residency obligations.
- Access reduction: identifying sensitive stores readable by broad groups, external accounts, public links or unused service accounts, then feeding those findings into access reviews. See the Data Classification Guide for the label scheme DSPM findings should use.
- Breach scoping: when a credential is stolen, answering within hours which sensitive data that identity could reach. This turns a guess about notification into a list.
- Cloud migration and M&A: establishing what data arrived, where, and with what protection, before it is merged or decommissioned.
- Retention and minimisation: finding stale sensitive data past its retention period so it can be deleted, which shrinks the attack surface rather than just guarding it.
Deployment models and what to ask about them
How a DSPM tool reaches your data decides its coverage, its cost and the new risk it introduces. Three models are common, and many products combine them. The table is our editorial summary, not a vendor or analyst classification.
| Model | How it works | Advantages | Questions to ask |
|---|---|---|---|
| Provider-native service | Runs inside the cloud provider and reads stores through internal integrations | No data leaves the provider; simple to enable per account | Which stores and other clouds are covered, and how findings reach your SIEM |
| Agentless, in-account scanning | A read-only role lets the tool enumerate stores; scanning runs in compute deployed in your own accounts | Broad multi-cloud coverage; data contents stay in your environment | What leaves your account (metadata, samples, snippets), and how the scanner role is scoped |
| Vendor-hosted scanning | Samples or snapshots are processed in the vendor's environment | Least infrastructure to run | Where samples are stored, for how long, in which jurisdiction, and under what contract terms |
Whatever the model, ask whether classification results include snippets of the sensitive values themselves. A DSPM console that displays card numbers or health data to every analyst has created a new exposure; prefer masked evidence and role-based access to findings. Agree the scanner's read scope with data owners up front, and log every read the scanner identity performs so its access can be audited like any other privileged non-human identity.
DSPM for AI
AI programmes create new data stores quickly: training and fine-tuning datasets, retrieval-augmented generation (RAG) indexes, vector databases, prompt and response logs, and agent memory. Each can contain sensitive data copied from systems with stricter controls. DSPM extends naturally here, and vendors now market AI coverage explicitly: Google's discovery service profiles Vertex AI training data, and Microsoft Purview DSPM inventories AI apps and agents and their sensitive interactions.
- Before ingestion: classify sources feeding a model or RAG index so restricted data is excluded or masked, rather than discovered after it is embedded.
- Permission inheritance: a retrieval index or agent that runs with a broad service identity can surface documents to users who could not open the originals. DSPM access mapping should include the identities AI systems use.
- Logs and memory: prompt logs and conversation history are new sensitive data stores; include them in scope and retention policy.
Related guidance: Vector Database Security Guide, Generative AI Data Loss Prevention Guide and GenAI Data Security Risks and Mitigations Guide.
Where identity fits
Data exposure is usually an access problem. A DSPM finding is only actionable if it names the identities that can reach the data, and in cloud estates most of those are non-human: service accounts, roles, access keys, OAuth applications and data pipeline credentials. Prioritise findings where sensitive data is reachable by identities with long-lived keys, external trust or no recent use, and feed them into the Cloud IAM Review Checklist process. Credentials are also a data class: DSPM that detects secrets in storage, logs and environment variables helps close the loop between data security and secrets management.
Limits of DSPM
- Classification is probabilistic: sampling and machine learning produce false positives and misses, especially for unstructured data, images and domain-specific identifiers. Tune with custom identifiers and allow lists, and measure accuracy.
- Coverage stops at the connector: on-premises stores, niche SaaS and self-hosted databases may need agents or network access, and anything without a connector is invisible.
- Scanning has a cost and a footprint: reading data means the DSPM tool itself needs read access to sensitive stores. Its service identity becomes a high-value target; scope it read-only and monitor it.
- Posture is a snapshot: reprofiling intervals (for example, a default 30-day wait before reprofiling changed resources in Google's discovery service) mean new exposures can sit for a while between scans unless event triggers are used.
- It does not fix anything by itself: remediation depends on owners, workflows and permission to change production. See the DSPM Implementation Playbook.
Detection and measurement
| Metric | Why it matters |
|---|---|
| Percentage of data stores discovered and classified, by environment | Coverage is the foundation; unknown stores are unmanaged risk |
| Sensitive stores with public or external access | The most direct measure of exposure; target zero without an approved exception |
| Sensitive stores reachable by unused or long-lived non-human identities | Links data risk to identity hygiene |
| Median time to remediate critical findings | Shows whether discovery leads to change |
| Sensitive data past retention, by volume | Tracks minimisation progress |
| Classification precision on a sampled review | Keeps trust in findings high enough for owners to act |
Route new critical findings (sensitive store made public, sensitive data copied to a new account or region) to the SOC as alerts, not just dashboard items, and correlate with access logs using MITRE ATT&CK T1530 Data from Cloud Storage detections.
Framework mapping
| Framework | Reference | DSPM contribution |
|---|---|---|
| NIST CSF 2.0 | ID.AM-07, PR.DS-01, ID.RA-01 | Inventory of data and metadata; protection of data at rest; identifying weaknesses |
| NIST SP 800-53 Rev. 5 | CM-8, RA-2, PM-5(1), SC-28 | Component inventory, security categorisation, PII inventory, protection of information at rest |
| CIS Controls v8.1 | Control 3 Data Protection | Data inventory, classification and access control lists |
| ISO/IEC 27001:2022 | Annex A 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 8.12 Data leakage prevention | Evidence-based inventory, classification and exposure reduction |
| GDPR | Articles 5(1)(c), 30, 32 | Data minimisation, records of processing, appropriate security measures |
Common failure patterns
- Buying discovery without owners: thousands of findings with no data owner to accept or fix them; the dashboard ages and trust collapses.
- Scanning only the obvious stores: production databases are covered, but snapshots, backups, logs, analytics exports and AI datasets, where shadow data actually lives, are not.
- Classification without access context: knowing a store holds personal data but not that a decommissioned integration's key can still read it.
- Over-privileged scanner: granting the DSPM tool write or broad admin rights across every account, creating a single identity that can read everything.
- Treating DSPM as DLP: expecting a posture tool to stop an insider uploading files, then discovering it only reports what is stored.
- Ignoring logs as data: application and AI logs holding tokens and personal data are excluded from scope, as the DeepSeek database exposure illustrates.
Practitioner checklist
- Agree a classification scheme and sensitive data types before deploying, and map DSPM labels to it.
- Connect every cloud account, data platform and major SaaS, and track coverage as a metric.
- Include snapshots, backups, logs, analytics exports and AI datasets in scope.
- Give the DSPM service identity read-only, scoped access and monitor its use.
- Assign a data owner to every sensitive store, with remediation service levels by severity.
- Automate fixes for common issues such as public access and stale sharing links, with owner notification.
- Feed access findings into IAM and non-human identity reviews, prioritising unused and long-lived credentials.
- Alert the SOC on critical changes such as sensitive stores becoming public or copied to new accounts.
Standards and references
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Data from Cloud Storage
- AWS: What is Amazon Macie
- Google Cloud: Sensitive Data Protection data profiles
- Microsoft: Learn about Data Security Posture Management
Related NHI Mgmt Group resources: DSPM Implementation Playbook · DSPM Buyer's Guide · Data Security Guide · Data Loss Prevention (DLP) Guide