Sensitive Information Types

Sensitive Information Types (SITs) are the detection engine that drives auto-labeling, DLP policies, and Insider Risk Management. Every policy in this chapter references one or more SIT groups. Getting SIT configuration right before deploying any label or policy prevents both false positives (over-blocking) and false negatives (missed detections).

How SITs Work

Each SIT evaluates content using a combination of pattern matching (regex), keyword proximity, and checksum validation. The result is a confidence level:

Confidence Level	Meaning	Typical Use
High (85)	Higher-confidence pattern defined by the SIT	Candidate for blocking or auto-labeling after validation
Medium (75)	Medium-confidence pattern defined by the SIT	Alert or policy tip after validation
Low (65)	Lower-confidence pattern defined by the SIT	Discovery and tuning

These are pattern confidence levels, not measured probabilities. Supporting evidence and available confidence levels vary by SIT.

Deploy Purview Without the Noise

Shifting from manual classification to automated, secure-by-default data protection is the ultimate goal, but poorly tuned Data Loss Prevention (DLP) rules will overwhelm your business with false positives. At Mindline, we help defense contractors build practical label taxonomies and tune their sensitive information types so security enables collaboration rather than blocking it. Need help untangling your data protection strategy? Book a scoping call at mindline.com.

Policies should reference the confidence level explicitly. A DLP rule that fires at Low confidence on Credit Card will generate excessive false positives in any organization that sends invoices by email.

Core SIT Groups

Financial SITs

Used in DLP Finance alert policies and auto-labeling of Confidential content.

Sensitive Info Type	Detection Method	Notes
Credit Card Number	Luhn checksum + keyword proximity	See false positive mitigation below
U.S. Bank Account Number	ABA routing + account pattern
SWIFT Code	ISO 9362 pattern
International Banking Account Number (IBAN)	Country-specific regex + checksum
U.S. Individual Taxpayer Identification Number (ITIN)	SSN-format + ITIN keyword

PII SITs

Used in DLP PII alert policies and auto-labeling.

Sensitive Info Type	Detection Method	Notes
U.S. Social Security Number (SSN)	Pattern + keyword	Avoid Low confidence in email
All Full Names	NER model	High false-positive rate in isolation; pair with other SITs
U.S. Driver's License Number	State-specific patterns	50 distinct patterns
U.S. Individual Taxpayer Identification Number (ITIN)	Pattern + keyword	Overlaps with SSN pattern
U.S. Physical Addresses	NER model	Useful for HR/benefits data detection

Credential SITs

Used in the highest-priority DLP alert policies (AD Credential Protection).

Sensitive Info Type	Detection Method	Notes
General Password	Pattern + keyword proximity	Fires on "password:" followed by a value
Azure Active Directory Client Secret	Pattern	Rotate immediately on detection
Azure SAS Token	Pattern
Software Development Credentials	Pattern bundle	npm tokens, API keys, connection strings

The Credit Card False Positive Problem

Credit Card Number is the most common source of false positives. Purchase orders, invoices, and financial reports contain 16-digit numbers that match the Luhn checksum but are not card numbers. Two mitigations:

1. Keyword Exclusion Dictionary

Investigate false positives using representative documents. Billing terms that may help explain a match include:

Invoice #
PO Number
Purchase Order
Account Number
Reference Number
Order ID
Quote Number

Built-in SITs cannot be edited in place. Copy the built-in SIT or create a custom SIT before tuning supported pattern elements. Do not suppress every match near these words: real card numbers also occur on invoices. Test exclusions against both false-positive samples and documents containing genuine card data.

2. Confidence Level Gating

Do not trigger block actions at Low or Medium confidence for Credit Card. Use the following tiered approach:

Confidence	Action
High (85)	Alert + require justification
Medium (75)	Policy tip only
Low (65)	Audit log only, no user notification

Environment-Specific SITs

GCC High (CMMC)

CUI-Specific Sensitive Information Types

CMMC AC.L2-3.1.3 and SC.L2-3.13.1 address information flow and boundary protection. The following SITs identify candidates for CUI review; keywords and contract numbers alone do not establish CUI status.

Distribution Statement Keywords

Create a custom keyword SIT named CUI - Distribution Statement with the following keyword groups:

Keyword Group	Terms
Distribution Statement B	Distribution Statement B, Dist Stmt B, DISTRIBUTION B
Distribution Statement C	Distribution Statement C, Dist Stmt C, DISTRIBUTION C
Distribution Statement D	Distribution Statement D, Dist Stmt D, DISTRIBUTION D
Distribution Statement E	Distribution Statement E, Dist Stmt E, DISTRIBUTION E
Distribution Statement F	Distribution Statement F, Dist Stmt F, DISTRIBUTION F

Start with a minimum match count of 1 in simulation. A quoted distribution statement can occur in training or policy documents; validate the context before automatic enforcement.

ITAR / EAR Export Control Keywords

Create a custom keyword SIT named CUI - Export Control:

Keyword Group	Terms
ITAR	ITAR, International Traffic in Arms, 22 CFR 120, USML, Defense Article
EAR	EAR, Export Administration Regulations, 15 CFR 730, ECCN, Commerce Control List
CUI Export Control	CUI//EXPT, CUI//SP-EXPT

DoD Contract Number Pattern

Create a custom regex SIT named CUI - DoD Contract Number:

\b[A-Z0-9]{6}-?[0-9]{2}-?[A-Z]-?[A-Z0-9]{4}\b

