2.1 Identify Sensitive Information Requirements

SC-401 opens the information protection domain with a planning skill, not a portal click-path. The official bullet is Identify sensitive information requirements for an organization's data. Microsoft's information protection documentation is explicit that identifying and classifying sensitive items is the first step in the discipline. A sensitive information type (SIT) is a classifier, not a control. If you cannot name the data, the regulation, the location, and the false-positive tolerance, you are not ready to create a SIT.

Microsoft Purview Information Protection is organized as know your data, protect your data, and prevent data loss. Classification work lives in the first of those three. Later SC-401 chapters cover sensitivity labels, DLP, retention, and insider risk. This chapter stays on the identification layer that those controls consume.

Discovery versus classification versus protection

Candidates routinely collapse three different jobs into one phrase, "turn on Purview." The exam (and production design) treats them as a sequence.

Discovery is inventory. Purview can scan SharePoint, OneDrive, Exchange, Teams, and (with the right workload configuration) devices and cloud apps so you can see labeled and SIT-matched items. Microsoft documents zero change management: data classification scans sensitive content and labeled content before you create any policies. That lets you judge impact before you publish a DLP rule that blocks email.

Classification is identification. A SIT match says "this item looks like a U.S. Social Security number at medium confidence." A user-applied sensitivity label says "this item is Confidential." Those are related but not identical. SITs are pattern-based (or, in later chapters, example-based or exact-value-based) classifiers. Labels are the taxonomy you publish to people and policies.

Protection is enforcement. Encryption, headers, watermarks, block, warn, audit, and restrict-sharing actions live on labels and DLP, not on the SIT definition itself. A classic exam trap is "create a custom SIT to encrypt payroll files." The SIT can detect payroll identifiers; a sensitivity label or DLP policy applies the protection.

Three official ways Purview classifies content

Microsoft's classifiers overview states that Purview offers three ways to classify content:

1. Manually — users and admins apply preexisting or custom labels and SITs as they encounter items. Human judgment is required. This is still classification; it is just not automated.
2. Automated pattern-matching — Keyword Query Language (keywords or metadata), sensitive information types (patterns such as social security, credit card, or bank account numbers), document fingerprinting (a variation of a template), and exact data match (exact strings from a sensitive-information table).
3. Trainable classifiers — you give the service samples of the content you care about. The classifier learns the kind of document, not a regex.

For this chapter, the skill you are practicing is turning requirements into SIT-shaped detection. Fingerprinting, EDM, and trainable classifiers are the next chapter. You still need the decision boundary now: if the requirement is "find every row that matches our HR export of employee SSNs," that is EDM, not a custom nine-digit regex. If the requirement is "find filled-out copies of our benefits enrollment form," that is document fingerprinting. If the requirement is "find source-code-like files or resumes with no stable identifier," that is a trainable classifier. Write those exceptions down during requirements gathering so you do not force a regex onto unstructured content.

What "requirements" actually contain

A usable requirements set for SC-401 is not a slogan such as "we must protect PII." Interview legal, HR, finance, engineering, and the business owners of each Microsoft 365 workload, then record the following.

Data types and authoritative definitions

List each class of sensitive information in language the business already uses, then map it to a detection idea:

• Regulated personal data — government identifiers, driver's licenses, passport numbers, national IDs. Many of these already have built-in SITs with published entity definitions (format, pattern, checksum yes/no, keywords, proximity).
• Payment data — primary account numbers, IBAN, ABA routing. Built-in credit card SITs typically combine a function or regex with a Luhn (or similar) checksum plus keywords such as card brand names.
• Health data — ICD terms, medication names, lab terms. Named entity SITs cover many medical terms and conditions; do not reinvent a dictionary of drug names unless the built-in named entity is the wrong scope.
• Credentials and secrets — Microsoft publishes a family of credential scanning SITs. Official documentation states that an E5 license is required to use credential scanning SITs. If the requirement is "detect leaked passwords and API keys," licensing is part of the requirement, not an afterthought.
• Organization-specific identifiers — employee numbers, project codes, customer record numbers, internal "badge IDs." These are the usual custom-SIT candidates because Microsoft cannot ship your payroll format.
• Unstructured sensitive content — merger decks, source code, legal holds, harassment language. Pattern matching is a poor fit; note trainable classifiers or communication compliance for later design, and do not pretend a keyword list of three words is a classifier.

For each type, capture format (digits, checksum, delimiters), supporting evidence (the word "SSN" near the number, a hire date, a department name), languages, and test artifacts you are allowed to use (never production PAN dumps in a laptop folder).

