Configure Microsoft Purview: deployment guide

Kloudeal Journal · Business guide

Setting up Microsoft Purview requires defining what information is protected, who manages the policies, and how their impact is checked. This guide organizes permission preparation, classification, data loss prevention, and retention before extending controls to the enterprise.

Editorial review: 16 October 2026 · Reading time: 29 min

01Preparation

Licensing, administrative functions and data inventory.

02Controls

Labels, DLP, retention and auditing.

03Deployment

Simulation, user testing and operation.

Contents of this guide

Recommended order for configuring Microsoft Purview

Phase	What do we configure?	Purpose
1. Assessment	Data, locations, users, licenses and requirements.	Avoid designing policies without context.
2. Roles	Least privilege Purview permissions.	Separate administration, research and business.
3. Visibility	Data Classification, Activity Explorer, Content Explorer and DSPM.	Understand what exists before blocking.
4. Classification	Sensitivity Labels.	Create a common language for data.
5. Publication	Label policies.	Deliver the labels to pilot groups.
6.DLP	Policies in simulation mode.	Detect behavior and false positives.
7. Endpoint	DLP Endpoint.	Extend controls to the device.
8. On-premises	Information Protection scanner.	Discover and classify local repositories.
9. Enforcement	Tips, override and selective blocks.	Reduce risk without interrupting valid processes.
10. Research	Audit, eDiscovery and Data Security Investigations.	Being able to understand what happened.
11. Advanced risk	Insider Risk / Communication Compliance.	Manage specific use cases.
12. Government	Data Map and Unified Catalog.	Govern data assets beyond Microsoft 365.

Do you need to configure Purview but don’t know what to activate first?

We can review your tenant, licenses, sensitive data, SharePoint, OneDrive, Teams, endpoints and regulatory needs to define a pilot before introducing restrictive policies.

Review my Microsoft Purview settings

How to take a data protection case to a verifiable policy

To configure Microsoft Purview, your starting point must be a specific information risk. A request like “prevent sensitive data from leaving” needs to be translated into what data will be protected, where it is located, who is using it, and what action should trigger a warning or block. Without that detail, a policy can detect many events and provide little information to decide if it is working.

As an illustrative example, a department wants to control the sending of a document with customer data to external recipients. The pilot uses authorized test information and considers one shipment allowed, another that must be reported, and another that must be stopped according to the design. The notice that the user receives, the signal that reaches the responsible equipment and the record that allows us to investigate what happened is checked.

Simulation mode helps observe matches before applying constraints, but the results need revision. A match can be real data, an incorrect detection, or a process that requires a justified exception. The person responsible for the data must participate in this classification so that the adjustment does not depend only on the platform administrator.

What to resolve before publishing sensitivity labels

A label is useful when people understand in which cases they should apply it and what effect it will have. An extensive catalog with similar names can lead to inconsistent decisions. It is a good idea to start with categories that the business can explain with examples of documents, and check the result of sharing and opening labeled information from the applications that are used daily.

The publication must be accompanied by support and a way to correct errors. If document protection is added, the pilot should include relevant internal and external recipients. A properly classified file that cannot be opened by the authorized collaborator requires a design review before extending the policy to the rest of the organization.

Define the goal before setting up Microsoft Purview

Purview contains too many capabilities to start configuring without having a goal. An organization that only needs to prevent certain contracts from leaving SharePoint does not have the same project as another that needs to prepare an eDiscovery procedure, govern a data lake, or control data entered into AI applications.

Purpose	Solutions we should review
Classifying information	Information Protection, Sensitivity Labels.
Avoid external shipping	DLP.
Control USB or printing	DLP Endpoint.
Finding sensitive data on file servers	Information Protection scanner.
Know the global position of the data	DSPM.
Analyze an exhibition	Data Security Investigations.
Investigate user behavior	Audit / Insider Risk.
Legal investigation	eDiscovery.
Keep documentation	Data Lifecycle Management.
Manage records	Records Management.
Prepare Copilot	Permissions, DSPM, Information Protection, DLP, Audit.
Govern SQL/Fabric/data lakes	Data Map, Unified Catalog.

Create a goals document. Before the portal we recommend leaving in writing:

Field	Example
Data	Payrolls.
Owner	HR HH.
Location	SharePoint, endpoint.
Allowed	HR users HH.
Warn	Internal sharing outside of HR. HH.
Block	Unauthorized personal account/USB.
Retention	According to the company’s legal policy.
Exception	Controlled export for authorized supplier.

This little exercise prevents the technical department from having to decide on its own what “confidential data” means.

Recommended architecture: visibility before enforcement

A good Purview implementation should be able to be drawn as a succession of layers.

