Where Purview Ends, Defender for Cloud Apps Begins
- E.C. Scherer
- 11 minutes ago
- 5 min read
Many Microsoft Purview deployments focus on three core capabilities:
Sensitivity labels
Data Loss Prevention (DLP)
Insider Risk Management
Those controls are important. They define what data matters and how it should be protected.
But there’s a gap that shows up in almost every environment I work in.
Organizations focus heavily on protecting data inside Microsoft 365 but have very little visibility into what happens when users start interacting with everything else.
Google Drive
Dropbox
Personal email
File transfer sites
AI tools
Random SaaS platforms someone found to solve a problem
Work no longer happens entirely inside Microsoft 365. Data moves across dozens of services constantly.
And when I walk into environments where Purview is “fully deployed,” my first thought is usually:
Cool, but you're completely blind to anything that isn't M365.
That’s where Microsoft Defender for Cloud Apps (MDCA) starts to matter.
The Questions We’re Actually Trying to Answer
Most conversations about MDCA start with features. That’s not usually the real problem.
The real questions are simpler:
What cloud apps are we actually using?
Which of those apps create risk for sensitive data?
What guardrails are we putting in place?
Because if the answer is “we don't know,” then it doesn’t really matter how strong your internal controls are.
Users will just move the work somewhere else.
Step 1: Discover Shadow IT
Most organizations underestimate how many cloud applications employees are interacting with.
Marketing tools
Developer utilities
File sharing sites
AI platforms
Personal storage services
People solve problems with whatever tools are easiest to access.
MDCA can surface this activity through Shadow IT discovery, typically using firewall or proxy logs.
This visibility helps security teams understand:
which applications employees are using
how frequently those apps are accessed
how much data is being uploaded or downloaded
The first time organizations see this data it’s usually eye-opening.
It’s not unusual to find hundreds or thousands of cloud apps in use across an environment.
That’s not a failure of employees. It’s just the reality of modern work.
Step 2: Understand Which Apps Actually Create Risk
Once you know what apps exist in the environment, the next step is figuring out which ones actually matter from a security perspective.
MDCA helps with this through Microsoft’s cloud app catalog, which evaluates thousands of services based on factors such as:
security certifications
data protection practices
compliance posture
breach history
This helps security teams prioritize risk instead of trying to block everything.
Because the goal isn’t to eliminate cloud apps.
The goal is understanding which ones interact with sensitive data in ways that create exposure.
Step 3: Apply Guardrails When Sensitive Data Is Involved
This is where MDCA connects directly to Microsoft Purview.
Purview helps organizations identify sensitive data through labeling and classification.
MDCA helps monitor and control how that data interacts with cloud services.
That can include things like:
monitoring sensitive files uploaded to cloud apps
blocking uploads of classified data to risky services
restricting downloads of sensitive data to unmanaged devices
applying session controls when users interact with third-party SaaS platforms
The goal isn’t to stop people from working.
It’s to intervene when sensitive data moves somewhere it shouldn’t.
What Actually Happens in Real Environments
One pattern shows up over and over again.
Organizations build strong controls inside Microsoft 365.
Labels are configured. DLP policies are deployed. Sharing restrictions are enforced.
And then users hit friction.
A file won't send externally. A sharing policy blocks a workflow. A collaboration scenario gets complicated.
So someone solves the problem the fastest way possible.
They move the work somewhere else.
A personal cloud drive.
A file transfer site.
An AI tool.
Some SaaS platform security has never evaluated.
I've seen environments where controls inside Microsoft 365 were working exactly as designed. But sensitive data was still moving everywhere. Not because users were malicious.
Just because the path of least resistance was somewhere else.
Note from the field
If a control makes work harder, the work usually moves somewhere else.
Where Data Usually Leaves First
In most environments, two places show up quickly once visibility improves.
Personal cloud storage
Users upload documents so they can share with vendors or collaborators without running into internal restrictions.
AI tools
Employees paste data into AI tools to summarize documents or speed up work.
In both cases the intent usually isn’t malicious.
It’s just someone trying to get their job done.
The problem is that without cloud visibility, security teams never see it happening.
Security Blanket Nature Break
Step away from the dashboards for a moment.
Mandatory nature break: the fox I caught stalking my chicken coop.
If you only watch the door, you miss what’s happening outside the fence.
Notes from the field: if you’re not looking outside the boundary, you’re missing what’s actually happening.
Where MDCA Fits
Microsoft Purview answers an important question:
What data matters?
Sensitivity labels identify sensitive information.
DLP policies define how that data should move inside Microsoft 365.
MDCA answers a different question:
Where is that data going once it leaves those boundaries?
It provides visibility into the cloud apps users interact with and helps organizations respond when sensitive data enters those environments.
Or put another way:
You're locking the door, but you're leaving the windows wide open.
MDCA helps you see the windows.
When MDCA Becomes a Compensating Control
Security architectures often assume every control can be deployed exactly as designed.
In reality, environments are messy.
Maybe Endpoint DLP isn’t fully deployed yet.
Maybe users rely on SaaS platforms where Purview controls don’t apply.
Maybe collaboration requirements push work into tools outside Microsoft 365.
This is where MDCA often becomes a compensating control.
Instead of blocking everything immediately, it provides visibility into how data interacts with cloud services.
That visibility allows security teams to understand risk and respond appropriately while other controls mature.
A Common Misunderstanding
One thing I see fairly often is organizations treating MDCA purely as a visibility tool.
They deploy it to discover shadow IT and generate reports but stop there.
Visibility is useful.
But it’s only part of the value.
MDCA also allows organizations to apply guardrails when sensitive data interacts with cloud services.
Session controls. Access restrictions. Activity monitoring tied to data sensitivity.
Used well, it’s not just showing you the problem. It helps you manage it.
The Simple Architecture View
When you step back, the relationship between these tools is pretty straightforward.
Purview labels identify what data matters.
DLP policies control how that data moves inside Microsoft 365.
MDCA gives you visibility and guardrails when that data interacts with cloud services outside those boundaries.
Or more simply:
Labels tell you what matters.
DLP controls how it moves.
MDCA shows you where it goes when it leaves the room.
Final Thought
Purview is very good at protecting data inside Microsoft 365.
But modern organizations don’t operate entirely inside Microsoft 365.
If you can’t see how sensitive data interacts with the broader cloud ecosystem, you’re only seeing part of the picture.
MDCA helps close that gap.
Not by blocking everything.
But by helping organizations understand where their data actually goes.