Purview leaves SaaS data exposed across the midmarket stack

At a glance

What this is: HYCU says Purview is useful inside Microsoft 365, but it does not cover the broader SaaS footprint where much of a midmarket organisation's sensitive data now lives.

Why it matters: IAM, PAM, and data security teams need to treat SaaS data access and offboarding as a governance problem, not just a Microsoft 365 control problem.

By the numbers:

• A typical 500-to-3,000-person company runs somewhere between 50 and 200 SaaS applications.

Context

Midmarket data security now extends far beyond Microsoft 365, because sensitive information is distributed across SaaS applications that business teams adopt faster than security teams can inventory or govern them. Traditional DLP and classification tools can still be useful inside a single productivity suite, but they do not provide a complete access or data-lifecycle view across the wider application estate.

That gap matters because SaaS collaboration defaults often trade control for convenience. When data protection does not follow the application lifecycle, offboarding, sharing, and export risks become identity and governance problems as much as data problems. For most midmarket organisations, the issue is not the absence of a policy. It is the absence of coverage across the actual data-bearing systems.

Key questions

Q: What breaks when Microsoft 365 data controls do not extend across SaaS apps?

A: The control boundary breaks at the application edge. Sensitive data can remain visible, shared, and exported in non-Microsoft tools even while Microsoft 365 appears governed. That creates a false sense of coverage, because the real risk sits in the apps where business teams collaborate, retain, and move data every day.

Q: Why do broad SaaS collaboration defaults increase data exposure risk?

A: They turn convenience into persistence. When link sharing, guest access, and default visibility are generous, access survives longer than the business process that created it. In practice, that means data can remain reachable after role changes, offboarding, or project closure unless the entitlement lifecycle is actively managed.

Q: How can teams tell whether SaaS governance is actually working?

A: Look for evidence that discovered applications can be assigned an owner, tied to an access policy, and removed through an enforced workflow. If the platform can only report on SaaS usage but cannot drive deprovisioning or entitlement review, governance is still fragmented.

Q: Should organisations prioritise Microsoft 365 data controls or cross-SaaS visibility first?

A: Cross-SaaS visibility should come first when sensitive data is already distributed across multiple business applications. Microsoft 365 controls still matter, but they do not reduce exposure in systems they cannot see. The right sequence is inventory, ownership, and entitlement control across the broader SaaS estate, then deeper content policy inside M365.

Technical breakdown

Why Microsoft 365 coverage stops at the SaaS boundary

Microsoft Purview is built to classify, label, and govern data inside Microsoft 365 workloads such as SharePoint, OneDrive, Exchange, and Teams. Its control plane ends where the Microsoft tenant ends, which means it cannot natively inspect entitlements, sharing paths, or data movement in independent SaaS platforms such as Salesforce, Box, Jira, or Slack. That creates a governance split: one environment has visibility and policy enforcement, while the rest of the collaboration stack remains outside the same control model.

Practical implication: Treat Microsoft 365 controls as one domain in a wider SaaS governance architecture, not as complete data security coverage.

Why enterprise DSPM often misses the midmarket use case

DSPM is designed to discover, classify, and govern sensitive data across multiple clouds and applications, but the operating model assumes budget, integration depth, and analyst capacity that many midmarket organisations do not have. Every connector needs credentials, scopes, and review. Every finding creates triage work. In a lean team, the tooling overhead can exceed the control value before coverage is even complete.

Practical implication: Assess whether DSPM can be deployed and sustained with your actual team size before you commit to it as a programme dependency.

How SaaS entitlements turn data exposure into an identity problem

The article's examples show that data loss is often enabled by standing access, weak offboarding, or broad collaboration settings rather than by a single malicious exploit. If a contractor still has Salesforce access after leaving, or a folder is shared by link for months, the failure is lifecycle control, not just data classification. In practice, SaaS data governance depends on identity lifecycle, access review, and entitlement visibility across every app that stores sensitive content.

Practical implication: Map high-risk SaaS repositories to ownership, offboarding, and entitlement review processes before you rely on DLP alerts alone.

NHI Mgmt Group analysis

Data governance has become a SaaS estate problem, not a Microsoft 365 problem. The article is right to draw a hard line between Purview coverage and the rest of the collaboration stack. Once sensitive data sits in Salesforce, Box, Jira, Slack, or similar tools, the control model shifts from tenant-scoped DLP to cross-application governance. For identity and security teams, the practical conclusion is that data visibility now depends on the application inventory as much as on the data policy.

