Sensitivity Labels Deep Dive — Purview: Labels and DLP

Sensitivity labels look simple from the user’s chair: a document, email, or data asset gets marked Public, Internal, Confidential, or something similar. The deeper work happens behind that mark. Microsoft Purview can apply labels automatically, resolve competing matches, encrypt content, and extend the same label vocabulary beyond files into structured data. Those details matter because they turn a label taxonomy from a naming exercise into an access decision that affects people, applications, and artificial intelligence systems.

From manual labels to automated decisions

A sensitivity label is a persistent classification applied to data. In Microsoft Purview, that label can drive protection settings such as encryption, content markings, sharing restrictions, and downstream policy decisions.

Manual labeling means a person chooses the label. Automatic labeling, often shortened to auto-labeling, means Purview applies or recommends a label by evaluating configured rules. Those rules commonly look for a sensitive information type, a keyword or phrase, or a trainable classifier designed to recognize a kind of unstructured content.

The important shift is accountability. With manual labeling, the user makes the final classification choice. With auto-labeling, the administrator’s rules and label order make that choice at scale. That is powerful, but it also means weak rules or careless ordering can quietly repeat the same mistake across thousands of items.

What auto-labeling actually looks for

A sensitive information type is a pattern-based detector for data such as a credit card number, passport number, national identification number, or other regulated identifier. It usually combines pattern matching with supporting evidence, such as nearby words, to reduce false positives.

A keyword rule is simpler. It looks for words or phrases that matter to the organization, such as a project codename, acquisition name, product launch phrase, or internal business marker. Keyword rules are useful, but they can be noisy when the same word appears in harmless contexts.

A trainable classifier is different again. It is used for unstructured content where a rigid pattern is not enough. Instead of looking only for a fixed number format or exact phrase, it is trained to recognize examples of a content category.

These signals can be combined, tuned, and scoped. A mature design rarely starts by labeling everything automatically on day one. It usually begins with a small number of high-confidence conditions, then expands as the organization learns which detections are reliable.

Use sensitive information types for recognizable regulated data, such as national identifiers or payment data.
Use keywords for organization-specific terms, such as internal project names or transaction codenames.
Use trainable classifiers where the content category is meaningful but not easily captured by a fixed pattern.

Auto-labeling can look for sensitive info types, keywords, or trainable classifiers.

When more than one label matches

A document can satisfy more than one auto-labeling condition. For example, it might mention an internal project name that matches an Internal rule and also contain a customer national identification number that matches a Highly Confidential rule.

Purview does not stack both labels on the same item. It resolves the conflict using label priority. In the sensitivity label list, the more restrictive label should sit lower in the priority order. When multiple auto-labeling conditions match, the label with the higher priority, typically the more restrictive one, is the one that wins.

This is not an edge case. Real content is messy. Contracts, support exports, engineering notes, board materials, and merger files often contain several classes of information at once. Priority order is the quiet mechanism that decides what happens when those signals collide.

⚠️

Order is policy. If label priority does not reflect the organization’s real risk hierarchy, auto-labeling will enforce the wrong answer consistently.

When several labels match one item, the higher-priority label wins.

The leadership decision hidden in label order

Label priority looks like an administration detail, but it is a governance decision. The practical question is simple: if one item matches two labels, which outcome would the business want without asking a human reviewer every time?

That question belongs in design workshops with security, privacy, legal, compliance, records management, data owners, and business leaders. A technical team can configure the order, but it should not invent the organization’s risk hierarchy alone.

A useful test is to walk through ambiguous examples. What if a harmless internal project plan contains one customer identifier? What if a board presentation includes unreleased financial results and routine operational metrics? What if a database export includes both employee names and health-related data? The answers reveal whether the strictest matching label should win, whether exceptions are needed, and where user education must be clearer.

For practitioners, the lesson is to document priority order as an explicit design decision. Do not bury it inside a configuration spreadsheet. Future administrators, auditors, and data owners need to know why the labels are ordered the way they are.

List the labels from least restrictive to most restrictive.
Create realistic examples where two labels could match at once.
Ask the business which label should win in each example.
Adjust the priority order to match those decisions.
Record the rationale so later changes do not undo the design accidentally.

Encryption changes the question from label to rights

A label can classify content without encrypting it, or it can apply encryption as part of the label configuration. Once encryption is involved, access is no longer just about seeing the label name. Opening and using the protected content depends on usage rights.

A usage right is a specific permission granted over encrypted content. VIEW is the familiar one: it allows a person to open and read the content. But VIEW is not the whole story, especially when software needs to process the content rather than merely display it to a person.

The right to pay close attention to is EXTRACT. The EXTRACT usage right allows content to be extracted from a protected item. In the context of Microsoft 365 Copilot and agents, this matters because an artificial intelligence system must be able to read and reuse the content to answer questions, summarize, reason across files, or generate output from the protected material.

