When I started exploring Microsoft Purview, my original goal was fairly simple. I wanted to understand how
Microsoft identifies sensitive information such as Social Security Numbers and credit card numbers, and then
see how that information could be used to protect organizational data.
That sounded straightforward enough.
As with many Microsoft technologies, the real learning started once I stopped reading documentation and
started clicking buttons.
My first stop was Information Protection inside Microsoft Purview. While browsing Sensitive Information
Types, I discovered there were more than 200 built-in classifiers available, including U.S. Social Security
Numbers, credit card numbers, banking information, passport numbers, and many others.
The U.S. Social Security Number classifier immediately caught my attention.
At first, I assumed Microsoft was simply looking for a pattern that matched an SSN format such as
123-45-6789. That assumption turned out to be wrong.
Using the built-in testing capability, I created a sample file containing an SSN and a credit card number.
To my surprise, the classifier reported that no sensitive information was found.
That result raised an obvious question.
Why didn't it match?
Digging deeper into the classifier definition revealed several important clues. The classifier wasn't using
a simple pattern match. It relied on function processors, confidence levels, and supporting evidence. Buried
in the configuration was a requirement that a valid SSN must be found along with supporting keywords related
to Social Security Numbers.
That discovery completely changed how I viewed the feature.
I began experimenting.
The value 123-45-6789 didn't generate a match. Neither did several other common test values. However, when I
supplied a different number along with supporting keywords such as "SSN" or "Social Security Number," the
classifier immediately detected the information with low, medium, and high confidence ratings.
At that point I had proven the classifier worked.
The next question became far more interesting.
Where is this classifier actually used?
That investigation eventually led me into Data Loss Prevention policies.
I created a new DLP policy using Microsoft's U.S. State Social Security Number Confidentiality Laws
template. During the policy creation process I learned that the policy wasn't simply looking for Social
Security Numbers. It was looking for Social Security Numbers being shared outside the organization.
That distinction is important.
A classifier identifies information.
A policy determines when that information becomes important enough to act upon.
Rather than enabling blocking actions immediately, I enabled Simulation Mode with notifications. This
allowed me to safely test the policy without affecting email delivery or disrupting anything in the
tenant.
That decision reminded me of another lesson learned while working with Conditional Access policies in
Report-only mode.
Test first. Enforce later.
To keep the experiment focused, I restricted the policy scope to Exchange Online and removed SharePoint,
OneDrive, Teams, and other locations from the policy scope. The goal was to test a single scenario and
understand the results before introducing additional variables.
With the policy deployed, I sent an email containing a valid Social Security Number to an external Gmail
account that I control.
The result was immediate.
The email was delivered successfully because the policy was operating in simulation mode. However, Microsoft
also generated DLP notifications explaining exactly why the policy matched.
The notification identified two conditions:
• The message was sent outside the organization.
• The message contained a U.S. Social Security Number.
Success.
But the most valuable lesson came from additional testing.
I sent another email containing the same valid number but removed the "SSN" and "Social Security Number"
keywords. The number appeared by itself with no supporting context.
This time there were no DLP notifications.
That result aligned perfectly with the classifier definition I had examined earlier. Purview wasn't simply
looking for number patterns. It was evaluating context and evidence before concluding that the content was
actually a Social Security Number.
To confirm the theory, I sent a third message containing the phrase "Social Security Number" along with the
same number.
The policy triggered again.
That final test tied everything together.
By the end of the lab I had learned several valuable lessons:
• Sensitive Information Types are far more sophisticated than simple pattern matching.
• Purview uses supporting evidence and confidence levels to reduce false positives.
• Classifiers identify information, but policies determine when detection matters.
• Simulation Mode is an excellent way to learn DLP safely.
• Small, focused tests make troubleshooting and learning significantly easier.
What started as a simple experiment to see whether Microsoft could recognize a Social Security Number turned
into a deeper lesson about classification, governance, compliance, and data protection.
More importantly, it reinforced a lesson that seems to appear in almost every technology lab I
build.
Understanding why something works is usually far more valuable than simply knowing that it works.
Not a bad rabbit hole for a Tuesday morning. 🐦🐦