Every DSPM vendor claims their classification is accurate. Few of them explain how it works. That matters because the accuracy characteristics of different classification techniques are genuinely different, and the failure modes that matter for your data environment depend on the combination of techniques being used and the nature of your data.
This is what we have learned building classification into PostQKey, including which approaches work well, which ones produce systematic errors in specific contexts, and what "tuning for your environment" actually means in practice rather than as a marketing phrase.
The three layers of data classification
Modern classification systems for structured and semi-structured data generally operate in three layers that run in sequence. Understanding these layers helps you understand why a scanner misses something or why it flags a false positive.
Layer 1: Schema and metadata signals
The first pass examines field names, column types, table names, and schema structure before looking at actual data content. A column named ssn in a table named customer_records is a very strong signal for Social Security Number, even before the scanner reads a single value. A column of type DATE named dob is a very strong signal for date of birth.
Schema-level classification is fast and low-cost: it reads metadata, not data. It also produces a predictable category of false negatives: obfuscated or ambiguously named columns. A column storing SSNs named id_field_2 in a legacy data warehouse schema passes schema classification without generating a signal. Column names in enterprise data environments are frequently cryptic, abbreviated, or inherited from source systems that used naming conventions that made sense in context at the time.
For any cloud environment with schema debt, schema-level classification alone will miss a material fraction of sensitive data.
Layer 2: Regex and pattern matching against sampled content
The second layer reads a sample of actual field values and runs pattern matching. Social Security Numbers match \d{3}-\d{2}-\d{4} or \d{9}. Credit card numbers have Luhn check digit validation plus BIN range patterns. Email addresses and phone numbers have well-established patterns. IBAN and routing numbers have format and checksum rules.
This layer catches what schema classification misses on the obfuscated column names. A column called id_field_2 that contains values matching the SSN pattern will be flagged.
Regex classification has its own failure modes. High false positive rate for numeric patterns that resemble sensitive identifiers without being them: product IDs, internal reference codes, and order numbers can match SSN or credit card patterns if they happen to follow a similar format. Tuning regex classifiers for a specific environment means identifying and suppressing these false positive patterns, which requires knowing your data well enough to distinguish real SSNs from product IDs that happen to be nine digits.
The false negative side of regex: free-form text fields containing sensitive data in narrative form. A customer support note that reads "patient's date of birth is March 15, 1978 and their member ID is 0044821" contains sensitive data that no standard regex for DOB or member ID will catch because the format is narrative rather than structured.
Layer 3: ML-based contextual classification
The third layer applies trained models that understand context rather than just pattern. This is where classification of unstructured and semi-structured content happens: JSON payloads, free-text columns, log entries, CSV files with variable schemas.
ML classification can catch sensitive data in contexts where regex fails. The customer support note example above is tractable for a model trained on examples of PII appearing in narrative text. A JSON payload with a field named usr_meta containing an email address and a device fingerprint is classifiable through contextual understanding even though the field name carries no signal and the content does not match a simple pattern.
The failure modes are different from regex. ML classifiers have precision-recall tradeoffs that are tuned during training, and the training distribution matters. A model trained primarily on English-language data may have weaker performance on data containing non-Latin scripts, regional identifier formats (national ID numbers outside the US, EU VAT formats, etc.), or domain-specific encoding schemes.
Confidence thresholds are a real control surface. A classifier that fires at 0.75 confidence will have more false positives than one set to 0.90. Neither threshold is universally correct. In a compliance context where missing a true sensitive data occurrence is expensive, you want a lower threshold. In a context where alert fatigue is already a problem, you may tolerate more false negatives to keep the signal-to-noise ratio workable.
The sampling problem
All three classification layers operate on samples, not full table scans. Scanning every row of a 500M-row customer transaction table is not operationally viable during a continuous discovery cycle. Sampling strategies affect classification accuracy in ways that are easy to overlook.
Random sampling works reasonably well for dense sensitive data: tables where most rows contain PII because the entire table is customer records. It works poorly for sparse sensitive data: tables where 0.1% of rows contain a sensitive identifier because of an error in an upstream process, or tables that hold sensitive data only in a specific date range. A sample of 1,000 rows from a 10M-row table has a good chance of missing ten sensitive records that ended up there by accident.
This is a genuine limitation, not something marketing copy should claim to have solved. The practical mitigation is sample diversity: stratified sampling across date ranges, data distributions, and schema partitions, plus periodic full-column cardinality sampling for fields that carry high-value classification signals.
We are not saying that sampling-based classification is unreliable. We are saying that the scenarios where it has the highest miss rate are predictably the scenarios where a single missed occurrence has the highest consequence: a small number of sensitive records in a large non-sensitive dataset. That is a risk that should be understood rather than assumed away.
Context collapse: where classification accuracy breaks down at the table level
A classification that fires at the column level tells you this column likely contains PII. It does not automatically tell you whether the table as a whole should be treated as sensitive or whether one column's PII status is the exception or the rule.
This matters for access control decisions. A table with 50 columns, one of which contains PII as an artifact of a join operation, has a very different risk profile from a table that is entirely customer PII. Treating both tables as identically sensitive produces over-restriction; ignoring column-level context in favor of table-level categorization produces under-classification of the one-column case.
The classification layer that PostQKey uses tracks sensitivity at the column level and aggregates upward with explicit logic: a table is classified at the highest sensitivity level of its most sensitive column, and the column-level detail is preserved so that access decisions can be made with awareness of what specific data the access touches. This detail gets surfaced in the access graph, so when a service account has SELECT * on a table, the exposure report shows both the table-level classification and which specific sensitive columns are reachable.
Custom classifiers and environment-specific tuning
General-purpose classification handles common sensitive data types well: PII formats defined by GDPR and CCPA, payment card data, US government identifiers. It handles industry-specific or proprietary identifiers poorly by default, because those identifiers were not in the training distribution.
Examples of identifiers that require custom classifiers: internal employee ID schemes where the format is company-specific; proprietary customer reference formats; pharmaceutical compound codes; insurance policy numbers that follow carrier-specific patterns; legal matter identifiers. These carry business-critical sensitivity in specific contexts but are invisible to a general-purpose classifier.
Building a custom classifier requires labelled examples of the target identifier appearing in your actual data. This is a lighter lift than it sounds: 50-100 labelled positive examples and an equal number of negative examples is enough for a pattern-matching classifier covering a structured format. ML-based custom classifiers for freeform text require more, but structured identifier classification is achievable with a small labelled set.
The output of a well-tuned classification layer is not just a label. It is a confidence score, a source (which technique produced the signal), and the specific sample values that triggered the classification. That provenance matters for two reasons: it lets security teams validate the classification without accessing full tables, and it produces the evidence record that compliance reviews need to verify that classification is working as intended.