Cloud security posture management (CSPM) tells you a storage bucket is public; data security posture management (DSPM) tells you whether that bucket holds test files or a million customer records, and neither tool on its own tells you which identity can reach it. Teams buying posture tooling keep asking whether they need DSPM if they already run CSPM, or whether a cloud-native application protection platform (CNAPP) with a data module settles the question. This guide compares the two models in depth: what each inspects, the threats each catches, how each is built, how they fail, where they overlap inside CNAPPs and native cloud services, and which to deploy first. It is for cloud security, data protection and security architecture leads. The Cloud Security Posture Management (CSPM) Guide and the Data Security Posture Management (DSPM) guide cover each tool on its own.
Key takeaways
- The short answer is CSPM first, DSPM when data context changes your priorities. CSPM is the baseline for any cloud estate; DSPM earns its cost when you cannot say where sensitive data lives, or when CSPM produces more findings than you can fix and you need to know which ones expose real data.
- They inspect different objects. CSPM evaluates resource configuration against benchmarks; DSPM opens the data stores, classifies contents and maps who can read them. A finding means little without the other half.
- Identity is the join. Most cloud data loss runs through a valid identity with too much access, not a configuration error alone. Both tools are weakest where they do not model effective permissions to data stores.
- CNAPPs and native platforms are merging the two. Native services now feed data sensitivity into posture scoring and attack paths, so check whether your "DSPM" is a classification engine or just a data-aware CSPM view.
- Measure exposure of sensitive data, not finding counts. The useful combined metric is how many stores holding sensitive data are reachable from the internet or by over-privileged identities, and how fast that number falls.
What each one looks at
- CSPM: continuously checks cloud resource configuration against security standards. AWS describes Security Hub CSPM as running continuous account-level configuration checks against controls from standards including AWS Foundational Security Best Practices, CIS, PCI DSS and NIST, with most controls relying on AWS Config rules. The questions are about settings: is public access blocked, is encryption on, is logging enabled, is this port open to the internet.
- DSPM: discovers data stores, including ones nobody registered, samples or scans their contents, classifies sensitive data and evaluates exposure and access. The questions are about content: is there personal, payment or credential data here, who can read it, how many copies exist, and does its protection match its sensitivity.
- Where they meet: data store configuration. Both will flag a public bucket; only DSPM knows what is in it, and only CSPM covers the network, compute and identity settings that make it reachable.
In framework terms CSPM implements configuration baselines and settings (NIST SP 800-53 CM-2 and CM-6), while DSPM implements information location and categorisation (CM-12 and RA-2) and inventories of personal data (PM-5(1)).
Side-by-side comparison
| Dimension | CSPM | DSPM |
|---|---|---|
| Core question | Is cloud infrastructure configured securely? | Where is sensitive data, who can access it, and is it protected to match? |
| Object inspected | Resource configuration and control plane metadata | Data store contents, data copies and access paths |
| How it reads the estate | Cloud provider APIs and configuration recorders, agentless | APIs plus content sampling or scanning, often inside your account |
| Rule source | Benchmarks and standards (CIS, provider best practice, PCI DSS, NIST) | Classifiers and data identifiers, data policies (residency, retention, encryption by sensitivity) |
| Typical finding | Storage public access block disabled; database snapshot shared publicly | Unencrypted copy of payment data in an analytics bucket readable by 40 roles |
| Coverage beyond IaaS | Compute, network, identity, Kubernetes, PaaS settings | Object stores, managed databases, data warehouses, and in some products SaaS and on-premises stores |
| Prioritisation without the other | Severity of the setting, blind to content | Sensitivity of the content, partly blind to network and compute reachability |
| Primary owners | Cloud platform and security engineering | Data protection, privacy and data platform owners |
| Main operating cost | Finding volume, exceptions, remediation routing | Scan cost, classifier tuning, false positives, data owner engagement |
Threat model: what each catches
- Exposed storage: both catch a publicly readable bucket. CSPM catches it as a setting; DSPM raises the priority when the contents are sensitive. The data theft itself maps to ATT&CK T1530 Data from Cloud Storage.
- Misconfigured compute and network: an internet-facing instance with an open management port, or a workload that can reach the instance metadata service without protection. CSPM catches these; DSPM does not look at them.
- Shadow and copied data: production records copied into a test database, a data science bucket or a forgotten snapshot. DSPM catches these by discovering and classifying stores; CSPM sees only a correctly configured resource with no idea what it holds.
- Over-privileged identities reaching data: a workload role or service account that can read far more stores than its function needs. DSPM products that map access, and CSPM products with entitlement analysis, can both surface this; tools that do neither miss the most common path to cloud data loss.
- Attacker discovery: enumeration of cloud resources and objects (T1580 Cloud Infrastructure Discovery, T1619 Cloud Storage Object Discovery) after an identity is compromised. Neither posture tool detects this activity in real time; that is the job of cloud detection and logging. Posture tools reduce what the attacker finds.
- Exfiltration to another account: copying data to an attacker-controlled cloud account (T1537 Transfer Data to Cloud Account). DSPM can flag cross-account sharing of sensitive stores before it is abused; CSPM flags the sharing setting without knowing what it shares.
Architecture in words
CSPM
A CSPM reads configuration through read-only roles or provider-native recorders, normalises resources into an inventory, and evaluates rules continuously or on change. Findings carry the resource, the failed control and the mapped standards. Remediation runs through tickets, guided fixes or automation, and the strongest programmes also push the same rules left into infrastructure as code checks and preventive guardrails. Because CSPM reads metadata only, it is cheap to run across every account and needs no access to data.
DSPM
A DSPM discovers data stores, then needs to read samples of their contents to classify them. Products do this through provider APIs, snapshots or scanners deployed in your own accounts so data does not leave them. Microsoft, for example, documents smart sampling of up to 20 MB per file in storage and 300 to 1,024 rows from selected database tables. Classification results are joined with access and configuration data to score each store by sensitivity and exposure. The architecture question that matters most for buyers is where scanning happens and what the scanner identity can read, because that identity can read your most sensitive data. See Securing the DSPM platform itself.
The combined model
The joined view is a graph: data stores labelled with sensitivity, connected to the identities that can reach them and the network and compute paths that expose those identities. That is what turns "public bucket" or "sensitive data found" into "internet-exposed workload with a role that can read payment data", which is the finding worth fixing first.
Identity access to data stores: the overlap that matters
Cloud data incidents rarely need a public bucket. They need a valid identity with read access to the right store.
- Workload roles: in the Capital One breach, temporary credentials for the role a firewall ran under could list and read many storage buckets holding customer data, far more than the firewall needed. A CSPM sees a role and a bucket that are each acceptably configured; the risk exists only in the combination of reachable workload, broad role and sensitive contents.
- Human and service logins to data platforms: in the Snowflake breach, attackers used credentials stolen by infostealer malware to log in to customer data warehouse accounts that relied on passwords alone. The lesson was customer-side authentication and network restriction, which sits in the identity layer, not in storage configuration. ATT&CK tracks this pattern as T1078.004 Cloud Accounts.
- What to require from either tool: effective permission analysis (not just attached policies) from identity to data store, coverage of machine identities as well as users, cross-account and external sharing, and unused access. Where neither tool does this well, pair them with cloud entitlement management. See the Cloud PAM and CIEM Guide.
Overlap in CNAPPs and native platforms
CNAPPs combine CSPM, workload protection and often entitlement and data modules in one graph; see the CNAPP Guide. The cloud providers' native services show the same convergence. They are listed alphabetically; the order is not a ranking and NHI Mgmt Group does not recommend products.
| Platform | Posture side | Data side | How they join |
|---|---|---|---|
| Amazon Web Services | AWS Security Hub CSPM: continuous checks against standards, findings in the AWS Security Finding Format (ASFF) | Amazon Macie: automated sensitive data discovery by sampling S3 objects, discovery jobs, managed and custom data identifiers, and an S3 bucket inventory evaluating public access, sharing and encryption | Macie publishes policy findings to Security Hub CSPM by default and sensitive data findings once enabled, so bucket posture and contents can be triaged in one ASFF view |
| Google Cloud | Security Command Center: Security Health Analytics misconfiguration detectors, including Cloud Storage public ACL and uniform bucket-level access checks | Sensitive Data Protection discovery: data profiles for BigQuery, Cloud SQL, Cloud Storage and Vertex AI, plus Amazon S3 and Azure Blob Storage, with sensitivity and data risk levels | With data-sensitivity prioritisation enabled, resources holding high or medium sensitivity data become high-value resources in attack exposure scoring |
| Microsoft Azure | Defender for Cloud: Foundational CSPM (inventory, Microsoft cloud security benchmark, secure score, recommendations) and Defender CSPM | Sensitive data discovery extension using Microsoft Purview sensitive information types and labels across object stores and databases | Defender CSPM attack paths and Cloud Security Explorer queries surface, for example, internet-exposed virtual machines with access to sensitive data stores |
- Availability, Amazon Web Services: most Security Hub CSPM controls need AWS Config enabled and recording, and Security Hub CSPM processes findings in the Regions where it is enabled. Macie's 30-day free trial excludes discovery jobs.
- Availability, Google Cloud: attack exposure scores need the Premium tier (or the deprecated Enterprise tier) activated at organisation level, and Google directs new activations to Compliance Manager for misconfiguration checks. Google states the Enterprise tier shuts down on 21 May 2027.
- Availability, Microsoft Azure: Foundational CSPM is free; attack paths, Cloud Security Explorer and sensitive data scanning need the paid Defender CSPM plan, and for Google Cloud resources the data scanning covers Cloud Storage.
Two buyer questions follow. First, is the data module a full classifier with discovery of unregistered stores, or does it label resources for prioritisation only? Microsoft, for instance, notes its discovery may not detect every information type and points to Purview scanning for complete cataloguing. Second, does the product cover the data that matters to you beyond IaaS, such as SaaS, data warehouses and on-premises file shares? Standalone DSPM products often differentiate there. See also DSPM vs DLP and AI-SPM vs DSPM.
Which to deploy first
| Situation | Lead with | Why |
|---|---|---|
| New or fast-growing cloud estate, no posture tooling yet | CSPM | Baseline hygiene across every resource type; cheap, agentless and needed regardless |
| CSPM running, thousands of open findings, no way to rank them | DSPM (or the data module of your CNAPP) | Sensitivity context tells you which findings expose real data |
| Privacy or regulatory obligation to know where personal data lives | DSPM | Information location and data inventories are DSPM outputs, not CSPM ones |
| Merger, data platform sprawl or AI programme copying data into new stores | DSPM | Shadow data and copies are invisible to configuration checks |
| Single cloud, mostly infrastructure workloads, little regulated data | CSPM with native data-aware features | A standalone DSPM may not pay back; enable the provider's data discovery for the few sensitive stores |
| Significant data in SaaS and on premises as well as cloud | CSPM plus standalone DSPM | CNAPP data modules usually focus on cloud stores |
- Small organisations: start with the provider's free or entry posture tier, turn on native data discovery for the stores you know are sensitive, and fix public exposure and broad roles first. A separate DSPM rarely pays back until data spreads across several platforms.
- Large organisations: run CSPM estate-wide, then use DSPM to build the data inventory and feed sensitivity labels back into CSPM and CNAPP prioritisation. Agree early who owns data findings, because cloud teams cannot decide whether a dataset should exist.
- Buying one platform for both: acceptable if its data module discovers and classifies (not just tags), covers your data platforms, and its scanner architecture keeps data in your accounts. Use the CNAPP Buyer's Guide and DSPM Buyer's Guide to test those claims.
Phased approach
- Enable CSPM across all accounts, subscriptions and projects, including the configuration recording it depends on, in every Region you use. Start with one standard rather than all of them.
- Fix the exposure classes first: public storage, public snapshots, internet-exposed management ports and unprotected metadata access, then encryption and logging gaps.
- List known sensitive stores with their owners and turn on data discovery for those first, then widen to the whole estate to find the stores nobody listed.
- Tune classifiers before acting on results: add custom identifiers for your own record formats and allow lists for test data, and review a sample of findings with data owners.
- Join the views: feed sensitivity labels into posture prioritisation (natively or through your CNAPP), and set a rule that any CSPM exposure finding on a sensitive store is critical.
- Add identity: map effective access to sensitive stores for workload roles and service accounts, remove unused access, and require strong authentication on data platform logins.
- Push left: apply the same configuration and data-store rules in infrastructure as code pipelines and preventive guardrails so new stores are born compliant.
Worked scenario: one estate, two tools
A retailer runs 120 cloud accounts across two providers. Its CSPM reports 6,400 open findings, including 230 storage resources with some form of public or cross-account access. The team cannot fix them all in a quarter.
- Data discovery: enabling DSPM on all object stores and managed databases finds 31 stores holding payment or personal data, nine of which were not in the asset register, including a nightly export of the customer table into an analytics bucket.
- Combined priority: of the 230 exposed stores, four hold sensitive data. Those four are fixed in a week. The remaining exposure findings return to the normal CSPM backlog with lower priority.
- Identity finding: access mapping shows 38 roles can read the analytics bucket, including a build pipeline role. The pipeline role is scoped down and the export is moved to a store with tokenised data.
- Prevention: a guardrail now blocks public access on any store tagged sensitive, and DSPM labels drive the tag automatically.
Detection and measurement
Posture tools are not threat detection. Keep cloud audit logging and data access logging on for sensitive stores and alert on bulk reads, new cross-account shares and access from unusual identities (NIST CSF 2.0 DE.CM-09). Measure the posture programme with combined metrics:
| Metric | Source | What good looks like |
|---|---|---|
| Sensitive data stores with public or external access | DSPM plus CSPM | Zero, with any new one fixed within days |
| Percentage of data stores discovered and classified | DSPM | Rising to full coverage of in-scope platforms |
| Sensitive stores unknown to the asset register when found | DSPM | Falling each quarter |
| Identities with unused read access to sensitive stores | DSPM or CIEM | Falling; machine identities reviewed as well as users |
| Median time to remediate critical findings on sensitive stores | Ticketing | Shorter than for other critical findings |
| Accounts, subscriptions and projects with CSPM enabled | CSPM | All, in every Region used |
Framework mapping
| Framework | CSPM | DSPM |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-2 Baseline Configuration, CM-6 Configuration Settings, CA-7 Continuous Monitoring | CM-12 Information Location, RA-2 Security Categorization, PM-5(1) Inventory of PII, SC-28 Protection of Information at Rest, AC-3 Access Enforcement |
| NIST CSF 2.0 | PR.PS-01 Configuration management practices | ID.AM-07 Inventories of data, PR.DS-01 Data at rest protected |
| CIS Controls v8.1 | 4.1 Establish and Maintain a Secure Configuration Process | 3.2 Establish and Maintain a Data Inventory, 3.3 Configure Data Access Control Lists |
| ISO/IEC 27001:2022 Annex A | A.8.9 Configuration management | A.5.12 Classification of information |
| MITRE ATT&CK (threats reduced) | T1580 Cloud Infrastructure Discovery (less to find), T1530 Data from Cloud Storage via exposure | T1530 Data from Cloud Storage, T1537 Transfer Data to Cloud Account |
Common failure patterns
- Treating every public bucket the same: CSPM alone ranks an empty bucket and a customer export identically, so the team works the backlog in the wrong order.
- Assuming the CNAPP data module is a DSPM: it labels known resources but does not discover unregistered stores or cover SaaS and data warehouses, and nobody checks.
- Classifier noise accepted as truth: untuned identifiers flag test data as personal data, data owners stop reading findings, and real exposures are lost.
- Ignoring the scanner's own access: the DSPM scanner role can read every sensitive store and is not treated as privileged.
- No identity layer: both tools report configuration and contents while over-privileged workload roles and password-only data platform logins remain the real path in.
- No data owner: cloud teams receive data findings they cannot decide on, so findings age out unresolved.
Practitioner checklist
- Enable CSPM in every account, subscription and project and every Region you use, including the configuration recording it depends on.
- Fix public storage, public snapshots and internet-exposed management interfaces before tuning anything else.
- Turn on data discovery for known sensitive stores, then estate-wide to find unregistered ones.
- Feed sensitivity labels into posture prioritisation and mark exposure on sensitive stores as critical.
- Map effective access from workload roles, service accounts and users to sensitive stores, and remove unused access.
- Require strong authentication and network restrictions on data platform logins, including service accounts.
- Treat CSPM, CNAPP and DSPM scanner identities as privileged and review their permissions.
- Assign a data owner for every sensitive store and route data findings to them.
- Report sensitive stores with external exposure as the headline metric, not total finding counts.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- Amazon Web Services: What is AWS Security Hub CSPM?
- Amazon Web Services: Amazon Macie integration with AWS Security Hub CSPM
- Google Cloud: Attack exposure scores and attack paths
- Google Cloud: Sensitive Data Protection data profiles
- Microsoft: Cloud security posture management in Defender for Cloud
- Microsoft: Data security posture management in Defender for Cloud
Related NHI Mgmt Group resources: Cloud Security Posture Management (CSPM) Guide · Data Security Posture Management (DSPM) · CNAPP Guide · CWPP vs CSPM · DSPM vs DLP