Cloak	Purpose	Tools
Discover	Know what we have.	DSPM, Data Classification, Explorer, scanner.
Classify	Understand the data.	SITs, classifiers, sensitivity labels.
Observe	See real behavior.	Simulation, Activity Explorer, Audit.
Educate yourself	Correct before blocking.	Policy Tips, notifications.
Protect	Apply restrictions.	DLP, Endpoint DLP, encryption.
Investigate yourself	Understand incidents.	Audit, eDiscovery, DSI, Insider Risk.
Govern	Continuous control.	Retention, Records, Data Map, Unified Catalog.

Skip the first layers and start directly with Protect It is one of the best ways to create problems.

Technical and organizational prerequisites

Before configuring Purview, it is advisable to check a minimum set of conditions.

Area	Check
Tenant	Microsoft 365 operating environment.
Users	Updated identities and groups.
Licences	SKUs and add-ons inventoried.
Roles	Identified responsible parties.
Data	Known critical locations.
Business owners	Responsible for the defined data.
Legal	Defined retention and research requirements.
Endpoints	Known operating systems and management.
SharePoint	Revised permissions and sharing.
Copilot	Current/future known scope.
Azure	Subscription available if we will use PAYG.
Pilot	Representative users and devices.

Don’t forget the applications. Before introducing encryption or DLP restrictions we must identify processes that automatically consume documents. For example: ERP, CRM, RPA, Power Automate processes, applications that generate PDF, OCR, signature solutions and applications that read files from SharePoint. The user can perfectly open a protected document while a legacy application stops processing it.

Roles and permissions: Do not use Global Administrator for convenience

Microsoft Purview has a system of roles and role groups so that each person has only the necessary capabilities. Permissions are currently managed from: Microsoft Purview portal → Settings → Roles and scopes. Guidance separation.

Responsibility	Access type
Label design	Information Protection Roles.
DLP Policies	Appropriate DLP/Information Protection roles.
Query for sensitive content	Content Explorer Content Viewer when essential.
Audit	Reading/research permissions.
eDiscovery	eDiscovery Manager / Administrators according to role.
Insider Risk	Specific Insider Risk roles.
Data Governance	Purview Administrators / Data Source Administrators / Data Governance according to task.

Two levels of sensitivity. Power is not the same: create a policy what power: view the exact content that caused a match. The viewing capabilities of sensitive content should be especially limited. Global Administrator also doesn’t see everything by default. For particularly sensitive solutions such as Insider Risk Management or Communication Compliance, Microsoft applies specific controls and we should not assume that being a Global Administrator automatically grants investigative access.

Official reference: Microsoft – Permissions in the Microsoft Purview portal.

Licensing and billing: check before you build

Purview currently uses two complementary models. Per-user licensing. It is mainly used for capabilities applied to: Microsoft 365 and Windows/macOS endpoints.

Pay-as-you-go

Extends Purview to certain scenarios: non-Microsoft 365 sources, data governance, AI applications, and other capabilities not tied directly to a user. Billing is typically associated with an Azure subscription.

Function	Model to review
Sensitivity Labels	Microsoft 365/Purview license per user.
Self-labeling	Advanced licensing according to function.
DLP Microsoft 365	Per user according to workload/capacity.
Endpoint DLP	Corresponding advanced licensing.
DSPM	It depends on the functionalities used.
Insider Risk	Advanced Purview/supported plan.
Audit Premium	Compatible plan/add-on.
eDiscovery	Per user license, PAYG for certain uses.
Data Security Investigations	Consumption/capacity.
Data Map / Unified Catalog	PAYG associated with Azure.

Do not assign licenses based solely on department. It may be more useful to determine: who generates the data, who manipulates it, who needs to be investigated/covered by a policy and who manages the solution. Official references:

Design the pilot before creating policies

The pilot should reproduce reality. It is not enough to select five IT users who know exactly what we are testing.

Profile	Why include it?
Standard user	Everyday experience.
HR HH. / Finance	Sensitive data.
User with external sharing	B2B cases.
User with automated processes	Compatibility.
Mobile user	Cross-platform experience.
Endpoint Windows	DLP Endpoint.
macOS Endpoint	If it exists in production.
Copilot user	AI controls.

Acceptance criteria. Before starting we define what success means.

Test	Acceptance
Apply label.	Visible and understandable.
Open encrypted document.	Authorized users access.
Share externally.	Policy acts as expected.
Automated process.	You are not affected unexpectedly.
DLP.	Acceptable false positive rate.
Endpoint.	Policy comes to the device.
Audit.	Localizable event.

Before blocking: use visibility capabilities

One of the advantages of Purview is that we can obtain information before imposing restrictions. The most useful tools for this phase are: DSPM, Activity Explorer, Content Explorer, Data Classification and Audit. What do we want to find out?

Question	Tool
Where does sensitive information appear?	Data Classification / Content Explorer.
How are labels used?	Activity Explorer.
What policies are generating events?	DLP/Activity Explorer.
What data is overexposed?	DSPM.
What did a user do?	Audit.