SaaS data sprawl is also identity sprawl: the decisive failure mode is not simply misplaced content, but unmanaged access paths to that content. Offboarding, shared links, contractor accounts, and departmental apps all create persistence windows that standard Microsoft-centric governance will miss. IAM and PAM teams should read this as a lifecycle warning: if the access layer is fragmented, the data layer will be fragmented too.

Midmarket security debt now includes tooling that assumes enterprise staffing. The article exposes a structural mismatch between what DSPM vendors often expect and what lean teams can actually operate. That is a governance issue, not a product feature issue. A control stack that cannot be deployed, triaged, and maintained at midmarket scale becomes aspirational rather than operational, which leaves the organisation relying on hope and manual cleanup.

Coverage gaps create a false sense of compliance. A completed questionnaire or a Microsoft 365 deployment does not prove that sensitive data is governed across the SaaS estate. That matters for audit readiness, incident response, and third-party risk because the real exposure often sits in tools nobody has modelled. Security leaders should treat cross-SaaS visibility as a baseline control requirement, not an advanced maturity project.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Read next: Collaboration Tool Security Guide

What this signals

Midmarket data security is drifting from suite-level control to estate-level governance. The practical problem is no longer whether Microsoft 365 is covered. It is whether the organisation can see, own, and revoke access in the SaaS tools where sensitive data is actually created and shared. Security teams should expect offboarding and link-sharing controls to become the first measurable weak points.

SaaS collaboration tools are now part of the identity surface: when access is spread across departmental applications, the data problem becomes an entitlement problem. That means access governance, not just classification, has to be built into how teams manage finance, HR, sales, and support repositories.

The gap is widening because each new departmental app adds another place where sensitive data can outgrow the original control model, and the article's 50 to 200 SaaS applications range is a reminder that scale alone makes manual oversight unrealistic.

For practitioners

• Map the non-Microsoft SaaS estate Inventory the applications where sensitive data actually resides, including collaboration tools, departmental platforms, and acquired-team systems. Prioritise the repositories that hold customer, financial, HR, source code, and compliance evidence data.
• Tie offboarding to every SaaS application Extend deprovisioning beyond the identity provider so contractor, employee, and partner access is removed from each app that stores sensitive data. Track residual access paths such as shared folders, guest accounts, and delegated permissions.
• Review collaboration defaults for data-sharing risk Audit link-sharing, guest access, external collaboration, and export settings in the highest-risk SaaS apps. Replace open-ended defaults with explicit ownership and approval for sensitive repositories.
• Validate DSPM deployment assumptions before purchase Test whether a DSPM programme can be integrated with your SaaS estate using available staffing, budget, and operational tolerance. Reject models that require a dedicated analyst team if your programme does not have one.
• Align data controls with IAM and PAM ownership Assign ownership for SaaS data repositories to the teams that manage access, not just the teams that label data. Use identity governance reviews to catch standing access that data tooling alone will miss.

Key takeaways

• Purview can control Microsoft 365 content, but it does not create visibility across the broader SaaS estate where midmarket sensitive data now lives.
• The main exposure pattern is not exotic exploitation. It is ordinary collaboration, incomplete offboarding, and data-sharing defaults that persist beyond the original business need.
• Security teams need ownership, entitlement review, and application inventory across non-Microsoft SaaS before they rely on DLP or DSPM as proof of governance.

Key terms

• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.
• SaaS Entitlement Drift: SaaS entitlement drift is the gradual mismatch between assigned access, actual usage, and current business need across a software estate. It appears when provisioning, renewal, and offboarding are managed separately, leaving stale permissions in place long after they stop serving a valid purpose.
• Application boundary: An application boundary is the identity and policy separation created by distinct client IDs, redirect URIs, session lifetimes, and credentials for each app. It matters because shared users can still have different trust contexts, and governance fails when one application’s controls bleed into another.
• Offboarding Coverage: Offboarding coverage is the completeness of account and entitlement removal across every system a departing user could still access. Strong offboarding covers direct accounts, shared folders, guest access, and delegated permissions, because any remaining path can preserve data access after employment or contract end.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect access governance to the wider programme risks that shape resilience.