2.3 Create and Manage Custom Sensitive Info Types

The third blueprint bullet is Create and manage custom sensitive info types. Microsoft's create article (updated 2026-06-26) is the procedure you should memorize for the portal path, the copy path, and the PowerShell path. Custom SITs you create in the UI are added to the Microsoft.SCCManaged.CustomRulePack rule package. Built-in types stay in Microsoft Rule Package. Get-DlpSensitiveInformationType shows a Publisher other than Microsoft Corporation for custom types.

Microsoft Customer Service & Support cannot write your classification or regex. Engineers may share sample patterns for simulation or help troubleshoot a pattern that does not fire; they will not certify that your custom matcher meets legal obligations. On the exam, "open a Microsoft support ticket to generate the employee-ID regex" is the wrong answer.

Portal: create from scratch

1. Sign in at the Microsoft Purview portal.
2. Go to Information Protection > Classifiers > Sensitive info types and choose Create sensitive info type.
3. Enter Name and Description.
4. Create pattern. You may add multiple patterns, each with its own elements and confidence (Low / Medium / High).
5. Set the pattern's default confidence.
6. Define the Primary element: regular expression with optional validator, keyword list, keyword dictionary, or a preconfigured function.
7. Set Character proximity.
8. Optionally add supporting elements (they may have their own proximity) and additional checks.
9. Choose the recommended confidence for the SIT, then save.

Purview supports custom SITs in double-byte languages (Chinese simplified and traditional, Japanese, Korean). Because those languages do not delimit words the way single-byte languages do, Purview adds a space between each word and removes special characters such as punctuation. Plan keywords with and without that extra space, as in the previous section.

Regex rules the portal will reject

Microsoft 365 SITs use the Boost.RegEx 5.1.3 engine. Custom patterns must follow published rules:

• Do not use positional anchors ^ and $. Scanners do not guarantee that those anchors match the start or end of the whole item.
• Use exactly one primary capturing group. Put prefixes and suffixes in noncapturing groups: (?:prefix)(primary capturing group)(?:suffix).
• Put all match variants inside that one group with |. Multiple top-level capturing groups separated by | are blocked.

Invalid (three top-level capturing groups):

(?:[\s,;])([A-Z]{2}[0-9]{3})(?:[\s,;])|(?:[\s,;])([A-Z]{2}[A-Z]{4}[0-9])(?:[\s,;])|(?:[\s,;])([A-Z]{2}[0-9]{5})(?:[\s,;])

Valid (one capturing group, alternation inside):

(?:[\s,;])([A-Z]{2}[0-9]{3}|[A-Z]{2}[A-Z]{4}[0-9]|[A-Z]{2}[0-9]{5})(?:[\s,;])

PowerShell upload validation also rejects variable-length lookbehinds, alternators at the start or end of a pattern, certain unbounded repeaters in groups, and other performance hazards. Lookbehinds must be fixed length.

Portal: copy and modify

Open an existing SIT, choose Copy, then edit patterns. This is how you customize a built-in type without touching Microsoft Rule Package.

These SITs cannot be copied (published list):

• Canada driver's license number
• EU driver's license number
• EU national identification number
• EU passport number
• EU social security number or equivalent identification
• EU tax identification number
• International classification of diseases (ICD-10-CM)
• International classification of diseases (ICD-9-CM)
• U.S. driver's license number

Named entity SITs also cannot be copied or edited.

If a SIT has 10 text processors (keyword lists, regexes, keyword dictionaries, or functions), the UI will not copy it. Use PowerShell (Set-DlpSensitiveInformationTypeRulePackage after exporting XML) as documented in "Modify a custom sensitive information type using PowerShell."

Published configuration limits

Microsoft's Sensitive information type limits page (updated 2026-06-26) applies to Purview policies that use SITs:

Instance count when the SIT is used in DLP, Information Protection, Data Lifecycle Management, Communication Compliance, Records Management, Defender for Cloud Apps, and Priva: min 1–500; max 1–500 or Any.

The PowerShell create article adds operational notes: recommendedConfidence is required on each Entity; keyword dictionaries may also be described as 480 KB compressed for AD schema; a maximum of 50 keyword-dictionary-based SITs per tenant; deserialized return size is about 1 MB, with a suggested upload size around 770 KB for consistent processing. Prefer the dedicated limits table for portal quotas, and do not invent additional numbers.

PowerShell versus the portal