Configure Data Security Posture Management before adding more controls

Data Security Posture Management should be part of the initial phase of a modern Purview project. The current version is located at: Microsoft Purview portal → Solutions → DSPM. Not to be confused with classic experiences. Microsoft maintains references to: Data Security Posture Management (classic) and DSPM for AI (classic). For a new deployment we must work on the current DSPM experience when it is available to our tenant.

First use. On initial access DSPM can propose different configuration tasks to activate the signals you need. Instead of enabling them automatically, it is worth checking: what service activates each task, what data it processes and what licensing it involves. What to review.

Area	Question
Sensitive data	Where is it concentrated?
Overexposure	Who can access?
Unprotected data	Are there labels or policies missing?
User activity	Are there relevant behaviors?
AI	What data is used with Copilot/agents?
Recommendations	Which improvement has the greatest impact?

DSPM should not become a blind list of recommendations. Each recommendation should become a decision: accept → test → implement or discard → document reason. Official reference: Microsoft – Data Security Posture Management.

Data Classification, Content Explorer and Activity Explorer

These tools help us move from theory to reality. Content Explorer. Allows you to gain visibility into classified content and certain sensitive data. Access to content should be carefully limited by specific roles. Activity Explorer. Allows you to analyze activities related to: tagging, DLP, endpoints and other operations supported. What to look for before building DLP. For example: what types of sensitive data actually appear, on what sites, what departments use it, and how it is shared.

1. Create sensitivity labels

A label should express an understandable business meaning. Initial example.

Label	When to use it	Initial protection
Public	Content intended for publication.	No protection.
Internal	Information for internal use.	Visual classification.
Confidential	Clients, contracts, finances.	Protection according to case.
Highly confidential	Management, M&A, legal, secrets.	Encryption/restricted access.

Not protecting all of them from day one. During the pilot we can start using labels primarily for classification. Then we add: markings → encryption → DLP → restrictions only where they make sense. Current route in the portal. Microsoft Purview portal → Solutions → Information Protection → Sensitivity labels. Create the label: Select Create a label, Define name, Define administrative description, Define description for users, Select scopes, Configure protection when applicable, Configure markings if necessary, Review configuration and Create.

The user description matters a lot. Do not simply use: “Confidential information.” It is more useful: “Use this label for contracts, financial information, and client documentation that should not be shared publicly.” Official reference: Microsoft – Create and configure labels sensitivity.

Modern label scheme: important for new tenants

Microsoft is currently using a new modern label schema. The tenants created from the October 1, 2025, and specifically migrated tenants, use this modern experience. How to identify it. The portal itself displays information about the scheme on the label page. Why it matters. Some scripts, old procedures and screenshots from the Internet correspond to the classic scheme.

That is why we recommend: design and manage from the current portal first and use PowerShell only when there is a clear need.

2. Publish labels: creating a label does not make it visible to users

After creating the labels we must publish them. Current route. Microsoft Purview portal → Solutions → Information Protection → Publishing policies. First publication. We select a pilot group, not the entire organization.

Settings	Initial recommendation
Users	Pilot group.
Labels	Only the necessary ones.
Default label	Evaluate before imposing.
Mandatory labeling	Not necessarily in the first phase.
Downgrade justification	It may be useful.

Propagation time. We should not interpret a label that does not appear seconds after publishing the policy as being misconfigured. Policies require propagation and experience may vary by application. Minimal testing. Validate: Word, Excel, PowerPoint, Outlook, Office web, SharePoint and any critical application.

Labels for SharePoint, Teams, and Microsoft 365 Groups

Labels can also be used on compatible collaboration containers. They can control aspects such as.

Control	Example
Privacy	Private.
Guests	Do not allow guests.
SharePoint external sharing	Limit sharing.
Unmanaged devices	Restrictions.
Authentication Context	Additional Conditional Access.

Activate integration with SharePoint and OneDrive. In tenants where it is not yet enabled, Purview can display a banner to enable sensitivity labels support for Office files in SharePoint and OneDrive. It is advisable to check this before designing auto-labeling for these workloads. Official reference: Microsoft – Sensitivity labels for groups and sites.

3. Set up auto-tagging

Self-tagging can reduce dependence on manual user decisions. But it should come after you have a mature taxonomy. Current route. Microsoft Purview portal → Solutions → Information Protection → Policies → Auto-labeling policies. Recommended process.

Step	Action
1	Select an existing label.
2	Define information that must match.
3	Limit locations.
4	Run simulation.
5	Review results.
6	Adjust conditions.
7	Apply in small scope.
8	Expand.

Do not automate bad classification. If a rule incorrectly identifies the data, auto-labeling will simply make the problem apply on a larger scale. Official reference: Microsoft – Automatically apply labels sensitivity.

