What is DSPM (Data Security Posture Management)?

DSPM at a glance

DSPM meaning: the problem it solves

Most organisations cannot answer a simple question: where is our customer data?

Not because nobody cares, but because data spreads faster than anyone documents it. One production database becomes three read replicas, several analytics warehouses, buckets of CSV exports, a data lake, a warehouse stage and a cache someone stood up for a demo. Every copy carries the same risk as the original, and no map exists until an auditor, a regulator or an incident asks for one.

Copies nobody tracks are often called shadow data: snapshots kept after a migration, test environments loaded with production records, exports left in a bucket after a one-off analysis. DSPM security starts by finding them.

How DSPM works

1. Discover every data store across accounts, subscriptions and projects, including the ones not in any inventory. A cloud asset inventory is the starting point.
2. Classify what each store holds, by content sampling, by metadata, or both.
3. Map access by joining each store to the identity graph: which users, roles, service accounts and third parties can read or write it, directly or through role assumption.
4. Assess exposure by adding network reachability and encryption context. Is the store public? Is the key usable by everyone in the account, Is a copy sitting in a less-protected region?
5. Prioritise and remediate by sensitivity multiplied by exposure, not by the severity of the configuration rule alone.
6. Monitor continuously, because new datasets and new permissions appear every day.

Metadata vs content classification

DSPM tools split into two approaches, and the difference matters for procurement and privacy review.

Content-based classification reads samples of the data and pattern-matches on it: national ID formats, card numbers that pass a Luhn check, email addresses. It is the more precise method and the more invasive one: it needs read access to real records, and the scanning may run outside your environment.

Metadata-based classification infers sensitivity from resource names, tags, schemas and column names, storage class and configuration. A table with columns ssn and date_of_birth, or a bucket named customer-pii-exports, is a confident label without reading a row. It is less precise on ambiguous stores, but it never touches the underlying data. That is often the deciding factor in regulated environments.

Ask any DSPM vendor which one it uses, where the scanning runs, and whether sampled data leaves your account.

DSPM vs CSPM

The two are complementary. CSPM tells you a bucket is public; DSPM tells you whether that bucket holds marketing images or customer records. Same misconfiguration, very different priority. See What is CSPM? for the infrastructure side.

DSPM vs DLP

• DLP (data loss prevention) watches data in motion (email, uploads, endpoints, web traffic) and blocks it leaving through channels it should not.
• DSPM assesses data at rest: where it is stored, how sensitive it is, and who can reach it.

DLP is a control at the boundary; DSPM is an assessment of the estate. DSPM findings make DLP policy sharper, because you know which data deserves the strictest rules.

DSPM vs data governance and DSPM vs CIEM

Data governance decides who should own and use data, through catalogues, stewardship and retention policy. DSPM checks what is true in the cloud: whether the copies, permissions and exposure match that intent.

CIEM maps effective permissions for every identity. DSPM uses that map from the data's side: not "what can this role do?" but "who can read this table?". The two answers should come from the same identity graph, or they will disagree.

DSPM use cases

• Find shadow data: forgotten snapshots, test copies of production, abandoned exports.
• Prove compliance scope: GDPR Article 30 records of processing, HIPAA safeguards for PHI, PCI DSS Requirement 3 for stored account data. You cannot scope an audit for data you have not found.
• Prioritise cloud findings: raise the priority of any misconfiguration on a store that holds sensitive data.
• Reduce access: remove read access to sensitive stores from identities that never use it.
• Govern AI and analytics data: know which training sets, vector stores and notebooks hold personal data before they are shared.
• Respond to incidents: when a credential leaks, answer "what sensitive data could it read?" before the investigation stalls.

DSPM examples: three findings and their fixes

1. A database snapshot shared with another account. A snapshot taken before a migration was shared with a vendor account and never unshared. CSPM may flag the sharing; DSPM adds that the snapshot holds a customer table. Fix: revoke the share, delete the snapshot if it is no longer needed, and add a policy that blocks cross-account snapshot sharing.

2. An analytics export bucket readable by a web tier role. The bucket is private, encrypted and passes every configuration rule. But the role attached to an internet-facing service has s3:GetObject on *, so it can read the exports. Fix: scope the role to the buckets it uses, and add a bucket policy that allows only the analytics role.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::customer-exports/*",
  "Condition": {
    "StringNotEquals": { "aws:PrincipalArn": "arn:aws:iam::111122223333:role/analytics-reader" }
  }
}

3. "Encrypted at rest" with a key everyone can use. Compliance shows full encryption coverage. But the key is a provider-managed default that any principal in the account can use, so encryption adds nothing against a stolen credential. Fix: use a customer-managed key for sensitive stores and restrict kms:Decrypt to the roles that need the data. See What is cloud secrets management? for key handling.

Why "encrypted at rest" is a weak answer

Encryption at rest protects against one threat: someone obtaining the physical storage medium. It does nothing about the likelier case: a legitimate credential reading the data through the API exactly as designed. DSPM asks the better questions: what is in this store, who can decrypt it, and is any path to it reachable from outside? That last question is attack path analysis, with the data store as the target.

DSPM best practices

1. Start with discovery. Classification comes second. You cannot classify stores you have not found; include backups, snapshots and every account.
2. Agree the sensitivity labels first. Four or five labels that map to your regulations beat thirty nobody applies.
3. Decide how classification may touch data. Settle content versus metadata scanning with privacy and legal before rollout.
4. Join data to identity. A sensitivity label without an access map tells you what to worry about. It does not tell you what to fix.
5. Prioritise by sensitivity times exposure. A public store of public data is low; a private store of PII readable by an internet-facing role is high.
6. Delete before you protect. The cheapest secure copy of data is the one that no longer exists.
7. Re-scan continuously. New datasets and new grants appear with every deploy and every analyst query.

DSPM tools: what to ask

DSPM is sold as a standalone product and as part of a CNAPP. When you compare options, ask: which stores and clouds it covers (including warehouses and SaaS data platforms); whether it classifies by content, metadata or both, and where scanning runs; whether it shows effective access through role assumption as well as direct grants; and whether data findings appear next to the cloud and identity findings that create the exposure.

How Onam approaches data security posture

Onam evaluates data stores in the same platform as its cloud posture and identity checks, across AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud and Kubernetes. In its rule catalogue, 1,321 rule definitions are tagged to the data protection domain, 310 to storage and databases, and 502 to secrets and key management; Snowflake is one of its eight SaaS connectors, with 39 CIS SaaS rules. One honest limit: configuration rules tell you how a store is protected, not how many sensitive records sit inside it.

• Onam Data Security (DSPM)
• Onam Database Security