Locations and workloads

The same SIT can produce different results depending on where content is evaluated. Microsoft documents detection differences across Exchange (email in transit), SharePoint and OneDrive (files at rest), and Endpoint DLP (files on managed devices). Requirements must name locations:

• Exchange Online mailboxes and attachments
• SharePoint sites and OneDrive libraries
• Teams chat and channel files
• Windows endpoints and Office clients
• Cloud apps reached through Microsoft Defender for Cloud Apps

If legal says "no Social Security numbers in email to personal accounts," that is an Exchange/DLP location requirement. If HR says "the census file in the Compensation site is the system of record," that is a SharePoint discovery requirement and possibly an EDM source later. Do not write a single global regex and assume every workload will match it the same way. Microsoft also notes that content-extraction limits (maximum file size and characters scanned) can affect detection; those numeric limits are published on DLP platform considerations, not as a single SIT-wide constant, so do not invent a file-size number on the exam.

Confidence, volume, and false-positive tolerance

Requirements should state how sure you must be before a control fires. A privacy team that will accept a review queue can live with low confidence (more matches, more false positives). A DLP policy that blocks outbound email should usually demand high confidence and a sensible instance count. Microsoft's SIT guidance recommends pairing high-confidence patterns with low counts (it gives the example of about five to ten) and low-confidence patterns with higher counts (it gives the example of about twenty or more). That pairing is a requirements decision, not a portal default you discover later.

Stakeholders and permissions

You will not implement this alone. The SC-401 audience profile says the information security administrator collaborates with governance, data, and security roles. For the classification portal itself, Microsoft lists these Microsoft 365 role groups for access to the data classification page: Global administrator, Compliance administrator, Security administrator, and Compliance data administrator. Microsoft's stated best practice is to use the role with least privilege. Finer Information Protection roles (Admin, Analyst, Investigator, Reader) exist for the Information Protection solution. Record who may see explorer results (often a privacy analyst) versus who may create classifiers (a smaller admin set).

A requirements workshop that maps to the exam

Walk a Contoso scenario the way an item writer would. Contoso is a U.S. health-tech employer. Legal cites HIPAA and state breach statutes. Finance cites PCI DSS for a small card-not-present flow. HR stores employee SSNs in a Workday export landed weekly in a locked SharePoint library. Engineering wants to stop API keys from landing in Teams. Marketing stores vendor contracts that do not contain a stable identifier.

A competent requirements list looks like this:

• U.S. SSN in email and Teams — prefer the built-in U.S. Social Security Number SIT; decide medium versus high confidence; name Exchange and Teams as locations; decide whether a block action is acceptable given false positives.
• Cardholder data — built-in credit card SIT with checksum; PCI scope is a location problem (which sites and which devices), not a reason to write a new regex.
• Employee SSN values that exist in the HR export — this is exact data match, not "nine digits plus the word employee." Flag it for the EDM chapter.
• API keys and passwords — credential scanning SITs; confirm E5.
• Vendor contracts — trainable classifier or manual labeling; not a custom SIT.
• Named people and U.S. addresses next to health terms — named entity SITs (All full names, physical addresses, medical terms), with the licensing and advanced-classification notes you will use in the next section.

Notice what you did not do: you did not open Create sensitive info type yet. The skill measured here is identification of requirements. Translation into built-in versus custom SITs is the next section.

Exam traps

• SIT equals DLP. A SIT is reused across DLP, sensitivity labels, retention, insider risk, communication compliance, auto-labeling, and Microsoft Priva. Creating the SIT does not create a policy.
• Scan after you lock everything down. Zero change management is the opposite: classify and observe first.
• One classifier for every requirement. Pattern-based SITs are for patterned data. Templates, exact database values, and unstructured document types have other classifiers.
• Ignore licensing. Credential scanning SITs are called out as E5. Named-entity documentation also states that Entity Match and other advanced classifiers are offered to users with E5 licenses. If the item mentions credentials or advanced named-entity use, look for the license.
• Invent limits during planning. Published SIT configuration limits (500 custom SITs through the portal, regex length, keyword-list size) belong to creation. Requirements gathering should not invent a "Microsoft maximum of N SSNs per tenant." Microsoft does not publish an SC-401-specific count of built-in SITs as an exam constant; use the entity-definitions catalog rather than a memorized total.

When the requirements packet names data types, locations, confidence tolerance, licensing, and the classifier family (SIT versus EDM versus fingerprint versus trainable), you have completed this blueprint bullet.