There is a relatively small Microsoft Purview change coming that could have a bigger operational impact than its roadmap description suggests.
Microsoft Purview Endpoint Data Loss Prevention is gaining the ability to scope Just-in-Time Audit by user or group.
The change is associated with Microsoft 365 Roadmap ID 562991 and Message Center announcement MC1387575.
Microsoft currently says rollout will begin in December 2026, with completion expected by the end of December. The timeline was previously scheduled for early July.
At first glance, this might sound like just another configuration option.
I think it’s more interesting than that.
It moves JIT Audit towards a more deliberate and risk-based model.
👉 First, what is changing?
Microsoft says that administrators will be able to determine which users or groups have their activities audited when Just-in-Time protection is enabled in Endpoint DLP.
Previously, when Just-in-Time protection was enabled, user activities could be logged automatically for users who weren’t targeted by DLP policies.
The new approach means audit logging can be explicitly configured so that only users or groups included in the audit scope have their activities logged. Microsoft says this gives organisations greater control over audit signal collection and helps reduce unnecessary audit noise.
And that last part is important.
Audit more doesn’t necessarily mean monitor better.
👉 More data isn’t always better data
This is something we regularly encounter in security and compliance.
We turn on a capability.
It starts generating signals.
The security team gets more events.
The dashboards get busier.
And eventually someone asks:
“Which of this actually matters?”
That’s where JIT Audit becomes interesting.
If you have thousands of users, do you necessarily want the same level of audit activity generated for everyone?
Probably not.
There may be groups where increased visibility makes sense.
For example:
- users working with particularly sensitive information
- privileged or highly privileged users
- administrators
- users in higher-risk business functions
- users participating in a DLP pilot
- specific groups being investigated
- users subject to particular organisational controls
The right answer will obviously depend on your organisation and risk model.
But the important thing is that you can start making that decision deliberately.
👉 JIT Audit shouldn’t be confused with DLP policy scope
This is where I think administrators need to be careful.
There are two different questions:
1. Who is my DLP policy protecting?
That’s about policy scope.
Who is covered by your Endpoint DLP controls?
2. Who do I want additional audit visibility for?
That’s about audit scope.
Those aren’t necessarily the same thing.
And that’s a useful distinction.
You might have a broad Endpoint DLP policy covering a large population while wanting more targeted JIT Audit visibility for a smaller group.
That allows you to separate:
Protection
from
additional visibility and investigation.
👉 Why reduce audit noise?
Because audit data isn’t free from an operational perspective.
Someone has to:
- collect it
- understand it
- investigate it
- correlate it
- retain it
- build processes around it
- potentially integrate it into wider security operations
Microsoft Purview Audit provides extensive capabilities for searching and investigating user and administrator activity, including filtering by users and activities.
But there’s a difference between:
“We can collect this.”
and:
“We need to collect this.”
Good governance is often about making that distinction.
👉 Think risk-based, not everything-based
One of the biggest lessons I’ve taken from working with security and compliance technologies is this:
Don’t automatically apply the maximum level of monitoring everywhere.
Instead, think about:
Risk → People → Data → Activity → Control
Who is high risk?
What data are they working with?
What activities matter?
What level of visibility do we actually need?
And what are we going to do with the information once we’ve collected it?
That’s a much more mature conversation than:
“Let’s turn on all the auditing.”
👉 This could be particularly useful for pilots
There’s another scenario I like here.
Imagine you’re introducing Endpoint DLP and want to understand what JIT Audit looks like before rolling it out more widely.
Rather than immediately generating audit activity across a huge population, you could potentially use a controlled group to understand:
- what activity is being generated
- how much signal you’re getting
- whether the data is useful
- whether your investigation processes work
- whether your SOC understands the events
- whether your policies need adjusting
Then expand.
That’s a much more sensible adoption pattern.
Pilot → Validate → Tune → Expand
Rather than:
Enable → Generate everything → Figure it out later
👉 What should administrators be thinking about?
If you’re using Endpoint DLP and JIT protection, I’d be asking a few questions.
Who should be in scope?
Don’t automatically assume everyone.
Document the reason for your chosen users and groups.
Why are they in scope?
Is it risk?
Sensitivity?
Role?
Privilege?
A pilot?
An investigation?
Have a reason.
What will you do with the audit data?
This is an important one.
If nobody is going to review or act on the information, why are you collecting it?
How does this align with your DLP policies?
Make sure your audit scope and protection scope make sense together.
They don’t necessarily need to be identical.
How will you review it?
Think about Purview, SOC workflows, investigation processes and any downstream integrations.
What happens when the group changes?
If you’re using Entra ID groups, consider the lifecycle of those groups.
People join.
People leave.
Roles change.
Your risk profile changes.
Your controls should be able to keep up.
👉 There’s a bigger governance lesson here
I think this change represents something we’re seeing across Microsoft Purview more broadly.
Controls are becoming more granular.
We’re moving away from:
“Turn the feature on.”
Towards:
“Define exactly where, why, for whom and under what conditions the feature should operate.”
That’s a much better place to be.
Because governance isn’t about collecting everything.
It’s about collecting the right information, for the right reason, with the right level of control.
And that applies just as much to audit as it does to DLP, retention, sensitivity labels and AI governance.
💡 The Jim Talks takeaway
Roadmap ID 562991 might look like a small Endpoint DLP configuration change.
But I think the underlying direction is worth paying attention to.
Microsoft is giving organisations more control over who generates JIT Audit activity.
That means we can start thinking about JIT Audit less as:
“Audit everything.”
and more as:
“Give me the visibility I actually need to manage my risk.”
That’s a much more mature approach to compliance and security.
And as our Microsoft 365 environments become more complex, reducing noise while increasing useful visibility is going to become increasingly important.
More audit isn’t necessarily better governance.
Better-targeted audit might be.
Microsoft references
- Microsoft Message Center MC1387575 / Roadmap ID 562991 – Scope Just-in-Time Audit by user or group.
- Microsoft Purview Audit – Search and investigate audited activity.
Leave a Reply