Data classifiers define the logic that the ASDD discovery uses to identify sensitive data during discovery.

Each classifier evaluates database columns using predefined matching rules. When a column matches the classifier’s detection criteria, the associated data class is assigned to that column. Classifiers allow DCT Compliance to automatically detect sensitive information across large datasets without requiring manual inspection.

Multiple classifiers can be associated with the same data class to improve detection accuracy. For example, one classifier may detect sensitive data based on column names, while another evaluates the values stored in the column.

Data Control Tower includes several built-in objects that are provided out of the box with the product, including Data Classes, Data Classifiers, and Discovery Policies. These built-in objects are system-defined and cannot be edited or deleted. You can create and manage custom objects as needed.

Classifier frameworks

Each classifier is based on a classifier framework, which defines the type of logic used to detect sensitive data.

DCT Compliance supports the following classifier frameworks:

Framework Description
Path Identifies sensitive data based on column or field names
Regex Detects sensitive data using regular expression patterns
Data type Identifies sensitive data based on database column types
List Compares values against predefined lists of known values

Path classifiers

Path classifiers analyze database metadata such as table names and column names.

These classifiers use pattern matching to detect naming conventions commonly associated with sensitive data.

For example, path classifiers may detect column names such as:

  • email

  • ssn

  • account_number

  • credit_card

Path classifiers provide fast detection because they evaluate schema metadata rather than scanning data values.

Data type classifiers

Data type classifiers evaluate the data type and structural characteristics of a column.

These classifiers restrict classification to columns that match expected data types such as:

  • string values

  • numeric identifiers

  • dates

  • binary data

Data type classifiers help reduce false positives by ensuring that classification only occurs when the column structure matches the expected data format.

Regex classifiers

Regex classifiers analyze column values using regular expression patterns.

These classifiers are used to detect structured data formats such as:

  • credit card numbers

  • email addresses

  • phone numbers

  • identification numbers

Regex classifiers may include validation rules such as checksums to improve detection accuracy.

REGEX classifiers support checksum validation to improve the accuracy of sensitive data detection. When checksum validation is enabled, the classifier verifies that detected values conform to the mathematical validation rules used by the corresponding identifier format.

Some checksum algorithms apply only to values with a specific number of digits. Ensure that the REGEX pattern used in the classifier matches the expected length and format of the identifier before checksum validation is applied.

Supported checksum algorithms include:

  • LUHN – Used for credit card numbers

  • MOD10_ABA – Used for ABA routing numbers

  • MOD11_NHS – Used for NHS identification numbers

  • MOD11_TFN – Used for Australian Tax File Numbers (TFN). The checksum validation applies to 9-digit TFNs. Legacy 10-digit TFN formats are not supported by this checksum validation.

  • MOD97 – Used for IBAN numbers

  • MOD9_JPN_CORP – Used for Japanese corporate numbers

  • MOD11_IBM_JPN_DRIVERS_LICENSE – Used for Japanese driver's license numbers

  • MOD9_IBM_JPN_MY_NUMBER – Used for Japanese national identification numbers

List classifiers

List classifiers compare column values against predefined value lists.

These lists contain known values associated with specific data classes, such as:

  • first names

  • last names

  • countries

  • job titles

List classifiers are useful when sensitive data values are drawn from a known set of values.

Configuration considerations for classifiers

Classifier design is more complex than search or type expressions because classifiers offer more flexibility in matching logic and configuration around match strength. Classifiers contain more configuration, typically encompassing all logic of the framework's type for a particular data class. Classifiers also add the notion of rejection strength, which allows the profiling logic to eliminate data classes from consideration earlier in the discovery process.

Strength values

Classifiers use a scale of -1.0 to 1.0 to represent match and reject strength, which correspond to the -100 to 100 confidence values used in the UI. The product currently does not display confidence values for non-matches, so only values between 0 and 100 are typically visible.

A value of -1.0 indicates absolute rejection, and the data class in question is immediately eliminated from the set of possible matches. Similarly, a value of 1.0 indicates absolute confirmation, and the data class is assigned as a match without checking any other classifiers for that data class .

When multiple classifiers produce match or reject strength values, those results may be combined to get a final confidence. If the results conflict, with opposite signs, the result with the highest absolute value takes precedence. If the results have the same sign, the final result for that data class is a stronger match. The exact values and formula applied are under development and may change in the future. Currently, only the strongest column level result and strongest data level result are combined in this fashion.

Examples

  • A column named ssn_present matches a Path classifier for the SSN data class with a match strength of 0.67. However, the column is boolean type and does not match the TYPE classifier for the SSN data class, which returns a -1.0 result. The verdict is -1.0 and the SSN data class is not assigned.

  • A column named passport_no contains 9-digit numeric values, which match the REGEX classifiers for both the SSN and PASSPORT_NO data classes. Both REGEX classifiers return a confidence of 0.5 for this match. However, while the Path classifier for the PASSPORT_NO data class matches and returns a match strength of 0.67, the Path classifier for the SSN data class does not match, returning 0. The final confidence values are PASSPORT_NO at 0.84, and SSN at 0.5, so the PASSPORT_NO data class is the best match and the PASSPORT_NO data class and associated masking algorithm are assigned to the column.

