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
I have completed more testing based on the above too - thanks for this helpful feedback.
Testing confirms that the observed behaviour is an expected Microsoft Purview limitation rather than a configuration error. Microsoft Purview Data Map can detect a broad range of classifications, but native sensitivity auto-labelling can use only eligible Microsoft built-in classifiers or Sensitive Information Types available within the Data Map auto-labelling policy.
Direct UK identifier matches including National Insurance Number, Driving Licence Number, NHS Number, Passport Number, Unique Taxpayer Reference and Electoral Roll Number are valid candidates for automatically applying the PERSONAL DATA sensitivity label, subject to confirming their availability in the tenant’s rule picker.
Other Data Map classifications do not have an eligible one-to-one auto-labelling condition. Person Name and Person Address rely on advanced named entities that Microsoft explicitly excludes. Person Age and Person Gender are machine-learning Data Map classifications without direct built-in SIT matches. Date of Birth and Email are pattern-based Data Map classifications, but Microsoft does not currently publish corresponding standalone built-in SITs for native Data Map auto-labelling.
The 60% classification threshold and scan sampling can affect whether a classification is detected, but they do not affect whether a SIT is available in the auto-labelling rule picker. For Azure SQL, the confirmed native target is column-level metadata; table-level inheritance should not be assumed.
The sensitivity label improves discovery, reporting and consistent governance, but it does not modify or directly protect the underlying Azure SQL data. Technical controls such as permissions, masking and encryption remain necessary, while glossary terms, CDEs, tags and custom attributes provide supporting governance context.
Where several alternative PII SITs should trigger the label, configure the rule using Any of these, rather than the default All of these, unless the label should apply only when every listed identifier is present.