Microsoft Purview Sensitive Information Types: Built-in vs Custom SITs, Regex and Exact Data Match

An enterprise guide to sensitive data classification, custom detection patterns, regular expressions, confidence levels and Exact Data Match in Microsoft Purview.

Introduction

Data protection begins with understanding what information an organization needs to protect.

Microsoft Purview provides Sensitive Information Types (SITs) to identify sensitive content across supported Microsoft 365 workloads and other integrated environments.

Organizations commonly use SITs to detect:

• Personal identification information
• Financial and banking information
• Credit card numbers
• Employee identifiers
• Customer account numbers
• Healthcare-related information
• Business-specific reference numbers
• Confidential records and regulated data

However, selecting the correct detection method is one of the most important decisions in a Microsoft Purview deployment.

Should an organization use a built-in Sensitive Information Type?

Should it create a custom SIT using regular expressions?

Or should it implement Exact Data Match to identify information belonging to actual customers or employees?

These approaches solve different problems.

In this article, I explain how each detection method works, when to use it, how to implement it and how to avoid common classification mistakes.

1. What Are Sensitive Information Types in Microsoft Purview?

A Sensitive Information Type is a classification mechanism that identifies content matching predefined or custom detection criteria.

Microsoft Purview uses SITs in supported features such as:

• Data Loss Prevention (DLP)
• Information Protection
• Data classification and discovery
• Auto-labeling policies
• eDiscovery scenarios

A SIT is not itself a DLP policy or a sensitivity label.

It identifies information. Other Microsoft Purview capabilities use the classification result to take action.

For example:

Document containing sensitive information → SIT detection → DLP policy evaluation → Alert or restriction

The detection logic and the enforcement logic are separate components.

This distinction is important when troubleshooting policies that do not behave as expected.

2. Understanding the Three Detection Approaches

Microsoft Purview supports several methods for identifying sensitive content.

Three important approaches are built-in SITs, custom SITs and Exact Data Match.

Architecture recommendation: Start with built-in SITs where appropriate. Introduce custom SITs when business-specific formats are required. Use EDM when identifying values belonging to an authoritative dataset is necessary.

3. Built-in Sensitive Information Types

Microsoft provides a collection of predefined Sensitive Information Types.

Examples include:

• Credit Card Number
• U.S. Social Security Number
• International Bank Account Number (IBAN)
• Country-specific identity numbers
• Passport and other identification formats

Built-in SITs may combine regular expressions, keywords, checksums and supporting evidence.

Example: Credit card detection

A built-in credit card SIT can evaluate more than whether a document contains a sequence of digits.

Depending on the detection pattern, additional evidence or validation may be involved.

This helps reduce false positives compared with a simple regular expression.

When to use built-in SITs

Built-in SITs are usually the preferred starting point when:

1. Microsoft already supports the required data format.
2. The organization does not require a unique identifier format.
3. The detection logic is appropriate for the business requirement.
4. The SIT produces acceptable results during testing.

Important limitation

A built-in SIT detects values matching its configured definition.

It does not necessarily establish that the detected value belongs to the organization’s actual customers or employees.

That distinction is one reason Exact Data Match exists.

4. Custom Sensitive Information Types

Custom SITs allow organizations to define their own detection patterns.

These are particularly useful for business-specific information that is not covered by Microsoft’s predefined classifiers.

Examples include:

• Employee identification numbers
• Internal contract references
• Customer account numbers
• Insurance policy identifiers
• Banking customer references
• Internal case numbers
• Business-specific document identifiers

Example: Employee identifier

Suppose an organization uses employee IDs in this format:

EMP-123456

The format contains:

• The prefix EMP
• A hyphen
• Six digits

A custom SIT can be created to identify this pattern.

However, simply detecting the format may produce false positives if similar strings appear in unrelated documents.

Supporting keywords and confidence levels can improve detection quality.

5. Anatomy of a Custom SIT

A custom Sensitive Information Type can contain several detection components.

Primary element

The primary element can use:

• Regular expressions
• Keyword lists
• Keyword dictionaries
• Supported functions

Supporting elements

Supporting elements provide contextual evidence.

For example, the employee identifier EMP-123456 may appear near:

• Employee ID
• Staff Number
• Personnel Number
• Employee Reference

These keywords help distinguish an employee identifier from a similar-looking random string.

Confidence levels

Microsoft Purview uses three confidence levels:

• Low
• Medium
• High

Higher-confidence patterns generally require stronger evidence.

A higher confidence level can reduce false positives but may increase false negatives.

Best practice: Configure confidence levels according to the reliability of the detection evidence, not simply according to how sensitive the data is.

6. Creating a Custom SIT in Microsoft Purview

To create a custom Sensitive Information Type:

1. Sign in to the Microsoft Purview portal at https://purview.microsoft.com.
2. Navigate to Information Protection → Classifiers → Sensitive info types.
3. Select Create sensitive info type.
4. Enter a descriptive name.
5. Add a business-focused description.
6. Create a detection pattern.
7. Select the confidence level.
8. Configure the primary element.
9. Add supporting elements where appropriate.
10. Configure character proximity.
11. Review additional checks.
12. Save the SIT.
13. Test it with representative synthetic content.

Naming example

Name: CORP - Employee Identifier

Description: Detects internal employee identifiers following the organization’s approved numbering convention.

Use a naming standard that clearly separates custom classifiers from Microsoft-provided classifiers.

This simplifies administration, change management and troubleshooting.

7. Regular Expressions in Microsoft Purview

Regular expressions, commonly called regex, are patterns used to identify text with a defined structure.

For example:

EMP-123456

A simple regex for this format is:

EMP-[0-9]{6}

This matches the prefix followed by six digits.

However, Microsoft Purview custom SIT regex patterns have specific requirements.

Microsoft documents the use of the Boost.RegEx 5.1.3 engine for custom SITs.

Custom SIT regex patterns must use exactly one primary capturing group. Other grouping should use noncapturing groups.

Example: Recommended structure

(EMP-[0-9]{6})

This uses one capturing group for the primary match.

Example: Supporting multiple formats

Suppose the organization supports:

• EMP-123456
• STF-123456

A single capturing group can handle both formats:

((?:EMP|STF)-[0-9]{6})

The inner group is noncapturing.

The outer group captures the primary value.

Important regex rules

Microsoft documents the following requirements:

• Use exactly one primary capturing group.
• Use noncapturing groups for other grouping.
• Place alternative primary match formats inside the same capturing group.
• Avoid positional anchors such as ^ and $ in custom SIT patterns.
• Validate regex behavior in Microsoft Purview, not only in external regex testers.

A regex that works in another programming language or online tester may not behave identically in Microsoft Purview.

8. Supporting Keywords and Character Proximity

Regex identifies structure.

Supporting keywords provide context.

Consider this document:

Employee ID: EMP-123456

The primary regex detects:

EMP-123456

A supporting keyword list might include:

• Employee ID
• Staff Number
• Personnel Number

If the supporting keyword appears within the configured character proximity, the SIT can match a higher-confidence pattern.

Example design

A proximity value of 300 characters is a useful starting point recommended in Microsoft’s false-positive reduction guidance, but it should be validated against actual document structures.

For large tables, the correct proximity configuration may differ from ordinary documents.

Why proximity matters

A proximity that is too restrictive can miss valid matches.

A proximity that is too broad can associate unrelated keywords with a value, increasing false positives.

Test both conditions.

9. Built-in vs Custom SIT: Choosing the Right Approach

Consider three business requirements.

Scenario A — Protect credit card numbers

A financial organization wants to detect credit card numbers in email attachments.

Recommended starting point: Built-in Credit Card Number SIT.

The organization should validate confidence levels, thresholds and detection results before creating a custom alternative.

Scenario B — Protect internal contract references

A company uses identifiers such as:

CTR-2026-123456

Microsoft does not necessarily provide a built-in SIT for this proprietary format.