Choosing values for match strength

The match strength value (typically called matchStrength in the classifier configuration) reflects how confident the classifier is that a particular data element exclusively matches the associated data class. A match strength of 0.01 indicates that the data element may belong to the data class, but might also belong to any number of other data classes or not be sensitive at all, while a value of 1.0 reflects absolute certainty that this data matches this data class and no other data class. A value of 0 provides no information.

Not all classifiers have a match strength greater than 0. One example of this is TYPE classifiers, which typically have a high reject strength, but 0 match strength (since it is impossible to match any of the built-in data classes based on the data type of a column alone).

Path classifiers built-in to the product typically have a match strength of 0.67, so in order for a REGEX or LIST classifier to override a Path result, that classifier's match strength or reject strength would have to be higher than this value. This can help eliminate false positive results from the Path classifiers, but be wary of the next recommendation before setting match strength to a high value.

When choosing match strength for REGEX classifiers, consider whether the pattern is unique to the type of sensitive data being detected. If it is not, it is safer to give a relatively low match strength in the range of 0.1 to 0.5, so that Path level results can contribute information. Consider this example of REGEX detection of US Social Security numbers. These might be stored as a string value with a more distinct pattern like "001-23-4567", or simply as a 9-digit number "001234567". A 9-digit number might be any number of other numeric identifiers, like account number, passport number, a row identifier for rows in another table, etc. so the match strength for the [0-9]{9} regex should be quite low. The distinct text pattern with dashes has a much higher match strength since it is unlikely to be any other kind of information.

For LIST classifiers that utilize tokenization of inputs and reuse the same lists as other classifiers, consider lowering the match strength for each of these files used for tokenization. For example, list classifiers for First Name and Full Name may reference the same list of values, but during discovery with tokenization, the same values that match the First Name classifier will also match the Full Name classifier. Ideally, this configuration should allow the first name column to have a higher match to the First Name classifier.

Here are some additional tips for choosing match strength:

  • Use a higher match strength for patterns that are more likely to be unique to the type of sensitive data being detected.

  • Use a lower match strength for patterns that are less likely to be unique to the type of sensitive data being detected.

  • Use a match strength of 0 for patterns that are not unique to the type of sensitive data being detected.

Choosing values for reject strength

The reject strength (typically called rejectStrength in the classifier configuration) value reflects how likely it is that a value matches the classifier's data class when the classifier does not match. If you are certain that your classifier configurations will match every possible value for the data class, the reject strength should be set to 1.0; however, this degree of certainty is rare. Similar to match strength, not all classifiers provide any rejection capability. This is true of Path classifiers, for example, as we cannot rely on an unknown database schema to use predictable or human-readable names for columns.

The reject strength for classifiers applies any time there is no match. For example, if a REGEX classifier contains 4 regular expressions, each expression would be tested against the column data value, and if none match, the reject strength defines the result. For this reason, it can be useful to add a pattern that matches quite broadly, even if it's not particularly selective for the data class in question, with a low match strength. This prevents a full rejection for values that might match this classifier's data class as well as one or more other data classes.

For LIST and REGEX classifiers where the set of patterns or list values is known to be only a subset of possible values for the data class, reject strength should be below 0.5 to allow column-level matches to take precedence, even if none of the data values match. For example, the value lists built-in for first and last name LIST classifier only contain English values, and names might be in other languages. These classifiers have "reject strength" set relatively low, to prevent the LIST classifiers from overriding the Path classifier match if, for example, the column contains only Japanese names.

Here are some additional tips for choosing reject strength:

  • Use a higher reject strength for classifiers that are more likely to match all values in the data class.

  • Use a lower reject strength for classifiers that are less likely to match all values in the data class.

  • Use a reject strength of 0 for classifiers that are not designed to match all values in the data class.

Path and Regex configuration

The Path and REGEX classifier types consume regular expressions using Java 8 regex syntax and matching logic. These classifiers have additional configuration options to control whether these patterns should match the entire input, and whether they are case-sensitive. For this reason, avoid using regex constructs such as ^(pattern)$ for these purposes.

Type classifiers configuration

The TYPE classifier framework uses four supported Type Expressions: String, Number, Date, and Binary. However, the type-matching system is more versatile and provides better type identification across all database variants. This framework also supports the identification of auto-incrementing columns. The property matchAutoIncrement defines whether auto-incrementing columns should be considered for discovery (true) or completely skipped (false) for the domain. The default value is false.

Tokenization in List classifiers

List classifiers to identify complex data can be created by combining multiple sets of list files and enabling tokenizeInput. In such list classifiers, the input is tokenized to individual tokens which are split by delimiter values specified by the tokenizationDelimiter field. The default value for this field is a space " ", but can be a string of individual characters such as -_.\n where each character is a delimiter. The confidence value for each input value is calculated by summing the match strengths of all matching tokens divided by the total number of tokens in the input.

For example, to identify a FULL_NAME which is a combination of FIRST_NAME & LAST_NAME, it's unrealistic to create a list with all possible combinations of first and last names, but by providing separate lists and turning on tokenization, discovery can match each token of the input to the value lists.

You can perform the following opeartions:

Create a classifier

Edit a classifier

Delete a classifier

Last updated
Oct 8, 2026