4. Configure Data Loss Prevention

DLP allows us to define what behavior we want when certain data is used in a specific way. Route. Microsoft Purview portal → Solutions → Data Loss Prevention → Policies. Process: Select Create policy, Select template or Custom, Define Admin Units if used, Select locations, Define conditions, Define actions, Configure notices, Configure alerts, Select simulation mode and Review before enforcement. Design the rule in natural language before the portal.

For example:

If a user attempts to externally share a document labeled “Highly Confidential,” log the event, display a warning, and raise an alert to the security team during the pilot.

Then we turn that phrase into conditions and actions. What a policy can use. Among other signs: Sensitive Information Types, sensitivity labels, classifiers, sharing context, users, groups and locations.

Simulation mode: test DLP before blocking

Current Microsoft documentation recommends using simulation mode to test and tune DLP policies. Simulation allows you to check which elements would match the policy without necessarily applying the restrictive actions. What to check during the simulation.

Metrics	What are we looking for?
Matches	Does it detect the correct data?
False positives	What are you misidentifying?
Users	What departments are affected?
Locations	Where do events appear?
Volume	Is the policy too general?
Exception	Are there legitimate processes?

A practical sequence. Simulation → Policy Tip → Block with override → Block It is not a technical obligation, but it is a good way to progressively increase control. Official reference: Microsoft – Test your DLP policies.

DLP Pilot Example

Suppose we want to reduce the external sending of financial information.

Phase	Settings
Scope.	10 Finance users.
Location	Exchange, SharePoint, OneDrive.
Detection	Financial SITs, Confidential label.
Week 1	Simulation.
Week 2	Policy Tips.
Week 3	Override with justification.
Week 4	Blocking only for higher risk cases.

What we document. false positives, exceptions, volume, users, affected processes and adjustments made.

5. Configure Endpoint DLP

Once the file is downloaded from SharePoint to the device, cloud policies are no longer enough to control everything that happens with it. Endpoint DLP extends the DLP model to the operating system. You can monitor or control actions such as.

Action	Example
USB	Copy sensitive file.
print	Print regulated information.
Clipboard	Copy content.
Browser upload	Upload to a cloud service.
Network share	Copy to a certain location.
Application	Use from unauthorized application.

Supported systems. Current documentation covers supported Windows devices and macOS built into Purview. For macOS, Microsoft maintains support for the three most recent major versions in the documented context of Endpoint DLP. Official reference: Microsoft – Get started with Endpoint DLP.

Device onboarding for Endpoint DLP

Intune is a very common option, but not the only one. Windows. Microsoft documents methods such as: Intune, Group Policy, Configuration Manager, and local script depending on the scenario. macOS. Can be used: Intune or JAMF Pro in supported scenarios, including integrations with Defender for Endpoint. This is important. We should not write in the scope of a project that: “Endpoint DLP requires Intune” if we have not previously reviewed the client’s onboarding method.

Check device health before enforcement

Microsoft Purview currently has a device health reporting dashboard. Route. Settings → Device onboarding → Device report. What to review.

Indicator	Use
Onboarding	Is it incorporated?
Connectivity	Are you reporting?
Policy readiness	Can you receive policies?
Feature readiness	Does it meet requirements for functionality?
Last seen	When did you last report?

Rule of thumb. Do not convert an Endpoint DLP policy to Block if we do not first know what percentage of devices are actually prepared to receive it. Official reference: Microsoft – Endpoint DLP device health dashboard.

Design Endpoint DLP Controls Progressively

Scenario	Pilot	Future production
Confidential → USB.	Audit.	Block with override.
Highly confidential → USB.	Alert.	Block.
PII → print.	Audit.	Override when applicable.
Sensitive data → personal cloud.	Audit, alert.	Block.

Exceptions may be more precise than “exclude user.” Endpoint DLP allows you to design controls over: groups of printers, devices, networks, applications and other supported contexts. This allows you to avoid huge exceptions like: “Finance is left out of DLP.”

6. Microsoft Purview Information Protection scanner

The Information Protection scanner It remains an important tool when the organization maintains information in local repositories. It was previously known as: Azure Information Protection unified labeling scanner and on-premises scanner. Currently you can work with. UNC network shares via SMB, NFS in preview, and SharePoint Server libraries/folders in supported versions. What can you do?

Mode	Result
Discovery	Detects without modifying.
Classification	Identifies content.
Labeling	Apply compatible labels.
Protection	Applies protection when the label requires it and the file supports it.

It does not work in real time. The scanner systematically scans the configured repositories. It can be run once or scheduled periodically. Official reference: Microsoft – Information Protection scanner.

Information Protection scanner architecture

The scanner works as a service on Windows Server. An implementation needs to review:

