Forum Discussion
Microsoft Purview Data Map Sensitivity Labelling
Your testing is correct, and this is expected behaviour rather than a configuration gap on your side.
The short version: the auto-labelling rule picker is driven by Information Protection SITs, not by Data Map classifications. These are two separate catalogues with only partial overlap, and the overlap is roughly the set of things that can be matched with a regex and a checksum.
IS THIS EXPECTED? YES.✅
The docs state it directly. In "Apply sensitivity labels to your data in Data Map", step 9 lists what cannot be used as conditions: custom sensitive info types, and advanced classifiers such as named entities (All Full Names, All Physical Addresses), trainable classifiers, credentials, and Exact Data Match. The FAQ adds that advanced classifiers do not appear at all, which is why Email Address is missing from your picker rather than greyed out.
https://learn.microsoft.com/purview/data-map-sensitivity-labels-apply
https://learn.microsoft.com/purview/data-map-sensitivity-labels-faq
Your table splits cleanly along that line. The three that work, NI number, passport and payment card, are regex plus checksum classifications with direct built-in SIT equivalents. The ones that fail, Full Name, Date of Birth, Person Age and Person Gender, are all listed under "Machine Learning based classifications" in the Data Map classification reference. There is no non-ML SIT to bind them to, so they cannot become a condition.
https://learn.microsoft.com/purview/data-map-classification-supported-list
Email is the odd case. Data Map has a regex based Email classification, but Information Protection has no equivalent standalone built-in SIT for you to select, so nothing appears in the picker.
IS THERE A PUBLISHED MAPPING? NOT ONE THAT I HAVE FOUND.❌
You have to intersect two lists by hand, the Data Map classification reference linked above, and the sensitive information type reference here:
https://learn.microsoft.com/purview/sensitive-information-type-learn-about
A shortcut that works: in the Data Map list, ignore the entire Machine Learning based classifications section. That section is effectively your unsupported list. Then confirm that each remaining regex or Bloom Filter classification has a built-in SIT with the same name.
CAN CUSTOM SITS BE USED? NO.❌
The FAQ is explicit, only Microsoft built-in sensitive information types are supported. This is the limitation that hurts most in your case, since UK UTR and Electoral Roll identifiers are exactly what you would otherwise solve with a custom SIT.
ROADMAP? NOTHING PUBLICLY COMMITTED THAT I CAN FIND.❌
The capability is still in preview. Worth watching the M365 roadmap, but I would not design around it arriving.
https://learn.microsoft.com/purview/sensitivity-labels
HOW OTHERS ARE HANDLING IT
Your proposed split is the right one. ✅
Three things I would add.
Check the 60 percent match threshold before you conclude that anything is unsupported. Per the classification reference, system classifications require 60 percent of the values in a column to match, and that value is not configurable. A surname column with many nulls or free text can fall below it and simply never classify.
Label at the asset grain rather than the column grain. Full Name and Date of Birth cannot trigger a label, but they nearly always sit in the same table as something that can. Labelling the asset from the strong identifier, and treating the surrounding columns as in scope by association, is cruder, but it holds up better in an audit than a half labelled table.
Be clear about what the label actually does. In Data Map the label is metadata on the asset, it does not protect the Azure SQL data itself, as the FAQ notes. So the CDE, glossary and access control track is not a fallback for unsupported classifications, it is the enforcement layer either way. The label gives you discovery, reporting and consistency with your M365 estate.
One last practical point. If you have not already, set detection criteria to Any of these rather than the default All of these. The labelling best practices article covers this, the default requires every listed SIT to be present in the asset, which for a mixed PII table is almost never what you want.
https://learn.microsoft.com/purview/data-gov-best-practices-sensitivity-labels
Thanks for the above
I have updated my summary;
Requirement Explanation
The purpose of this requirement is to define how Microsoft Purview identifies Personally Identifiable Information (PII) and how that information can be automatically assigned the proposed sensitivity label PERSONAL DATA using Microsoft Purview Information Protection.
Microsoft Purview Data Map scans supported data sources and applies classifications to tables and columns based on the data it detects. These classifications describe what type of information has been found, such as a National Insurance Number, Passport Number or Email Address.
However, a detected classification does not automatically mean that a sensitivity label can be applied. Microsoft Purview Data Map classification scanning and Information Protection sensitivity auto-labelling are separate capabilities with different supported rule sets.
A sensitivity label can only be applied automatically when the detected classification has a corresponding Microsoft built-in Sensitive Information Type (SIT) that is supported by the Data Map auto-labelling policy and is available within the tenant's policy rule picker.
The proposed sensitivity label for this implementation is: PERSONAL DATA
Initially, Azure SQL Database will be used to configure and validate native Microsoft Purview Data Map sensitivity auto-labelling. SharePoint and Azure Databricks Unity Catalog will also be assessed to determine which classification and sensitivity-labelling capabilities are supported. Where native auto-labelling is unavailable, an alternative governed metadata or tagging approach will be defined.
What the Image Demonstrates
The image explains the relationship between Microsoft Purview Data Map classifications and Microsoft Purview Information Protection sensitivity auto-labelling.
It demonstrates that there is not always a one-to-one relationship between a detected classification and a sensitivity label.
The process shown is:
- Microsoft Purview scans a supported data source.
- Data Map detects and applies one or more classifications to the relevant table or column.
- Microsoft Purview checks whether that classification has a corresponding supported Microsoft built-in Sensitive Information Type that can be used within the auto-labelling policy.
- If a supported match exists, the policy automatically applies the proposed sensitivity label PERSONAL DATA to the Microsoft Purview Data Map column metadata.
- If no supported match exists, the classification remains visible in Microsoft Purview, but the sensitivity label is not automatically applied.
The reference table shows, for each common UK personal-data classification:
- the Microsoft Purview Data Map classification;
- the corresponding Microsoft built-in Sensitive Information Type (where one exists);
- whether it can currently trigger the proposed sensitivity label;
- and the reason why it can, cannot or requires further validation.
The image also highlights the current Microsoft limitations. Some classifications, such as U.K. National Insurance Number, Passport Number and NHS Number, have corresponding built-in Sensitive Information Types that can typically be used for native auto-labelling. Other classifications, such as All Full Names and All Physical Addresses, are advanced named entities and are not currently supported as native Data Map auto-labelling conditions. Some classifications, including Email Address and Date of Birth, require validation within the organisation's Microsoft Purview tenant because Microsoft does not publicly confirm a one-to-one mapping for Data Map auto-labelling.
Overall, the image provides a governance reference that helps Data Owners, Data Stewards, Information Governance teams and Microsoft Purview administrators understand which detected PII classifications can automatically receive the proposed PERSONAL DATA sensitivity label, which require further validation, and which are not currently supported by Microsoft Purview Data Map sensitivity auto-labelling.