DSPM

How it works

DSPM (Data Security Posture Management) scans your cloud data stores, S3 buckets, RDS instances, Snowflake warehouses, SaaS drives, and builds an inventory of what data lives where, what it actually contains, and who or what can reach it. It classifies sensitive fields (PII, PHI, secrets, source code) using pattern matching and increasingly LLM-based classifiers, then maps exposure paths: a public bucket, an over-permissioned IAM role, a stale service account with read access to a customer table. The output is a prioritized list ranked by data sensitivity times exposure, not a flat vulnerability count. Vendors in this class: Varonis, BigID, Cyera, Wiz's DSPM module.

When it matters

DSPM matters once data sprawls across more storage systems than your team can manually track, usually somewhere past 5-10 production data stores or the first time a cloud migration duplicates a dataset into a new environment nobody remembers to lock down. Skip it and you learn about the exposed bucket from a researcher's tweet or a breach notification, not from your own tooling. It is distinct from network or app scanning: DAST and SAST find code and request-path flaws, DSPM finds where sensitive data physically sits and who can touch it regardless of application logic.

Common misconceptions

• "DSPM is the same as DLP." DLP inspects data in motion (email, uploads) to block exfiltration in real time. DSPM inventories data at rest and reports exposure; it does not intercept traffic.
• "Encryption at rest makes DSPM unnecessary." Encryption stops someone reading the raw disk. It does nothing about an authenticated identity with excessive access reading the decrypted data through the normal application path, which is what DSPM is built to find.
• "One scan is enough." Cloud storage changes daily as engineers spin up new buckets and tables. DSPM has to run continuously or the inventory is stale within weeks.