3.2 Exact Data Match Sensitive Info Types

Pattern-based SITs are excellent at "this looks like a U.S. Social Security number." They are poor at "this is our patient 219-09-9999, not a random nine-digit string." Exact Data Match (EDM) based classification closes that gap. You supply a sensitive information source table of real values. Microsoft Purview hashes those values with a salt and uploads only the hashes. At scan time, strings in documents and email are hashed the same way and compared to the table. A match means the exact (or configured near-exact) value from your dataset is present.

The SC-401 decision boundary is: exact values from a reference dataset—employee IDs, account numbers, medical record numbers, customer account keys—not a shared form layout (fingerprint) and not unstructured prose (trainable classifier). EDM is designed to be dynamic and refreshable, to produce fewer false positives than generic patterns, to work with structured sensitive data, and to keep the clear-text table off Microsoft's service.

Microsoft documents that the database can be refreshed daily and can contain up to 100 million rows. EDM SITs can be used in Microsoft Purview Data Loss Prevention, auto-labeling (service side and client side), Insider Risk Management, eDiscovery, and Microsoft Defender for Cloud Apps. Locations include SharePoint, OneDrive, Teams chat, Exchange Online, devices, and Office clients depending on the service.

Schema, source table, and searchable fields

An EDM schema is an XML definition of the DataStore name and the fields that map 1:1 to column headers in the source table. The schema also records which fields are searchable, whether matching is case-insensitive, whether configurable matches ignore delimiters, and which corroborative fields need multi-token match mode.

The sensitive information source table is a text file of rows you want to detect. Save it as .csv, .tsv, or pipe-separated (|) text. Microsoft recommends .tsv when values contain commas (street addresses). Column header names cannot include spaces or underscores; they must start with a letter, contain at least three alphanumeric characters, and include only alphanumeric characters. Published table limits are:

A single schema can back multiple SITs that share the same table in the classic experience. The new EDM experience creates schema and SIT together in a 1:1 mapping, autogenerates the schema name as the SIT name plus schema, and therefore caps you at 10 EDM SITs unless you use classic or PowerShell. Use classic when you must map multiple SITs to one schema, manage more than 10 EDM SITs, specify a custom schema name, or edit schemas originally created in classic or uploaded as XML.

In the new experience you can upload a sample file with the same headers and 10–20 rows of representative, nonsensitive data. That sample is not hashed the way the real table is, and it is not retained after the SIT is created. The system recommends SITs for primary fields and generates high and medium confidence rules using the other fields as corroborative evidence.

Primary elements, supporting elements, and rule packages

Every EDM SIT has a rule package that defines how matches work:

• Match — the primary element used for exact lookup.
• Classification — the existing SIT that triggers the EDM lookup.
• Supporting elements — nearby evidence (last name, date of birth, phone) that raises confidence.
• Confidence level — High, Medium, or Low based on how much supporting evidence is found.
• Proximity — the number of characters between primary and supporting elements.

Primary elements must be discoverable through an existing SIT. If the primary column is U.S. Social Security number, associate it with the built-in U.S. Social Security Number (SSN) SIT. If no built-in SIT fits, create a custom SIT first. Primary fields should be strongly patterned: SSNs, account numbers, medical record numbers. Do not make FirstName, LastName, or DateOfBirth the only primary element. Names do not follow a tight pattern, and dates appear in almost every email, so those columns cause load, timeouts, and missed detections. Microsoft's new experience warns you if you map a primary field to a loosely defined SIT (for example a custom type that matches all personal identification numbers) or if the same primary value repeats across many rows.

Supporting (secondary) elements do not have to follow a pattern; EDM compares them to the text surrounding a primary hit. Multi-token matching lets fields such as Isaiah Langer or 1432 Lincoln Road match as whole strings when marked multi-token in the schema. If you set ignoredDelimiters (hyphens, slashes, hashes, and other nonalphanumeric characters), EDM can treat FOO-1234 and FOO#1234 as the same value. caseInsensitive treats FOO-1234 and fOo-1234 as identical. Those flags do not change how the classification SIT finds the primary string, so the mapped SIT must still detect values with and without those delimiters.

In the classic portal path, sign in to Microsoft Purview > Information Protection > Classifiers > EDM classifiers, turn the New EDM experience toggle Off, choose an existing schema, create patterns, pick confidence and primary element, map the primary element's SIT, add supporting elements, and submit. You can also author a Unicode XML rule package and upload it with New-DlpSensitiveInformationTypeRulePackage. There is a limit of 10 rule packages in a Microsoft 365 tenant; because a package can contain many SITs, export and extend an existing package instead of creating a new package for every type. Schema field changes take 10–60 minutes to update before you use the new fields.

Salt, hash, upload, indexing, and refresh

Because the table is highly sensitive, you encrypt values with a hash function that includes a randomly generated or self-supplied salt. Only hashed values are uploaded. You cannot use custom hashing; you must use the EDM Upload Agent on Windows 10 or later, Windows Server 2019 or later, or Windows Server 2016 with .NET 4.6.2.

Create a security group named EDM_DataUploaders and add the upload account. Best practice is the two-computer method: hash on a secure computer that does not need internet (EdmUploadAgent.exe /CreateHash), which writes .EdmHash and .EdmSalt files, then copy those files to an internet-connected computer that runs the same agent version, authorize it (/Authorize), and upload hashes (/UploadHash). The single-computer method hashes and uploads in one /UploadData step but leaves clear text on a machine that can reach the tenant. Validate formatting first with /ValidateData. After upload, verify with /GetDataStore and /GetSession. The new experience reports status such as Data not yet uploaded, Data upload complete, Indexing complete, Data upload failed, and Data indexing failed. Detection does not start until indexing completes.

When employees, patients, or accounts change, refresh the table: re-export the file (keep the same name and location if the schema is unchanged), rehash, and reupload. Compliance administrators can refresh the database up to 5 times in every 24-hour period. Each refresh overwrites the existing table. You can schedule the Upload Agent with Windows Task Scheduler or PowerShell. If column names change, update the schema and rule package before hashing.

Required roles for the EDM tasks in the get-started guidance are Global Administrator, Compliance Administrator, or Exchange Administrator; Microsoft recommends the least-privileged role that can complete the work. Groups Administrator is the least-privilege option for creating the EDM_DataUploaders group.

Exam traps

Do not upload the real table as the new-experience sample file. Do not pick email address or phone number as the only primary field if you can avoid it—Microsoft calls out the load risk. Do not map a primary column to a SIT that matches every word or every number (\b\w*\b). Combine a high-confidence EDM SIT with a lower-confidence built-in SIT in DLP when you want both exact hits and bulk pattern hits. If the question is about a blank HR form, that is fingerprinting, not EDM.