Component	Function
Windows Server	Run the service.
SQL Server	Configuration database.
Scanner cluster	Group instances.
Service account	Run the service.
Content scan job	Defines repositories and behavior.
Entra token	Service authentication.
Purview client	Components necessary for classification/protection.

Scaling with multiple nodes. Microsoft allows multiple nodes to be deployed using the same scanner cluster and database. This can be useful when there is a large volume of repositories.

Install and configure the scanner

1. Create cluster. From: Microsoft Purview portal → Settings → Information Protection → Information protection scanner. In Clusters, create the cluster. 2. Create content scan job. Define: repositories, schedule and scanning behavior. 3. Prepare Windows Server. Review official prerequisites, service account and connectivity.

4. Install the scanner

Install-Scanner `
    -SqlServerInstance "SQLSERVER\INSTANCE" `
    -Cluster "Purview-Europe"

5. Configure authentication. Prepare the Microsoft token Entra following the current procedure. 6. Run discovery. Before allowing the scanner to modify files. 7. Review results. Evaluate: volume, file types, sensitive information, errors and performance. 8. Enable classification/protection. Only after the pilot. Official reference: Microsoft – Configure and install the Information Protection scanner.

Discovery before applying labels to millions of files

The first job should prioritize visibility. Example.

Repository	First action
`\\fileserver\RRHH`	Discovery.
`\\fileserver\Finanzas`	Discovery.
`\\fileserver\Legal`	Discovery.
`\\fileserver\Publico`	Lower priority.

What do we want to know? what files exist, what can be inspected, what sensitive information appears and what would happen if we applied the current labels. Then we design enforcement. Not the other way around.

Do you have file servers in addition to Microsoft 365?

We can review whether it is appropriate to use the Information Protection scanner to locate sensitive information before migrating, tagging or protecting entire repositories.

Review repositories and Purview Scanner

7. Prepare Insider Risk Management

Insider Risk should not simply be the next box on the technical roadmap. Before configuring it we have to agree: objective, legal basis, responsible parties, privacy, investigation procedure and escalation. Participants.

Team	Responsibility
Security	Signals and technical research.
Legal	Legal framework.
HR HH.	Labor procedures.
Compliance	Policy and requirements.
Management	Approval of use cases.

Specific use cases. It is preferable: “analyze possible movements of employee data in the formal exit process” that: “monitor all users in case they do something strange.” Privacy. Microsoft includes mechanisms such as pseudonymization and separation of roles, but this does not replace the legal and labor evaluation of each organization. Official reference: Microsoft – Plan for Insider Risk Management.

8. Configure Communication Compliance when a use case exists

Communication Compliance is aimed at reviewing certain compatible communications when they exist: regulatory requirements, conduct risk, sensitive information or business communication policies. Before creating policies. Define: what communications, what users, what risk, who reviews and what procedure exists after a match. Do not use generic reviewers. Access should be limited to authorized personnel and use the specific roles available.

9. Configure Microsoft Purview Audit

Audit is one of the first solutions that should be reviewed because it will be essential to investigate the rest of the environment. Current status. Audit Standard is enabled by default for organizations with corresponding subscriptions. Retention.

Capability	Relevant current retention
Audit Standard	180 days.
Audit Premium	Up to one year depending on workload/license and default policy.
Long-term	Up to 10 years with corresponding add-on.

The policy is not retroactive. If we need to keep records for several years, we must prepare the retention before they disappear. What to test. Find events related to: SharePoint, Exchange, OneDrive, Teams, administrative activity, DLP and eDiscovery. Official reference: Microsoft – Audit solutions.

10. Set up eDiscovery before an actual investigation

The modern eDiscovery experience is organized around cases. Initial preparation.

Step	Purpose
Roles	Who can investigate?
Procedure	Who requests the case.
Case naming	Nomenclature.
Search	Technical test.
Hold	Validate preservation.
Export	Chain of custody.

Create a lab case. It is better to discover how searches, permissions, holds and exports work now than to do it while legal waits for urgent results. Review sets. Advanced capabilities allow you to copy content to review sets to: search, filter, tag, analyze near-duplicates, review conversations and apply other analysis functions. eDiscovery and PowerShell in 2026. There is an important technical change. To use eDiscovery cmdlets like: *-ComplianceSearch or New-ComplianceSearchAction Microsoft currently requires: ExchangeOnlineManagement 3.9.0 or later, Connect-IPPSSession -EnableSearchOnlySession.

Official reference: Microsoft – eDiscovery features and components.

11. Data Security Investigations

A modern Purview architecture should also consider how we will respond when a data incident occurs. Data Security Investigations can help understand what sensitive information was involved. Example. A compromised account downloads 2,000 documents. Audit can help us determine: What activity did you do? Data Security Investigations can help us analyze: what type of information was within the potentially affected set.

