The unified portal, one door
Purview consolidated the old Compliance and (retired) Security & Compliance centres into a single portal. Solutions (DLP, Information Protection, Data Lifecycle Management, eDiscovery, Insider Risk, Communication Compliance, DSPM) each surface only if your role groups and licence permit — so two admins can see very different portals in the same tenant.
Role groups, not roles
Access is assigned through role groups — named bundles of granular roles — rather than individual permissions. The built-ins matter more than any custom scheme at first:
| Role group | Grants | Keep away from |
|---|---|---|
| Compliance Administrator | Broad config across most solutions | Anyone who only needs to read |
| Compliance Data Administrator | Config plus device/data management | Investigators |
| eDiscovery Manager / Administrator | Cases, holds, exports — Administrator can see all cases | Line reviewers (use Manager, case-scoped) |
| Insider Risk Management roles | Split into Analysts vs Investigators vs Admins — deliberately separated | Combining analyst + investigator in one person defeats the privacy model |
| Reviewer | Read-only into review sets | Anyone needing to change policy |
The design principle is separation of duties: the person who builds a DLP policy should not be the person who investigates its alerts, and the eDiscovery holder should not be able to quietly delete what they hold. Purview's role split exists to enforce that — collapsing everyone into Compliance Administrator throws it away.
The app-only PowerShell reality (the failure mode)
Security & Compliance PowerShell connects via Connect-IPPSSession. Certificate-
based app-only authentication is supported for many cmdlets — but not all.
Several sensitive solutions (notably parts of eDiscovery, records management and
insider risk) are gated so they require an interactive, licensed user in the
right role group; a service principal running app-only will get access-denied or
simply won't see those cmdlets. Any automation or scanner built on Purview must
state which surfaces it can reach app-only and which it cannot — overclaiming
coverage here is the classic mistake, and it is exactly the honest boundary
serv365 draws.
What to watch (proofs)
- Who holds what:
Get-RoleGroupandGet-RoleGroupMemberfor the compliance role groups — the separation-of-duties audit; a fat Compliance Administrator list is the finding. - Portal-vs-licence: the solutions visible in the portal vs the role groups assigned — invisible solutions are either unlicensed or unassigned.
- App-only reachability: run the scanner's service principal against
Connect-IPPSSessionand confirm which cmdlets return data vs access-denied — the true coverage line, documented, not assumed. - Role changes over time: audit-log role-group membership changes
(
Search-UnifiedAuditLogforAdd-RoleGroupMember) — privilege creep, caught.