Recommended approach: Custom SIT using regex and supporting keywords.

Scenario C — Protect actual customer records

A bank wants to identify customer account information belonging to its own customer database.

Detecting every number matching the account-number format may generate too many irrelevant matches.

Recommended approach: Evaluate Exact Data Match.

EDM can compare detected values against an organization-supplied reference dataset.

10. What Is Exact Data Match?

Exact Data Match, or EDM, is a Microsoft Purview classification capability designed to identify sensitive information using reference data supplied by an organization.

Unlike a conventional custom SIT that identifies generic patterns, EDM can validate whether detected information corresponds to records in an authoritative dataset.

Example

A bank maintains a customer dataset containing:

All values are fictional.

A conventional regex might detect many ten-digit numbers.

An EDM classifier can be configured to identify account values represented in the organization’s uploaded reference data, using its configured primary and supporting fields.

Important distinction

EDM does not simply search arbitrary content for every row in a CSV file.

The classifier uses a primary element associated with a detectable SIT, then performs the configured exact-data matching process.

Supporting fields can provide additional evidence.

11. EDM Architecture and Data Protection

A typical EDM implementation involves:

1. Identifying an authoritative data source.
2. Designing the EDM schema.
3. Selecting primary and supporting fields.
4. Creating the EDM classifier.
5. Preparing the source dataset.
6. Hashing the sensitive data.
7. Uploading the hashed reference data.
8. Testing the classifier.
9. Integrating the EDM SIT into supported protection policies.

Why hashing matters

Microsoft’s EDM workflow uses hashing with a salt value before reference data is uploaded.

The EDM Upload Agent performs the supported hashing and upload process.

This reduces exposure of the original sensitive reference dataset.

For higher-security environments, Microsoft recommends separating hashing and uploading across two computers.

Security recommendations

• Restrict access to the original reference dataset.
• Use a dedicated upload identity with appropriate permissions.
• Protect intermediate files and hashing material.
• Follow Microsoft’s documented EDM Upload Agent process.
• Avoid copying production customer data into unmanaged test environments.
• Establish a secure dataset refresh procedure.

Important: EDM hashing is part of the supported Microsoft workflow. Do not replace it with a custom hashing implementation.

12. Designing an EDM Schema

The EDM schema defines the fields used for classification.

For example:

The primary element must be associated with an appropriate SIT capable of discovering candidate values.

Supporting elements help establish the relationship between detected content and the reference data.

Design considerations

Choose the primary field carefully.

A primary identifier that is too generic can produce unnecessary scanning overhead.

Microsoft specifically warns against selecting overly broad classifiers that match large amounts of irrelevant text or numbers.

Use the narrowest reliable detector for the primary field.

13. EDM Deployment Workflow

An enterprise EDM implementation should follow a controlled sequence.

Phase 1 — Discovery

Identify:

• The business requirement
• The authoritative source system
• The sensitive fields
• The required protection actions
• The relevant Microsoft 365 workloads

Phase 2 — Schema design

Define the primary and supporting fields.

Confirm that the primary element has an appropriate SIT.

Phase 3 — Dataset preparation

Export the approved reference data in a supported format.

Validate column names, delimiters, encoding and source-data quality.

Phase 4 — Hash and upload

Use the Microsoft EDM Upload Agent.

The supported workflow includes data validation, hashing and upload.

Phase 5 — Classification testing

Use synthetic or approved test records.

Verify that expected values match and unrelated values do not.

Phase 6 — Policy integration

Reference the EDM SIT in a supported DLP or classification scenario.

Start with a controlled pilot and review results before enforcement.

Phase 7 — Operations

Document how the reference dataset will be updated as records change.

EDM is not a one-time configuration when the underlying business dataset changes regularly.

14. Common False Positives and False Negatives

Detection quality is as important as detection coverage.

False positive

A false positive occurs when content is classified as sensitive even though it does not meet the intended business meaning.

Example:

A regex intended to identify customer numbers also matches unrelated transaction references.

