Purview Ends at M365. Your Data Doesn't.

Walk into almost any midmarket company and you'll find the same security setup: Microsoft 365 with some level of Purview coverage, maybe Defender, and a checkbox next to "data protection" on the last audit questionnaire. 

Then look at the actual SaaS footprint. 

Confluence. Salesforce. Box. GitHub. Jira. Slack. Workday. Notion. Zendesk. DocuSign. Asana. A handful of departmental tools nobody in IT remembers approving. 

That's where sensitive data actually lives now. And, for most midmarket security teams, it's a black hole. 

What Purview actually covers 

Purview is a reasonable tool for what it is: a data governance and DLP layer for Microsoft 365. If you have the right license tier — usually E5 or the standalone compliance add-on — you can classify data in SharePoint, OneDrive, Exchange, and Teams. You can write DLP policies. You can see some sensitivity labels propagate. 

Purview doesn't cover your Salesforce pipeline. It can't tell you who has standing access to the Box folder where finance drops quarterly projections. It doesn't see the HR tool, the recruiting tool, the support tool, or the dozen other places sensitive data lives. 

If your data only lived in Microsoft, this would be fine. Your data doesn't only live in Microsoft 365. 

The real midmarket stack 

A typical 500-to-3,000-person company runs somewhere between 50 and 200 SaaS applications. A meaningful fraction of those hold sensitive data: customer PII, financials, source code, HR records, health information, contracts, credentials. 

Most of that data is: 

• Shared broadly by default (SaaS apps optimize for collaboration, not least privilege) 
• Accessible to far more people than anyone realizes 
• Invisible to the security tools the company already owns 
• Growing in volume and sensitivity every quarter 

Nobody planned this. It happened because business teams bought tools faster than security could inventory them, and because the governance story for non-Microsoft SaaS has always been somebody else's problem. 

Why existing DSPM doesn't solve it 

The obvious answer is DSPM. These platforms exist specifically to discover, classify, and govern data across SaaS, IaaS, and unstructured stores. 

Here's the problem: none of them were built for the midmarket. 

They were built for Fortune 500 buyers with six-figure budgets, dedicated data security teams, and enough runway to run lengthy deployments. Ask a 400-person company to stand up an enterprise DSPM vendor and you'll typically get three reactions in order: the quote, the silence, and the polite no. 

The specific barriers: 

• Cost. Most DSPM platforms start in the mid-six figures annually. For midmarket security budgets, that's the entire tooling line item. 
• Deployment complexity. Every SaaS app needs an integration, every integration needs credentials and scopes, and every scope needs a security review. A lean team cannot spend a quarter wiring up connectors. 
• Operational overhead. DSPM generates findings. Findings require triage. Triage requires analysts. Midmarket teams don't have analysts — they have one security person who also runs IAM, patches servers, and owns the phishing training program. 
• Enterprise bias baked into the product. The UI assumes you have a data security analyst reading it. The policies assume you have a team to tune them. The alerts assume someone has time to investigate. 

The result: midmarket companies either pay for enterprise tooling they can't operationalize, or they go without and hope. 

The risk isn't theoretical 

I've seen this pattern repeatedly: 

• A contractor keeps access to Salesforce 90 days after offboarding because nobody owns the deprovisioning checklist for non-IdP apps. 
• An engineer exports a customer list from HubSpot to a personal Google Drive "just to work offline." 
• A departing sales rep downloads three years of account data from Gong before their last day. 
• A misconfigured Box folder containing SOC 2 evidence is shared with "anyone with the link" for 14 months. 

None of these would surface in Purview. None would surface in a SIEM without custom work nobody has time to do. And most wouldn't surface in existing DSPM either, because the customer couldn't afford to deploy it against that SaaS app in the first place. 

These aren't hypothetical attacks. They're the actual incidents midmarket companies quietly deal with — the ones that show up in a post-mortem instead of a dashboard. 

Why it stays unsolved 

The gap persists because the economics don't work under the traditional DSPM model. Building a scanner for every SaaS app, maintaining connectors, handling API rate limits, classifying data at scale, it's expensive engineering, and vendors price accordingly. Midmarket buyers get priced out, and vendors move upmarket to chase larger deals. The cycle continues. 

Meanwhile the SaaS footprint keeps growing. Every new department tool, every acquisition, every "we just need this for the team" purchase adds another pocket of sensitive data nobody is watching. The gap isn't closing. It's widening. 

Midmarket security teams know this. They're not naive. They're stuck between tooling priced for someone else and a problem that keeps getting worse. Most have made peace with it the way you make peace with any risk you can't afford to fix, document it, hope, move on. 

That's the honest state of data security posture management outside Microsoft 365 for most of the midmarket. Not solved. Not close. And not something Purview is going to fix.