MS-102: Purview Controls for Sensitive Data

A company can enable strong authentication and keep devices fully patched while still lose control of sensitive information. A spreadsheet containing customer records may be copied into an unapproved workspace, forwarded to a personal address, retained long after its legal purpose, or deleted before a regulatory investigation ends. Protecting that information requires rules about its meaning and lifecycle, not merely the health of the computer that opened it.

Microsoft Purview is part of the MS-102 exam’s compliance coverage under the April 2026 study guide. Microsoft has scheduled the exam and related expert certification to retire on November 30, 2026. For current administrators, the relevant challenge is to design classification, labeling, retention, and data loss prevention controls that behave predictably across the Microsoft 365 workloads the organization actually uses.

Begin with information ownership and intended use

Imagine a financial consultancy with three kinds of documents: public marketing material, confidential client models, and employee records subject to statutory retention. A universal label of ‘confidential’ would provide little operational direction. The company needs a classification scheme that distinguishes permitted sharing, protection needs, retention obligations, and exceptions. A document’s sensitivity and its required retention are related but not identical properties.

Ownership is essential. Legal and compliance teams define many obligations, but service owners understand how records are created, exchanged, and used. Technology teams can implement the policy only when those groups agree about the intended behavior. A classification program without owners becomes an expanding collection of labels whose meanings nobody can explain to employees.

Start with representative data flows. Where are customer models stored? Are Teams messages used to approve changes? Does a support application generate reports in SharePoint, OneDrive, or an external system? Which users need legitimate external collaboration? A protection policy should not be designed solely around file types if the same information moves between messages, documents, and application integrations.

Sensitive information types are evidence, not perfect truth

Purview supports sensitive information identification using built-in and configured patterns, including approaches based on keywords, lists, and regular expressions where applicable. A detection rule for a national identification number may have false positives when ordinary product codes share a similar format. A high-confidence classification may require additional context such as nearby terms, validation logic, or document structure.

Building a reliable rule therefore requires a test set that includes both sensitive examples and realistic benign material. Compare how the detection behaves across the sources you intend to protect. If the organization scans only a subset of repositories, it should not claim complete discovery coverage. Confidence indicators can help prioritize review, but an automated match does not establish that the document was intentionally leaked or even contains a real customer record.

Use discovery results to improve information handling. A directory with sensitive exports but no established owner may be a greater governance weakness than a few false matches. Classification should prompt concrete decisions about access, sharing, retention, and protection, rather than remain an attractive chart on a compliance portal.

Sensitivity labels govern handling in context

A sensitivity label can carry an organization’s classification meaning into supported Microsoft 365 workflows. Depending on configuration and capabilities, it may influence markings, encryption, and the handling of content. Label publication determines who can see or use particular labels. The effective behavior depends on the workload, license, and application support; a label name alone does not guarantee the same protection in every location.

Suppose client financial models are labeled for a specific engagement team. Access should be tested with an authorized employee, another department, and an external consultant whose permission is limited by contract. Check both online collaboration and downloaded copies where relevant. If a label applies encryption, plan for how legitimate recipients authenticate and how access is withdrawn. A policy that prevents the engagement team from completing its work will encourage unsafe workarounds.

Automatic and recommended labeling can reduce dependence on users remembering each rule, but it needs careful validation. A pattern that mislabels public proposals as restricted can create widespread access incidents. Conversely, a model that misses sensitive data in an unusual document format can create false confidence. Roll out in a manageable scope, gather representative feedback, and monitor exceptions.

Retention and disposal need a business rationale

Retention policy determines how long specified content must be preserved and when it may be disposed of. A retention label can target particular classes of content under supported conditions, while broader retention policies can apply to defined locations or workloads. Those mechanisms may have different precedence and behavior, so administrators should test actual outcomes rather than assume one retention period applies universally.

A consultancy may need to retain signed engagement documents for years while deleting temporary analysis exports after an appropriate period. Keeping everything forever increases exposure and operational burden; deleting too early can obstruct contractual, legal, or regulatory obligations. A reliable policy documents the event or date from which retention begins, exceptions, review responsibilities, and evidence of authorized disposition.

