Forum Discussion
Microsoft Purview Data Map Sensitivity Labelling
I'm testing the new Microsoft Purview Data Map Sensitivity Labelling capability against Azure SQL and have a question about the relationship between Data Map classifications and Information Protection auto-labelling.
My goal is to automatically apply a sensitivity label such as PERSONAL DATA to Data Map assets and columns when PII is detected.
Examples of the PII classifications I'm interested in include:
- All Full Names
- Email Address
- Date of Birth
- Ethnic Group
- Person Age
- Person Gender
- Personal IP Address
- UK Driving Licence Number
- UK Electoral Roll Number
- UK NHS Number
- UK Passport Number
- UK UTR
- National Insurance Number
- Payment Card Number
- Other common personal identifiers
From my testing, it appears that Data Map classifications and Microsoft Purview Information Protection auto-labelling use different detection engines and different supported rule sets.
For example:
| Data detected | Data Map classification | Can directly trigger the Data Map Sensitivity Label? |
|---|---|---|
| Full Name | Yes | No |
| Date of Birth | Yes, or detected through schema and context | No |
| Email Address | Yes | Not available in my tenant's rule picker |
| National Insurance Number | Yes | Yes |
| UK Passport Number | Yes | Yes |
| Payment Card Number | Yes | Yes |
This suggests that Purview can classify many types of personal data during scanning, but only a subset of those classifications are available as conditions in the Data Map auto-labelling policy.
My questions are:
- Is this the expected behaviour, or am I missing additional configuration?
- Is there a published mapping between Data Map classifications and the supported Sensitive Information Types (SITs) that can trigger Data Map sensitivity labels?
- Can custom Sensitive Information Types be used for Data Map auto-labelling, or are only Microsoft prebuilt SITs supported?
- Is there a roadmap for supporting classifications such as All Full Names, Date of Birth, Email Address, Person Age, Person Gender and similar PII as auto-labelling triggers?
- How are other organisations implementing a consistent PII handling model when many common personal-data classifications cannot currently trigger a Data Map sensitivity label?
At present, my understanding is that the practical approach is:
- Use supported auto-labelling for eligible identifiers, such as National Insurance numbers and passport numbers.
- For classifications that cannot trigger a sensitivity label, such as Full Name or Date of Birth, use governance metadata such as custom attributes, glossary terms or Critical Data Elements (CDEs), together with governance policies and access controls.
I'd be interested to hear how others are implementing this in enterprise Purview environments and whether there are any recommended patterns from the Microsoft product team.
4 Replies
Your testing has corrected two things in my earlier answer, and both corrections are right. Worth stating clearly so anyone reading this later gets the accurate version.
FIRST CORRECTION, AND IT MATTERS FOR YOUR SCOPE
I implied that UK Unique Taxpayer Reference and Electoral Roll Number would need a custom SIT. That was wrong. Both exist as Microsoft built-in sensitive information types.
https://learn.microsoft.com/purview/sit-defn-uk-unique-taxpayer-reference-number
https://learn.microsoft.com/purview/sit-defn-uk-electoral-roll-number
Both also appear under RegEx Classifications in the Data Map list, so all six of the UK identifiers in your summary have a built-in SIT behind them. You can drop the hedge in your requirement document. The only caveat left is tenant rule picker availability, which is a tenant state question rather than a platform limitation.
Do note that both are medium confidence and keyword dependent within a 300 character proximity. Electoral Roll is two letters followed by one to four digits, which is a weak pattern on its own, so in a database column with no surrounding keywords it may under detect. Worth testing that one specifically rather than assuming parity with NI number.
SECOND CORRECTION
You are right that Date of Birth is pattern based rather than machine learning. It sits under RegEx Classifications, not under Machine Learning based classifications. I grouped it wrongly.
That also means the shortcut I gave you was incomplete. Ignoring the Machine Learning section is necessary but not sufficient, because the RegEx section contains entries with no standalone built-in SIT equivalent either, Date of Birth and Email being exactly those. The reliable test is per classification, checking whether a built-in SIT of the same name exists, rather than by section.
Your framing is more accurate than mine was. Machine learning classifications and advanced named entities are excluded by design. Pattern based classifications without a published standalone SIT are a separate category, excluded for a different reason.
ON COLUMN LEVEL VERSUS ASSET LEVEL
Your point that the confirmed native target for Azure SQL is column level metadata, and that table level inheritance should not be assumed, is a useful correction to what I suggested. My asset grain advice comes from file based estates and does not transfer cleanly here. Treat your tested behaviour as authoritative over my general advice.
ON YOUR THRESHOLD DISTINCTION
Separating the 60 percent threshold from rule picker availability is the right call, and it is a distinction worth keeping explicit in the document. They fail differently. A threshold failure means the classification never appears at all, so there is nothing to label. A picker failure means the classification is visible in Data Map but has no eligible condition. Two different investigations, and the symptom looks identical from a report.
Your summary is a better reference than anything Microsoft currently publishes on this. Worth considering posting the table publicly once you are through validation.
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.
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.
