rss.livelink.threads-in-node

# Seeking Feedback – Microsoft Purview Governance Domain Metamodel

sashakorniakUK — Fri, 19 Jun 2026 11:47:56 GMT

I've been working on a proposed metamodel for some time to help organisations decide how to structure Governance Domains within Microsoft Purview and would appreciate feedback from others who have implemented Purview at scale.

The intention is not to prescribe a single approach, but to describe several governance patterns that seem to emerge in practice.

Some additional assumptions I've made:

* Numeric prefixes such as `01.01.01` help maintain sort order and readability.

* Standardising on three levels appears easier to manage, although Purview supports five levels.

* Microsoft guidance suggests keeping Governance Domains to approximately 200.

* Governance Domains themselves are relatively flexible and can be renamed or repositioned within the hierarchy.

* Data Products currently appear to be bound to the Governance Domain in which they are created and cannot presently be reassigned to another Governance Domain, making early design decisions more important.

I'm interested in hearing from organisations already using Governance Domains in production.

A few questions for discussion:

Have you adopted one of these patterns, or a hybrid approach?

Are there Governance Domain types missing from this metamodel?

Is the recommendation of standardising on three hierarchy levels sensible, or have you found deeper structures manageable?

Are there any Microsoft best practices, roadmap items or implementation experiences that would suggest a different approach?

I've attached an infographic illustrating the proposed metamodel and would welcome any thoughts, criticism or lessons learned from real-world implementations.

Managed VNET Integration Runtime failing with 502 error.

DevonBritton — Thu, 18 Jun 2026 14:12:58 GMT

Good afternoon everyone.

I'm a DevOps Engineer who is new to Purview.

I used Terraform to deploy a Purview account for a POC for a client, however, I'm having a real issue creating a Managed VNET IR. The private endpoints are all visible and approved and if I check in the shell I can see the IR and the Managed VNET both exist (names sanitized).

{ "name": "SAMPLENAME", "properties": { "managedVirtualNetwork": { "referenceName": "ManagedVnet-name" }, "typeProperties": { "computeProperties": { "location": "WestEurope" } } } }

But in the Purview portal the status shows as failed and if I try update it, I get a popup notification stating that the process timed out due to a 502 error. The URL in the error is "

https://api.purview-service.microsoft.com/scan/integrationRuntimes/{NAME}?api-version=2022-02-01-preview"

I thought this might be an issue with permissions or that I'm not in the admin role group in my client environment so I did the same process in my local purview account (where I'm global admin and in the Purview Administrators role group) and I'm having exactly the same problem. The managed vnet and IR exist when queried in the cloud shell but the state in the portal shows as failed.

I am a "Data source Admin" in both purview accounts but I'm wondering if there's some other role assignment or role group assignment that I'm missing?

Thanks in advance.

Devon Britton.

Terribly lost - what are the basic controlls here?

underQualifried — Wed, 17 Jun 2026 13:12:07 GMT

Hello all. I'm an MSP, looking at methods of securing data in the wake of AI adoption. Obviously, I'm getting pointed to Purview for this. And I've managed to make sense of SOME of it - sensitivity labels, labeling policies, and sensitive info types.

The problem I have is that these 'solutions' are spread out amongst 3-4 different 'solutions' - Information Protection, DLP, DSPM (DSPM,, DSPM classic, DSPM for AI 'classic') and it's genuinely just really badly designed. It's done the classic Microsoft move of having the Marketing team build the interface, and caring more about market capture/buzzwords than usability. As is the norm, the documentation quality varies a ton. And between Intune, SharePoint, Entra, Defender, Azure, certifications - I don't actually have time to learn another market-capture tool, which I will use 2% of.

