Stop Tuning DLP Patterns. Match Your Actual Records Instead.

There are two ways to teach Microsoft 365 what a Social Security number is. You can describe its shape, three digits, dash, two digits, dash, four digits, and accept that phone numbers, project codes, and invoice numbers share that shape. Or you can hand it a hashed copy of the actual SSNs you hold and tell it to block exactly those.

The first approach is standard pattern-based DLP, and it is why so many deployments collapse: the rule flags everything that looks right, users start overriding policies, admins start ignoring alerts, and the program quietly dies. The second approach is Exact Data Match (EDM), and this is the full setup, command by command.

Why matching real data beats matching patterns#

With EDM, you upload a hashed copy of your actual sensitive database (employee records, customer data, whatever needs protecting), and DLP checks content against that real data. Finds an actual record from your database? Blocked. Finds a string that merely resembles one? Passes.

The practical difference: an HR onboarding packet containing a real employee's SSN gets blocked, while a budget spreadsheet that happens to use the same format for project codes sails through. No false positive, no alert fatigue.

What you need before you start#

• Microsoft 365 E5 or a Purview Suite add-on (the add-on can bolt onto Business Premium)
• Compliance Admin or Global Admin permissions
• Your sensitive data in a clean CSV file: no empty cells, no duplicate rows

Build the classifier schema#

Go to purview.microsoft.com > Solutions > Information Protection > Classifiers > EDM classifiers and click Create EDM classifier. Microsoft's workflow reference is here (opens in new tab).

Name it and upload a sample data file. Use fake data in the same format as your real data: the sample file is uploaded in plain text, not hashed, so never put actual sensitive records in it. The system reads your column headers and builds the schema automatically.

Choose a match mode per column#

• Single-token for values with no spaces (SSNs, employee IDs, emails, dates). EDM matches the exact string as one unit.
• Multi-token for values with spaces (full names, department names). EDM matches each word independently, so "Rachel Whitmore" also catches "Whitmore, Rachel."

Pick primary elements carefully#

This is the most consequential decision in the whole setup. Primary elements are the fields EDM looks for first, and if it does not find one, it stops searching entirely. Choose fields that are both unique and likely to appear in any document containing the sensitive data.

Good choices: SSN, linked to the built-in U.S. Social Security Number SIT, and Employee ID, linked to a custom SIT matching your ID format. Everything else (names, dates, emails, departments) becomes a supporting field that raises confidence when found near a primary element. Primary elements are the trigger; supporting fields are the proof.

Set the confidence tiers#

EDM grades each hit by how much supporting evidence sits within 300 characters of the primary element:

• High confidence: primary field plus 2 or more supporting fields
• Medium confidence: primary field plus 1 supporting field
• Low confidence: primary field alone (disabled by default)

Requiring more supporting evidence means fewer false positives but a higher chance of missing real matches. The defaults are solid for most environments.

Hash locally, upload safely#

This step is where people worry about shipping sensitive data to Microsoft. Don't. Your data is hashed locally on your machine before anything uploads. Microsoft only sees scrambled, one-way cryptographic hashes that cannot be reversed. The hash-and-upload reference is on Microsoft Learn (opens in new tab).

One-time setup#

1. Create an EDM_DataUploaders security group in Entra ID and add your admin account. Skip this and the upload agent will not authorize.
2. Install the EDM Upload Agent from Microsoft.
3. Authorize it by running EdmUploadAgent.exe /Authorize and signing in.

The three commands#

Download your schema. Wait at least one hour after creating it in Purview first; the system needs time to sync:

EdmUploadAgent.exe /SaveSchema /DataStoreName "YourSchemaName" /OutputDir "C:\EDMData"

Validate your data file:

EdmUploadAgent.exe /ValidateData /DataFile "C:\EDMData\employees.csv" /Schema "C:\EDMData\YourSchema.xml"

Hash and upload:

EdmUploadAgent.exe /UploadData /DataStoreName "YourSchemaName" /DataFile "C:\EDMData\employees.csv" /HashLocation "C:\EDMData\Hashed" /Schema "C:\EDMData\YourSchema.xml"

Watch Purview for an Index complete status and you are done. For production, schedule the upload as a recurring task: employees come and go, and the matched dataset has to stay current.

If you hit the maximumNumberOfTokens error#

A schema validation error complaining that maximumNumberOfTokens is missing almost always means you did not wait long enough after creating the schema, so the downloaded schema file is out of sync. Wait an hour, re-download with /SaveSchema, and try again. Also make sure you are on the latest upload agent version, and never manually edit the XML schema file: the agent adds internal tags during download that break if modified.

Wire the classifier into a DLP policy#

In Purview, go to Data Loss Prevention > Policies > Create Policy and choose Custom > Custom policy.

Apply it to Exchange email, SharePoint, OneDrive, and Teams. Create a rule with the condition Content contains your EDM sensitive info type at High confidence with an instance count of 1.

For actions: block external sharing, show a policy tip explaining why the content was blocked, and send incident alerts to your compliance team.

Then the rule we consider non-negotiable: start in simulation mode. Let it run for a week or two, review what triggers, and only then switch to enforced.

What it looks like when it works#

An HR coordinator attaches an onboarding packet with a real employee's SSN, employee ID, and department to an email headed for an external vendor. Blocked, with a policy tip telling her why.

The same coordinator sends a quarterly budget spreadsheet that uses employee ID formats as project codes. It goes right through. EDM checked it against the database, found no matching record, and let it pass.

That is the whole difference between pattern matching and exact data matching: one creates noise, the other creates protection. If false positives are the reason you have been avoiding DLP, EDM changes the equation, and it is worth the setup time.