SharePoint Permissions Audit: Nested Groups

Nested-group permissions are the number one audit blind spot in enterprise SharePoint. An auditor asks who can access a site; the site owner points at a group; the group contains three other groups; and one of those contains an "Everyone Except External Users" claim that nobody remembers adding. That's how a supposed twelve-person team ends up with 43,000 effective members. This playbook is the four-step audit we run for financial services, healthcare, and manufacturing clients — with the actual PowerShell and Microsoft Graph code, a decision tree for remediation, and the compliance mapping to SOX ITGC, HIPAA minimum necessary, and ISO 27001 Annex A.9.

What "nested" actually means in SharePoint

There are three distinct nesting patterns, and they produce different audit failures.

Pattern 1: Active Directory groups nested inside SharePoint groups

A SharePoint group ("Marketing Owners") contains an on-premises AD security group ("CORP-Marketing-Team"), which contains other AD groups ("CORP-Regional-Marketing-NA", "CORP-Regional-Marketing-EMEA"), which contain individual user accounts and service accounts. SharePoint's UI only shows the top-level group; the effective member list requires walking the AD graph.

Pattern 2: Microsoft 365 Groups nested through team ownership

A Microsoft 365 Group owns a Team, which has a private channel, which has a SharePoint site with its own separate M365 Group. Adding a user to the parent Team does not add them to the private channel site, but adding them to the private channel site can inadvertently grant broader access if inheritance was broken elsewhere.

Pattern 3: Broad claims inside targeted groups

The most dangerous pattern. A SharePoint group named "Finance Executives" (implied: 12 people) actually contains the "Everyone Except External Users" (EEEU) claim, granting access to every internal user in the tenant. This happens when someone temporarily needs to share a link "with the whole company" and forgets to remove the claim.

The four-step audit

Step 1: Baseline export via PnP PowerShell

Export the full permissions state for every site in scope. This is the "known-good" you'll compare against during quarterly audits.

```powershell

# Install PnP.PowerShell if you don't have it

# Install-Module -Name PnP.PowerShell -Scope CurrentUser

# Register your Entra app once with Sites.FullControl.All

$tenant = "contoso.onmicrosoft.com"

$clientId = "your-app-registration-guid"

$thumbprint = "your-cert-thumbprint"

$sites = Get-PnPTenantSite -Detailed | Where-Object {

$_.Template -notlike "*REDIRECT*" -and $_.Url -notlike "*-my.sharepoint.com*"

}

$auditResults = @()

foreach ($site in $sites) {

Connect-PnPOnline -Url $site.Url -ClientId $clientId -Thumbprint $thumbprint -Tenant $tenant

$web = Get-PnPWeb -Includes RoleAssignments, HasUniqueRoleAssignments

$groups = Get-PnPGroup

foreach ($group in $groups) {

$members = Get-PnPGroupMember -Identity $group.Id

foreach ($member in $members) {

$auditResults += [PSCustomObject]@{

SiteUrl = $site.Url

GroupName = $group.Title

MemberLoginName = $member.LoginName

MemberTitle = $member.Title

PrincipalType = $member.PrincipalType

IsEEEU = ($member.LoginName -like "*spo-grid-all-users*")

HasBrokenInheritance = $web.HasUniqueRoleAssignments

}

}

}

}

$auditResults | Export-Csv -Path "sp-permissions-baseline-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

```

This baseline typically produces 50,000 to 500,000 rows for a mid-enterprise tenant. Store it in a permissioned location — this is sensitive data.

Step 2: Break-inheritance detection

Sites with broken inheritance are where audit findings hide. Identify every site, library, and list with unique permissions.

```powershell

$brokenInheritanceReport = @()

foreach ($site in $sites) {

Connect-PnPOnline -Url $site.Url -ClientId $clientId -Thumbprint $thumbprint -Tenant $tenant

# Web-level

$web = Get-PnPWeb -Includes HasUniqueRoleAssignments

if ($web.HasUniqueRoleAssignments) {

$brokenInheritanceReport += [PSCustomObject]@{

SiteUrl = $site.Url

Scope = "Web"

ObjectUrl = $site.Url

BreakLevel = 0

}

}

# List and library level

$lists = Get-PnPList -Includes HasUniqueRoleAssignments, HasUniqueRoleAssignments

foreach ($list in $lists) {

if ($list.HasUniqueRoleAssignments) {

$brokenInheritanceReport += [PSCustomObject]@{

SiteUrl = $site.Url

Scope = "List"

ObjectUrl = "$($site.Url)/$($list.DefaultViewUrl)"

BreakLevel = 1

}

}

}

# Item-level (only for lists flagged as high-risk in your inventory)

# Item-level unique permissions on more than a few hundred items is itself an audit finding

}

$brokenInheritanceReport | Export-Csv "sp-broken-inheritance-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

```

In a healthy tenant, fewer than 15 percent of sites should have web-level broken inheritance. If your number is 40+ percent, the tenant has structural permissions debt and needs remediation before an audit.

Step 3: Orphaned user detection via Microsoft Graph

Orphaned users are accounts that no longer exist in Entra ID but still appear in SharePoint permissions. They're audit findings under access review controls (SOX ITGC.06, ISO A.9.2.5).

