Classification and its limits
How DSPM labels a store PII, PHI, PCI, financial or confidential from metadata — names, tags and schema — and what that approach cannot see.
The labels
| Label | Meaning | Typical signal |
|---|---|---|
| PII | Personal data | Name or tag tokens such as customer, user, member, employee, contact, profile, patient |
| PHI | Health data | Tokens such as patient, health, medical, clinical, HIPAA, EHR |
| PCI | Payment card data | Tokens such as PCI, card number, CVV, payment card (self-hosted databases) |
| FINANCIAL | Financial data | Tokens such as billing, payment, bank, transaction, revenue, finance |
| CONFIDENTIAL | Secrets and restricted material | Tokens such as secret, credential, password, token, private; every Kubernetes Secret; ConfigMaps with credential-like key names |
A store can carry more than one label — a table called patient-intake is labelled both PII and PHI.
The signals
- Store name and description. Split into words on dashes, underscores and dots, then matched against the token lists above.
- Tags. Used when a store has no description, so a tag such as
data-class=customeris picked up. - Database and schema names for self-hosted databases discovered by the technology engine, matched against PII and PCI patterns.
- Kubernetes ConfigMap key names — a key named like a password or token marks the ConfigMap confidential. The values are not inspected.
- Rule metadata. When a posture rule with a data-classification context fails on a store, its context contributes a label.
Because every signal is metadata you can read — a name, a tag, a schema — the reason for a label is visible in the store's own configuration.
What classification does not read
- Objects or files in buckets
- Rows or columns of data in tables
- Messages on streams or queues
- Secret values in vaults, secrets managers or Kubernetes Secrets
The limits, stated plainly
- False negatives. A bucket called
nightly-exportsholding customer records gets no label, because nothing in its metadata says what it holds. Fix: tag it, or name it for its contents. - False positives. A bucket called
user-avatars-thumbnailsis labelled PII because of the token user. Fix: rename it, or accept the label; the reason is in the name. - No record counts. Because contents are not read, DSPM cannot tell you how many personal records a store holds, or which columns hold them.
- No content-level PCI proof. A PCI label means the metadata points to card data, not that a card number was found.
If you need to know exactly what is inside unlabelled files, that requires a content scanner, which Onam's DSPM is not. The design choice is deliberate: your data stays where it is, and no permission to read it is needed.
Making classification better
- Tag data stores with what they hold. A consistent tag such as
data-classwith values likecustomer,paymentorhealthgives DSPM a reliable signal on every store. - Name new stores for their contents.
- Review stores with no label but high exposure first: public, cross-account or unencrypted stores where classification has nothing to go on.