So the control is layered. The user must be allowed to access the protected item, and the protected item must allow extraction for the artificial intelligence experience to use its contents. Merely giving someone VIEW permission to an encrypted document does not automatically mean Copilot or an agent can use that document as source material.

📌

AI is not a bypass. Copilot and agents must respect the protection on encrypted labeled content, including the need for the EXTRACT usage right.

VIEW lets a person read content; EXTRACT lets software reuse it.

Why EXTRACT matters in the age of Copilot and agents

Before generative artificial intelligence became common in productivity tools, many organizations thought mostly in human terms: can this user open the file, forward it, print it, or edit it? Copilot and agents add another question: can software read the protected content and use it to produce a new answer?

That is why EXTRACT deserves its own design discussion. If a label’s encryption settings grant VIEW but not EXTRACT, a user may be able to read the document directly while an artificial intelligence experience cannot use the document in the same way. This can be exactly what a policy intends for highly sensitive content.

The trade-off is usability. Removing extraction can reduce the chance that sensitive material is pulled into summaries or generated answers, but it can also make legitimate knowledge work harder. The right setting depends on the sensitivity of the content, the audience, and the organization’s appetite for artificial intelligence-assisted reuse.

Treat EXTRACT as a policy lever, not a mysterious technical flag. For highly confidential data, restricting extraction may be reasonable. For broad internal collaboration data, allowing extraction may be necessary for Copilot to be useful. The design should be intentional either way.

Ask whether protected content should be usable by artificial intelligence tools, not only whether humans can read it.
Review label encryption templates for VIEW and EXTRACT together.
Test representative files with representative users before assuming Copilot behavior.
Document labels where extraction is intentionally withheld.

Labels are moving beyond files and email

Sensitivity labels are often introduced through documents and email, but the same vocabulary can also apply to structured data. Microsoft Purview can extend sensitivity labels to assets in the Microsoft Purview Data Map when the organization enables the capability, which is currently in preview.

That matters because important data does not live only in Microsoft Word documents, spreadsheets, slide decks, or mailboxes. It also lives in database tables and columns. A column named national identification number inside a customer table may deserve the same Highly Confidential label as a document containing the same kind of data.

With this capability, labels can be applied to schematized data assets, including specific columns in SQL Server, Azure SQL Database, Azure Synapse Analytics, Azure Cosmos DB, and Amazon Web Services Relational Database Service, often shortened to AWS RDS.

The architectural benefit is consistency. Security, compliance, and data governance teams can use one label language across very different stores. The label does not make a database column behave like a document, and implementation details still differ by platform, but the classification vocabulary becomes shared.

Sensitivity labels are extending from files and email to structured data columns.

A practical design checklist

A good sensitivity labeling design is not measured by how many labels exist. It is measured by whether people, policies, and systems can make consistent decisions from them.

Start small enough that each label has a clear purpose. Then define the conditions that justify automatic labeling, the priority order that resolves conflicts, the encryption settings that enforce access, and the usage rights that control artificial intelligence-assisted reuse.

Finally, test the design with real examples. Use documents that contain multiple signals, encrypted files with different rights, and structured data assets that hold regulated fields. The goal is not to prove the configuration works once. The goal is to discover the cases where the business expectation and the technical outcome do not yet match.

✅

Best test. The most useful validation file is one that should be hard to classify because it reveals whether your priority and protection choices are real.

Key takeaways

Auto-labeling applies sensitivity labels from configured rules rather than from a user’s manual choice.
Rules can use sensitive information types, keywords, and trainable classifiers, each suited to a different kind of detection problem.
When more than one label condition matches, label priority decides the result, so ordering labels is a governance decision.
For encrypted labeled content, VIEW permission alone does not necessarily let Copilot or an agent use the content; the EXTRACT usage right also matters.
Restricting EXTRACT can be a deliberate control for highly sensitive content, but it may reduce artificial intelligence-assisted productivity.
Sensitivity labels can extend beyond files and email to schematized assets in the Microsoft Purview Data Map, including database columns in supported platforms.

Glossary

Sensitivity label: A persistent classification applied to data that can drive protection, marking, and governance behavior.
Automatic labeling: The application or recommendation of a sensitivity label based on configured rules rather than a person’s manual choice.
Sensitive information type: A detector that identifies a known kind of sensitive data, often by combining patterns with supporting evidence.
Trainable classifier: A classification model trained to recognize a category of unstructured content that is not easily found with a simple pattern or keyword.
Label priority: The ordered ranking of labels that determines which label wins when multiple auto-labeling conditions match the same content.
Usage right: A specific permission that controls what someone or something can do with encrypted protected content.
EXTRACT usage right: The permission that allows content to be extracted from a protected item, which is required for some artificial intelligence experiences to use encrypted labeled content.
Microsoft Purview Data Map: The Microsoft Purview capability that inventories and describes data assets across an organization’s data estate.
Schematized data asset: Structured data with a defined schema, such as a database table or column.