Data Security (DSPM)

Data Security Posture Management (DSPM) answers two questions security teams cannot answer manually at cloud scale: where is your sensitive data, and is it properly secured? Onam's Data Security engine discovers every data store across cloud storage, databases, and data pipelines — managed AND shadow stores — classifies the data inside them as PII, PCI, or PHI, and grades each store for encryption, access control, retention, and logging.

This page explains the four-stage DSPM pipeline, the classification taxonomy, how exposure levels determine severity, and how data-flow analysis catches sensitive data leaking into less-secure downstream stores.

What DSPM Solves

Every cloud organization hits the same five data-security failure modes. They share a single root cause: new data stores are created faster than they are reviewed, classified, and secured.

DSPM closes the gap by re-evaluating every data store on every scan — managed stores, shadow stores, backups, snapshots, and the pipelines that move data between them.

How DSPM Works

DSPM runs as a four-stage pipeline against every data store in your connected accounts: Discover what exists, Classify what's inside, Evaluate the security controls, Emit prioritized findings. The pipeline is agentless — no database extensions, no inline scanners, no network taps.

1. Discover — find every data store

The engine enumerates every data store reachable from your read-only credential, including ones nobody is tracking:

• Object storage — every S3 bucket, Azure Blob container, GCS bucket, OCI Object Storage bucket, Alibaba OSS bucket, and IBM COS bucket, including buckets untouched for a year.
• Managed databases — RDS (every engine), Azure SQL, Azure DB for Postgres/MySQL, Cosmos DB, Cloud SQL, BigQuery, DynamoDB, Redshift, Synapse, and more.
• Shadow stores — self-managed databases on compute instances, attached volumes containing data files, orphaned RDS snapshots. Detected through instance-metadata pattern matching, security-group inspection, and data-file fingerprinting.

A typical AWS account has 2–3x more shadow stores than the security team is tracking. Surfacing them is half the value of DSPM.

2. Classify — identify what's sensitive

For every discovered store, the engine samples a small, statistically valid window of content using your read credential, returns only matched-pattern metadata, and discards the sampled data immediately. Bulk data never leaves your cloud account.

Classification combines regex patterns, format validators (Luhn for cards, mod-11 for national IDs), and ML models for ambiguous cases. Each classification carries a confidence score; below a configurable threshold the data is flagged "possibly sensitive" rather than positively classified.

3. Evaluate — check the security controls

For every store containing sensitive data, four control axes are evaluated, plus residency for regulated data:

• Encryption at rest — is a KMS-managed key in use, is rotation enabled, is the key shared more broadly than it should be?
• Access controls — is the store public, reachable from external accounts, or broader than the workload needs? (The CIEM signal feeds in here.)
• Retention — is a lifecycle policy in place, and is data older than the policy window flagged?
• Logging — are access logs enabled and tamper-proof? Can you reconstruct who read what for the last 90 days?
• Residency — PCI cardholder data or GDPR-scoped data outside the approved geographic region is flagged immediately.

4. Findings — prioritized, framework-mapped output

Each finding includes the affected store, the data classification, the failed control, the suggested fix, framework citations (GDPR, PCI-DSS, HIPAA, ISO 27001), and the MITRE ATT&CK technique where applicable.

Data Classification

Onam classifies data into five sensitivity categories. Each maps to specific regulations and triggers different finding severities. You can extend the catalog with custom data classes under Settings → DSPM → Custom Patterns.

Credentials are graded Critical in every context because a leaked credential cascades: an attacker with an API key pivots into the system it authorizes, exfiltrates more data, and mints more credentials. Onam treats credential leakage as the worst-case category by default.

Data Exposure Levels

Every classified store is rated against four exposure tiers. The combination of sensitivity and exposure determines severity.

The combination matrix that determines severity:

Intentionally public assets (website images, public docs, marketing content) never produce findings — once you confirm a bucket as intentionally public, Onam stops alerting on it in future scans.

Supported Data Stores

Both fully managed stores and self-managed stores running on cloud compute are detected.

Snowflake is supported via a read-only connector you authorize on the Snowflake side. Databricks support is on the roadmap.

Key DSPM Findings

The ten most-encountered DSPM findings. Re-grade per finding type in Settings → DSPM → Severity Policy.

Each finding includes sample matched-pattern metadata (never the data itself), suggested remediation, and framework citations such as GDPR Art. 32, PCI-DSS Req 3.4, and HIPAA §164.312.

Data Flow Analysis

Sensitive data rarely stays in one place — it moves through ETL pipelines, backup jobs, analytics exports, and BI tools. A secure source database means nothing if a downstream pipeline lands the same data in a public bucket. DSPM follows the flow.

The worked example: a production RDS instance is configured correctly — encrypted, VPC-only, audit-logged. But three pipelines move its data onward:

Onam traces these flows automatically by reading IAM permissions (which identities can read which source), pipeline definitions (Lambda, Glue, Data Factory, Dataflow), and snapshot/backup configuration. Every downstream store inherits the source's classification — when sensitive data lands in a less-secure store, that is the finding.

Compliance Mapping

One DSPM finding usually triggers controls in three or more frameworks at once. Per-framework rollups live on the Framework Coverage page.

API

Data Security endpoints live under the unified platform API (/api/v1, behind the BFF gateway).

# List data security findings
GET /api/v1/data-security/findings?severity=CRITICAL&classification=PII

# Get data stores with sensitive data
GET /api/v1/data-security/stores?has_sensitive_data=true&exposure=public

# Get the data flow graph from a specific source
GET /api/v1/data-security/flow?source_resource_uid={uid}

Full schemas are in the API reference. Webhook delivery on new Critical DSPM findings can be configured under Settings → Notifications.

FAQ

Does Onam copy our data to scan it? No. Classification samples a small window using your read credential, returns only matched-pattern metadata, and discards the sample immediately. Bulk data never leaves your cloud account.

How are false positives handled? Every classification carries a confidence score; low-confidence matches are flagged "possibly sensitive" instead of positively classified. You can mark a store, file, or column "not sensitive" with a documented justification — the suppression carries through every future scan.

Can I exclude certain data stores from DSPM scanning? Yes, via tag-based exclusion (for example dspm:scan=false). Excluded stores still appear in inventory but are not classified or graded.

How often is data re-classified? Once per scan cycle (daily by default). A typical account with 200 buckets and 50 databases completes the DSPM stage in 5–8 minutes.

Can I use DSPM findings for residency compliance reports? Yes. Residency violations are tagged with the violated regulation and export as PDF audit evidence in one click.

Next steps

• Compliance — how DSPM findings roll up into per-control pass rates
• CIEM — the identity side of "who can read this data"
• Risk Quantification — what exposed data costs in dollar terms
• Framework Coverage — the full framework catalog