We don't license Purview. And I'm not going to license Purview until some effort is put into usability, and the interface is redesigned by native, technical english speakers (no hate, but I've seen first-hand how MBAEnglish-as-a-second-language translates into this sort of opacity). But obviously, we HAVE to use it because a bunch of stuff was pushed into it.

Without adding another set of half-automated Microsoft recommendations to my list, and avoiding premium 'solutions' - what are the basic 'solutions' that are required for Data controls, in the face of AI? What exactly was merged into Purview, that existed elsewhere previously? Here is what I've gotten familiar with so far:

1. DLP policies. These are pretty opaque to me, and seem to heavily rely on OTHER 365 products, like Defender for Endpoint, Edge for Business. So again, designed by the marketing team.
2. Sensitivity labels, labeling publishing policies, auto-labeling policies.

What am I missing?

Best approach for contractor block policy

Rk10 — Wed, 17 Jun 2026 04:44:21 GMT

Hello there I need some assistance with your best approach for vendor block policy. I am thinking to create one policy with three rules

Block all vendors with the block AD group
Vendors to allow emails to approved domains only
vendors to send email to external to organisation with ability to send to approve domains

Do you think this is a good approach by breaking down into three different rules ? Also I am bit confused with the conditions on the rule 2 and rule 3.

what would you your approach with complete breakdown ?

Anthropic Claude Purview Data Connector showing all users as Guests..

Jroth — Thu, 11 Jun 2026 17:34:07 GMT

It appears this connector is not mapping fields properly causing internal users to be mapped as "guests", and since prompts/data isn't maintained for guest users the connector is effectively not gathering anything but noise. Unlike the other data connectors, one cannot create field mappings. Also the app being named using the guid of Microsoft's own "dataassessments" service principal I don't think is intended either. Has anybody else experienced this? See below for an example.

Enhancements to Device Status API & Logged-In User Email in Endpoint DLP

Harysh9 — Fri, 05 Jun 2026 19:34:11 GMT

1. The Real‑World Problem Endpoint DLP analyst Faced (What Was Missing Earlier)

Before the introduction of the Device Status API enhancements and logged‑in user visibility, Endpoint DLP teams consistently struggled in below discussed areas:

Device Visibility Was Fragmented and Manual - Customers repeatedly told us:

We know some devices are unhealthy, but we don’t know who owns them.
We export the onboarding table to Excel every week just to understand drift.
By the time we detect a policy issue, the user is already blocked or impacted.

In practice, this meant:

Device onboarding views were static snapshots, not operationally actionable.
Admins relied on manual Excel exports to track onboarding, drift, and health.
Reporting pipelines were brittle and always out of date.

2. Device Status API: Why Customers Asked for This (Beyond “Reporting”)

The Hidden Cost of Excel‑Driven Operations as earlier, customers had to:

Export device onboarding data manually.
Rebuild dashboards every time they needed updated insight.
Repeat this process weekly or even daily for compliance and SOC reviews.

This approach failed at scale and created blind spots during incidents. When a device policy sync failed or appeared unhealthy, admins had no real‑time, view to answer basic questions like:

Is this device configured correctly?
Is the OS or Defender version lagging?
Is the issue widespread or isolated?

3. What the Improvement Unlocks (New Operational Reality)

From Static Views to Continuous Monitoring with the Device Status API:

Device health, configuration status, policy sync state, OS version, and Defender version become query able signals
Customers can power custom reporting and Advanced Hunting queries that are always current
SOC and Endpoint teams finally share a single source of device truth

This fundamentally changes how customers monitor Endpoint DLP not as a setup task, but as a living control plane. The Device Status API directly addresses this gap by making device‑level status continuously available through Advanced Hunting, allowing customers to build living dashboards instead of static reports.

4. The Old Workflow (Customer Pain)

Historically, when a device showed:

Policy Sync Failed
Unhealthy
Configuration mismatch

Admins had to:

Leave the Purview console
Open Microsoft Defender for Endpoint or Intune
Correlate device IDs or names
Identify the user
Start remediation

This context‑switching cost time, accuracy, and confidence.

5. The New Reality: User Context Where It Matters

Admins can now see who is logged in directly on the device onboarding page, aligning Windows with the macOS experience like:

Immediate user context during device issues.
Faster outreach and remediation.
One unified investigative surface.

What used to require three portals and multiple teams now happens in One Place.

6. When Customers Actually Needed This Data (But Didn’t Have It)

This improvement wasn’t driven by curiosity it was driven by failure points in production. Some of the common customer scenarios listed below:

Scenario	Before	Now / After Improvement
Scenario 1: Quarterly Compliance Reviews	Teams exported Excel files days before audits, resulting in stale data. Auditors questioned the reliability of reports.	Advanced Hunting queries power live compliance dashboards. Reports are defensible because the data is always current.
Scenario 2: Incident Post‑Mortems	Teams struggled to answer whether devices were healthy at the time of the incident or if policies were enforced versus just configured. Reviews relied on assumptions.	Device status, policy sync state, and OS/Defender versions are query able facts. Incident reviews shift from guesswork to evidence‑based analysis.
Scenario 3: Silent Policy Drift	Devices drifted due to OS updates, sensor lag, or configuration changes. Issues surfaced only after a DLP violation occurred.	Policy drift becomes detectable before enforcement failures. Endpoint DLP acts as a reliability signal rather than a last‑line alarm.

7. New enhancement on Device Status API

Device status API provides admins with access to device level information to integrate onboarded device information to custom reporting or use in advanced hunting queries.
It has helped admins track down users associated with devices instead reaching out to Entra, on-premises Active Directory, or Intune team.
During troubleshooting, if a device is not receiving policies on time, the device API allows quick identification of the device owner and assists in enabling always-on diagnostics or collecting logs directly from the device via Purview console.

8. Steps to capture User UPN

Admin can find the device status by login to Security.microsoft.com as security admin. Click on Investigation and responses > Hunting > Advanced hunting.
Device data can be found under DLPInfo JSON Column in the Deviceinfo table

3. Once we run above or any custom query as per requirement, you would see below as response.

4. Click on the loggedonuser field and expand the right-side information and look for DLPUPN under inspect record.

9. User login details on the Purview onboarding page

Admins now can see who is currently logged in on the device onboarding page. This update aligns the Windows experience with macOS, allowing admins to respond quickly if necessary.
In the past, when a device displayed a "Policy Sync Failed" or "Unhealthy" status, it was necessary to switch to Microsoft Defender for Endpoint (MDE) or Intune to identify the affected user. With this update, all relevant information is now accessible in a single view, streamlining the process.

Benefits -

Admins gain faster confirmation of device ownership and user context without extra investigation.
It simplifies troubleshooting onboarding or policy issues by surfacing the user alongside other device insights like status and IP.
No impact on users or DLP policies occurs, and it's enabled by default with no action required.

10.Steps to find User UPN on Purview admin console

Final Takeaway: Why This Matters More Than It First Appears

"These enhancements evolve Endpoint DLP from a static, deployment‑centric control into a continuously observable, user‑context aware security signal, significantly reducing investigation time, operational overhead, and trust gaps at scale"

Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance

Inwafula — Tue, 09 Jun 2026 21:17:12 GMT

Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure?

This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies.

Fig 1. AWS console page showing "ExpenseApprovalAgent" details of the Agent blade

Why Purview should be the central policy engine

Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made.

That is the value proposition for Microsoft Purview in cross-cloud AI scenarios.

Purview gives you:

A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content.
A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments.
A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams.
A way to apply data-aware controls to AI interactions, not just to storage locations.

In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well.

The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists.

What this Bedrock agent demonstrates

The sample solution in this blog is a cross-cloud AI pattern:

The frontend is a single-page browser-based chat app.
Users authenticate with Microsoft Entra ID via MSAL.
The backend runs in AWS Lambda.
The model is Amazon Bedrock using Nova 2 Lite.
Microsoft Purview evaluates prompts and model responses for DLP policy violations.

This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure.

The core architecture

Fig. 2 Architectural overview of the solution

As shown above the end-to-end flow follows this pattern:

A user signs in through Microsoft Entra ID from the frontend.
The frontend sends the user's access token and prompt to an API endpoint in AWS.
The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity.
Purview scans the full prompt for sensitive information before the model is called.
If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock.
Purview scans the model response before it is returned to the user.
The frontend shows the result along with a Purview evaluation badge.

That gives you two strong governance controls:

In-line data loss prevention enforcement, which can block risky requests before they ever reach the model.
Response-time enforcement, which can stop sensitive data from being returned even if a model generates it.

The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running.

Why this pattern is useful for security, governance, and compliance teams

There are three reasons this pattern is worth paying attention to.

First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point.
Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows.
Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough.

Policy definition in Purview

Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy

Collection policy

2. DLP policy

Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples

To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples

Once deployed, you will have:

An AWS Lambda function that calls Amazon Bedrock.
A browser frontend that authenticates with Microsoft Entra ID.
Microsoft Purview evaluating both prompts and responses.
A demo flow where safe prompts succeed and sensitive prompts are blocked.

With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview.

Minimal code integration requirements using the SDK

Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model.

Results of Purview’s verdict presented to user in the App UI

Review governance evidence in Purview Data Security Posture Management

Summary

The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds.

That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented.

Additional resources

Configure Microsoft Purview - purview-sdk | Microsoft Learn

Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft Learn

Lakebase connector

joaosilveira07 — Tue, 02 Jun 2026 11:38:59 GMT

I'm requesting a native Purview connector for Databricks Lakebase. Although Lakebase reached general availability in January, no dedicated connector currently exists. As a workaround, we're scanning Lakebase Postgres tables as generic PostgreSQL sources, but this approach only supports username/password authentication and prevents us from using service principals—a requirement for our security posture.

I believe that Lakebase volume will grow and it would be a great add on.

Performance in scanning

sagedogusa — Thu, 28 May 2026 14:41:22 GMT

We are trying to search for CUI data on internal file stores. Last week, I decided to run another discovery scan, this time using ALL instead of Policy Only. It took much longer and left the scanner server in an almost unusable state and didn’t give really any more information than the first one did.

Based on my research, we need to define and set the policy before we run scans. This is the information tip from the Purview scanner settings:

Scan started at: 2026-05-20 22:54:06Z

Scan ended at: 2026-05-24 16:16:51Z

Scan duration: 3 days, 17 hours, 22 minutes, 45 seconds

Scan id: 93acb922-e2ac-4fb7-b259-d6184e7aa434

Repository: \\cab-filesrv-01.fg.com\Departments. Enforce mode is Off

Scanned files:3509640

Actions:

Classified:3369456

Classified as Public:14

Classified as Fg Private:3369442

Labeled:0

Remove label:0

Protected:0

Remove protection:0

Files with matched information types:572895

Skipped due to - No match:0

Skipped due to - Not supported:0

Skipped due to - Already labeled:0

Skipped due to - Already scanned:0

Skipped due to - Require justification:0

Skipped due to - Unknown reason:0

Skipped due to - Excluded:98833

Skipped due to - Attribute:0

Failed:41318

I just want to secure AI. DLP vs Info Protection vs DSPM vs Governance vs...

underQualifried — Wed, 20 May 2026 18:56:24 GMT

I'm with an MSP, and I've avoided Purview like the plague, because it seems to be suffering from the same 'made by marketing teams' 'strategy' the 365 documentation is. However, it's my understanding Purview policies are needed for Data control of Copilot.

Here's my issue: all of these different 'solutions' sound like the exact same thing, but are pitched as if they are something different. i'm going to post a couple of descriptions for these 'solutions' to illustrate this.

'discover, label, and protect sensitive and business-critical info'
'make sure your organization can identify, monitor, and protect sensitive info across the expanding Microsoft 365 landscape'
'discover and secure all your sensitive data across Microsoft 365 and non-365 data sources'
'Discover, label, and protect sensitive and business-critical info across your multicloud data estate.'

I genuinely do not have time to figure out what each of these 'solutions' are, then figure out their policies, then their giant library of settings (below)... It's not even clear to me what's active NOW, considering we never licensed Purview - but somehow have been roped into it. It SEEMS like these are all variations of marketing terms, which all point to 3-4 actual technical implementations in obscure ways.

Can someone advise on the ACTUAL technical policies we want to target and enable? Or just give some clarity? I've never felt so overwhelmed or disconnected from Microsoft's environment. We just want to secure our tenant's AI usage.

Data System Wide Lineage via API Request

southpawmurph — Fri, 15 May 2026 13:52:54 GMT

I'm struggling with finding a solution. My goal is to identify all existing lineage relationships for any data objects within a specific data system they belong to. I've been using the Purview REST API (Datamap Dataplane) but I haven't found an endpoint returning data system side lineage/relationships.

For my scenario I have a Databricks metastore and need to know the existing lineage relationships of those data objects within Purview so I can purge them out when we are doing our scheduled lineage refresh.

Separating IRM Full Control from Excel Worksheet Protection

jmartos — Tue, 12 May 2026 17:14:37 GMT

We've developed several excel workbooks that leverage VBA macros with workbook structure and worksheet password protections to maintain standards. The VBA macros unlock workbook/sheet protections to perform tasks and relock on completion. Our executive management has tasked us to protect the workbooks to prevent unauthorized access so we have applied a sensitivity label to restrict access to an AD group (Project Managers). However, short of granting Full Control, the IRM prevents the macros from removing sheet/book protections. We have tried to allow permissions for OBJMODEL and DOCEDIT already at Copilot's recommendation but this was unsuccessful. We don't want to grant full control because users are then able to remove the document label.

Any suggestions for how to grant workbook/sheet protection permission without allowing users to remove labels? At this time the best we've come up with is to grant the full access but require an explanation for a label downgrade with an alert to the admin/document owner.

Endpoint DLP Device Onboarding - WorkspaceOne

Sabita1 — Wed, 06 May 2026 07:16:52 GMT

Hi everyone,

We have a customer who is using WorkspaceOne for managing the Endpoints. It is an Hybrid environment. We need some guidance and documentation(if any), to help onboard devices for Purview eDLP. The ruled-out option is Group Policy as some employees are working from home and some working from office. There are around 25k+ devices in the tenant that needs to be onboarded. The customer is not using Intune or SCCM.

We are looking for best method/approach to onboard devices where the org is using WorkspaceOne.

Purview not getting enough attention from Microsoft - Will be Decom

riverazure — Tue, 05 May 2026 18:35:57 GMT

At this stage is clear for everybody that Microsoft is not putting the same effort in Purview as they are putting in other products like Fabric, D365 , etc..

Seems to me that in one or two years purview will probably be decommisioned

Rational :

- The support is very week (teams taking care of the support tickets are very week from a knowhow perspective and take ages to resolve something )

- Functionalities take a lot of time to be released

- Its not properly integrated with Fabric, for example there is almost no lineage and the classification is not set via data map

- DLP for Fabric only works with some SITs, does not work for example with Trainable Classifiers, etc..

- The Roadmap takes care of something, but minimal

- The Way to Log Error records for data quality rules is very week and not user friendly

I wonder what is the idea of Microsoft for the next 3 or 4 years when it comes to Purview

Will it continue to have Governance ? will it only be taking care of security or compliance?

Get-AdaptiveScopeMembers doesn't show the SiteURL for OneDrive

Raechel Moermond — Tue, 05 May 2026 14:08:26 GMT

I am working through reporting for Adaptive Scopes and Adaptive Retention policies. I'm so close. But I discovered a problem with my script in that when people return to the company after their account has been deleted, they get a new OneDrive URL. This is expected. While they can have the same email address as an inactive mailbox, they cannot have the same OneDrive URL as an inactive URL. Since we keep all data for a minimum of 7 years, it is possible for a UPN to be the "owner" of 2 or more OneDrive URLs (one active and the others are from previous accounts). I have no easy way of seeing which OneDrive URL is active short of looking for digits at the end of the URL and taking the highest digit. But, what I want to know, is why isn't it here?

Why doesn't "Get-AdaptiveScopeMember" return the SiteURL for the user? I thought maybe it was because my test user didn't have a OneDrive site when the account was added to the scope, so I added my actual user account to the scope and it shows the same thing. Is SiteURL only for SharePoint sites and not OneDrive sites? This makes no sense. Does it just take more time to show up? what's the time frame on that?

Microsoft Purview to detect passwords

miro2022 — Thu, 30 Apr 2026 22:26:52 GMT

Hi All

What would you recommend for scanning and setting up scheduled scans in Microsoft Purview to detect passwords or sensitive credentials stored in SharePoint sites and OneDrive?

We would like to discover whether anyone has shared or stored passwords in SharePoint or OneDrive, as we have already had an incident because of this.

Are there any recommended Purview solutions, policies, or detection rules we should use for this? Ideally, we would like to schedule regular scans and receive alerts or reports when potential passwords, credentials, or secrets are detected.

Any advice or recommended approach would be appreciated. thanks

thanks

Miro

Welcome, Purview Lightning Talks audience!

RenWoods — Thu, 30 Apr 2026 12:41:14 GMT

Please log in and then post any of your Data Security (and AI) spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles:

Session Title	Speaker	Tech Community Alias (tag)
The Purview Label Engine: Automated Classification, Translation, and Co-Documentation for Enterprise Tenants	Michael Kirst Neshva	MichaelKirst1970
Stop, Think, Protect: Data Security in Real Life with Purview	Oliver Sahlmann	Oliver Sahlmann
Using Purview to Prevent Oversharing with AI Services	Viktor Hedberg	headburgh
How I Helped My Customers Understand Their AI Usage (and Protect Their Sensitive Data)	Bram de Jager	Bram de Jager
Four Labels Max for Daily Use: Which Ones & Why?	Romain Dalle	RomainDalle_MVP_MCT
Data‑driven Endpoint DLP Solution with Advanced Hunting	Tatu Seppälä	tseppala
The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast	Nikki Chapple	nikkichapple
Why You Should Create Your Own Sensitive Information Types (SITs)	Niels Jakobsen	Niels_Jakobsen
From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter	Sathish Veerapandian	Sathish Veerapandian
Securing Data in the Age of AI	Júlio César Gonçalves Vasconcelos	jcvasconcelos
Beyond eDiscovery – Purview DSI for Security Investigation	Susantha Silva	susanthasilva
Elevating Purview DLP with a Real‑World Use Case	Victor Wingsing	vicwingsing

Purview Lightning Talks takes place April 30th at 8am pacific: Webinar Details

Full agenda here.

Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!

Welcome, Purview Lighting Talks audience!

RenWoods — Wed, 29 Apr 2026 22:04:11 GMT

Please log in and then post any of your Risk and Compliance spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles:

The Day Offboarding Exposed Infinite Retention - Nikki Chapple nikkichapple

Length: 10 minutes | Topic: Data Lifecycle Management

A routine Purview request led to an unexpected discovery: more than 9,000 orphaned OneDrives and thousands of inactive mailboxes still storing content long after employees had left. This talk explains how a retain-only policy created hidden retention debt and how Adaptive Scopes can help organisations separate active users from leavers to avoid similar pitfalls.

What's In My Compliance Manager Toolbox: A Cloud Security Architect's Perspective - Jerrad Dahlager j-dahl7

Length: 8 minutes | Topic: Compliance Manager

A practical walkthrough of how I use Compliance Manager across real client engagements to map controls, track improvement actions, and simplify multi-framework compliance. No theory, just what works in the field.

Does M365 Support eDiscovery? - Julian Kusenberg - Leprechaun91

Length: 11 minutes | Topic: eDiscovery

A myth-busting session that separates perception from reality when it comes to Microsoft 365 eDiscovery capabilities.

Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!

Purview Lightning Talks takes place April 30th at 8am pacific: Webinar Details

Welcome, Purview Lighting Talks audience!

RenWoods — Wed, 29 Apr 2026 21:54:01 GMT

Please log in and then post any of your Data Governance spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles:

Improving Discovery, Trust, and Reuse of Analytics with Purview Data Products - CraigWyndowe

Length: 5 minutes | Topic: Governance

This talk shows how bringing Power BI and Fabric assets into Microsoft Purview Governance Domains and Data Products creates a single, trusted view of enterprise analytics. By connecting reports, semantic models, and underlying data with shared metadata, ownership, and business context, organizations can make existing assets easy to discover and safe to reuse.

Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!

Activity explorer scoping to AU

AlaaAy — Wed, 29 Apr 2026 15:39:32 GMT

I remember that Activity Explorer can be fully scoped to Admin Units, and that the Restricted admin can see activity explorer and DLP matching events for the scoped AU only, is that correct?
Cause I was checking and I found the Restricted admin can see the activities also for the users out of the scoped AU. Does that make sense?