Microsoft Purview Data Security Posture Management

I’ve been spending a lot of time with Microsoft Purview’s Data Security Posture Management lately — DSPM for short — and I reckon it’s going to matter a great deal for most organisations over the next year or two. Especially if you’re caught up in any kind of AI adoption conversation, which, let’s face it, that’s basically everyone right now.

Data security has always had this annoying “where do I even start” problem. You know there’s sensitive data floating around. You know it’s probably sitting in places it shouldn’t be. But actually quantifying that risk and doing something useful about it? That’s traditionally meant a lot of manual effort, pricey third-party tools, or both. I’ve lost count of how many times I’ve walked into an organisation that knows they have a problem but can’t put numbers against it.

DSPM is Microsoft’s attempt to fix that, and honestly, it works well. Here’s what it actually does.

DSPM vs DLP — What’s the Difference?

First question everyone asks, and fair enough. Data Loss Prevention and Data Security Posture Management sound like they should be the same thing. They’re not, though they do complement each other.

DLP is reactive — it’s about enforcement. It watches for sensitive data being shared, moved, or accessed in ways it shouldn’t be, then blocks or warns based on policies you’ve set up. The catch is that DLP needs you to already know what you’re protecting and where to apply those policies.

DSPM takes the opposite approach. It’s proactive and discovery-focused. It continuously scans your data estate to find where sensitive data lives, looks at the security posture around that data, and flags risks before they turn into incidents. Put simply: DSPM tells you what to worry about. DLP is what you do about it.

The way I think about it — DSPM is the reconnaissance that should be feeding your DLP strategy. Without it, you’re writing DLP policies based on guesswork. With it, you’re writing them based on actual evidence.

What DSPM Actually Shows You

When you open DSPM in the Purview portal, you get a dashboard that pulls together:

• Sensitive data overview — how much sensitive data exists across your Microsoft 365 environment, broken down by type (financial, personal, health, credentials, and so on)
• Data at risk — sensitive data that’s been overshared, is externally accessible, or is sitting in locations without proper protections
• Unprotected sensitive data — files containing sensitive information that haven’t got sensitivity labels applied
• User activity insights — who’s interacting with the most sensitive data and what they’re doing with it

Where it really earns its keep is the risk insights. DSPM doesn’t just say “you have 50,000 files with credit card numbers.” It says “you have 50,000 files with credit card numbers, 12,000 of them are in SharePoint sites accessible to the entire organisation, and 3,000 have been shared externally.”

That’s the kind of thing you can take to your CISO. That’s actionable.

Multicloud Data Discovery

It doesn’t stop at Microsoft 365 either. DSPM extends into multicloud environments, scanning data stores in Azure (Storage Accounts, SQL databases, Data Lake) and AWS (S3 buckets, RDS instances). So you get a single view of sensitive data risk across your whole cloud estate.

Setting up the multicloud bit does take some work — you’ll need the right connectors configured and Purview needs scanning permissions on the target resources. The Purview data map documentation covers the details.

One thing worth mentioning: the depth of scanning isn’t uniform across data sources. Microsoft 365 content gets the richest analysis, which makes sense. Azure and AWS sources are well covered but some of the contextual risk insights aren’t quite as detailed. It’s getting better with each release though.

The Copilot Readiness Connection

This is where DSPM gets really interesting. If your organisation is deploying or planning to deploy Microsoft 365 Copilot, you need to understand your data security posture before you switch it on.

Here’s why. Copilot inherits the permissions of the user who’s running it. If someone has access to a SharePoint site full of sensitive financial data — even if they’ve never once visited that site — Copilot can pull that data into a response. That’s not a bug. Copilot is working exactly as designed. The problem is that most organisations have years of permission sprawl that nobody’s ever tidied up.

DSPM includes Copilot readiness assessments that flag:

• Overshared sensitive content that Copilot could surface to the wrong people
• Sites with sensitive data and overly broad access permissions
• Specific actions to reduce risk before you flip the switch on Copilot

I’ve seen this be the thing that finally gets organisations to sort out their data governance. Nothing gets people moving quite like showing them: “if you turn on Copilot tomorrow, here’s the sensitive data that 5,000 users will suddenly be able to find through natural language queries.” Concentrates the mind, that one.

Practical Risk Insights

The recommendations you get out of DSPM are specific. Not just vague “you should label your data” advice but actual findings:

• This SharePoint site has 2,300 files matching the financial data classifier, is accessible to all employees, and has no DLP policy — here’s one you could apply
• These 45 users have been accessing the most sensitive data over the last 30 days without justification controls in place
• These Azure Storage Accounts contain PII and have public access enabled

Each recommendation links through to the relevant tool or policy configuration. You can create DLP policies, slap on sensitivity labels, or tighten sharing settings right from the DSPM recommendations. No bouncing between five different admin portals.

Getting Started

You’ll need Microsoft Purview licensing for DSPM — either the dedicated Purview Data Security Posture Management add-on, or it’s bundled with Microsoft 365 E5 Compliance. Worth checking what you’ve actually got licensed before you assume you have access.

Once that’s sorted, the setup is fairly straightforward:

1. Enable DSPM in the Purview compliance portal
2. Check your data classification — make sure your sensitive information types and trainable classifiers actually match what your organisation cares about
3. Let the initial scan run — DSPM will start analysing your Microsoft 365 data automatically
4. Set up multicloud connectors if you need visibility beyond M365
5. Actually act on the recommendations — this is the part that matters, and it’s the part people skip

I’ll be honest — don’t let the initial findings scare you. Every organisation’s first DSPM scan looks alarming. Every single one. That’s kind of the point. Start with the highest risk stuff: externally shared sensitive data first, then broadly accessible internal data, then work your way down from there.

Why This Matters Now

Here’s the bottom line: organisations are being pushed to adopt AI tools quickly, but most haven’t done the foundational data security work that makes AI adoption safe. DSPM fills that gap by showing you your actual data security posture — not the one you think you have.

It won’t solve everything on its own — you still need to fix the findings, get proper labelling in place, clean up oversharing, and keep on top of it. But it takes what feels like an impossible problem and turns it into a manageable, prioritised programme of work. And that’s worth a lot.

The Microsoft Purview DSPM documentation is a good place to start. I’d also recommend the Copilot readiness assessment if that’s anywhere on your roadmap.

Happy to chat about any of this. Data security posture is only going to matter more as AI adoption picks up speed, and I’d much rather organisations got ahead of it than found out the hard way.