Onam

Data Security (DSPM)

Data Security (DSPM): every cloud data store, labelled from metadata and joined to exposure, access, encryption and lineage. The short version.

This page is the short version. The full documentation has its own section: start at the DSPM overview.

How DSPM works — data stores, discovery, metadata classification, the access and exposure join, findings
How DSPM works — data stores, discovery, metadata classification, the access and exposure join, findings

What it answers

  • What data do we hold, and where? Every data store across the connected clouds — object storage, managed databases and warehouses, streams, Kubernetes secrets and ConfigMaps — plus self-hosted databases you onboard. See Discovery and Coverage by cloud.
  • Which stores look sensitive? PII, PHI, PCI, financial and confidential labels inferred from names, descriptions, tags and schema. Contents are not read. See Classification and its limits.
  • How can each store be reached? Public grants, other accounts in bucket policies, principals seen in the last 30 days of audit events, encryption and keys, and attack paths that end at the store. See Access mapping.
  • Is it protected? Encryption at rest, access logging, versioning and backup, residency, and a 0–100 governance score per store. See Exposure, encryption and residency.
  • Where does the data go next? Replication, backup, ETL, streaming and export hops linked into chains, with cross-region and cross-account hops flagged. See Data lineage.

What it does not do

  • It does not read objects, rows, messages or secret values, so it cannot count records or prove what an unlabelled store contains.
  • It does not compute a per-store list of every identity whose effective permissions allow a read; that is answered per identity in CIEM.
  • It is not DLP: it does not inspect or block data in motion.

Every check

The complete list of checks, what passes them and their severities is in the DSPM findings reference.