Retention is not synonymous with backup. A service may preserve content against certain user deletion actions without providing every recovery feature the business expects during a malicious incident. Backup design and retention design should be coordinated but separately validated. A recorded legal hold or eDiscovery requirement may also change what deletion means in a specific context; such obligations must be reviewed with the organization’s responsible legal function.

DLP should distinguish risky movement from ordinary work

Data loss prevention policies can evaluate defined sensitive content and sharing behavior across supported Microsoft 365 locations such as Exchange, SharePoint, OneDrive, Teams, and other listed integrations, subject to licensing and configuration. The objective is to prevent or govern prohibited movement while allowing legitimate collaboration. A rule that blocks all external email containing a common six-digit number may create more damage than protection.

Use a realistic example: the finance department sends routine invoices to customers, but employees may not send raw employee tax records to personal accounts. A good DLP design identifies the sensitive information accurately, distinguishes approved channels from unsafe ones, and communicates an actionable reason when an operation is restricted. Policy tips and user education can improve compliance where the platform supports them; silent blocks without explanatory workflow often cause repeated support requests.

Policy scope matters. An external sharing action in SharePoint is different from a copy to a removable device or a paste into an unmanaged browser. Endpoint DLP addresses relevant endpoint activities when devices and services are correctly configured. A server-side policy does not automatically govern every local operation, and an endpoint policy is not proof that every remote device is enrolled. Administrators should state where enforcement occurs and what remains outside coverage.

Investigate alerts without assuming wrongdoing

A DLP alert indicates that activity met configured criteria. It does not, by itself, prove intentional exfiltration. An employee may have attempted a legitimate transfer to an incorrectly classified recipient, a newly changed policy may be overbroad, or an application may have produced sensitive-looking test data. Analysts should inspect event details, affected content, user context, destination, and policy conditions before classifying intent.

Response may range from giving guidance to blocking a transfer, opening a policy exception process, or escalating a credible incident. Policies should establish who can override a restriction, what justification must be recorded, and how exceptions expire. For example, a legal team working with an external counsel may require a controlled distribution channel rather than an improvised tenant-wide bypass.

Activity explorer, Content explorer, and label reporting provide different windows into classification and usage where enabled and authorized. Their outputs should be handled with privacy and least-privilege considerations: a tool that helps investigate sensitive content can itself become a source of exposure when too many people receive unrestricted access.

Copilot and new interfaces still depend on data governance

Generative AI features can surface or summarize information according to the permissions and connectors through which they operate. That makes existing oversharing especially important. If a broad group can read a sensitive document that should have been restricted, an AI interface may make the poor permission easier to discover. Improving labels and DLP is helpful, but it does not excuse weak underlying access control.

The MS-102 study guide explicitly includes DLP for Microsoft 365 Copilot among its covered workloads. Administrators should test how relevant policies apply to actual supported scenarios and not assume identical enforcement across every prompt, file, and connected system. Protecting sensitive material may require changes in permissions, classification, workflow design, and employee guidance alongside Purview configuration.

Data governance is also a change-management problem. New collaboration practices, acquired business units, or new AI tooling can render an old classification model incomplete. Revisit coverage when the business changes how it stores or processes information, not only when an auditor requests a report.

A successful policy is observable from end to end

Finish by testing the complete lifecycle of one representative document. Confirm its classification, check how a label affects authorized sharing, validate a prohibited transfer scenario, inspect the resulting alert, verify relevant retention behavior, and record any necessary exception. Repeat for at least one message and one endpoint action if those workloads are in scope. A policy deployment is incomplete if nobody can describe the result it is supposed to produce.

For those who specialize in information-security administration, SC-401 focuses more directly on many protection responsibilities that a general tenant administrator encounters as one part of the job. In Microsoft 365, compliance engineering is as much about workflow design as it is about policy configuration. An administrator who understands the relationship between information ownership, sensitivity, retention, and user activity can make Purview protect actual business records instead of accumulating disconnected rules. That remains a valuable skill even as the MS-102 certification reaches the end of its published lifecycle.