Most organisations cannot say where their sensitive data lives across cloud, SaaS and AI pipelines, or which people, service accounts and AI agents can reach it. Data security posture management (DSPM) tools set out to answer both questions: they discover data stores, classify what is inside them, analyse who and what has access, and flag posture problems such as public exposure, missing encryption or data held in the wrong region. Products differ widely in which stores they really scan, how accurately they classify and whether they go beyond a findings list. This vendor-neutral guide is for security architects, data protection leads and cloud security teams writing requirements or running an RFP: what to define first, the criteria to score, the questions that expose weak answers and a proof of concept on your own data. Our Data Security Guide covers the wider control set.
Key takeaways
- Coverage is the first filter. List your data stores (object storage, managed databases, warehouses, SaaS, on-premises shares, vector stores) and score each product on what it scans today, not on its roadmap.
- Classification quality decides the noise level. Test accuracy on your own data, including custom identifiers for internal record formats, and ask how the tool samples rather than accepting a headline detection rate.
- Access analysis is where DSPM earns its keep. A sensitive bucket only matters in context: which identities, including service accounts, roles and AI agents, can read it, and through which path.
- The scanner is a privileged non-human identity. It usually holds read and decrypt rights across your estate. Score how it is scoped, where it processes data and what leaves your region.
- Price the scanning, not just the licence. Per-gigabyte inspection, cloud API and compute charges add up quickly, so model the cost of your real data volumes before you sign.
Define requirements
DSPM sits between several existing tools, and buying it without defining the boundary leads to overlapping findings and unclear ownership. Agree the following before talking to vendors.
- Data estate in scope: list cloud accounts, subscriptions and projects; managed databases and warehouses; SaaS applications holding regulated data (collaboration suites, CRM, ticketing); on-premises file shares and databases; and AI pipelines such as training data sets, feature stores and retrieval-augmented generation (RAG) indexes.
- Data types that matter: regulated personal, payment and health data, credentials and secrets, intellectual property and internal record formats. Your classification scheme should drive classifier configuration, not the reverse. See the Data Classification Guide.
- Scanning constraints: whether data may be processed outside its region, whether a vendor's SaaS may receive content or only metadata, and which teams must approve the cloud roles the scanner needs.
- Outcomes: inventory and classification only, posture findings with remediation, or detection and response on data access (often marketed as data detection and response, DDR). Each step up changes the integrations you need.
- Owners: who acts on a finding for each database, bucket or site. Without named data owners, DSPM produces a backlog no one works. A record of processing or data map gives a starting list. See the Data Mapping and ROPA Guide.
- Control obligations: map requirements to what you report against: NIST CSF 2.0 ID.AM-07 (inventories of data and metadata for designated data types) and PR.DS-01 (data at rest), NIST SP 800-53 RA-2 (security categorisation), AC-6 (least privilege) and SC-28 (protection of information at rest), CIS Controls v8.1 Safeguards 3.2 (data inventory), 3.7 (data classification scheme), 3.8 (document data flows) and 3.11 (encrypt sensitive data at rest), ISO/IEC 27001:2022 Annex A 5.9 (inventory of information and other associated assets) and 5.12 (classification of information), and GDPR Articles 30 (records of processing) and 32 (security of processing). Ask each vendor which findings and reports evidence these.
| Tool category | Primary question it answers | Overlap with DSPM |
|---|---|---|
| DSPM | Where is sensitive data, who can reach it, and is its posture acceptable? | Not applicable |
| CSPM and CNAPP | Are cloud resources configured securely, and what attack paths exist? | Public buckets and unencrypted stores; CNAPP adds attack paths but often lacks deep content classification. See the CNAPP Guide and the Cloud Misconfiguration Guide. |
| DLP | Is sensitive data leaving through email, endpoints, web or SaaS? | Shared classifiers and labels; DLP enforces on data in motion, DSPM assesses data at rest. See the DLP Buyer's Guide. |
| CIEM | Which identities hold excessive cloud permissions? | DSPM access analysis should reuse entitlement data. See the Cloud PAM and CIEM Guide. |
Size changes the answer. A single-cloud organisation may find native discovery covers most stores, with a third-party DSPM adding mainly cross-cloud and SaaS coverage. An enterprise with several clouds, on-premises databases and regulated data in many jurisdictions needs broader connectors, residency controls and workflow that routes findings to hundreds of owners. Native tools also change: Google Cloud states that its Security Command Center DSPM "will be shut down on February 1, 2027", so check the lifecycle of any native capability you plan to rely on.
Evaluation criteria
Weight these to your requirements. An illustrative split is 25% coverage and scanning, 20% classification, 20% access analysis, 15% remediation and integrations, 10% detection, 10% cost and platform security; adjust it rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Discovery coverage | Object storage, managed databases and warehouses across your clouds, named SaaS applications, on-premises shares and databases, and AI data stores; discovery of unmanaged ("shadow") stores such as copies, snapshots and self-hosted databases on virtual machines | Database coverage that requires you to export data first; "supported" lists with storage classes, engines or encryption modes quietly excluded |
| Scanning method and residency | Agentless scanning through cloud APIs or snapshots, processed in your account or region, with only metadata sent to the vendor; documented sampling depth and rescan frequency | Content copied to the vendor's cloud; no statement of what leaves the region; unknown impact on production databases |
| Classification accuracy | Built-in identifiers for personal, financial and credential data; custom classifiers (regular expressions plus keywords and proximity rules); allow lists for known false positives; confidence thresholds; reuse of existing sensitivity labels | No way to tune or suppress; accuracy claims without a method; secrets and tokens not detected |
| Access analysis | Effective access to each sensitive store, resolved through groups, roles, policies, sharing links and cross-account trust, covering human users, service accounts, workload roles and AI agents | Lists bucket policies but does not resolve role assumption, impersonation or shared access tokens and links; ignores non-human identities |
| Data flow and lineage | Tracks copies, exports, snapshots and pipeline movement of sensitive data, including movement across regions and into non-production | Each copy appears as an unrelated finding with no source |
| Posture rules and remediation | Rules for public exposure, encryption with customer-managed keys, retention limits and residency; ticketing and owner routing; optional automated fixes with approval | Fixed rule set; remediation means "open the console and fix it" |
| Detection and response (DDR) | Alerts on unusual access to sensitive stores using cloud audit logs, such as mass reads, access from new principals or locations, and policy changes; SIEM and SOAR integration | Detection that depends on logs you have not enabled, with no warning that they are missing; no coverage of warehouse or SaaS query logs |
| AI data security | Discovers training data sets and RAG sources, classifies them, and flags overshared content that copilots and agents can retrieve | AI support limited to a dashboard of AI app usage |
| Cost and platform security | Transparent pricing by store, object or volume; cost estimates before a scan; SSO, MFA, tenant audit log and current independent assurance for the vendor platform | Unbounded per-gigabyte charges; no audit log of who changed scan scope or suppressions |
Provider documentation shows the level of detail to demand. Microsoft's Defender for Cloud discovery "operates by sampling" (up to 20 MB per file, 300 to 1,024 table rows), "might not detect all types", scans RDS from an automated snapshot "in an isolated scanning environment within the same AWS region", and cannot read S3 objects encrypted with customer-provided keys (Microsoft Learn, prerequisites). Amazon Macie analyses S3 buckets only, so RDS, Aurora and DynamoDB data must be exported first; custom identifiers combine a regular expression with optional character sequences and a proximity rule (AWS documentation). Scanning cost is real: Macie lists $1 per GB inspected in US East, plus S3 request charges (AWS pricing). For AI data, OWASP warns: "Inadequate or misaligned access controls can lead to unauthorized access to embeddings containing sensitive information." (OWASP LLM08:2025), and Microsoft notes that "generative AI amplifies the problem of oversharing data" (Microsoft Purview). See the Enterprise AI Copilot Security Guide.
Two incidents show why the access and detection rows carry weight. In the Microsoft SAS token exposure, one over-permissive sharing link exposed 38TB of internal data: a DSPM that only reads bucket policies would not see that path. In the Snowflake breach, infostealer credentials on accounts without MFA unlocked 165 customer data warehouses, so ask whether the product watches warehouse query activity for mass reads, not just storage configuration.
Where identity fits
A classified data store is only a risk if someone or something can reach it, and in cloud estates most of that access belongs to non-human identities: workload roles, service accounts, CI/CD pipelines, ETL jobs, analytics connectors and, increasingly, AI agents. Score how completely the product resolves effective access for these identities, including role chaining, service account impersonation and cross-account trust. Native controls are not always complete here: Google Cloud documents that for its "Restrict Access to Sensitive Data to Permitted Users" control, "Access by service accounts, including service account impersonation, is exempt" (Google Cloud documentation). The Capital One breach is the reference case: credentials for a firewall's cloud role were used to reach stored data on 106 million people. The DSPM scanner is itself an NHI: Microsoft's AWS connector creates an IAM role with "S3 read only; KMS decrypt", and Google's discovery runs through a service agent that must be granted profiling permissions on the resources it profiles. Require a named owner, least privilege, monitoring of the scanner role and a way to revoke it. See the Service Account Security Guide and the Cloud Workload Identity Guide.
Questions to ask vendors
- For each data store type in our estate, which engines, storage classes and encryption modes do you scan today, and which require us to export or copy data first? Show it on our environment, not a slide.
- Where is content processed during a scan, what exactly is sent to your service, and can scanning be confined to our accounts and regions?
- How do we build and test a custom classifier for an internal record format, and how do we suppress a recurring false positive without hiding real findings?
- How do you calculate effective access for a service account or workload role that reaches data through role assumption, impersonation or a cross-account trust? Show one end to end.
- Which permissions does your scanner request in each cloud and SaaS application, are they read-only, and can it use short-lived federated credentials rather than static keys?
- How do you discover and classify RAG sources and vector stores, and can you show which identities and AI agents can retrieve a given sensitive document? See the Permission-Aware RAG Guide.
- Which findings can you remediate automatically, with what approval, and how is a change rolled back?
- What does the pricing count, and what would a first full scan and a year of rescans cost for our volumes, including cloud provider charges?
Red flags
- Coverage claims that fall apart for databases, on-premises stores or SaaS once the proof of concept starts.
- Scanning that copies your content into the vendor's environment by default, or no clear answer about data residency.
- Classification accuracy quoted as a single percentage with no test method and no ability to tune.
- Access analysis that covers people but not service accounts, workload roles or AI agents.
- A scanner role that asks for write, delete or administrator permissions, or relies on long-lived access keys. See the API Key Management Guide.
- Findings with no owner routing, so every alert lands on the security team.
- Cost estimates that leave out per-gigabyte inspection or cloud API and compute charges.
Proof of concept
- Scope it: choose one account or subscription per cloud, two managed databases, one warehouse, one SaaS collaboration tenant, one on-premises file share if in scope and one RAG index. Agree pass criteria and weights before the first demo.
- Seed known data: plant test records (synthetic personal data, test card numbers, dummy API keys and an internal record format) in known locations, including a snapshot and a copy in a non-production account. Measure what is found, what is missed and the false positive rate.
- Connect with least privilege: create dedicated read-only scanner identities with named owners and expiry, record every permission requested, and confirm what data leaves each region.
- Test access analysis: give a test service account read access to a seeded store through a role assumption or group, and check the product reports the path. Repeat for a broadly shared document reachable by an enterprise copilot.
- Exercise remediation and detection: make a seeded bucket public, remove encryption from a test store and run a bulk read from a new principal. Time each finding and alert, and check it reaches the right owner and the SIEM. Re-enable encryption and public access blocks straight after each test.
- Measure cost: record the vendor charges and the cloud provider charges for the trial scans, then extrapolate to your full estate.
- Roll back: remove the scanner roles and connectors, confirm scanning stops, and obtain written confirmation that any metadata held by the vendor has been deleted.
Carry a few measures into production: percentage of in-scope data stores scanned in the last 30 days, false positive rate on sampled findings, number of sensitive stores reachable by non-human identities with no owner, median time to remediate public or unencrypted sensitive stores, and scanning cost per terabyte.
How NHI Mgmt Group can help
We provide independent market analysis, requirements definition and RFP support for data security and DSPM programmes, including how scanners and other non-human identities reach your data. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Data Security Guide · Data Classification Guide · Data Loss Prevention (DLP) Guide · CNAPP Guide · NHI Security Platform Buyer's Guide