Microsoft Purview classification explained: sensitive info types, trainable classifiers, EDM · Microsoft Purview

Classification is the layer every downstream control reads — DLP, auto-labeling, retention and DSPM all ask it 'is this sensitive?'. SITs, trainable classifiers and EDM are the three ways it answers, and tuning them is the difference between real coverage and a flood of false positives.

The three detectors

Detector	What it matches	Best for	The trap
Sensitive information types (SITs)	Regex patterns + supporting evidence (keywords, checksums, proximity), scored to a confidence level (low/medium/high)	Structured identifiers — card numbers (Luhn-checked), national IDs, passport numbers	A bare pattern (any 16 digits) fires on invoices and part numbers unless corroborating evidence and confidence are set
Trainable classifiers	An ML model trained on example content (built-in or your own seeded set)	Categories no regex catches — contracts, resumes, source code, harassment/threat	Needs a clean seed set and a feedback loop; drifts silently as your content changes
Exact data match (EDM)	Your ACTUAL records (a hashed customer/patient list) rather than a generic shape	Precision on known data — real account numbers, not any number of that length	Requires a schema, a hash-and-upload pipeline, and refreshes; stale EDM = missed matches

Confidence and count — the two dials that decide noise

A SIT match carries a confidence level and an instance count. Every policy that consumes classification (DLP conditions, auto-label rules) filters on these. The most common false-positive cause is a policy keyed to any match at low confidence with a count of 1 — that catches every stray pattern in the estate. Raising the confidence floor and requiring N instances is the first tuning lever, and it is done in the consuming policy, not in the SIT itself.

EDM: matching YOUR data, not a shape

EDM is the precision instrument. You define a schema, hash a sensitive table locally with the upload agent (EdmUploadAgent), and upload only the hashes — the plaintext never leaves your control. Policies then match on real values. This is how you cut the "any 9 digits looks like an SSN" noise down to "these specific SSNs we actually hold." The cost is operational: the dataset must be refreshed on a cadence or matches decay as records change.

Trainable classifiers and the feedback trap

Built-in classifiers ship ready; custom ones need ~50–500 seed items and a publish-then-validate cycle. The failure mode is treating a classifier as fire-and-forget: without periodic match review (confirming true/false positives back into the model), accuracy drifts as the language and formats in your content evolve. Classifiers are a program, not a setting.

Why this is the foundation

Labels, DLP and DSPM findings inherit the quality of this layer wholesale. A mis-tuned SIT produces either a flood (users learn to ignore alerts) or silence (leaks sail through). "Get classification right before building policies" is not a slogan — a policy on bad classification is worse than no policy, because it manufactures confidence.

What to watch (proofs)

Inventory the detectors: Get-DlpSensitiveInformationType for the active SITs and their confidence definitions; Get-DlpEdmSchema for EDM datasets and their last refresh — a stale EDM date is a silent coverage hole.
Match volumes by SIT and confidence (Purview classification/content explorer) — a SIT firing at implausible volume is mis-tuned; one never firing is dead weight or a broken pattern.
Classifier accuracy: the match-review true/false-positive split per trainable classifier — the drift signal that says a retrain is due.
The consuming-policy floor: confirm DLP/auto-label rules specify a confidence level and instance count, not "any match" — the single biggest false-positive source, checked in Get-DlpComplianceRule output.

The classification engine: SITs, classifiers, EDM