Use the portal when a handful of patterns, keyword lists, dictionaries, and validators will do. Use Security & Compliance PowerShell (not Exchange Online PowerShell for import) when you need XML-only features or packaging control.

Typical cmdlets:

• New-DlpSensitiveInformationTypeRulePackage -FileData ([System.IO.File]::ReadAllBytes('PathToUnicodeXMLFile')) — first upload. Save XML as Unicode.
• Set-DlpSensitiveInformationTypeRulePackage — update an existing package. Increment the Version; Microsoft 365 will not deploy an unchanged version number.
• Get-DlpSensitiveInformationTypeRulePackage / Get-DlpSensitiveInformationType — verify. Portal custom types live in Microsoft.SCCManaged.CustomRulePack.
• New-DlpKeywordDictionary / Get-DlpKeywordDictionary — large lexicons; reference the dictionary Identity GUID as idRef in XML.

Generate two GUIDs for a new package: one for the RulePack, one for the Entity (and matching Resource idRef). Localized Name/Description strings affect the Purview UI language only; they do not localize the regex.

XML gives you Any/minMatches/maxMatches, minCount, matchStyle word versus string, caseSensitive terms, uniqueResults, advanced checksum, and reusable Regex/Keyword children under Rule. Microsoft does not let you upload your own compiled functions; you may only reference built-in ones.

Changes can take up to one hour to appear in the Exchange admin center. Endpoint DLP classifies files against all SITs in the tenant, including custom types not used in any DLP policy. Untuned custom SITs that match most files create classification noise. Remove unused custom SITs and tighten patterns.

Test (simulation) before production

Microsoft recommends running a simulation for every SIT you create before a policy uses it.

• Test is greyed out unless the tenant has at least one Exchange Online license.
• Tests support unencrypted files only.
• You upload one file at a time.
• Prepare a positive sample that should match and a negative sample that should not.
• Results show match counts per confidence level.
• You can test built-in SITs, custom SITs, trainable classifiers, and EDM (EDM has its own test article).

Permissions are dual: a Purview role group and an Exchange / Entra role or role group. Purview groups listed for testing include Compliance Administrator, Compliance Data Administrator, Security Administrator, Communication Compliance Admins, Information Protection Admins, Information Protection Investigators, and Organization Management. Simulation-mode access is documented for Communication Compliance Admins, Information Protection Admins, Information Protection Investigators, and Organization Management.

After a SIT is live, Sensitive info types and Content explorer show match volume. Match / Not a match feedback is the published way to tune accuracy (see Increase classifier accuracy).

Because detection can differ across Exchange, SharePoint/OneDrive, and Endpoint DLP, a passing Test upload is necessary but not sufficient. Validate in each workload you will enforce. Content-extraction limits (file size and characters scanned) are documented with DLP platform considerations — do not invent a number.

Recrawl and on-demand classification

SharePoint and OneDrive classification uses the search crawler. Updated files recrawl automatically. Existing content will not show a brand-new custom SIT until it is recrawled. You can manually request crawling for a site collection, list, or library, or use on-demand classification to re-evaluate many locations at once.

When not to create a custom SIT

Create a custom SIT when you have a stable pattern Microsoft does not ship, or when you must copy a built-in type to change keywords, proximity, or confidence. Do not create a custom regex SIT when:

• You need exact database values → EDM (next chapter).
• You need form/template detection → document fingerprinting (New-DlpSensitiveInformationType with file bytes is a different workflow).
• You need example-based detection of unstructured documents → trainable classifiers.
• A named entity already detects names, addresses, or medical terms.
• A built-in SIT already implements the checksum and keywords you need.

Those later classifiers still appear as SITs or classifiers in the portal, but they are not "Create sensitive info type" regex objects. SC-401 will punish the admin who writes \d{9} to approximate an HR system of record.

Management checklist

• Name SITs after the business identifier, not after a DLP action.
• Keep unused custom SITs out of the tenant; Endpoint DLP still classifies against them.
• After XML edits, bump Version and re-upload with Set-DlpSensitiveInformationTypeRulePackage.
• After portal creates, Refresh the Sensitive info types list.
• Recrawl SharePoint/OneDrive (or run on-demand classification).
• Test positive and negative unencrypted samples; then simulate the actual DLP or auto-label policy.
• Record that CSS will not own your regex.

If you can create or copy a SIT within published limits, test it, recrawl where needed, and explain why you did not use EDM, fingerprinting, or a trainable classifier, you have completed this skill.