Graphic Design Institute uses an internal employee ID format: the prefix 'GDI-' followed by exactly 6 digits (for example, 'GDI-482931'). The compliance team wants DLP policies to be able to detect these employee IDs when they appear in documents or emails. What is the FIRST step the administrator must complete before the DLP policies can detect this pattern?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Microsoft Purview can't detect your company's custom ID format out of the box — there's no built-in SIT for 'GDI-' employee IDs. You have to teach Purview what to look for by building a Custom Sensitive Information Type using a regex pattern first, and then you can reference that SIT inside DLP policies. The SIT is the building block; the DLP rule is where you use it.
Full explanation below image
Full Explanation
The correct answer is C. Microsoft Purview requires that patterns used to detect sensitive data be defined as Sensitive Information Types (SITs) before they can be referenced in DLP policies, retention policies, or auto-labeling policies. For a custom pattern like 'GDI-' followed by 6 digits, you create a Custom SIT in Microsoft Purview > Data classification > Sensitive info types > Create. You define a primary pattern using a regular expression (regex) such as GDI-\d{6}, optionally add supporting evidence (keyword lists like 'employee', 'ID', 'Graphic Design Institute') to increase detection confidence, and set confidence levels (Low, Medium, High). Once the Custom SIT is created, it becomes available as an option in DLP policy rules under the 'Content contains sensitive info type' condition.
Option A is incorrect. A keyword dictionary is used to match a large list of specific, known string values — for example, a list of banned product names or specific known account numbers. A keyword dictionary is not appropriate for a pattern-based format like 'GDI-' + 6 digits, where the specific values are unknown and could be any combination of 6 digits. A regular expression is the correct mechanism for pattern matching. Additionally, a keyword dictionary is a separate object that would still need to be incorporated into a Custom SIT or DLP policy — it is not a standalone detection mechanism for this use case.
Option B is incorrect. Microsoft Purview does include hundreds of built-in sensitive information types covering common patterns like Social Security Numbers, credit card numbers, passport numbers, and more — but there is NO built-in SIT for 'Employee ID' in a generic or custom format. Built-in SITs target regulated, standardized data formats. An organization-specific internal ID format like 'GDI-######' does not exist in the built-in SIT library and must be created as a custom type.
Option D is incorrect. This describes a capability that does not exist in Microsoft Purview. DLP policy rules do not have a field where you can directly enter a raw regular expression. The only ways to use pattern matching in DLP are through (1) built-in SITs that are already defined in the Purview library, or (2) custom SITs that you create and then reference in DLP rules. The regex must be encapsulated in a named SIT object first.
Exam tip: The AB-650 exam tests the Custom SIT creation workflow. Know the path: Microsoft Purview > Data classification > Sensitive info types > + Create sensitive info type. The three confidence levels (Low/Medium/High) are defined by how much supporting evidence (keywords, other patterns) accompanies the primary regex match. Also know that Custom SITs can be shared across DLP policies, retention label auto-apply policies, and sensitivity label auto-labeling policies — create once, reuse everywhere.