Billing. The solution uses models of: storage, AI capacity. Therefore, before enabling it we must configure and estimate costs. Proactive AI insights. Certain proactive insights configurations from DSPM may cause periodic processing and therefore consumption while they remain enabled. Official reference: Microsoft – Data Security Investigations.

12. Retention and Records Management

Configuring protection without defining the lifecycle leaves the project incomplete. Questions. For each category: How long should it be kept? Who decides? Can it be eliminated sooner? What happens when it expires? Is it a formal record?

Concept	Use
Retention Policy	Retention at scale by location/population.
Retention Label	Specific life cycle of the element.
record	Greater formal control over information.
Disposition	Review before deletion when configured.

Don’t keep everything indefinitely. “Just in case” is not a lifecycle policy. You can increase: eDiscovery volume, costs, exposure and complexity.

13. Set up Purview before and after Microsoft 365 Copilot

Copilot makes it even more important to know your permissions and data. Before expanding Copilot.

Area	Review
SharePoint	Sites opened unnecessarily.
OneDrive	External links.
Teams	Memberships and guests.
Labels	Identified sensitive data.
DLP	Priority use cases.
DSPM	Overexposure and AI posture.
Audit	Traceability.

Purview is not a substitute for Permissions Governance. The first fix for a document accessible in error remains: correct permission. Then we use labels, DLP and other protections. Official reference: Microsoft – Purview for Microsoft 365 Copilot.

14. Configure Data Map and Unified Catalog

This part should be treated as a project Data Governance, not as a direct extension of DLP. Important business prerequisite. The modern Data Governance experience currently uses pay-as-you-go. We need: Azure subscription in the same tenant, resource group. Guidance process.

Phase	Action
1	Set up PAYG.
2	Define governance domains.
3	Assign data owners.
4	Connect/discover sources.
5	Review Data Map.
6	Create glossary terms.
7	Create data products.
8	Define critical data elements.
9	Measure data health.

Current billing. The modern PAYG model came into effect for this experience on January 6, 2025. Currently there are meters related to: governed assets and data governance processing. Do not scan the entire environment on the first day. Start with: a domain, a platform or a really important data product. Official reference: Microsoft – Billing in Microsoft Purview Data Governance.

Current PowerShell for Microsoft Purview

PowerShell is still useful, but we no longer recommend building an entire deployment around old scripts. The current portal should be the reference for initial design and configuration, especially with the modern labeling scheme.

Security & Compliance PowerShell

The module is used: ExchangeOnlineManagement.

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Import-Module ExchangeOnlineManagement

Connect-IPPSSession -UserPrincipalName admin@empresa.com

REST. Current versions of the module use REST mode for virtually all Security & Compliance compatible, avoiding the historical dependency of Basic Authentication on WinRM.

eDiscovery

When we are going to use the Compliance Search cmdlets:

Connect-IPPSSession `
    -UserPrincipalName admin@empresa.com `
    -EnableSearchOnlySession

This modality currently requires ExchangeOnlineManagement 3.9.0 or later.

Inventory labels

Get-Label |
    Select-Object Name,DisplayName,Guid,Priority

Inventory publishing policies

Get-LabelPolicy |
    Format-Table Name

Inventory DLP policies

Get-DlpCompliancePolicy |
    Select-Object Name,Mode

Review distribution of a DLP policy

Get-DlpCompliancePolicy `
    -Identity "DLP - Finanzas" `
    -DistributionDetail |
    Format-List Name,DistributionStatus

Inventory DLP rules

Get-DlpComplianceRule |
    Select-Object Name,Policy,Disabled

Test a DLP policy on a SharePoint/OneDrive file

Test-DlpPolicies `
    -Workload ODB `
    -FileUrl "https://tenant-my.sharepoint.com/personal/usuario/Documents/Contrato.docx" `
    -SendReportTo "dlp-admin@empresa.com"

This cmdlet can be especially useful for checking which rules match a specific element.

Search audit

$Start = (Get-Date).AddDays(-7)
$End   = Get-Date

Search-UnifiedAuditLog `
    -StartDate $Start `
    -EndDate $End `
    -ResultSize 5000

Large audit volumes. Search-UnifiedAuditLog has paging mechanisms and can use SessionCommand ReturnLargeSet, but for high-volume programmatic integrations Microsoft recommends using appropriate APIs such as the Microsoft 365 Management Activity API.

Microsoft Graph for user inventory

If we need to cross users and licenses we can use Microsoft Graph PowerShell instead of the legacy AzureAD or MSOnline modules.

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"

