In today’s data-driven environment, organizations need strong and accurate controls to prevent sensitive information from being exposed, shared, or misused. Symantec Data Loss Prevention (DLP) helps security teams discover, monitor, and protect confidential data across endpoints, networks, storage systems, and cloud environments. By combining content awareness with flexible policy enforcement, Symantec DLP enables organizations to reduce risk while supporting regulatory compliance and protecting critical business information.
When it comes to protecting structured sensitive data, two important detection technologies in Symantec DLP are Exact Data Matching (EDM) and Exact Match Data Identifier (EMDI). Although these technologies are closely related and both enhance detection accuracy, they serve different purposes.
EDM works by comparing content against actual records from a protected database. For example, if your company wants to protect a list of real customer credit card numbers or employee IDs, EDM can detect when one of those exact records appears in an email, file, or other monitored channel.
EMDI is similar, but it is more flexible because it lets you use exact-match detection as a data identifier inside policies. For example, instead of only matching full database records, you can create an identifier based on sensitive values such as customer account numbers, national IDs, or patient IDs, and then use that identifier in different detection policies.
Understanding these differences is the foundation for making the right implementation decision. In the sections below, we will define EDM and EMDI in detail, walk through their configuration, and review practical test scenarios to demonstrate how each approach works in real-world environments.
When to use EMDI
EMDI (Exact Match Data Identifier) is designed for structured data where one important column can be tied to a data identifier, such as a credit card number, account number, or national ID. To use it, Symantec DLP requires an Exact Match Data Identifier Profile, a cleansed data source, and an EMDI validator added to a data identifier policy.
A common example is a bank protecting customer payment-card records. Instead of alerting on any number that merely looks like a card number, EMDI checks whether the value exists in the indexed source and whether related columns also match. Symantec requires at least one required key column mapped to an existing data identifier and at least one optional column in the profile.
How to configure EMDI
- Create a tabular text data source file from your database or repository.
- Cleanse the file before indexing.
- From Manage > Data Profile > Exact Data > Add EMDI profile:
- Upload or copy the source file to the Enforce Server.
- Check on read first Row as the column name.
4. Create an Exact Match Data Identifier Profile.
5. Mark columns as Required, Optional, or Ignored. At least one required column must be associated with an existing data identifier, and there must also be at least one optional column.
6. Run indexing immediately or schedule it. 
Create a policy for the data identifier ( Credit Card )
Then in Optional Validators:
When an EMDI match is found, Symantec DLP generates an incident
One important design point is that after the EMDI data source is indexed, its schema cannot be changed. If the column structure changes later, a new EMDI profile is required.
When to use EDM
EDM (Exact Data Matching) is designed for protecting structured records from databases or tabular files by creating an Exact Data Profile, mapping the fields, indexing the data source, and using that profile in policy conditions.
A good example is HR or payroll data. An organization may want to detect records such as employee name, employee ID, salary, department, and national ID when those values appear together in email, files, or other monitored channels. In this case, EDM is usually the better fit because it is built around an Exact Data Profile and exact record matching logic.
How to configure EDM
- Create & clean the EDM data source file.
- Export source data to a delimited tabular text file (comma).
- Upload/copy the file to Enforce
- Either upload it while creating the profile, or place it on the Enforce Server so it can be referenced.
- Map and validate columns correctly
- Map each column to the correct System Field (or custom field) so DLP can validate the format (example: Email → Email Address, Phone → Phone, National ID → relevant ID type, etc.).
- Index the profile
- Choose Submit Indexing Job on Save.
- Choose Submit Indexing Job on Save.
- Create the policy rule
- Add detection rule: Content Matches Exact Data From an Exact Data Profile.
- Select:
- The EDM profile
- The columns you want to match + optional WHERE clause filtering
- Set match logic (example):
- "1" for default
- IMPORTANT: Select the correct message components for content testing:
- Use Body and/or Attachments (Subject isn’t available for EDM).
- Use Body and/or Attachments (Subject isn’t available for EDM).
Testing
- Test (Trigger)
- Create a test text file (or email body / upload content) containing 3 fields from the SAME ROW in your EDM file (exact values).
- Send/upload it through a channel your DLP actually monitors (Web upload if you only have Network Prevent for Web).
- Expected result
- A new incident appears for that policy.
- A new incident appears for that policy.
Like EMDI, EDM also locks the schema after indexing . If the data source changes in structure, a new EDM index must be created and the related policies must be updated.
The Difference Between EMDI & EDM
The easiest way to explain the difference is this:
- EMDI starts with a data identifier and adds exact validation from an indexed source.
- EDM starts with an exact data profile and matches structured records directly from that profile.
Final Takeaway
If your data contains a strong identifier such as a credit card number, account number, or national identifier, and you want that identifier validated against real indexed records, EMDI is usually the simpler and more focused choice. If your goal is to protect a broader structured dataset such as HR, payroll, or customer master data, EDM is often the better option because it is built around full, exact data profiles and structured field mapping.