Study guide
2.3 Create and Manage Custom Sensitive Info Types
SC-401: Administering Information Security in Microsoft 365 Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current SC-401 Exam Facts 1.2 Scoring, Retakes, and Annual Renewal 1.3 Role, Blueprint, and Prep Path
2 Data Classification Foundations
2.1 Identify Sensitive Information Requirements 2.2 Translate Requirements into Sensitive Info Types 2.3 Create and Manage Custom Sensitive Info Types
3 Specialized Classification Methods
3.1 Document Fingerprinting 3.2 Exact Data Match Sensitive Info Types 3.3 Trainable Classifiers
4 Classification Monitoring and OCR
4.1 Monitor Classification with Data Explorer and Content Explorer 4.2 Configure OCR Support for Sensitive Info Types
5 Sensitivity Label Design
5.1 Roles and Permissions for Sensitivity Labels 5.2 Define and Create Sensitivity Labels for Items and Containers 5.3 Protection Settings and Content Marking
6 Label Policies, Containers, and Defender for Cloud Apps
6.1 Configure Publishing Policies for Sensitivity Labels 6.2 Configure Auto-Labeling Policies 6.3 Apply Sensitivity Labels to Containers 6.4 Apply Sensitivity Labels with Microsoft Defender for Cloud Apps
7 Information Protection Client and Scanner
7.1 Plan and Implement the Microsoft Purview Information Protection Client 7.2 Manage Files with the Information Protection Client 7.3 Bulk Classification with the Information Protection Scanner
8 Microsoft Purview Message Encryption
8.1 Design and Implement Microsoft Purview Message Encryption 8.2 Design and Implement Advanced Message Encryption
9 DLP Policy Design
9.1 Design Data Loss Prevention Policies 9.2 Roles and Permissions for Data Loss Prevention 9.3 Create and Manage DLP Policies
10 Adaptive Protection, DLP Precedence, and MDCA File Policies
10.1 Configure DLP Policies for Adaptive Protection 10.2 Interpret DLP Policy and Rule Precedence 10.3 Create File Policies in Defender for Cloud Apps Using DLP
11 Endpoint DLP Configuration
11.1 Device Requirements for Endpoint DLP Including Extensions 11.2 Configure Advanced DLP Rules for Devices 11.3 Configure Endpoint DLP Settings
12 Just-in-Time Protection and Endpoint Monitoring
12.1 Configure Just-in-Time Protection 12.2 Monitor Endpoint Activities
13 Retention Labels and Adaptive Scopes
13.1 Plan Information Retention and Disposition with Retention Labels 13.2 Create and Manage Adaptive Policy Scopes 13.3 Create Retention Labels for Data Lifecycle Management
14 Publishing, Auto-Apply, and Retention Precedence
14.1 Publish Retention Labels 14.2 Auto-Apply Retention Labels 14.3 Retention Precedence and Policy Lookup
15 Retention Policies and Recovering Retained Content
15.1 Create and Configure Retention Policies 15.2 Recover Retained Content in Microsoft 365
16 Insider Risk Management Foundation
16.1 Roles and Permissions for Insider Risk Management 16.2 Plan and Implement Insider Risk Management Connectors 16.3 Integrate Insider Risk Management with Microsoft Defender for Endpoint
17 IRM Settings, Indicators, and Templates
17.1 Configure Insider Risk Management Settings 17.2 Configure Policy Indicators 17.3 Select an Appropriate Policy Template
18 IRM Policies, Forensic Evidence, and Adaptive Protection
18.1 Create and Manage Insider Risk Management Policies 18.2 Manage Forensic Evidence Settings 18.3 Enable Insider Risk Levels for Adaptive Protection
19 IRM Alerts, Cases, and Workflow
19.1 Manage Insider Risk Alerts and Cases 19.2 Insider Risk Workflow and Notice Templates
20 Purview Audit and Activity Explorer
20.1 Assign Microsoft Purview Audit (Premium) User Licenses 20.2 Investigate Activities with Microsoft Purview Audit 20.3 Configure Audit Retention Policies 20.4 Analyze Purview Activities with Activity Explorer
21 DLP, Insider Risk, and Defender XDR Alert Response
21.1 Respond to DLP Alerts in the Microsoft Purview Portal 21.2 Investigate Insider Risk Activities in the Microsoft Purview Portal 21.3 Respond to Purview Alerts in Microsoft Defender XDR
22 MDCA File Policy Alerts and eDiscovery
22.1 Respond to Defender for Cloud Apps File Policy Alerts 22.2 Perform Searches by Using eDiscovery
23 Protecting Content Used by AI Services
23.1 Implement Purview Controls for AI Services 23.2 Implement Microsoft 365 Workload Controls for AI
24 Data Security Posture Management for AI
24.1 Prerequisites for DSPM for AI 24.2 Manage Roles and Permissions for DSPM for AI 24.3 Configure DSPM for AI Policies 24.4 Monitor Activities in DSPM for AI
2.3 Create and Manage Custom Sensitive Info Types
Key Takeaways Explain This Topic AI
Portal-created custom SITs are stored in Microsoft.SCCManaged.CustomRulePack; built-in types remain in Microsoft Rule Package
Microsoft publishes a portal maximum of 500 custom SITs (support ticket for more), regex length 1024, 20 distinct regexes per SIT, keyword lists of 2048 terms and 50 characters per term, 10 rule packages, 50 SITs per package, and 150 KB package size
Custom regex must not use positional anchors ^ and $ and must use exactly one primary capturing group; the engine is Boost.RegEx 5.1.3
The Test action is greyed out unless the tenant has at least one Exchange Online license; you can test one unencrypted file at a time
Existing SharePoint and OneDrive content must be recrawled or run through on-demand classification before a new custom SIT is identified in already stored files
Last updated: August 2026
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
Sign in at the Microsoft Purview portal.
Go to Information Protection > Classifiers > Sensitive info types and choose Create sensitive info type .
Enter Name and Description .
Create pattern . You may add multiple patterns , each with its own elements and confidence (Low / Medium / High).
Set the pattern's default confidence.
Define the Primary element : regular expression with optional validator, keyword list, keyword dictionary, or a preconfigured function .
Set Character proximity .
Optionally add supporting elements (they may have their own proximity) and additional checks .
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:
- Limit Published value
- Custom SITs created through the Microsoft Purview portal 500 (raise a support ticket if you need more)
- Regular expression length 1024 characters
- Term length in a keyword list 50 characters
- Terms in a keyword list 2048
- Distinct regexes per SIT 20
- Combined keyword dictionaries (post-compression) 1 MB (~1,000,000 characters)
- Rule packages 10
- SITs per rule package 50
- Rule package size 150 KB
- Capturing groups in a regular expression 1
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.