Microsoft Purview Exact Data Match: Precise Detection With Reference Data

Pattern Recognition and Record Recognition Are Different

A nine-digit number can resemble a national identifier without belonging to any person in the organization. A sixteen-digit sequence can pass a checksum without being a customer payment card. Pattern-based sensitive information types are valuable because they can recognize structured data that the organization has never seen before, but broad patterns can also match test data, examples, unrelated numbers, or another institution’s records.

Exact Data Match, or EDM, adds a second question: does the content correspond to a record in a reference dataset the organization already knows is sensitive? Microsoft Purview answers this without uploading the clear-text table as the matching source. The table is normalized, hashed, and uploaded for comparison.

Use EDM when membership in a known dataset changes the security decision. Employee identifiers, patient records, customer accounts, and regulated case lists are common conceptual examples. Do not use it merely because every false positive is inconvenient; the reference data, operating process, and residual blind spots must justify the added complexity.

The Primary Field Finds Candidates; Corroboration Finds the Record

An EDM schema describes the columns in the source table. One or more fields can be designated as primary elements and mapped to existing sensitive information types. The primary element should have a strong, recognizable pattern because it is used to find candidate values in content.

EDM then uses additional fields from the same source row as corroborative evidence. Imagine a customer identifier appearing near the customer’s surname and date of birth. Matching those values to one reference row provides a more specific basis than finding any identifier-shaped number near any name.

Microsoft warns that weakly defined primary elements can hurt performance and cause throttling or timeouts that lead to missed detection. Choose the primary element for distinctiveness and extraction reliability. Choose corroborators for discriminatory value, not simply because the table contains them.

Protect the Clear-Text Source Before You Think About Hashing

The clear-text source table is often among the most sensitive datasets in the program. Hashing before upload reduces exposure in the Purview matching service, but it does not protect the source export, the sample file, temporary copies, administrator credentials, the hashing computer, backups, or operational logs.

Define a data owner, approved export path, minimum required columns, transfer controls, secure hashing environment, authorized operators, retention period, update cadence, and deletion process for temporary files. Separate duties where risk warrants it. The source should be generated from an authoritative system rather than a manually accumulated spreadsheet whose provenance is unclear.

The Data Map can help identify ownership and classification of authoritative data sources. It does not automatically make an EDM extract correct. Validate population, duplicates, missing values, encoding, delimiters, and field meaning before hashing.

Treat the EDM Workflow as a Versioned Data Product

Microsoft’s current Microsoft EDM workflow describes phases for exporting source data, creating a sample, defining the EDM sensitive information type, hashing and uploading the source table, and testing the result. Each phase creates an artifact whose version matters.

The schema defines columns and field behavior. The sample helps create and validate the sensitive information type. The hashed table represents the reference population at a point in time. The policy determines where and how matches affect users. Record which versions were designed and tested together.

When the source or schema changes, use a controlled refresh. Confirm row counts and expected changes, hash and upload from approved systems, wait for processing, run known positive and negative tests, and record activation. A technically successful upload does not prove that the correct population was uploaded.

Normalization Determines Which Real-World Variations Still Match

Real content rarely preserves database formatting. Identifiers gain spaces or hyphens. Names change case. Dates appear in different formats. EDM supports schema options that can ignore selected delimiters or case differences for configured fields.

Every normalization choice changes the match boundary. Ignoring a delimiter can correctly match a formatted account number, but overly permissive normalization can merge values that the source treats as distinct. Document the canonical form and compare it with how users, applications, exports, and scanned documents actually represent the field.

Follow Microsoft EDM schema guidance for supported configuration, then test examples that differ in case, punctuation, spacing, optical character recognition, and surrounding evidence. Unsupported variation is not a product defect if the schema never defined it; it is a known coverage boundary.

Test False Positives and False Negatives as Separate Problems

A positive test should contain a real but safely controlled reference value with the expected corroborators. A near-match should contain a valid-looking primary value that is absent from the table. Boundary tests should vary distance, ordering, punctuation, case, and missing corroborators. Negative tests should include common content that previously caused false matches.

Test extraction formats as well as plain text. A detector can be logically correct while the content parser fails to expose text from a document, image, archive, or unsupported format. Confirm the workloads and policy features where the EDM sensitive information type is supported.

Use a simulation-first rollout with Purview DLP. Review matched evidence, nonmatches, user workflow, performance, and alert context before blocking. Precision is valuable only when important records are still detected.

Keep the Reference Population Fresh and Accountable

EDM is not a one-time classifier. New employees, customers, patients, cases, or accounts can be absent until the next upload. Retired records can continue to match if the table is not refreshed. The acceptable delay depends on what the policy protects and how quickly the source changes.

Monitor extract success, row counts, rejected data, hash and upload status, processing completion, test results, policy match trends, performance, false-positive investigations, and known false negatives. Alert when the refresh exceeds its expected age. Assign owners for the source, schema, uploader, sensitive information type, and consuming policies.

The result should be described precisely: Purview found content that matched the configured EDM schema and a row in the uploaded reference population. That is strong evidence of known sensitive data. It is not proof that the transfer was unauthorized or that the user acted maliciously; those remain policy and investigative questions.