2.2 Translate Requirements into Sensitive Info Types

The second blueprint bullet is Translate sensitive information requirements into built-in or custom sensitive info types. Translation means you pick a classifier that already exists when it is fit for purpose, and you design a custom pattern only when the built-in catalog cannot express the requirement. Microsoft's SIT article (updated 2026) still starts from the same definition: SITs are pattern-based classifiers that detect items such as social security, credit card, or bank account numbers.

Categories you must not mix up

Microsoft also lists SITs as inputs to DLP, sensitivity labels, retention labels, insider risk management, communication compliance, auto-labeling, and Microsoft Priva. Translation is therefore "which classifier will those solutions consume," not "which DLP action."

Anatomy of a SIT pattern

Every SIT entity has a name, a description, and one or more patterns. A pattern is made of four ideas you will see in both the portal wizard and the XML rule package.

Primary element

The primary element is the thing you are actually looking for. Microsoft allows:

• a regular expression, optionally with a validator (checksum, date, Luhn, or a built-in function processor)
• a keyword list
• a keyword dictionary
• a function (compiled processors such as Func_credit_card or Func_ssn)

Once defined, an element can be reused; it appears in the list of existing elements with the built-in ones. In PowerShell XML, the primary element is the IdMatch — and a Pattern must have exactly one IdMatch.

Supporting elements (corroborative evidence)

A supporting element raises confidence that the primary element is the real thing. Microsoft's running example: nine digits are a weak SSN; nine digits plus the keyword "Social Security Number" nearby are a stronger SSN. Supporting elements can be regexes (with or without checksum), keyword lists, or keyword dictionaries. In the portal, supporting elements can have their own character proximity. In XML, Match elements are joined with an implicit AND unless you wrap them in Any (OR / subset / none logic, including minMatches / maxMatches).

Proximity

Proximity is the number of characters (PowerShell documentation specifies Unicode characters) between the primary element and supporting evidence. The window is anchored on the IdMatch and extends left and right. Microsoft's published Argentina national identity (DNI) example uses a proximity of 250 characters: the regex match plus a keyword from the DNI keyword list. The entire supporting value must sit inside the window — Microsoft's proximity diagram emphasizes that a window which only overlaps a name field does not count as a match.

Exam trap: proximity does not jump across item boundaries. For email, the message body and each attachment are separate items. Evidence in an attachment does not corroborate an ID in the body.

There is no single Microsoft-published default proximity for every custom SIT. Built-in entity definitions publish their own patternsProximity values (250 in the DNI example). Set proximity from how the real documents are written, then test.

Confidence levels: 65, 75, and 85

Microsoft publishes three discrete confidence levels and their numeric values:

High confidence yields the fewest false positives and the most false negatives. Low confidence does the reverse. If older policies used number-based "accuracy," Microsoft maps 76–100 → high, 66–75 → medium, and 65 or below → low.

Each pattern has a confidenceLevel. The entity also has recommendedConfidence, which is the default a policy uses if the admin does not pick a level. PowerShell documentation states recommendedConfidence is mandatory; without it you cannot save policies that use the SIT.

Microsoft's tuning advice: use high-confidence patterns with low instance counts (example: about five to ten) and low-confidence patterns with higher counts (example: about twenty or more). Instance count on a policy is not the same as SIT confidence. Microsoft's published instance-count range when SITs are used in DLP, Information Protection, Data Lifecycle Management, Communication Compliance, Records Management, Defender for Cloud Apps, and Priva is min 1–500 and max 1–500 or Any.

Built-in SITs: prefer them, then copy

Start translation by searching Sensitive information type entity definitions. For each requirement, ask:

1. Does a built-in SIT already describe this format, checksum, and keyword set?
2. If yes, can we live with its confidence patterns, or do we need more keywords / less corroboration?
3. If we need changes, copy the built-in SIT (portal) or clone its XML (PowerShell). You cannot edit the Microsoft original. The built-in package is Microsoft Rule Package.

Copy is the right translation when Contoso wants "credit card numbers plus the phrases company card and Contoso card" or wants a lower-confidence pattern that does not require keywords. Microsoft's customize-a-built-in article walks that exact credit-card scenario: removing corroborative evidence should be paired with a lower confidenceLevel (their example lowers from 85).

Some built-in SITs cannot be copied in the portal (listed in the next section). Named entity SITs also cannot be copied. Those are translation constraints, not bugs.

Named entities: names, addresses, medical terms