Get-MgUser -All `
    -Property DisplayName,UserPrincipalName,AccountEnabled |
    Select-Object DisplayName,UserPrincipalName,AccountEnabled

Do not publish destructive scripts in an article as a universal recipe. To create labels, policies, encryption, auto-labeling or retention at scale we prefer: portal → validation → documentation → controlled automation. This reduces the probability of a reader copying a script without adapting scopes, licenses or tenant version. Official references:

Reporting: what metrics to review after implementing Purview

Measuring only how many policies we have created does not contribute much.

KPIs	What does it tell us?
Label Coverage	Classification adoption.
DLP matches	Detected risk volume.
False positives	Quality of policies.
User overrides	Processes that require review.
Endpoint events	Behavior on devices.
Device readiness	Endpoint DLP technical coverage.
External sharing	Information exhibition.
Unprotected sensitive data	Coverage gaps.
DSPM recommendations	New risks.
Audit availability	Research capacity.

The most important KPI. It should be: Are we reducing a real risk situation without generating a disproportionate operational burden?

Practical Microsoft Purview Setup Roadmap in 90 Days

Days 1–15: assessment and visibility.

Action	Result
Review licenses.	Capability map.
Define roles.	Minimum privilege.
Identify sensitive data.	Scope.
Review SharePoint/OneDrive.	Locations.
Review DSPM.	Risk baseline.
Review Audit	Traceability.
Create pilot group.	Representative users.

Days 16–30: classification.

Action	Result
Design labels.	Taxonomy.
Create sensitivity labels.	Classification.
Post to pilot.	Real test.
Try Office.	Compatibility.
Test encryption.	Applications.
Train pilot.	Feedback.

Days 31–45: DLP in simulation.

Action	Result
Create pilot DLP.	Politics.
Simulation mode.	No lock.
Activity Explorer.	Events.
Check false positives.	Tuning.
Configure alerts.	SOC Visibility.
Documenting exceptions.	Government.

Days 46–60: Endpoint and limited enforcement.

Action	Result
Onboard endpoints.	Coverage.
Device Health.	Readiness.
Endpoint simulation.	Events.
Policy Tips.	Education.
Override.	Controlled flexibility.
Critical locks.	Selective protection.

Days 61–75: on-premises and research.

Action	Result
Evaluate scanner.	Local Scope.
Discovery scan.	Inventory.
Review Audit	Research.
Configure eDiscovery test.	Readiness.
Define retention.	Lifecycle.
Evaluate DSI.	Incident response.

Days 76–90: government and next iteration.

Action	Result
DSPM Review.	Pending risks.
Pilot self-labeling.	Automation.
Insider Risk assessment.	Advanced risk.
Copilot readiness.	AI.
Data Map assessment.	Data Governance.
Executive report.	State.
Roadmap quarter 2.	Continuous improvement.

Common errors when setting up Microsoft Purview

Error	Consequence	Better approach
Start with DLP.	We don’t know what we want to protect.	Perform an assessment first.
Do not review DSPM.	We design blindly.	Use posture as input.
Create too many labels.	Bad adoption.	3–5 categories initially.
Encrypt massively.	Affected applications.	Pilot.
Post labels to everyone.	Overall impact.	Pilot group.
Ignore modern label schema.	Old scripts/procedures.	Review current tenant.
Activate DLP directly.	Locks.	Simulation mode.
Do not check false positives.	noise.	Tuning.
Create exclusions for entire departments.	Security holes.	Precise exceptions.
Assume Endpoint DLP requires Intune.	Incorrect design.	Check compatible onboarding.
Do not check Device Health.	Policies that do not arrive.	Validate readiness.
Scanner directly in enforcement.	Massively modified files.	Discovery first.
Use old AzureAD/MSOnline scripts.	Legacy automation.	Graph, current cmdlets.
Automate labels before validating them.	Scale error.	Manual/pilot first.
Give Global Admin to everyone.	Excessive privilege.	RBAC Purview.
Do not prepare Audit.	Lack of future traceability.	Check retention.
Do not prepare eDiscovery.	Legal improvisation.	Test case.
Ignore ExchangeOnlineManagement version.	eDiscovery cmdlets fail.	Review current requirements.
Confuse Data Map with DLP.	Mixed objectives.	Separate governance/security.
Ignore PAYG.	Unexpected cost.	Configure and monitor billing.
Activate Insider Risk without legal.	Occupational risk/privacy.	Multidisciplinary government.
Prepare Copilot with DLP only.	Excessive permissions still exist.	Check access first.
Do not measure.	We don’t know if it improves.	KPI and quarterly review.

Checklist to configure Microsoft Purview

Area	Status
Objectives	Defined.
Critical data	Identified.
Owners	Assigned.
Licences	Inventoried.
PAYG	Evaluated.
Roles	Minimum privilege.
Global Admin	Minimized usage.
Pilot	Assigned.
DSPM	Revised baseline.
Content Explorer	Controlled access.
Activity Explorer	Reviewed.
SITs	Selected.
Labels	Taxonomy created.
Modern label schema	Verified.
Publishing policy	Pilot.
Encryption	Tested.
SharePoint labels	Revised integration.
Self-labeling	Simulation.
DLP	Simulation mode.
False positives	Measurements.
Policy Tips	Evaluated.
Overriding	Defined justification.
DLP alerts	Responsible.
Endpoint onboarding	Defined plan.
Device health	Reviewed.
Endpoint simulation	Completed.
USB	Defined policy.
Printing	Defined policy.
Cloud upload	Defined policy.
Scanner	Need assessed.
Scanner discovery	Executed before enforcement.
Audit	Operational.
Audit retention	Defined.
eDiscovery	Test case.
eDiscovery PowerShell	Current module.
Data Security Investigations	Evaluated.
Retention	Requirements defined.
Records	Evaluated.
Insider Risk	Legal involved.
Communication Compliance	Defined use case.
Copilot	Revised permissions.
Data Map	Scope defined.
Unified Catalog	Defined data owners.
Reporting	Defined KPIs.
Exceptions	Owner and expiration.
Documentation	Updated.
Review	Periodic cycle.

Frequently asked questions about setting up Microsoft Purview

Why shouldn’t you activate all Purview features when you get started?

Each capability addresses a different problem and may require its own licenses, permissions, data, and procedures. Starting with a limited case allows you to check detections, user experience, and team response. The scope is then expanded with evidence of operation, rather than maintaining controls that no one knows how to interpret or manage.

Does creating a label make it available to every user?

Creating and publishing are different steps. You should check which users the label is published to, what apps it appears in, and what behavior it will have. The pilot includes representative documents and relevant recipients, so that the label can be applied and the associated protection allows authorized use of the information.

What should be checked in a DLP simulation?

Matches and their context are reviewed, not just the total number of events. We must distinguish real data, incorrect detections and legitimate processes that require adjustment. It is also confirmed who will attend to the notices and how exceptions will be resolved. This review makes it possible to decide which conditions are ready to move to effective control.

Does a Purview configuration alone ensure compliance?

The technical configuration is a part of the information protection and governance system. Its usefulness also depends on business decisions, procedures, permissions and subsequent operation. The project should document what requirements each control covers and what aspects continue to need review and management by the organization.

Final Recommendations: Configuring Purview Means Designing a System, Not Enabling Features

Set up Microsoft Purview correctly requires first understanding what information exists and what risk we want to reduce. The sequence matters. Before blocking we must discover. Before automating we must classify. Before encrypting we must test. Before investigating we must prepare Audit and eDiscovery. And before governing thousands of assets we have to define who is really responsible for them. The current Microsoft Purview experience allows you to start by DSPM to obtain a vision of the data posture and complement it with Data Classification, Content Explorer and Activity Explorer.

We can then build a simple taxonomy of sensitivity labels and publish it to a pilot group. DLP policies should start in simulation mode. This phase allows us to observe which data matches, which departments would be affected and how many false positives appear before applying restrictions. When data leaves Microsoft 365 and reaches the device, Endpoint DLP extends controls. But we should not enable locks until we verify that the devices are correctly onboarded and prepared. The new Device Health dashboard facilitates precisely this validation.

For information stored on file servers or SharePoint Server it is still possible to use the Microsoft Purview Information Protection scanner. The procedure should still start in discovery mode before allowing an automatic process to modify or protect thousands of files. Research constitutes another different layer. Audit helps us determine what activity occurred. eDiscovery allows content to be preserved and reviewed for formal investigations. Data Security Investigations adds capabilities to analyze what sensitive information may have been compromised in an incident.

Insider Risk Management and Communication Compliance should only come when there is a clear organizational, legal and operational basis. Finally, Data Map and Unified Catalog extend Purview into enterprise data governance, with a different business model based on pay-as-you-go. This is why an entire Purview project cannot be reduced to a list of buttons. The final question should not be: “How many Purview features have we activated?”

Otherwise: “Do we know what important data we have, who can access it, how it is used, what actions we have decided to allow or prevent, and how we will investigate an incident when it occurs?” When we can answer those questions with real data and procedures, Purview begins to provide value.

Do you need to configure Microsoft Purview in your company?

In Kloudeal We can help you review the environment, design the architecture, and deploy Microsoft Purview progressively, starting with the use cases that make the most sense for the organization. We can work on DSPM, Data Classification, Sensitivity Labels, Information Protection, DLP, Endpoint DLP, Information Protection scanner, Audit, eDiscovery, Data Security Investigations, Insider Risk, Communication Compliance, Retention, Records Management, Data Map, Unified Catalog and Microsoft 365 Copilot preparation.

We can also review existing licenses and differentiate which capabilities are already available, which require add-ons, and which use a pay-as-you-go model associated with Azure.

Request valuation from Microsoft Purview