FAQs for Data Use Governance

The module, OneTrust Data Discovery, is for discovering data that is unknown or has no known location. The market solution, TDD, is for targeted data searches across catalog sources. TDD does not leverage performance-based searches; instead, it knows all existing tables, data sources, etc., to look for and retrieve back to the application.

After a worker node is deployed, connected data sources begin a catalog scan. This helps identify the data structure and alerts the system to the types of files in the source. Then it scans, first starting at the data element level. Once the data is profiled, metadata is sampled. For more information, see Data Discovery Architecture Overview.

As the scan occurs, data is read and sent to the classification service for sampling. The sample is copied and sent to the cloud. The data is then pulled in a single batch. The scan begins with the schemas, followed by the tables, and then proceeds through the remaining scan stages.

Data is performed in memory, purely ephemeral. Once processed, the data is dropped, and metadata is populated in the cloud. Customers can dictate whether data persists based on custom classifiers or data sources.

Typically, metadata doesn't require index storage unless it is used for a DSAR request. In this instance, OneTrust would query the index storage in the cloud, then use that information to search the database and retrieve the data. When a scan begins, you have the configuration option to index store or not.

Once the data is retrieved and scanned, it can be refreshed on an ad hoc basis and used for further discovery operations within the application.

Data Discovery requires a deployed worker node for worker-node scans. The worker node uses the applicable data source connector and the source's native mechanisms to perform scans. For more information, see the Worker Node Management and Deployment Guides sections in the Data Discovery Knowledge Base.

Data Discovery typically requires read-only access, but the required permissions depend on the data source. For databases, grant access to the schemas and users required to cover the intended scan scope. For SaaS products, configure OAuth-based access with the appropriate read-only permissions where supported.

Yes, for select providers like Azure or AWS. For more information on supported platforms, see Data Discovery Deployment Options.

A maximum of 5 scans can be run per data source type. RDBMS sources are the only exception: at most 5 can run simultaneously across all RDBMS sources. Example: 3 Oracle and 2 SQL can run, while if 5 Oracle are run, the SQL ones will be placed in pending until the 5 Oracle have completed.

Credentials are stored on the worker node, which is protected by your established security controls.

Run:

kubectl -n <namespace> get secret vault-keys --template={{.data.VAULT_TOKEN}} | base64 -d

Or use the vault_helper.sh in the utils folder:

./vault_helper.sh

The vault was locked requiring manual recovery decoding.

Port forward to it and open the localhost url for vault and enter the key fetched from the below command at vault login page:

kubectl -n <namespace> get secret vault-keys --template={{.data.VAULT_KEY}} | base64 -d

Or you can run the following command after you exec into the vault-0 pod

vault operator unseal

Discovery patterns are ran in the descending order they are configured. Note that patterns rely on AND conditions, meaning one or more patterns must match for a sample to be recommended.

Every discovery pattern has a different computation expense to execute. The following table identifies the recommended group ordering based on time required, from least to most consuming:

The sub-classifier with the highest confidence score will run first. If the second label has an 80% confidence score, it will run before the first with a 60% confidence score. Note that sub-classifiers rely on OR conditions.

The built-in package in Java, java.util.regex. To verify and test your classifiers, see Regular Expressions 101 documentation.

Similar records are identified through a fuzzy match. OneTrust uses key attributes (such as name and location) to detect records that are not identical but appear to refer to the same entity. This helps surface records that may have incomplete or slightly different information but are likely related.

Duplicate records, on the other hand, are a 100% match across defined attributes, indicating they are the same record entered more than once.

The Similar Records feature offers a broader view of potential overlaps, enabling teams to investigate and consolidate data more effectively, even when records are not exact duplicates.

Users in child organizations will only see a generic similar record alert (e.g., “Similar active record detected in another managing organization”) when they do not have access to the original record or its managing organization. The system will enforce strict access, ensuring no metadata from parent or unauthorized sibling organizations is exposed.