This illustrative pattern matches W81XWH-22-C-0001 and its unhyphenated form. Pair with keyword proximity: Contract, Award, Task Order. Validate against your actual contract identifiers; it is not a complete PIID validator or proof of CUI.

CUI Designation Indicator

Create a custom SIT for CUI banner tokens, including bare CUI:

\bCUI\b(?:\/\/[A-Z0-9][A-Z0-9/\-]*)?

Use this case-sensitive example for discovery and test it against your markings. It detects a token, not a complete NARA-compliant designation indicator or banner; prose mentioning CUI also matches.

Bundle all four CUI SITs into a custom SIT group named CUI Bundle for DLP conditions that need to catch any CUI marker in one rule. Auto-labeling does not use the bundle: a service-side auto-labeling policy applies exactly one label, so the GCC High mapping is three policies, each naming its sublabel and never the CUI parent. CUI - Distribution Statement or CUI - DoD Contract Number applies CUI//SP-CTI; CUI - Export Control applies CUI//SP-EXPT; a bare CUI Designation Indicator token with no category applies CUI (Basic). Run that last policy in simulation first, because prose that merely mentions CUI matches it. The policy table is in Auto-Labeling Policy Design.

Commercial

Regulatory SIT Groupings

For commercial organizations, SITs map to regulatory frameworks. Group them as named SIT collections for use in DLP policies and auto-labeling.

GLBA Financial SIT Group

SIT	Regulation
Credit Card Number	PCI-DSS
U.S. Bank Account Number	GLBA
SWIFT Code	GLBA / wire fraud
IBAN	GLBA / international
U.S. Individual Taxpayer Identification Number	GLBA

HIPAA / HITECH SIT Group

Start with the HIPAA DLP policy template and inspect its actual conditions. Candidate SITs and contextual signals include:

• U.S. Social Security Number (SSN)
• Drug Enforcement Agency (DEA) Number
• National Drug Code
• All Full Names (paired with medical terms)

FERPA SIT Group (Higher Education)

FERPA does not have a prescribed SIT set. Build a custom keyword SIT named Student PII with terms:

Student ID
EMPL ID
Grade Report
Transcript
Enrollment Status
Financial Aid
FAFSA

Pair with All Full Names or SSN at High confidence to reduce false positives from general HR content.

PCI-DSS SIT Group

For retail or payment processors, bundle: Credit Card Number, CVV (custom regex \b\d{3,4}\b with keyword CVV, Security Code, CVC), and U.S. Bank Account Number.

Trainable Classifiers

Trainable classifiers use machine learning rather than pattern matching. They are appropriate when content cannot be identified by a regex or keyword list, for example, recognizing "intellectual property" from context.

Pre-Trained Classifiers

Microsoft provides several pre-trained classifiers ready for use in policies without additional training:

Classifier	Use Case
Source Code	Detects code files across 25+ languages
Resumes	Detects HR candidate data
Financial Statements	Balance sheets, P&L statements
HR — Harassment	Policy violation detection
Threat	Threatening language
Profanity	Policy enforcement

Custom Trainable Classifiers

When pre-trained classifiers do not match your content, create a custom classifier:

1. Seed phase: Supply 50 to 500 positive documents and 150 to 1,500 negative documents, each set in its own SharePoint folder that holds nothing else (text-based files only; image-only PDFs are not read).
2. Test phase: Purview tests automatically after training. Keep a separate labeled test set of at least 200 items, with at least 50 positive and 150 negative examples, and evaluate both missed detections and false positives against the intended policy action.
3. Publish: Select Publish for use; the classifier then appears in auto-labeling and DLP conditions.

Training completes within 24 hours (classifier creation workflow). Review performance when the document population changes; an arbitrary precision percentage does not make blocking safe.

Classifier Limitations

• Trainable classifiers operate on text content only. Scanned PDFs, image-only files, and CAD drawings require OCR preprocessing.

OCR Limitation: Engineering CAD Drawings

Purview's own OCR is a tenant setting (Settings > Optical character recognition (OCR), pay-as-you-go, billed per image and per PDF page) that feeds image text to every SIT, exact data match SIT, and trainable classifier. It reads scanned and hybrid PDFs and the common raster formats in SharePoint, OneDrive, Exchange, Teams, and endpoints; native CAD files are not on its list. Test it against representative drawings: image quality, unusual fonts, dense layouts, and CAD export settings affect detection, and some exported PDFs already carry searchable text, so verify extraction before adding an OCR service. See Learn about optical character recognition in Microsoft Purview.

Solution: Azure AI Document Intelligence

For supported commercial deployments, a custom pipeline can be evaluated:

SharePoint (new PDF) → Logic App trigger
  → Azure AI Document Intelligence (custom model)
      → extracted title block fields (drawing number, revision, classification)
  → Microsoft Graph assignSensitivityLabel (commercial cloud)
      → Apply sensitivity label based on classification field value

Implementation steps:

1. Validate Document Intelligence model and regional availability, extraction accuracy, and authorization to process the source data.
2. Map the extracted classification field to label GUIDs using a Logic App variable or Azure Key Vault secret.
3. Use the Graph assignSensitivityLabel API, including its metered-service requirements, permissions, asynchronous completion, and error handling.
4. Record the source item, decision, label, actor, and confirmed result for audit evidence.

This is separate from native auto-labeling. The Graph API currently lists US Government L4 and L5 as unsupported, so this example is not a GCC High labeling runbook. Use a labeling method supported in the target cloud and validate any OCR integration before processing CUI.