Named entities are SITs, but they are complex dictionary and pattern-based classifiers, not a regex you will retype. They detect person names, physical addresses, and medical terms and conditions. They appear with other SITs in the portal. They cannot be edited or copied. The Test option is supported; copy and edit are not.

They come in two flavors:

• Bundled — broad class detectors such as All full names, All physical addresses, All medical terms and conditions. Use them as wide DLP criteria.
• Unbundled — narrower, such as Australia Physical Addresses, Blood Test Terms, Brand Medication Names. Use them when you need a tighter scope.

Microsoft states you must activate Advanced classification scanning and protection for named entity SITs to be discoverable in the relevant DLP settings. Separately, bundled named entity SITs in an Endpoint DLP policy require Advanced classification scanning and protection. Named-entity documentation also states that Entity Match and other advanced classifiers are offered only to users with E5 licenses.

Translation example: "alert when a file contains a patient name, a U.S. address, and a medication" is a named-entity design, not three custom keyword lists. "Alert when our 12-character project code appears" is a custom SIT.

Keyword lists versus keyword dictionaries

Use a keyword list for small, tightly scoped corroboration ("Employee ID", "badge", "Contoso card"). Microsoft's published list limits are 50 characters per term and 2048 terms. Microsoft recommends string match rather than word match for keyword lists, especially with double-byte languages.

Use a keyword dictionary when you outgrow those limits or need a large lexicon (disease names, product SKUs, prohibited terms). The dedicated limits page and the keyword-dictionary article (both updated June 2026) publish a combined 1 MB post-compression tenant size for dictionaries, described as about 1,000,000 characters. Dictionaries support any language. You can upload TXT or CSV in the portal while creating a SIT, pick an existing dictionary, or create one with New-DlpKeywordDictionary in Security & Compliance PowerShell (Unicode file). The PowerShell custom-SIT article still also publishes a 480 KB compressed AD-schema figure and a maximum of 50 keyword-dictionary-based SITs per tenant — cite the dedicated limits table for the 1 MB combined size, and do not invent a third number.

For Chinese, Japanese, and Korean mixed with English, Microsoft's guidance is to define two variants (with and without the extra space Purview inserts for double-byte text) and often two lists (double-byte terms versus English-only terms).

Checksums, Luhn, dates, and functions

Pattern translation is incomplete if the identifier has a check digit and you ignore it. Microsoft exposes:

• Checksum validator — weights, modulo, check-digit position (portal and XML).
• Advanced checksum — extra parameters (ASCII letters, position-based digit replacement); no UI support, PowerShell/XML only.
• Luhn check validator — payment-card style algorithms.
• Date validator — when part of the regex is a date (offset and format).
• Function processors as validators — for example Func_India_Aadhaar so your custom regex still passes the official Aadhaar logic. Other published function names include Func_credit_card, Func_ssn, Func_iban, Func_uk_nhs_number, and Func_canadian_sin.

Additional checks (exclude specific matches such as 4111111111111111, starts/ends with, exclude duplicate digits, include/exclude prefixes and suffixes) belong in the translation design when the business says "ignore test cards" or "employee IDs never end in 0."

When the correct translation is not a custom regex SIT

Stay inside this chapter's boundary, but mark the hand-off:

• Exact values from a database (this employee's SSN, this customer's account) → exact data match. A regex of \d{9} will match other nine-digit numbers. EDM hashes a table you refresh.
• Filled forms that share a template → document fingerprinting. The shape of the form is the signal.
• Unstructured classes of document (source code, resumes, harassment) → trainable classifiers, which match from examples, not elements in the item.
• Already covered by a built-in or named entity → use it. Custom SITs that duplicate Microsoft's credit-card function usually add false positives, not value.

Microsoft's classifiers overview lists those automated pattern-matching mechanisms side by side with SITs for a reason. Translation includes saying "this requirement is not a SIT."

Worked translation

Requirement: "Detect Contoso employee IDs in email. Format is nine digits. Badges also print the hire date and the words Employee ID."

• Primary: regex for nine digits (not ^/$ anchored). Consider a checksum if HR actually uses one.
• Supporting: keyword list Employee ID, badge; optional Func_us_date.
• Patterns: high confidence when regex + keyword + date within a few hundred characters; medium when regex + keyword; low only if legal insists on catching bare nine-digit strings (expect false positives).
• Policy: start with high confidence and a low instance count for a block rule; use a lower confidence / higher count for an audit rule.
• Not EDM unless they meant "only IDs that exist in the HR export."

That mapping is the skill. Creating the portal object is the next section.