OpenMetadata PII auto-classification

OpenMetadata reaches a personal data suggestion through two separate signals, and neither one settles the question alone. The first is name-based matching. Rules compare table and column names against patterns linked to personal data, so a column named email_address or date_of_birth becomes a candidate before any values are read. This signal relies only on metadata the connector has already ingested. Its blind spots are predictable: a column called ref_2 may hold a phone number and never match, while a column called customer_email in a sandbox table may match even when it holds only test values. Treat name matches as a list of places to look first, and check each one against the data itself.

The second signal is content-based inspection. After a profiler run has sampled values from a table, recognizers examine those values for formats that suggest personal data, such as email-shaped strings or identifiers with a recognizable structure. A column with an uninformative name can still be flagged this way, which is the main reason to enable it. The limit is that content inspection only sees what the profiler sampled. A table that is never profiled cannot receive a content finding, and a column whose sample is empty or unrepresentative can be missed. Before relying on either signal, confirm in the documentation for your version which recognizers ship, which are enabled by default, and how the profiler chooses its sample. OpenMetadata 2.0 made Dynamic Sampling the profiler default, so the sampling behavior you test may differ from older releases.

A finding is stored as a suggested classification on the column, under a PII-related classification, and it stays a suggestion until someone acts on it. The record shows the column and the classification, so a reviewer can decide what happens next. A reviewer confirms the suggestion, which turns it into an applied classification on the column, or rejects it, which removes the suggestion. Confirm in the documentation whether a rejected suggestion can reappear after a later profiling run, whether the record keeps the reviewer's identity and the date of the decision, and which roles may confirm or reject. Those answers determine whether your records can show who approved each personal data label.

Plan the review step before you enable detection across a whole schema. Decide who holds review rights, how many suggestions a reviewer can work through in one session, and what evidence you need to keep when a suggestion is rejected. Run a pilot on one schema, then compare the suggestions with a manual review of columns you select independently of the tool. Look for false positives and for missed columns, since missed columns are the ones that create unmanaged exposure. Finally, remember that a classification is a catalog record. It describes where personal data is held, but access to the data itself is still controlled in the source systems, so the catalog and those controls need to be reviewed together.

A personal-data tag and a confidentiality label answer different questions. A PII tag records what kind of personal information a column probably holds, such as an email address or a national identifier. A confidentiality label records how restricted the data must be and who may see it. Security and access teams usually work from the second question, using a short, approved scale of levels. OpenMetadata's auto-classification produces the first kind of output from column-name rules and sample-data scanning, so the mapping from personal-data categories to your internal levels is a governance decision that has to be made deliberately. Write it down before any automated tag reaches a policy engine, a data-sharing workflow or a retention job.

Build the mapping as a table with three columns: the PII category as OpenMetadata names it in your version, the internal confidentiality level it corresponds to, and the rationale for that level. Keep the number of levels small enough that data owners can apply them consistently. Direct identifiers and government identifiers often need the strictest handling, while some indirect categories may justify only a moderate level until they are combined with other fields. The approval should come from the data protection or privacy owner together with the owner of the access model, with the catalog administrator maintaining the entries. Record each approved version with its date, approver and reason for change, and keep earlier versions so that past classifications can be explained during an assessment.

The main risk is that an automatic mapping turns a detection into an access decision. If a column-name rule or sample scan labels a column as a sensitive category, and the mapping then assigns a restrictive confidentiality level, downstream tools that read that level may hide a table from analysts, block a sharing request or shorten retention. A false positive then has operational consequences. Illustrative example: a column named contact_ref that a sample scan tags as an email address could move an entire dataset into a restricted level without anyone reviewing it. Confirm in your version whether tags applied to a column propagate to its table, dashboards or glossary terms, and whether any policy in your access layer reads classification tags directly.

Place a review step between the automatic tag and any mapped label that drives access or retention. In practice, auto-applied PII tags should land in a queue owned by the data steward, who confirms or rejects each one, and only confirmed tags should be eligible for mapping. Mapped confidentiality labels should then be applied through a separate, versioned step that a second person approves. Test this workflow on one schema before enabling propagation across the catalog, and track how many suggestions are rejected, since that rate shows how far the detection rules can be trusted. Before designing the workflow, check how review states and tag propagation behave in your OpenMetadata version and document the answer.

Content scanning only works if the scanner can read values, so a PII scan that inspects column contents stores a piece of the personal data it finds. In OpenMetadata, sample rows pulled during profiling and scanning are kept in the catalog's metadata store, and sample values can also reach the search index. The catalog therefore stops being a place that only describes personal data and starts holding copies of it, with the same exposure, retention and access questions that apply to any copy. Before you enable content scanning on a connector, confirm where OpenMetadata writes sample values in your deployed version, whether those values are indexed for search, and how long they remain after a table is deleted or a scan is rerun.

Sample size and sampling method move detection quality and exposure in opposite directions. A larger sample gives the classifier more chances to see a personal value in a sparse or mixed column, which improves recall, but it also copies more personal records into the catalog. A smaller sample lowers exposure and can miss personal values that appear in only a small share of rows. Method matters as much as size. A sample taken from the first rows returned can reflect load order, so later records may never be inspected, while a random sample spreads the read across the table. Test any size and method against a labeled set of your own columns, and record the results for each table group so the decision can be reviewed later.

OpenMetadata 2.0.0 was released on August 24, 2026, and it made Dynamic Sampling the profiler default. That changes what a scan reads for any team that has not pinned its own sampling configuration. Before you upgrade, or before you enable PII scanning on a new connector, confirm what Dynamic Sampling does for your tables: how it chooses rows, whether the choice is the same for every table or varies with table size, and whether the same sample feeds the PII scan or only the profiler. The OpenMetadata 2.0 release notes are the starting point, but the answer should come from a test run on a non-production copy of your data. Record the sampling settings in the scan configuration so that a later upgrade cannot change them without someone noticing.

Decide per data class whether content sampling is allowed at all, before you choose any sample size. Column-name rules can flag many personal fields without reading a single value, so a class such as health or payment data may be limited to name-based detection, while content scanning is reserved for classes where the exposure has been accepted in writing. Record that decision with the owner of each domain, and name who approves exceptions. Then decide who can see sample rows. Limit sample visibility to the data stewards and security staff who must review classifications, check that catalog roles and search permissions apply the same restriction to sample values, and test this with a user who holds only a lower-privilege role. Ask the implementation team to show that test as part of acceptance.