What is DSPM?

A DSPM tool works in three steps. It discovers data stores, it classifies what is inside them, and it relates that to exposure and access. The point is to answer a question that settings-based checks cannot: how bad would it be if this particular store were reachable?

Discovery and classification

The tool lists object stores and databases, including ones nobody registered, and samples their content to look for patterns such as national ID numbers, payment card numbers or credentials. Sampling means it reads a representative slice, not every record.

• Microsoft: data security posture management in Microsoft Defender for Cloud discovers sensitive data resources across clouds, and uses the sensitive information types and sensitivity labels defined in Microsoft Purview. Microsoft documents that it samples data rather than scanning everything.
• AWS: Amazon Macie inventories S3 buckets, evaluates their security and access control, and uses machine learning and pattern matching to find sensitive data in the objects.
• Google Cloud: Sensitive Data Protection (formerly Cloud DLP) inspects and classifies data in Google Cloud storage and database services.
• Microsoft 365: sensitivity labels and Purview classify files in SharePoint, OneDrive and Exchange, which is the same idea applied to a SaaS suite.

Exposure and context

Once a store is known to hold sensitive data, the tool adds context: is the bucket public, is it shared with another account, is a virtual machine that faces the internet allowed to read it? Defender for Cloud describes this as attack paths, for example an internet-exposed VM with access to a sensitive data store.

The core problem is visibility. Microsoft's own documentation states that organisations move data to the cloud at a fast rate across many store types, and that this dynamic, complex nature increases data threat surfaces and risks, so security teams struggle with visibility and protection of the data estate.

In practice that looks like a developer copying a production export into a storage account for a test, a bucket policy loosened for a one-off share and never tightened, or a database snapshot left shared with another account. None of these is a flaw in the cloud provider. They are data and access decisions, and they only become visible once someone looks at the data, not just the setting.

AWS describes the same risk from the access side: unintended access to resources and data is a security risk, which is why it provides analysis of resources shared with external principals.

DSPM is often confused with neighbouring categories. The difference is the starting point: DSPM starts from the data, the others start from something else.

The categories overlap and vendors bundle them, so treat the table as a way to ask what a product actually inspects, not as a strict boundary.

1. Decide what sensitive means for you. Write down the handful of data types your business handles, such as customer records, payment data or credentials. Classification tools need this to be useful.
2. Start with the stores you already know. List storage accounts, buckets and databases per cloud, and note owner and purpose. Unowned stores are the first cleanup list.
3. Turn on the native discovery you already license. Macie on AWS, Sensitive Data Protection on Google Cloud, Defender for Cloud data security posture management on Azure, Purview labels in Microsoft 365. Check the vendor pages for what each plan covers.
4. Fix public and cross-account exposure first. A sensitive store that is public outweighs every other finding.
5. Re-run regularly. Data moves, so a one-off scan goes stale.