Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Requirements:
Immuta permission GOVERNANCE
This how-to guide is for enabling sensitive data discovery (SDD) for the first time. For additional information on sensitive data discovery, see the Data discovery page.
Navigate to the App Settings page and scroll to the Sensitive Data Discovery section.
Select the Enable Sensitive Data Discovery (SDD) checkbox to enable SDD.
Click Save and then click Confirm to apply your changes. Note that the Immuta tenant will have a system restart.
Once SDD is enabled on your tenant, SDD will automatically run when new data sources are added, but it must be manually run for all existing data sources. This allows you to test out SDD with a select few data sources without worrying that it will add tags throughout all your data sources.
For this step, you will pick the identifiers to match the data that matters to your organization. For example, for international data, you may want to enable many different identifiers for many countries, like the "Australia Passport" identifier and the "Finland National ID Number" identifier. However, if you are dealing with United States domestic financial data, those identifiers would be irrelevant. In that case, it would be better to identify the data likely to appear, like Bitcoin or US Bank Routing MICR.
First, create an empty framework,
Navigate to Discover and Identification.
Select Create New.
Enter a Name and Description for your new identification framework.
Select Create empty framework.
Then, add a new identifier to that framework,
Navigate to Discover and Identifiers.
Use the checkboxes to select all the identifiers relevant to your data. Tip: From the overview page you can see the name and the tags that will be applied by the identifier. To better understand the data it will match, click the name to read the description.
Once you have checked the identifiers you want in your framework, click Add to Framework.
Type the framework name in the text box.
Click Add to Framework.
Once you have created a framework relevant to your data, it is time to test it on your data and customize it. Run identification on a select number of data sources where you understand the data to assess and adjust the tags to reflect what you expect to see.
Add those select data sources to your new framework,
Navigate to Discover and Identification.
Click your new framework name.
Navigate to the Data Sources tab.
Click Add Data Sources.
Check the checkboxes for the select data sources you want to try SDD on.
Click Add Data Source(s).
Then, run identification on those data sources,
Navigate to Discover and Identification.
Click the action menu for your new framework.
Click Run Identification.
After identification runs, you will receive a notification that the job is complete. Then, you can view the results from the data source dictionary.
Navigate to the data source overview page of the data source you added to the framework.
Click the Data Dictionary tab.
Assess whether the Discovered tags are applied as expected.
If you are happy with the Discovered tags, follow the Assign data sources to frameworks guide to add the rest of your data sources to the framework and follow the Run identification guide to run identification on all your data sources.
If you want additional tags, follow the Create an identifier guide to create identifiers that matter to your data.
This guide provides information and best practices for migrating from the deprecated legacy sensitive data discovery (SDD) option to the improved native SDD. This guide is for users who have already enabled SDD on their tenant and have Discovered tags on their data sources.
Legacy SDD is deprecated. It will be removed and replaced by native SDD. Native SDD is significantly improved from legacy SDD for discovering and tagging your data with upgrades to the built-in identifiers. Additionally, the greatest benefit is the respect for data residency. Native SDD doesn't move any of your data when running. The discovery is done right in your data platform, and the platform only returns the matching identifiers and column names to Immuta.
See the Sensitive data discovery reference page for more information on native SDD.
Native SDD requires Snowflake, Databricks, Starburst (Trino), or Redshift data sources
Legacy SDD enabled on your tenant
Legacy SDD tags applied to your data sources: To find out if you have legacy SDD tags applied, create a governance report as described in the understand the context of you tags section.
Contact your Immuta representative to enable native SDD on your Immuta tenant. Many users already have native SDD enabled, so proceed to understand the context of your tags if you want to self-service check if native SDD is already running and tagging your data before you reach out to the representative.
This action will not change anything immediately on your tenant; however, anytime identification runs in the future, it will be native SDD instead of the legacy version.
To assess native SDD for your data, proceed with the steps below. If you do not review native SDD, the legacy SDD tags will all remain on your data source columns. However, when identification automatically runs on new data sources and columns, it will apply native SDD tags, and because of the improvements to SDD, it may tag different data than legacy SDD.
Requirement: Immuta permission GOVERNANCE
Manually run identification globally to run native identification on your data sources.
To check the tags on an individual data source, navigate to the data source data dictionary and select a Discovered tag. On the tag side sheet, you can determine the context of the tag. When identifiers match data, native SDD will apply tags, and their tag context will be Sensitive Data Discovery. Any tags with the context Legacy Sensitive Data Discovery were not matched by native SDD but will remain on the data source.
To check your tags globally, navigate to the governance reports page and build a report for sensitive data discovery. This report will present the legacy tags on your data sources' columns and native SDD tags that are also on those columns. Use this report to assess the context of the Discovered tags and understand if native SDD is matching the data you want it to.
These actions will allow you to understand the differences between how native SDD and legacy SDD tag your data and whether your data is recognized as expected by native SDD or if legacy SDD was over-tagging your data. This way you can better tune SDD to your data.
If there are any legacy SDD tags that you want native SDD to catch, you need to tune native SDD so that this type of data is discovered in future tables and columns; see guidance on that in the next section.
Requirement: Immuta permission GOVERNANCE
Using the report you built above, complete these actions to tune SDD:
Focus on a legacy SDD tag properly applied to your data. Assess whether the native SDD tag on the column instead was applied more accurately than the legacy tag. If it is applied incorrectly, proceed to the next step.
Create a new regex or dictionary identifier in the framework to discover this data with the tag you want applied. Ensure it is specific and will match your data with at least 90% confidence (or match).
Complete the steps above for all legacy SDD tags.
Retest your updated identifiers by re-running identification on the select data sources and continue refining to the level of accuracy you want.
Completing the actions above will create parity between what legacy SDD was tagging your data and what native SDD will tag in the future.
Requirements:
Immuta permission GOVERNANCE
Identification (or sensitive data discovery (SDD)) runs automatically. If you want to re-run identification when a new global framework is set or when new identifiers have been added to a framework, you can manually run it for all data sources using the API or from the UI by following a how-to below.
Click the Discover icon and the Identification tab in the navigation menu.
Select the more actions icon.
Select Run Identification and then select it again in the modal.
Navigate to the data source overview page.
Click the health status.
Select Re-run next to Sensitive Data Discovery (SDD).
Verify discovered tags
If sensitive data discovery has been enabled, then manually adding tags to columns in the data dictionary will be unnecessary in most cases. The data owner will just need to verify that the Discovered tags are correct.
If a governor, data owner, or data source expert disables a Discovered tag from the data dictionary, the column will not be re-tagged next time identification (or SDD) runs. When a Discovered tag is disabled, it will not completely disappear, and it can be manually enabled through the tag side sheet.
To disable a discovered tag,
Navigate to a data source and click the Data Dictionary tab.
Scroll to the column you want to remove the tag from and click the tag you want to remove.
Click Disable in the side sheet and then click Confirm.
Sensitive data discovery (SDD) is an Immuta feature that uses data patterns to determine what type of data your column represents. Using identification frameworks and identifiers, Immuta evaluates your data and can assign the appropriate tags to your data dictionary based on what it finds. This saves the time of identifying your data manually and provides the benefit of a standard taxonomy across all your data sources in Immuta.
Sensitive data discovery is supported for data sources from the following technologies:
Starburst (Trino): Sensitive data discovery for Starburst (Trino) is currently in public preview and available to all accounts. Enable this feature on the Immuta app settings page.
Redshift: Sensitive data discovery for Redshift is currently in private preview and available to all accounts. Reach out to your Immuta representative to enable it on your tenant.
To evaluate your data, SDD generates a SQL query using the identification framework's identifiers; the Immuta system account then executes that query in the native technology. Immuta receives the query result, containing the column name and the matching identifiers but no raw data values. These results are then used to apply the resulting tags to the appropriate columns.
This evaluating and tagging process occurs when identification runs, which happens automatically from the following events:
A new data source is created.
Schema monitoring is enabled, and a new data source is detected.
Column detection is enabled, and new columns are detected. Here, SDD will only run on new columns, and no existing tags will be removed or changed.
A user manually triggers it from the data source health check menu.
A user manually triggers it from the identification frameworks page.
A user manually triggers it through the API.
Users can manually run identification from a data source's overview page or the identification frameworks page.
Sensitive data discovery (SDD) runs frameworks to discover data. These frameworks are a collection of identifiers. These identifiers contain a single criteria and the tags that will be applied when the criteria's conditions have been met. See the sections below for more information on each component.
An identification framework is a group of identifiers that will look for particular criteria and tag any columns where those conditions are met.
While organizations can have multiple frameworks, only one may be applied to each data source. Immuta has the built-in "Default Framework," which contains all the built-in identifiers and assigns the built-in Discovered tags.
For a how-to on the framework actions users can take, see the Manage frameworks page.
Each organization has a single global framework that will apply to all the data sources in Immuta by default unless they have a different framework assigned. It is labeled on the frameworks page with a globe icon. Users can bypass this global framework by applying a specific framework to data sources.
An identifier is a criteria and the tags to apply to data that matches the criteria. When Immuta recognizes that criteria, it can tag the data to describe the type.
Immuta comes with built-in identifiers to discover common categories of data. These identifiers cannot be modified or deleted. Users can also create their own unique identifiers to find their specific data.
For a how-to on the identifier actions users can take, see the Create an identifier page.
Criteria are the conditions that need to be met for resulting tags to be applied to data.
SDD only supports regular expressions (regex) written in RE2 syntax.
Competitive criteria analysis: This criteria is a process that will review all the regex and dictionary criteria within the identifiers of the framework and search for the identifier with the best fit. In this review, each competitive criteria analysis identifier in the framework competes against each other to find the best and most specific identifier that fits the data. The resulting tags for the best identifier are then applied to the column. Only one competitive criteria analysis identifier will apply per column. To learn more about the competitive nature, see the How competitive criteria analysis works guide.
Regex: This criteria contains a case-insensitive regular expression that searches for matches against column values.
Dictionary: This criteria contains a list of words and phrases to match against column values.
Column name: This criteria includes a case-insensitive regular expression matched against column names, not against the values in the column. The identifier's tags will be applied to the column where the name is found. Multiple column name identifiers can match a column and be applied.
Create a new identifier in the Immuta UI or with the sdd/classifier endpoint.
Only application admins can enable sensitive data discovery (SDD) globally on the Immuta app settings page. Then, data source creators can disable SDD on a data-source-by-data-source basis.
When SDD is manually triggered by a data owner, all column tags previously applied by SDD are removed and the tags prescribed by the latest run are applied. However, if SDD is triggered because a new column is detected by schema monitoring, tags will only be applied to the new column, and no tags will be modified on existing columns. Additionally, governors, data source owners, and data source experts can disable any unwanted Discovered tags in the data dictionary to prevent them from being used and auto-tagged on that data source in the future.
The amount of time it takes to run identification on a data source depends on several factors:
Columns: The time to run identification grows nearly linearly with the number of text columns in the data source.
Identifiers: The number of identifiers being used weakly impacts the time to run identification.
Row count: Performance of identification may vary depending on the sampling method used by each technology. For Snowflake, the number of rows has little impact on the time because data sampling has near-constant performance.
Views: Performance on views is limited by the performance of the query that defines the view.
The time it takes to run identification for all newly onboarded data sources in Immuta is not limited by SDD performance but by the execution of background jobs in Immuta. Consult your Immuta account manager when onboarding a large number of data sources to ensure the advanced settings are set appropriately for your organization.
For users interested in testing SDD, note that the built-in identifiers by Immuta require a 90% match to data to be assigned to a column. This means that with synthetic data, there may be situations where the data is not real enough to fit the confidence needed to match identifiers. To test SDD, use a dev environment, create copies of your tables, or use the API to run a dryRun and see the tags that would be applied to your data by SDD.
Deprecation notice
Support for this feature has been deprecated.
Private preview: This feature is only available to select accounts.
The data inventory dashboard visualizes information about your organization's data. It presents your entire data corpus within the context of the frameworks you have actively tagging your data with details like when your data was scanned last or how much of the scanned data is relevant to your active frameworks.
In the data inventory dashboard, you will see tiles for scanned coverage and the percentage of data scanned within a specific time frame. These tiles reference data scanned by an identification framework with SDD. To increase the number of your data sources that have been scanned, run identification.
The next section of the dashboard shows tiles for the compliance frameworks. Within each graph is the separation of columns containing or not containing the data important to the compliance framework. These graphs update every time classification runs, which will happen from these events.
For information on the frameworks visualized in the dashboard, see the Immuta frameworks reference guide.
Deleting the built-in Discovered tags is not recommended: If you do delete built-in Discovered tags and use the Default Framework, then when the identifier is matched the column will not be tagged. As an alternative, tags can be disabled on a column-by-column basis from the data dictionary, or SDD can be turned off on a data-source-by-data-source basis when creating a data source.
Data regex
Text string columns
Case-sensitive
Column name regex
Any column
Not case-sensitive
Dictionary
Text string columns
Can be toggled in the identifier definition
Immuta compiles dictionary patterns into a regex that is sent in the body of a query.
For Snowflake, the size of the dictionary is limited by the overall query text size limit in Snowflake of 1 MB.
For Databricks, Immuta will start up a Databricks cluster to complete the SDD job if one is not already running. This can cause unnecessary costs if the cluster becomes idle. Follow Databricks best practices to automatically terminate inactive clusters after a set period of time.
SDD will only work on Starburst (Trino) data sources authenticated with username and password. OAuth 2.0 is not supported with SDD.
Redshift Spectrum is not supported with SDD.
The Redshift cluster must be up and running for SDD to successfully run.
The username and password auth method is fully supported with SDD.
Okta is not supported with SDD.
AWS access key is supported with limitations with SDD:
The AWS access key used to register the data source can do a minimum of the following redshift-data API actions:
redshift-data:BatchExecuteStatement
redshift-data:CancelStatement
redshift-data:DescribeStatement
redshift-data:ExecuteStatement
redshift-data:GetStatementResult
redshift-data:ListStatements
The AWS access key used to register the data source must have redshift:GetClusterCredentials for the cluster, user, and database that they onboard their data sources with.
If using a custom URL, then the data source registered with the AWS access key must have the region and clusterid included in the additional connection string options formatted like the following:
Redshift Serverless data sources are not supported for native SDD with the AWS access key authentication method.
These limitations are only relevant to users who have previously enabled and run Immuta SDD.
Immuta has improved the performance and behavior of sensitive data discovery (SDD), so references to two types of SDD can be found in the product:
Legacy SDD was available before October 2023. It is no longer available, but some users may still see the term "legacy SDD" in the context of their data tags.
Native SDD was released in the 2024.2 LTS release. Native SDD is the only type of SDD available with a standard install. It is often just referred to as SDD.
If you had legacy SDD enabled, running native SDD can result in different tags being applied because native SDD is more accurate and has fewer false positives than legacy SDD. Running a new SDD scan against a table will change the context of the resulting tags, but no Discovered tags previously applied by legacy SDD will be removed.
See the Migrate from legacy to native SDD page for more information.
Of sensitive data discovery's three criteria options, regex and dictionary are competitive. This means that when assessing your data, if multiple identifiers could match, only one with competitive criteria will be chosen to tag the data. To better understand how Immuta executes this competition, read further.
Discover employs a three-phased competitive criteria analysis approach for sensitive data discovery (SDD):
Sampling: No data is moved, and Immuta checks the identifiers against a sample of data from the table.
Qualifying: Identifiers with a criteria match of less than a 90% match are filtered out.
Scoring: The remaining identifiers are compared with one another to find the most specific criteria that qualifies and matches the sample.
In the end, competitive criteria analysis aims to find a single identifier for each column that best describes the data format.
In the sampling process, no database contents are transmitted to Immuta; instead, Immuta receives only the column-wise hit rate (the number of times the criteria has matched a value in the column) information for each active identifier. To do this, Discover instructs a remote database to measure column-wise hit rate information for all active identifiers over a row sample.
The sample size is decided based on the number of identifiers and the data size, when available. In the most simplified case, the requested number of sampled rows depends only on the number of regex and dictionary criteria being run in the framework, not the data size. The sample size dependence on the number of identifiers is weak and will not exceed 13,000 rows.
5
7369 rows
50
9211 rows
500
11053 rows
5000
12895 rows
In practice, the number of sampled values for each column may be less than the requested number of rows. This happens when the target table has less than the requested number of rows, when many of the column values are null, or because of technology-specific limitations.
Snowflake and Starburst (Trino): Discover implements native table sampling by row count.
Databricks and Redshift: Due to technology limitations and the inability to predict the size of the table, Discover implements a best-effort sampling strategy comprising a flat 10% row sample capped at the first 10,000 sampled rows. In particular, under-sampling may occur on tables with less than 100,000 rows. Moreover, the resulting sample is biased towards earlier records.
All platforms: Sampling from views can have significantly slower performance that varies by the performance of the query that defines the view.
During the qualification phase, identifiers that do not agree with the data are disqualified. An identifier agrees with the data if the hit rate on the remote sample exceeds the predefined threshold. This threshold is 90% match for most built-in identifiers; however, two built-in identifiers have lower threshold . The 90% threshold is standard for all custom identifiers as well to ensure the criteria matches the data within the column and avoid false positives. If no identifiers qualify, then no identifier is assessed for scoring and the column is not tagged.
During the scoring phase, a machine inference is carried out among all qualified identifiers, combining criteria-derived complexity information with hit rate information to determine which identifier best describes the sample data. This process prefers the more restrictive of two competing identifiers since the ability to satisfy the more difficult-to-satisfy identifier itself serves as evidence that it is more likely. This phase ends by returning a single most likely identifier per the inference process.
Here are a set of regex identifiers and a sample of data:
Identifiers:
[a-zA-Z0-9]{3} - This regex will match 3 character strings with the characters a-z, lowercase or uppercase, or digits 0-9.
[a-c]{3} - This regex will match 3 character strings with the characters a-c, lowercase.
(a|b|d){3} - This regex will match 3 character strings with the characters a, b, or d, lowercase.
dad
Yes
Yes
baa
Yes
Yes
add
Yes
Yes
add
Yes
Yes
cab
Yes
Yes
bad
Yes
Yes
aba
Yes
Yes
baa
Yes
Yes
dad
Yes
Yes
baa
Yes
Yes
When qualifying the identifiers, Identifier 1 and Identifier 3 both match 90% or more of the data. Identifier 2 does not, and is disqualified.
Then the qualified identifiers are scored. Here, Identifier 1, despite matching 100% of the data, is unspecific and could match over 200,000 values. On the other hand, Identifier 3 matches just at 90% but is very specific with only 27 available values.
Therefore, with the specificity taken into account, Identifier 3 would be the match for this column, and its tags would be applied to the data source in Immuta.
Dictionaries are part of the competitive process, while column-name regex are not.
Scoring ties are rare but can occur if the same criteria (either dictionary or regex) is specified more than once (even in different forms). Scoring ties are inconclusive, and the scoring phase will not return an identifier in the case of a tie.
Criteria complexity analysis is sensitive to the total number of strings an identifier accepts or, equivalently for dictionaries, the number of entries. Therefore, identifiers that accept much more than is necessary to describe the intended column data format may perform more poorly in the competitive analysis because they are easier to satisfy.
Immuta comes with a set of built-in identifiers that look for common data types. These identifiers were written by Immuta's research and development team and cannot be deleted or edited by users. However, users can add these built-in patterns to their own frameworks and edit the tags applied by them.
When using SDD with classification frameworks, it is recommended to use the default resulting tags listed in the table below for these built-in identifiers. This ensures that the framework rules apply sensitivity tags as intended.
Deprecation notice
The following Discovered tags have been deprecated:
Discovered.Identifier Direct
Discovered.Identifier Indirect
Discovered.Identifier Undetermined
Discovered.PCI
Discovered.PHI
Discovered.PII
New Immuta installs will not see these tags applied by SDD. Current installations relying on these tags for policies should contact their Immuta representative for support before these tags are removed from the product.
AGE
Matches numeric strings between 10 and 199.
Discovered.PII
Discovered.Identifier Indirect
Discovered.PHI
Discovered.Entity.Age
ARGENTINA_DNI_NUMBER
Matches strings consistent with Argentina National Identity (DNI) Number. Requires an eight-digit number with optional periods between the second and third and fifth and sixth digit.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Argentina
Discovered.PHI
Discovered.Entity.DNI Number
AUSTRALIA_MEDICARE_NUMBER
Matches numeric strings consistent with Australian Medicare number. Requires a ten- or eleven-digit number. The starting digit must be between 2 and 6, inclusive. Optional spaces can be placed between the fourth and fifth and ninth and tenth digit. The optional 11th digit separated by a / can be present. A checksum is required.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Australia
Discovered.PHI
Discovered.Entity.Medicare Number
AUSTRALIA_PASSPORT
Matches strings consistent with Australian Passport number. An 8- or 9-character string is required, with a starting upper case character (N, E, D, F, A, C, U, X) or a two-character starting character (P followed by A, B, C, D, E, F, U, W, X, or Z) followed by seven digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Australia
Discovered.PHI
Discovered.Entity.Passport
BELGIUM_NATIONAL_ID_CARD_NUMBER
Matches numeric strings consistent with Belgium's National ID card. Requires a twelve-digit number with hyphen (-) between the third and fourth digit and tenth and eleventh digits. A two checksum is required.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Belgium
Discovered.PHI
Discovered.Entity.National ID Card Number
BITCOIN_INVOICE_ADDRESS
Matches strings consistent with the following Bitcoin Invoice Address formats: P2PKH, P2SH, and Bech32. P2PKH and P2SH must start with a 1 or a 3, respectively, followed by 25 - 34 alphanumeric characters, excluding l, I, O, and 0. Bech32 formats must begin with bc1 and be followed by 39 characters. To be identified, any addresses must have a valid checksum.
Discovered.Entity.CRYPTO
Discovered.PCI
BRAZIL_CPF_NUMBER
Matches a numeric string consistent with Brazil's CPF (Cadastro Pessoal de Pessoa Física) number. An eleven-digit numeric string with non-numeric separators after the third, sixth, and ninth digits. A two digit checksum is required.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Brazil
Discovered.PHI
Discovered.Entity.CPF Number
CANADA_BC_PHN
Matches numeric strings consistent with British Columbia's Personal Health Number (PHN). Requires a ten-digit numeric string with optional hyphen (-) or spaces after the fourth and seventh digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Canada
Discovered.PHI
Discovered.Entity.British Columbia Health Network Number
CANADA_OHIP
Matches alphanumeric strings consistent with Ontario's Health Insurance Plan (OHIP). Requires a twelve-digit alphanumeric code. Optional hyphens (-) or spaces can appear after the fourth, seventh, and tenth digits. The final two characters are a checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Canada
Discovered.PHI
Discovered.Entity.Ontario Health Insurance Number
CANADA_PASSPORT
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Canada
Discovered.PHI
Discovered.Entity.Passport
CANADA_QUEBEC_HIN
Matches alphanumeric strings consistent with Quebec's Health Insurance Number (HIN). Requires four alphabetic characters followed by an optional space or hyphen (-), and then eight digits with an optional hyphen or space after the fourth digit.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Canada
Discovered.PHI
Discovered.Entity.Quebec Health Insurance Number
CREDIT_CARD_NUMBER
Matches strings consistent with a credit card number with prefixes matching major credit card companies. Must include a valid checksum.
Discovered.PCI
Discovered.Entity.Credit Card Number
DATE
Matches strings consistent with dates. These can include days of the week, dates, and date times.
Discovered.Entity.Date
DENMARK_CPR_NUMBER
Matches numeric strings consistent with Personal Identification Number (CPR-number or Person-number). Requires a ten-digit number with either a DDMMYY-SSSS or DDMMYYSSSS format. The first six digits are an individual's birth date in Day, Month, Year format. The final four digits comprise the sequence number.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Denmark
Discovered.PHI
Discovered.Entity.CPR Number
DOMAIN_NAME
Matches domain names using a very broad pattern.
Discovered.Entity.Domain Name
EMAIL_ADDRESS
Detect strings consistent with an email address. Usernames are required to be fewer than 255 characters, follow by @a, a domain of fewer than 255 characters, and a top level domain of between 2 and 20 characters.
Discovered.PHI
Discovered.Entity.Electronic Mail Address
Discovered.Identifier Direct
ETHNIC_GROUP
Matches strings consistent with the US Census race designations.
Discovered.PII
Discovered.Entity.Ethnic Group
FDA_CODE
Matches a string consistent with a drug or ingredient registered with Food and Drug Administration (FDA). Must start with between 4 to 6 digits, followed by a hyphen, followed by 3 to 4 digits, followed by a hyphen, and finishing with one to two digits.
Discovered.Country.US
Discovered.Entity.FDA Code
FINLAND_NATIONAL_ID_NUMBER
Matches a string consistent with Finland's National ID number. Requires an eleven-character string in a DDMMYYCZZZQ format. The first six digits are an individual's birth date in Day, Month, Year format. The C character is a century of birth indicator (+ for the years 1800-1899, - for years 1900-1999, and A for years 2000-2099). ZZZ is an individual ID number, and Q is a required checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Finland
Discovered.PHI
Discovered.Entity.National ID Number
FRANCE_CNI
Matches numeric strings consistent with the French National ID card number (carte nationale d'identité). Requires a twelve-digit numeric string.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.France
Discovered.PHI
Discovered.Entity.CNI
FRANCE_NIR
Matches numeric strings consistent with France's National ID number (Numéro d'Inscription au Répertoire). Requires a fifteen-digit numeric string. An optional hyphen (-) or space can appear after the 13th digit. The 14th and 15th digits act as a checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.France
Discovered.PHI
Discovered.Entity.NIR
FRANCE_PASSPORT
Matches alphanumeric strings consistent with the French Passport number. Requires two numbers followed by two upper case letters and ends with 5 digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.France
Discovered.PHI
Discovered.Entity.Passport
GENDER
Matches strings consistent with gender or gender abbreviations.
Discovered.PII
Discovered.Identifier Indirect
Discovered.PHI
Discovered.Entity.Gender
GERMANY_DRIVERS_LICENSE_NUMBER
Matches alphanumeric strings consistent with Germany's Driver's License number. Requires an eleven-element string, with a digit or a letter followed by two digits, 6 digits or letters, one digit, and one digit or letter.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Germany
Discovered.PHI
Discovered.Entity.Drivers License Number
GERMANY_IDENTITY_CARD_NUMBER
Matches alphanumeric strings consistent with Germany's Identity Card number. Requires a single letter followed by eight digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Germany
Discovered.PHI
Discovered.Entity.Identity Card Number
IBAN_CODE
Matches strings consistent with an International Bank Account Number (IBAN). Must contain a valid country code.
Discovered.Entity.IBAN Code
ICD10_CODE
Matches strings consistent with codes from the International Statistical Classification of Diseases and Related Health Problems (ICD), as drawn from the Clinical Modification lexicon from the year 2020.
Discovered.Entity.ICD10 Code
IMEI_HARDWARE_ID
Matches strings consistent with an International Mobile Equipment Identity (IMEI) number. Must contain 15 digits with optional hyphens or spaces after the second, 8th, and 14th digits.
Discovered.Entity.IMEI
IP_ADDRESS
Matches IP Addresses in the V4 and V6 formats.
Discovered.Entity.IP Address
LOCATION
Matches strings consistent with Countries, States, Addresses, or Municipalities. By default focuses on locations in the United States.
Discovered.Entity.Location
MAC_ADDRESS
Matches strings consistent with a Media Access Control (MAC) address. Must contain twelve hexadecimal digits, with every two digits separated by a colon.
Discovered.Entity.MAC Address
MAC_ADDRESS_LOCAL
Matches strings consistent with a local Media Access Control (MAC) address.
Discovered.Entity.MAC Address Local
PERSON_NAME
Matches strings consistent with a dictionary of people's names. Names are drawn from the US Social Security database.
Discovered.PII
Discovered.PHI
Discovered.Entity.Person Name
Discovered.Identifier Indirect
PHONE_NUMBER
Matches strings consistent with telephone numbers. Primarily looks for strings consistent with the United States telephone numbers naming convention.
Discovered.Entity.Telephone Number
POSTAL_CODE
Matches strings consistent with a valid US zip code with an optional +4. Only valid 5 digit zip codes are detected.
Discovered.Entity.Postal Code
SPAIN_NIE_NUMBER
Matches strings consistent with Spain's Foreigner Identification number. Requires an eight-character string. The initial character must be X, Y, or Z, followed by seven digits, then by an optional hyphen or space and a single checksum character.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Spain
Discovered.PHI
Discovered.Entity.NIE Number
SPAIN_NIF_NUMBER
Matches strings consistent with Spain's Tax Identification number. Requires an eight-character string. Requires eight digits followed by an optional hyphen or space and a single checksum character.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Spain
Discovered.PHI
Discovered.Entity.NIF Number
SPAIN_PASSPORT
Matches strings consistent with Spain's Passport number. Requires an eight- or nine-character string, starting with either two or three letters followed by six digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Spain
Discovered.PHI
Discovered.Entity.Passport
STREET_ADDRESS
Matches strings consistent with street addresses. Primarily looks for strings consistent with the United States street naming convention.
Discovered.Entity.Location
SWEDEN_NATIONAL_ID_NUMBER
Matches numeric strings consistent with Sweden's Nation ID number. Requires a ten- or twelve-digit string that must start with a date in either the YYMMDD or YYYYMMDD formats. An optional - or + character then separates four ending digits. The final digit is a checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Sweden
Discovered.PHI
Discovered.Entity.National ID Number
SWEDEN_PASSPORT
Matches numeric strings consistent with Sweden's Passport number. Requires an 8-digit number.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Sweden
Discovered.PHI
Discovered.Entity.Passport
SWIFT_CODE
Matches alphanumeric strings consistent with a SWIFT code (or Bank Identifier Code (BIC)) format.
Discovered.Entity.Swift Code
THAILAND_NATIONAL_ID_NUMBER
Matches strings consistent with Thailand's National ID number. Requires a 13-digit number with optional spaces or hyphens (-) after the first, fifth, tenth, and twelfth digits. The final digit is a checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.Thailand
Discovered.PHI
Discovered.Entity.National ID Number
TIME
Matches strings consistent with times. Can contain both date and time pieces.
Discovered.Entity.Date
UK_DRIVERS_LICENSE_NUMBER
Matches alphanumeric strings consistent with the United Kingdom's Driver's License number. Requires either a 16- or 18-character string. The first five characters represent the driver's surname, padded with 9s, followed by a single digit for decade of birth, two digits for month of birth (incremented by 50 for female drivers), two digits for day of birth, one digit for year of birth, two letters, an arbitrary digit, and two digits. Two additional digits can be present for each license issuance.
Discovered.PII
Discovered.Identifier Direct,
Discovered.Country.UK
Discovered.PHI
Discovered.Entity.Drivers License Number
UK_NATIONAL_INSURANCE_NUMBER
Matches alphanumeric strings consistent with the United Kingdom's National Insurance number. Requires a nine-character string. The first two digits must be letters, followed by an optional space, then six digits with optional spaces or hyphens (-) every two digits, ending with a letter.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.UK
Discovered.PHI
Discovered.Entity.National Insurance Number
UK_TAXPAYER_REFERENCE
Matches ten-digit numeric strings consistent with UK Taxpayer Reference (UTR) numbers. The final digit is a checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.UK
Discovered.PHI
Discovered.Entity.Taxpayer Reference
URL
Matches string consistent with a Uniform Resource Locator (URL). String must begin with http://, https://, ftp://, file:///, or mailto:, followed by a string and ending with a top level domain of no more than 128 characters.
Discovered.Entity.URL
US_ADOPTION_TAXPAYER_IDENTIFICATION_NUMBER
Matches a numeric string consistent United States Adoption Taxpayer Identification Number (ATIN). Requires a string similar in format to a US Social Security Number, but starting with a 9 in the Area Number and having 93 as an allowed Group Number.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.US
Discovered.PHI
Discovered.Entity.Adoption Taxpayer ID Number
US_BANK_ROUTING_MICR
Matches numeric string consistent with an American Bankers Association (ABA) Routing Number. Must be a nine-digit number starting with 0, 1, 2, 3, 6, or 7, followed by eight digits. The final digit is a checksum.
Discovered.Country.US
Discovered.Entity.Bank Routing MICR
US_DEA_NUMBER
Matches alphanumeric strings consistent with a Drug Enforcement Administration (DEA) number that is assigned to a health care provider. Must be a length of nine characters. The first two digits must be alphanumeric, and the last seven digits must be digits. The final digit is a checksum.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.US
Discovered.Entity.DEA Number
US_EMPLOYER_IDENTIFICATION_NUMBER
Matches numeric string consistent United States Employer Identification Number (EIN). Strings must contain nine digits with a hyphen after the second digit.
Discovered.Country.US
Discovered.Entity.Employer ID Number
US_HEALTHCARE_NPI
Matches numeric strings consistent with US National Provider Identifier (NPI). Strings must be either 10 or 15 digits with the final digit being a valid checksum.
Discovered.PII
Discovered.Country.US
Discovered.Entity.Healthcare NPI
Discovered.Identifier Undetermined
US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER
Matches a numeric string consistent United States Individual Taxpayer Identification Number (ITIN). Requires a string similar in format to a US Social Security Number, but starting with a 9 in the Area Number and having a limited set of allowed Group Numbers.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.US
Discovered.PHI
Discovered.Entity.Individual Taxpayer ID Number
US_PASSPORT
Matches numeric strings consistent with United States Passport number. Strings must contain nine digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.US
Discovered.PHI
Discovered.Entity.Passport
US_PREPARER_TAXPAYER_IDENTIFICATION_NUMBER
Matches strings consistent with a Preparer Taxpayer ID number. Strings must have nine characters, starting with a P that is followed by 8 digits.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.US
Discovered.Entity.Preparer Taxpayer ID Number
US_SOCIAL_SECURITY_NUMBER
Matches strings consistent with a US Social Security Number. Strings must contain nine digits and comprise three parts: the three left-most digits designating the area number, the middle two digits designating the group number, and the four right-most digits designating the serial number. For a column to be tagged, none of these parts can contain all zeroes, and area numbers must not be 666 or in the range of 900-999.
Discovered.PII
Discovered.Identifier Direct
Discovered.Country.US
Discovered.PHI
Discovered.Entity.Social Security Number
US_STATE
Matches strings consistent with either a full name or two-letter abbreviation of a US state or territory.
Discovered.Country.US
Discovered.Entity.State
US_TOLLFREE_PHONE_NUMBER
Matches strings consistent with a US toll-free telephone number. Allowed area codes are 800, 88+any digit, or 899.
Discovered.Country.US
Discovered.Entity.Tollfree Telephone Number
VEHICLE_IDENTIFICATION_NUMBER
Matches strings consistent with Vehicle Identification Numbers. A checksum is required as well as a valid World Manufacturer Identifier.
Discovered.Country.US
Discovered.Entity.Vehicle Identifier or Serial Number
Requirements:
Immuta permission GOVERNANCE
Click the Discover icon in the navigation menu and select the Identification tab.
Click Create New.
Enter a Name and Description for the identification framework.
Select the option to Create empty framework.
Click Create.
After you create the identification framework, you can .
Click the Discover icon in the navigation menu and select the Identification tab.
Click Create New.
Enter a Name and Description for the identification framework.
Select the option to Create identifiers from an existing framework.
Select the checkbox for the framework you want to copy. You can only copy a single framework. For more information about a framework, click the framework name to open a new tab with details about the framework.
Click Create.
To add an identifier to a framework,
Click the Discover icon in the navigation menu and select the Identification tab.
Select the framework name for the identification framework you want to edit.
Click Add Identifier.
Choose in the dropdown to add an identifier from those already in Immuta or create a new identifier for the framework.
For existing identifiers: Opt to edit the tags. Then click Add Identifier.
For new identifiers:
Fill out a Name and Description.
For regex, enter a regex to be matched against column values. The default criteria encoding is case-sensitive. You can change this encoding using the regex criteria. The regex must use RE2.
For column name regex, enter a regex to be matched against column names. The default criteria encoding is not case-sensitive. You can change this encoding using the regex criteria. The regex must use RE2 syntax.
For a dictionary, enter the values in a comma-separated list to match against column values. Opt to toggle the Case insensitive switch to on if you want the dictionary to be case sensitive.
Select the tags to apply: Use the text box to search for a tag under the "Discovered" hierarchy or type a tag name to create a new tag under the "Discovered" hierarchy to apply to columns that match your identifier.
Click Next to review your new identifier and click Create Identifier to create it.
To edit the tags applied by an identifier for a framework,
Click the Discover icon in the navigation menu and select the Identification tab.
Select the framework name for the identification framework you want to edit.
Click the more actions icon for an identifier and select Edit tags.
Remove the tags or type a tag name to add tags.
Click Save.
Click the Discover icon in the navigation menu and select the Identification tab.
Select the framework name for the identification framework you want to edit.
Click the more actions icon for an identifier and select Delete.
Click Delete again in the modal.
To assign a framework to run on specific data sources,
Click the Discover icon in the navigation menu and select the Identification tab.
Select the framework you want to assign and navigate to the Data Sources tab.
Click Add Data Sources.
Select the checkbox for the data source you want this framework to run on. You may select more than one.
Click Add Data Source(s).
After a data source is removed from a framework, it will use the global framework for any SDD scans and the tags applied by the removed framework will be replaced. The global framework is signified by the globe icon.
To remove data sources from a framework,
Click the Discover icon in the navigation menu and select the Identification tab.
Select the framework you want to remove data sources from and navigate to the Data Sources tab.
Select the checkbox for the data source you want to remove from the framework. You may select more than one.
Select Remove and click Remove again in the modal.
Requirement: No data sources assigned to the framework
To delete a framework,
Click the Discover icon in the navigation menu and select the Identification tab.
Select Delete and click Delete again in the modal.
Matches strings consistent with the Canadian Passport Number format as .
Enter criteria: Select the .
Only tags can be edited within a framework. Edits made to an identifier within a framework will only impact that specific identifier. To fully edit an identifier (including the name, description, or criteria) for all frameworks, use the .
Click the more actions icon in the Action column for the framework you want to delete. The global framework cannot be deleted. If you want to delete it, .
Immuta is pre-configured with a set of tags that can be used to write global policies before data sources even exist. See a list of the built-in Discovered tags below and the Built-in identifier reference page for information about where these tags will be applied by the built-in identifiers.
All the tags below belong to the Country parent. For example, the full tag name will appear as Discovered . Country . Argentina.
Argentina
This tag is applied to data recognized as specific to Argentina (e.g., an Argentina National Identity Number).
Australia
This tag is applied to data recognized as specific to Australia (e.g., an Australian Medicare number or Australian passport number).
Belgium
This tag is applied to data recognized as specific to Belgium (e.g., a Belgium National ID card).
Brazil
This tag is applied to data recognized as specific to Brazil (e.g., a Brazil CPF number).
Canada
This tag is applied to data recognized as specific to Canada (e.g., a British Columbia PHN, OHIP string, Canadian passport number, or Quebec's HIN).
Chile
This tag is for data specific to Chile.
China
This tag is for data specific to China.
Colombia
This tag is for data specific to Colombia.
Denmark
This tag is applied to data recognized as specific to Denmark (e.g., a Denmark CPR or Person-number).
Finland
This tag is applied to data recognized as specific to Finland (e.g., a Finland National ID number).
France
This tag is applied to data recognized as specific to France (e.g., a French National ID card number, France National ID number, or French passport number).
Germany
This tag is applied to data recognized as specific to Germany (e.g., a German driver's license number or a Germany Identity Card number).
Hong Kong
This tag is for data specific to Hong Kong.
India
This tag is for data specific to India.
Indonesia
This tag is for data specific to Indonesia.
Japan
This tag is for data specific to Japan.
Korea
This tag is for data specific to Korea.
Mexico
This tag is for data specific to Mexico.
Netherlands
This tag is for data specific to Netherlands.
Norway
This tag is for data specific to Norway.
Paraguay
This tag is for data specific to Paraguay.
Peru
This tag is for data specific to Peru.
Poland
This tag is for data specific to Poland.
Singapore
This tag is for data specific to Singapore.
Spain
This tag is applied to data recognized as specific to Spain (e.g., Spain Foreigner Identification number, Spain Tax Identification number, or Spanish passport number).
Sweden
This tag is applied to data recognized as specific to Sweden (e.g., a Sweden National ID number or Swedish passport number).
Taiwan
This tag is for data specific to Taiwan.
Thailand
This tag is applied to data recognized as specific to Thailand (e.g., a Thailand National ID number).
Turkey
This tag is for data specific to Turkey.
UK
This tag is applied to data recognized as specific to the United Kingdom (e.g., a United Kingdom driver's license number, United Kingdom National Insurance number, or United Kingdom Taxpayer Reference number).
Uruguay
This tag is for data specific to Uruguay.
US
This tag is applied to data recognized as specific to the U.S. (e.g., an FDA code, United States ATIN, ABA routing number, DEA number, United States EIN, United States NPI number, United States ITIN, United States passport number, United States Preparer Taxpayer ID number, United States SSN, United States territory or state, or United States toll-free phone number).
Venezuela
This tag is for data specific to Venezuela.
All the tags below belong to the Entity parent. For example, the full tag name will appear as Discovered . Entity . Aadhaar Individual.
Aadhaar Individual
This tag is for Aadhaar Individual numbers.
Adoption Taxpayer ID Number
This tag is applied to data recognized as a United States Adoption Taxpayer Identification number.
Age
This tag is applied to data recognized as an age.
Bank Account
This tag is for bank account numbers.
Bank Routing MICR
This tag is applied to data recognized as an American Bankers Association routing number.
Bankers CUSIP ID
This tag is for CUSP identification numbers for stocks and bonds.
British Columbia Health Network Number
This tag is applied to data recognized as British Columbia's Personal Health Number.
BSN Number
This tag is for Netherlands citizen service number.
BSN Number
This tag is for Netherlands citizen service numbers.
CDC Number
This tag is for CDC numbers.
CDI Number
This tag is for CDI numbers.
CIC Number
This tag is for CIC numbers.
CNI
This tag is applied to data recognized as a French National ID card number.
CPF Number
This tag is applied to data recognized as Brazil's CPF number.
CPR Number
This tag is applied to data recognized as Denmark's Personal Identification number.
Credit Card Number
This tag is applied to data recognized as a credit card number.
CURP Number
This tag is for Mexican CURP numbers.
CRYPTO
This tag is applied to data recognized as a Bitcoin Invoice Address.
Date
This tag is applied to data recognized as a date.
Date of Birth
This tag is applied to data recognized as a date of birth.
DEA Number
This tag is applied to data recognized as the DEA number of a healthcare provider.
DNI Number
This tag is applied to data recognized as an Argentina National Identity number.
Domain Name
This tag is applied to data recognized as a domain.
Driver's License Number
This tag is applied to data recognized as driver's licenses numbers from Germany or the United Kingdom.
Electronic Mail Address
This tag is applied to data recognized as an email address.
Employer ID Number
This tag is applied to data recognized as an Employer Identification number from the United States.
Ethnic Group
This tag is applied to data recognized as an ethnic group.
FDA Code
This tag is applied to data recognized as the code of a drug or ingredient registered with the FDA.
Gender
This tag is applied to data recognized as a gender.
GST Individual
This tag is for Indian GST individual numbers.
Healthcare NPI
This tag is applied to data recognized as a United States National Provider Identifier number.
IBAN Code
This tag is applied to data recognized as an International Bank Account number.
ICD10 Code
This tag is applied to data recognized as an ICD10 code from the International Statistical Classification of Diseases and Related Health Problems.
ICD9 Code
This tag is for ICD9 codes from the International Statistical Classification of Diseases and Related Health Problems.
ID Number
This tag is for any ID number.
Identity Card Number
This tag is applied to data recognized as an identity card number from Germany.
IMEI
This tag is applied to data recognized as an International Mobile Equipment Identity number.
Individual Number
This tag is for any individual number.
Individual Taxpayer ID Number
This tag is applied to data recognized as a United States Individual Taxpayer Identification Number.
IP Address
This tag is applied to data recognized as an IP address.
Location
This tag is applied to data recognized as a country, state, address, or municipality.
MAC Address
This tag is applied to data recognized as a Media Access Control address.
MAC Address Local
This tag is applied to data recognized as a local Media Access Control address.
Medicare Number
This tag is applied to data recognized as a Medicare number from Australia.
National Health Service Number
This tag is for national health service numbers.
National ID Card Number
This tag is applied to data recognized as a national ID card number from Belgium.
National ID Number
This tag is applied to data recognized as a national ID number from Finland, Sweden, and Thailand.
National Insurance Number
This tag is applied to data recognized as a United Kingdom national insurance number.
National Registration ID Number
This tag is for national registration ID numbers.
NI Number
This tag is for Norway NI numbers.
NIE Number
This tag is applied to data recognized as a Spanish Foreigner Identification number.
NIF Number
This tag is applied to data recognized as a Spanish Tax Identification number.
NIK Number
This tag is applied to data recognized as an Indonesian personal identification number (NIK).
NIR
This tag is applied to data recognized as France's National ID number.
Ontario Health Insurance Number
This tag is applied to data recognized as part of an Ontario Health Insurance Plan string.
PAN Individual
This tag is for PAN Individual numbers.
Passport
This tag is applied to data recognized as a passport number from Australia, Canada, France, Spain, Sweden, and the United States.
Person Name
This tag is applied to data recognized as people's names.
PESEL Number
This tag is for Poland PESEL numbers.
Postal Code
This tag is applied to data recognized as a United States zip code.
Preparer Taxpayer ID Number
This tag is applied to data recognized as a Preparer Taxpayer ID number.
Quebec Health Insurance Number
This tag is applied to data recognized as a Quebec Health Insurance Number.
Resident ID Number
This tag is for China Resident ID numbers.
RRN
This tag is for Korea Resident Registration numbers.
Social Insurance Number
This tag is applied to data recognized as a social insurance number.
Social Security Number
This tag is applied to data recognized as a United States Social Security Number.
State
This tag is applied to data recognized as a state of the United States.
Swift Code
This tag is applied to data recognized as a SWIFT code.
Tax File Number
This tag is applied to data recognized as a tax file number.
Taxpayer ID Number
This tag is applied to data recognized as Taxpayer ID numbers from the United States.
Taxpayer Reference
This tag is applied to data recognized as United Kingdom Taxpayer Reference numbers.
Telephone Number
This tag is applied to data recognized as a phone number.
Tollfree Telephone Number
This tag is applied to data recognized as a United States toll-free phone number.
URL
This tag is applied to data recognized as a URL.
Vehicle Identifier or Serial Number
This tag is applied to data recognized as a VIN.
Deprecation notice
The following identifier tags have been deprecated. New Immuta installs will not see these tags applied by SDD. Current installations relying on these tags for policies should contact their Immuta representative for support before these tags are removed from the product.
None of the tags below have an additional parent or child tag. For example, the full tag name will appear as Discovered . Identifier Direct.
Identifier Direct
This tag is applied to data recognized as a direct identifier that can be uniquely associated with an individual. Examples of direct identifiers include: name, username, email, official individual identification numbers such as passport or identity card numbers, or privately issued individual identification numbers such as a student ID.
Identifier Indirect
This tag is applied to data recognized as an indirect identifier that is not uniquely associated with an individual. However this indirect identifier could become distinguishable when combined with other attributes. Examples of indirect identifiers include: age and affinity.
Identifier Undetermined
This tag is applied to data which could be an identifier associated with an individual.
Deprecation notice
The following identifier tags have been deprecated. New Immuta installs will not see these tags applied by SDD. Current installations relying on these tags for policies should contact their Immuta representative for support before these tags are removed from the product.
None of the tags below have an additional parent or child tag. For example, the full tag name will appear as Discovered . PCI.
PCI
This tag is applied to data recognized as payment card information.
PHI
This tag is applied to data recognized as personal health data.
PII
This tag is applied to data recognized as personally identifiable information.
Requirement: Immuta permission APPLICATION_ADMIN
Click the App Settings icon in the left sidebar.
Click Sensitive Data Discovery in the left panel to navigate to that section.
Enter the request-friendly name of your global identification framework in the Global SDD Template Name field. This name can be found in the URL when you navigate to the identification framework's page.
Click Save, and then Confirm your changes.
Requirements:
Immuta permission GOVERNANCE
Click the Discover icon in the navigation menu and select the Identifiers tab.
Click Create New.
Enter a Name and Description for the new identifier.
Enter criteria: Select the Type of criteria.
For regex, enter a regex to be matched against column values. The default criteria encoding is case-sensitive. You can change this encoding using the regex criteria. The regex must use RE2.
For column name regex, enter a regex to be matched against column names. The default criteria encoding is case-insensitive. You can change this encoding using the regex criteria. The regex must use RE2 syntax.
For a dictionary, enter the values in a comma-separated list to match against column values. Opt to toggle the Case insensitive switch to on if you want the dictionary to be case sensitive.
Select the tags to apply: Use the text box to search for a tag under the "Discovered" hierarchy or type a tag name to create a new tag under the "Discovered" hierarchy to apply to columns that match your identifier.
Click Next to review your new identifier and click Create Identifier to create it.
See the Manage identification frameworks page to add your new identifier to a framework.
Note that all user-created identifiers must be a 90% match or greater for the contents of the column to be tagged.
Editing the details or criteria of an identifier from the identifiers menu will affect any framework with that identifier throughout Immuta. Editing the tags will only affect new frameworks the identifier is added to.
To edit an identifier,
Click the Discover icon in the navigation menu and select the Identifiers tab.
Click the name of the identifier you want to edit.
Click Edit.
Edit the field you want to change.
Click Save.
Built-in identifiers cannot be edited.
Deleting an identifier will remove it from all the frameworks it is in throughout Immuta.
To delete an identifier,
Click the Discover icon in the navigation menu and select the Identifiers tab.
Click the more actions icon in the Action column for the identifier you want to delete.
Select Delete and click Delete again in the modal.
Built-in identifiers cannot be deleted.