```powershell

# Requires Microsoft.Graph module and User.Read.All permission

Connect-MgGraph -Scopes "User.Read.All", "Sites.Read.All"

$allSpPrincipals = $auditResults | Select-Object -ExpandProperty MemberLoginName -Unique |

Where-Object { $_ -like "i:0#.f|membership|*" }

$spUpns = $allSpPrincipals | ForEach-Object {

($_ -split '\|')[-1]

}

$orphans = @()

foreach ($upn in $spUpns) {

try {

$null = Get-MgUser -UserId $upn -ErrorAction Stop

} catch {

$orphans += $upn

}

}

$orphans | Out-File "sp-orphaned-users-$(Get-Date -Format 'yyyyMMdd').txt"

Write-Host "Found $($orphans.Count) orphaned users"

```

For a 10,000-user tenant, expect 200 to 800 orphans in a first audit. Remediate by removing them from all sites and groups where they appear.

Step 4: Everyone / EEEU sweep

This is the highest-severity finding class. Any site, library, or list granting the "Everyone" or "Everyone Except External Users" claim outside of the intranet home is a candidate for immediate review.

```powershell

$eeeuFindings = $auditResults | Where-Object {

$_.MemberLoginName -like "*spo-grid-all-users*" -or

$_.MemberLoginName -like "c:0(.s|true"

}

$eeeuFindings | Group-Object SiteUrl | Sort-Object Count -Descending |

Select-Object Count, Name |

Export-Csv "sp-eeeu-exposure-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

```

For each finding: verify whether the site is intentionally broad (company-wide comms, published policies) or whether the claim was added ad hoc and needs removal.

Decision tree: restore inheritance vs document exception

Every broken-inheritance finding needs a decision. Our team uses this tree.

Q1: Is the unique permission a subset of the parent's permission?

If yes, restoring inheritance is safe — nobody loses access. Restore.

Q2: Is the unique permission a superset (adds users the parent doesn't have)?

If yes, ask Q3.

Q3: Are the added users a defined business function with an owner who can attest quarterly?

• Yes → document the exception in your permissions register, note the owner, note the review cadence, and leave the break in place.
• No → break needs remediation. Options: (a) add the users to the parent group, then restore inheritance, or (b) migrate the content to a site whose parent permissions match business intent.

Q4: Is the unique permission a disjoint set (different users than parent, unrelated business function)?

Almost always the content belongs in a different site. Migrate it, then remove the local permission.

Compliance mapping

The audit outputs map to specific compliance controls.

SOX ITGC (financial services, public companies)

• ITGC.02 — Logical access: the baseline export demonstrates who has access to which financial data
• ITGC.05 — Segregation of duties: the nested-group walk exposes where preparers and approvers share permissions
• ITGC.06 — Access reviews: the quarterly re-run of this playbook satisfies the periodic access review requirement

HIPAA Security Rule (healthcare)

• 164.308(a)(4) — Information access management: minimum necessary attestation requires the nested-group walk, not just the site-level view
• 164.308(a)(3)(ii)(B) — Workforce clearance: orphan detection satisfies the termination-of-access requirement
• 164.312(a)(1) — Access control: the EEEU sweep demonstrates access is not blanket

ISO 27001:2022 Annex A.9

• A.9.2.3 — Management of privileged access rights: the site collection admin inventory (a variant of the baseline query)
• A.9.2.5 — Review of user access rights: the quarterly cadence
• A.9.4.1 — Information access restriction: the EEEU sweep and unique-permission analysis

Microsoft's official SharePoint permissions documentation covers the model; the audit is what proves the model is correctly enforced.

Cadence recommendations

• Continuous: enable audit log ingestion into Microsoft Sentinel or Purview; alert on new EEEU grants and new site-collection-admin assignments
• Monthly: re-run orphan detection and remediate
• Quarterly: full playbook re-run and delta against baseline
• Annually: owner attestation across all site collections with unique permissions

Common pitfalls

• Running the audit without a Sites.FullControl.All app: delegated access misses site collections the auditor's account can't see. Use certificate-authenticated app-only access.
• Ignoring hidden system groups: limited-access users, ViewOnly groups, and "SharingLinks" groups all count as principals with access.
• Skipping OneDrive: SharePoint audits often exclude *-my.sharepoint.com, but shared OneDrive links can grant tenant-wide access equivalent to a SharePoint EEEU finding.
• Not versioning the baseline: without a signed, timestamped baseline stored securely, an auditor cannot verify that quarterly reviews actually happened.
• Auditing without a remediation budget: finding 4,000 orphaned users and not fixing them is worse than not auditing, because the finding is now documented.

Our SharePoint consulting service runs this playbook as a standard engagement for regulated clients. If you need help operationalizing the quarterly cadence, our SharePoint support team provides the ongoing attestation and remediation workflow. For deeper PnP command reference, see the Microsoft PnP PowerShell documentation.

Frequently asked audit questions

Expert help from our SharePoint consultants

If your team needs to stand up a repeatable permissions audit before your next SOX, HIPAA, or ISO audit cycle, our SharePoint consulting team can implement the four-step playbook against your tenant with certificate-based app-only access, deliver the compliance-mapped report, and hand your team the operational runbook. Start with our contact page.