False negative

A false negative occurs when genuinely sensitive information is not detected.

Example:

A customer identifier appears in an unexpected format that the regex does not recognize.

Troubleshooting matrix

15. Microsoft Purview SIT Limits

Microsoft documents several limits that should be considered when designing custom SITs.

These are documented service limits and should be checked again before a large deployment because Microsoft can update them.

Avoid building unnecessarily complex regex patterns when a simpler combination of primary patterns, supporting keywords and separate SITs would be easier to maintain.

16. Testing Sensitive Information Types Before Production

A SIT should be tested independently before it is used in an enforcement policy.

Recommended test cases

For each test, document:

• Test file or message
• Expected detection
• Actual detection
• Confidence level
• Number of instances
• Applicable policy
• Remediation, if needed

A successful regex test outside Microsoft Purview is not sufficient evidence that a custom SIT is ready for production.

17. Integrating SITs with DLP Policies

After validating a SIT, it can be used in supported Microsoft Purview DLP policy conditions.

Example: Employee data protection

Policy: CORP - Employee Data Protection

Locations: Exchange, SharePoint and OneDrive

Condition: Content contains the custom employee identifier SIT.

Action: Audit and notify during the pilot, followed by approved restrictions.

Example: Customer data protection using EDM

Policy: CORP - Customer Records Protection

Condition: Content matches the approved EDM classifier.

Action: Restrict supported external sharing scenarios.

Recommended deployment sequence

1. Validate the SIT.
2. Configure a scoped DLP pilot.
3. Run simulation.
4. Review matches and false positives.
5. Tune the classifier and policy.
6. Obtain business approval.
7. Enable enforcement.
8. Monitor and optimize.

Architecture principle: A well-designed DLP policy cannot compensate for an unreliable classifier.

18. Enterprise Best Practices

For a production Microsoft Purview implementation, I recommend the following:

1. Reuse built-in SITs where appropriate. Avoid duplicating Microsoft-provided classifiers without a clear business reason.
2. Use custom SITs for business-specific formats. Combine regex with supporting evidence to improve accuracy.
3. Use EDM when reference-data validation matters. Generic pattern matching and exact-data matching solve different problems.
4. Separate classification testing from DLP enforcement testing. Confirm detection before investigating policy actions.
5. Use synthetic data during initial validation. Avoid exposing production customer information unnecessarily.
6. Establish naming and ownership standards. Every custom classifier should have an owner, purpose and change history.
7. Review false positives and false negatives. Detection quality should be measured, not assumed.
8. Document dataset refresh procedures for EDM. Classification quality depends on the reference data remaining current.
9. Apply least privilege. Restrict who can manage classifiers, upload EDM data and investigate sensitive content.
10. Treat SIT design as part of data security architecture. Classification should align with sensitivity labels, DLP policies and business risk.

Conclusion

Microsoft Purview Sensitive Information Types provide the foundation for identifying sensitive data across supported Microsoft 365 security and compliance scenarios.

However, successful classification requires choosing the appropriate detection approach.

Built-in SITs are a strong starting point for commonly recognized sensitive information.

Custom SITs provide flexibility for business-specific identifiers through regular expressions, keywords, proximity and confidence levels.

Exact Data Match extends classification by comparing detected information with an organization-controlled reference dataset.

The key is not to create as many classifiers as possible.

The objective is to create classifiers that are accurate, maintainable, testable and aligned with real business requirements.

For enterprise Microsoft Purview deployments, classification quality directly affects DLP effectiveness, investigation reliability and the organization’s ability to protect sensitive information.

Microsoft Learn References

1. Learn about Sensitive Information Types
2. Create custom Sensitive Information Types
3. Sensitive Information Type limits
4. Regular expressions in DLP policies
5. Customize a built-in Sensitive Information Type
6. Learn about Exact Data Match
7. Create an EDM SIT and rule package
8. Hash and upload EDM source data
9. Regex validators and additional checks
10. Reduce false positives in data classification