Microsoft Purview RBAC Decision Audit Logs Coming to GCC, GCC High and DoD

Admins have asked for this for a long time. Purview already logs when someone changes a role group. Microsoft now says it will also log the authorization decisions the portal makes about roles and scoped roles, so administrators can troubleshoot access problems and watch authorization outcomes.

What the roadmap item says, and what the worldwide version shows​

The government-cloud entry only gives a short description, with no technical detail. The commercial version is a separate roadmap entry, ID 569363, and it has much more. Its roadmap record uses the same wording: "Improving permission checks when users access the Microsoft Purview portal." It lists a GA date of September CY2026.

The matching Message Center post, MC1473155, explains how it works. According to that notice:

• Microsoft is enhancing audit logging for permission checks performed in the Microsoft Purview portal to make Purview role-based access control (RBAC) more transparent and easier to troubleshoot.
• New audit records will be generated when access checks are performed in the Microsoft Purview portal.
• Two new audit operations will be available: CheckUsersInRoles and CheckUserInRolesWithScopes. Administrators will be able to review these audit records as part of SecurityComplianceRBAC audit activities.
• The enhancement is enabled by default and requires no configuration.
• Audit records will only be generated for access checks that occur after the feature is deployed.

Merill Fernando's M365 Admin tracker (handsontek) republished the notice with the worldwide schedule. The rollout is beginning in late September 2026 and expected to complete by late October 2026. The notice also confirms that no historical or retroactive audit records will be created for prior access checks.

One caveat: those operation names, the default-on behaviour and the dates all come from the commercial notice for 569363. The GCC/GCC High/DoD record (573447) doesn't list event names, record types or enablement steps. It's reasonable to expect the government version to work the same way. Until Microsoft publishes a government-cloud Message Center post, treat that as likely, not confirmed. "October 2026" is also a target month, not a promise that all three sovereign environments get it on the same day.

Section summary: Commercial tenants are getting two new RBAC check operations, on by default and starting late September. The government-cloud roadmap item points at the same feature for October, but Microsoft hasn't published the sovereign-cloud specifics yet.

Why this matters: permission changes vs. permission decisions​

Purview already audits changes to permissions. Microsoft Learn's audit log activities reference has a table of "Microsoft Purview permission activities." It covers events logged when an administrator manages RBAC role groups and user assignments, such as creating, updating or deleting role group definitions, granting or removing assignments, and changing assignment expiration dates.

That tells you who changed the permissions. It doesn't tell you what Purview decided when a user tried to open something.

Here's a typical case. An analyst says they can't open a DLP page, or that they can see data they shouldn't. The admin checks the role group membership and it looks fine. Before this change, nothing in the log showed how the portal actually evaluated that user. CheckUsersInRoles and CheckUserInRolesWithScopes are meant to fill that gap. The second one, by its name, covers checks where administrative-unit scope is involved. Microsoft says the records will show role and scoped-role authorization decisions, helping them investigate access issues and better understand how access evaluations are performed.

Neither the roadmap nor the Message Center text lists the fields inside these records. We don't yet know whether they include the role evaluated, the admin unit or the reason for the result. Don't build reporting around a schema you haven't seen yet.

The Entra precedence issue these logs could help explain​

One documented Purview behaviour regularly catches admins out. Microsoft Learn's "Permissions in the Microsoft Purview portal" page says that if a user has both a Microsoft Entra role and a scoped Purview role group assignment, the Entra role wins at runtime. Their effective permissions are then unscoped, even though a scoped assignment exists.

Microsoft gives two examples:

• A user with the Entra Compliance Administrator role and a scoped Purview Compliance Administrator assignment gets unscoped access.
• A user with Entra Global Reader and a scoped DLP Compliance Management role gets unscoped access to the overlapping features and APIs.

So you can scope someone carefully to one administrative unit and still find they can see the whole tenant. Decision-level logs could make that visible instead of leaving you to work it out. This isn't confirmed, though: Microsoft hasn't said whether the new records will show that an Entra role overrode a scoped assignment. The precedence rule itself is long-standing behaviour, not something this roadmap item changes.

Who can actually see these records?​

There are two layers of access control to keep in mind.

1. Audit search permissions. Microsoft Learn says you need the Audit Logs or View-Only Audit Logs role in the Purview portal to search the audit log. Those roles come with the built-in Audit Manager and Audit Reader role groups, or you can add them to a custom role group.

2. Admin-unit scoping of audit search. Audit search is scoped too. Microsoft's "Search the audit log" page says an admin with no administrative units assigned is unrestricted and can see logs from users, non-users and system accounts. A restricted admin can only search and export user-generated logs for users in their assigned units, and some listed activities only appear for unrestricted admins.

In practice, a scoped admin who can't find a CheckUserInRolesWithScopes record for someone outside their units shouldn't conclude that the check never happened. Run the search again from an unrestricted account before deciding.

How to look for the new events once they arrive​

These steps use existing, documented audit search methods. Nothing new needs to be enabled.

1. Confirm unified audit ingestion is on. In Exchange Online PowerShell, run Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled. True means search is on. Microsoft warns that the same cmdlet in Security & Compliance PowerShell always returns False, so make sure you're in Exchange Online PowerShell.
2. Open Audit in the Purview portal and start a new search.
3. Use the "Activities - operations names" field and enter CheckUsersInRoles,CheckUserInRolesWithScopes. Microsoft notes that operation names must match exactly or the search returns nothing, so copy and paste them.
4. Narrow by user and date range, especially if you're looking into one person's complaint. Remember the logs only start from deployment.
5. Export to CSV if you need deeper analysis. The detailed properties are in the AuditData column, which you can split in Excel with Power Query.
6. For automation, Microsoft documents Search-UnifiedAuditLog in Exchange Online PowerShell and the Office 365 Management Activity API for programmatic access. Neither the roadmap item nor the notice says whether every channel gets the new records on day one, so test before you rely on it.

Be patient with fresh events. Microsoft doesn't guarantee how long an audit record takes to become searchable. Even for core services it's typically 60 to 90 minutes, and it can be longer for others.

Success looks like this: a search on the two operation names returns records dated after rollout reached your tenant. If you get nothing, check four things: rollout hasn't reached you yet, your account is admin-unit scoped, the operation name has a typo, or the event is newer than the ingestion delay.

The likely downsides​

Decision logging could be noisy. A portal that checks permissions on every page load can produce a lot of records. The Message Center commentary says there's no impact on organizations. Still, SOC teams sending the unified audit log to a SIEM should watch ingestion volume and costs after rollout. That's a general industry concern, not a figure Microsoft has published.

The handsontek republication of MC1473155 recommends that admins review internal monitoring and audit procedures to determine whether the new audit activities should be included in access investigations, and update any documentation or reporting that depends on Purview RBAC audit data. That's sensible advice. Any parser that expects a fixed set of SecurityComplianceRBAC operations may need updating.

Bottom line​

Purview admins have been able to see who changed permissions but not why access was granted or denied. With roadmap 573447, Microsoft plans to bring decision-level permission auditing to GCC, GCC High and DoD in October 2026. The commercial version (569363 / MC1473155) is already rolling out with two default-on operations, CheckUsersInRoles and CheckUserInRolesWithScopes.

Until then:

• Check both Entra role assignments and Purview role group scopes when access looks wrong.
• Make sure your investigators have Audit Logs or View-Only Audit Logs and know whether their search is admin-unit scoped.
• Watch for a government-cloud Message Center post that confirms the event names and dates for your environment.