Microsoft Purview is not a single policy engine or a compliance switch. It brings together capabilities for data governance, data security and compliance, each addressing different questions: What information do we hold? How should it be protected? How long must it remain? What evidence can we produce when an incident or legal request arrives?
For a Microsoft 365 architect, the challenge is connecting those questions without confusing the controls. A sensitivity label does not establish a retention schedule. A retention policy does not prevent an inappropriate disclosure. An investigation tool does not replace preventive controls. This first article in the Microsoft Purview Deep Dive series maps those responsibilities and provides a practical starting point for deployment.
1. Establish the map: information, controls and ownership
Microsoft Purview spans data governance as well as data security and compliance. Its data governance capabilities support activities such as discovering and understanding data assets. This series concentrates on the Microsoft 365 security and compliance controls used to classify information, reduce inappropriate disclosure, manage its lifecycle and support investigations. Do not assume that deploying one area automatically configures the others.
Organise the programme around outcomes rather than portal navigation. The following map identifies the principal capability for each outcome; several may apply to the same information.
Understand sensitivity and apply protection: Microsoft Purview Information Protection, including sensitivity labels and supported classification methods.
Reduce inappropriate sharing and handling: Microsoft Purview Data Loss Prevention across supported services and endpoints.
Retain or delete information according to requirements: Microsoft Purview Data Lifecycle Management and Microsoft Purview Records Management.
Find activity evidence and manage legal discovery: Microsoft Purview Audit and Microsoft Purview eDiscovery.
Assess defined people-related risks: Microsoft Purview Insider Risk Management and Microsoft Purview Communication Compliance.
Organise compliance assessments and improvement work: Microsoft Purview Compliance Manager.
These capabilities complement other Microsoft security services. Microsoft Entra ID provides identity and access controls. Microsoft Defender XDR supports threat detection, investigation and response across its integrated products. Microsoft Purview supplies data-focused controls and compliance workflows; it is not a substitute for identity security or endpoint protection.
Assign ownership before configuration. Security may own disclosure controls, records management may own retention schedules, and legal may authorise discovery activity. Privacy and HR should help define appropriate boundaries for people-related investigations. IT implements the agreed controls, but should not independently decide the organisation’s legal obligations.
2. Start with classification and sensitivity labels
Microsoft Purview Information Protection provides a foundation for identifying and protecting sensitive information. Sensitive information types and trainable classifiers support classification scenarios, while sensitivity labels express an organisation’s handling categories. Their availability and behaviour depend on the capability, content and licensing involved.
Begin with a small vocabulary that employees can apply consistently. Public, Internal, Confidential and Highly Confidential are possible starting points, not a Microsoft-mandated taxonomy. Define each category using business examples, an accountable owner and an explicit handling rule. If employees cannot distinguish two labels, adding more policy settings will not resolve the design problem.
Sensitivity labels can apply settings such as content markings and encryption to supported files and emails. Labels can also be scoped to groups and sites, where they manage supported container settings. These scopes are not interchangeable: a label on a team or SharePoint site does not automatically label every file stored within it.
Identify representative information: customer contracts, employee records, financial forecasts and externally published material.
Decide which categories need encryption, which need markings, and which simply communicate handling expectations.
Publish labels to a pilot group and test supported applications, external collaboration and access by intended recipients.
Keep classification separate from enforcement in your design records. A label may identify sensitive information, apply protection, or provide a condition for another control. Document the actual configured behaviour rather than treating the presence of a label as proof that all desired protections exist.
3. Map disclosure controls across services and endpoints
Microsoft Purview Data Loss Prevention evaluates configured conditions and applies supported actions in selected locations. Policies can use signals such as sensitive information types and sensitivity labels. Depending on the workload and configuration, responses include user notifications, policy tips, restrictions and alerts.
In Microsoft 365, Exchange Online, SharePoint Online, OneDrive and Teams require deliberate scoping. Teams messages and files shared through Teams are different coverage paths: files are stored in SharePoint or OneDrive, so protecting Teams conversations alone is not equivalent to protecting the associated documents.
Microsoft Purview Endpoint Data Loss Prevention extends controls to supported activities on onboarded devices. Examples include copying sensitive files to removable media, printing, and uploading through supported browser scenarios. Coverage depends on operating system, application, browser and policy configuration; endpoint onboarding alone does not establish every desired restriction.
Translate a business concern into a precise rule: identify the information, the activity, the destination and the required response.
Separate service and endpoint tests. An email restriction does not demonstrate that copying the same document to a USB device is controlled.
Use simulation and scoped pilots where supported before broad enforcement. Review matches and user impact, then adjust conditions and exceptions.
Give each enforcement decision an operational owner. If a policy permits an override with justification, decide who reviews that justification. If an alert is generated, define triage and escalation. A technically correct policy without a response process can still leave the organisation unable to explain what happened or why an exception was accepted.
4. Separate protection from retention and records management
Microsoft Purview Data Lifecycle Management and Microsoft Purview Records Management address how long information remains and what happens at the end of that period. Retention policies apply common retention settings across selected locations. Retention labels apply retention settings at item level and support more specific lifecycle requirements.
A sensitivity label and a retention label answer different questions and can coexist on supported content. For example, a contract may need restricted access because it is confidential, while also requiring retention under an approved records schedule. Encryption does not establish that schedule, and retention does not prevent an authorised user from disclosing the information.
Where requirements extend beyond basic retention, records management supports capabilities such as declaring records, event-based retention and disposition review, subject to licensing and configuration. Choose these features from an approved records requirement, not because they appear more rigorous than a simpler policy.
Record the business record category, retention period, starting event and disposal authority before creating policies.
Identify overlapping retention settings and legal holds. An individual policy’s deletion date does not, by itself, establish when content will be permanently deleted.
Test the lifecycle with representative content and explain expected user behaviour, including what happens when users edit or delete retained information.
Microsoft documents retention principles for resolving overlapping settings, including retention taking precedence over deletion. Review those principles before predicting outcomes. Retention also should not be treated as a general-purpose backup and recovery design: its primary purpose is preserving or deleting content according to configured requirements.
5. Distinguish investigation evidence from people-risk workflows
Microsoft Purview Audit provides searchable activity records for supported services and activities. Microsoft Purview eDiscovery supports case-based discovery workflows, including searching, preserving and exporting content, with additional review and analysis capabilities depending on entitlement. Audit helps establish recorded activity; eDiscovery helps locate and manage potentially relevant content.
Plan both before an investigation. Audit retention, available events and access permissions affect what evidence is available. Searchable content and preservation depend on supported locations, permissions and case configuration. A new policy or licence cannot be assumed to reconstruct evidence that is no longer available.
Later articles will cover Audit and eDiscovery capabilities associated with Standard and Premium entitlements. For eDiscovery, use Microsoft’s current experience and licensing documentation when planning deployment; do not build an operating procedure around screenshots or navigation from retired experiences.
Microsoft Purview Insider Risk Management and Microsoft Purview Communication Compliance serve different purposes. Insider Risk Management correlates configured signals to identify potential insider risks. Communication Compliance supports detecting and reviewing communications that match configured policies, such as inappropriate content or communications subject to regulatory review. Neither should be treated as an automatic determination of wrongdoing.
Require a documented purpose, authorised reviewers and an escalation process before activating people-related monitoring.
Use the relevant role groups and privacy controls to separate policy administration from access to sensitive investigation material.
Define how reviewers record context, resolve false positives and obtain legal, privacy or HR input when required.
Keep investigation authority separate from ordinary administration. Someone responsible for maintaining Microsoft 365 services does not automatically need permission to search employee communications or review insider risk cases.
6. Build a baseline, then deploy in controlled increments
Start in the Microsoft Purview portal at purview.microsoft.com, but validate entitlements and permissions separately from portal visibility. Licensing requirements vary by feature, workload and user scenario. Assign the least-privileged roles needed for each task rather than using Global Administrator as the routine operating model.
Inventory existing controls before adding new ones. As one limited example, an authorised administrator can use Security & Compliance PowerShell to list retention and DLP policy names. The following assumes the ExchangeOnlineManagement module is already installed and an appropriate account is used. These commands read configuration; they do not change policy enforcement.
Import-Module ExchangeOnlineManagement
Connect-IPPSSession
Get-RetentionCompliancePolicy |
Select-Object -Property Name
Get-DlpCompliancePolicy |
Select-Object -Property NameThis output is a starting inventory, not proof of effective coverage. It does not show all settings, rules, exceptions, deployment status or user impact. Review the full configuration in the relevant solution and run controlled tests against representative locations, devices and accounts.
Use Microsoft Purview Compliance Manager to organise assessments, assign improvement actions and record supporting evidence. Its compliance score reflects progress against scored actions in assessments; it is not certification, legal advice or a guarantee of compliance. Review Microsoft-managed and customer-managed responsibilities rather than assuming the service provider completes every requirement.
For the initial rollout, select one business process with a clear owner and manageable scope. Map its data, choose the necessary controls, test them, document exceptions and expand only after the responsible teams can operate the result.
Before expanding the pilot, complete this short checklist:
Ownership: every control has a business owner, technical owner and escalation route.
Coverage: workloads, locations, users and devices are explicitly identified.
Access and licensing: required entitlements and least-privileged permissions are confirmed.
Validation: positive and negative tests demonstrate intended protection and acceptable collaboration.
Operations: alerts, exceptions, retention conflicts and investigation requests have documented handling procedures.
7. Conclusion: build a connected control system
A useful Microsoft Purview programme connects classification, disclosure prevention, lifecycle management and investigation without confusing their purposes. Start with information and obligations, assign accountable owners, then configure and validate the appropriate capabilities. Keep evidence of both the policy decision and its tested behaviour.
The rest of this series develops each part of that map. Part 2 begins with sensitivity labels: designing a practical taxonomy, choosing protection settings and rolling out labels without making everyday collaboration unnecessarily difficult.
Learn about sensitivity labels
Learn about data loss prevention
Learn about retention policies and retention labels
Microsoft Purview Compliance Manager
Originally published on Solution Savy. Need help with this? Book a consultation.
