SharePoint Permission Audit Checklist for CMMC Level 2

One broken permission can expose an entire CUI library. When I review Microsoft 365 tenants for defense contractors, permissions are often where quiet risk hides.

If you manage a CUI site, a practical SharePoint permission audit checklist helps you find overexposed content, prove your review process, and tighten access before an assessment. The point isn’t perfect screenshots. It’s a repeatable way to limit access, log changes, and fix drift.

Why CUI permissions need a closer audit in 2026

As of April 2026, CMMC Level 2 can’t wait. Phase 1 started in November 2025, and Phase 2 begins in November 2026 for new DoD contracts with CUI. Teams need evidence that SharePoint Online controls support NIST SP 800-171 practices every day.

Microsoft 365 can support those practices, but it doesn’t grant compliance by itself. I use Microsoft Entra guidance for CMMC Level 2 access control as a baseline, then map SharePoint settings, group design, audit logs, and procedures to the SSP. I also keep a broader CMMC Level 2 readiness checklist for gaps and POA&M items.

For CUI sites, I want three facts on record: access is limited to authorized users, permission changes are logged, and approvals plus review cycles are documented.

Step-by-Step SharePoint Permission Audit Checklist

I start with scope. If the site holds CUI, I treat every library, folder, group, and sharing setting as evidence.

1. Identify every CUI site and library. I record the site URL, owner, data type, label, and whether the site uses a dedicated site collection.
2. Review site-level sharing first. For CUI, I look for external sharing set to disabled or tightly restricted, and I confirm anonymous links are unavailable.
3. Export current permissions. I capture Site Owners, Members, Visitors, direct user grants, Entra ID group assignments, and any SharePoint groups still in use.
4. Check for broken inheritance. Unique permissions at the library, folder, or item level need a business reason, named owner, and review date.
5. Validate least privilege. Most users should have read-only or narrowly scoped access. Full Control should stay rare, and edit rights should match a job need.
6. Inspect link-based access. “Anyone” links should be absent on CUI sites. I also review default link types and active sharing links.
7. Test auditability. In Microsoft Purview, I search for permission changes, sharing events, file access, and downloads. I keep date-stamped results to show the control is operating.

I also compare permission membership to HR and ticket records. If a departed user, shared mailbox, or service account still has access, I flag it.

Common misconfigurations I flag on CUI sites

The biggest issue usually isn’t dramatic. It’s slow sprawl. A site starts clean, then months of one-off access requests pile up until nobody trusts the model.

I often find direct permissions granted to individuals instead of role-based Entra groups. That makes approvals harder to prove. I also see oversized Owners groups, legacy SharePoint groups with no sponsor, and libraries with item-level exceptions that outlive the project that created them. For ongoing monitoring ideas, this Microsoft 365 permissions audit overview lines up with what I see in the field.

If a CUI library has unique permissions that nobody owns, I don’t call it customization. I call it exposure.

Other red flags include guest accounts left enabled, inactive sites still holding CUI, default sharing links set too open, and permissions inherited from a parent site never meant for regulated content. Sensitivity labels help, but they don’t replace a clean permission model. MFA, Conditional Access, and audit logging matter too, yet they can’t fix a sloppy site structure later.

How I document findings, retain evidence, and close gaps

A good audit file should let another admin, or an assessor, follow my logic without guessing. I keep the evidence simple.

Here are the records I retain for each reviewed CUI site:

Evidence	What I keep	Why it matters
Site inventory	URL, owner, purpose, label, review date	Defines audit scope
Permission export	Site, library, folder, and direct grants	Shows current state
Screenshots	Sharing settings, link defaults, group pages	Supports configuration proof
Audit results	Purview searches for sharing and access events	Shows the control operating
Remediation log	Finding, risk, owner, due date, closure proof	Supports POA&M and follow-up

After the table, I write a short remediation summary. I note which permissions I removed, which groups I replaced with Entra roles, which libraries I re-inherited, and which site owners must re-approve access. Then I attach ticket numbers, change records, and before-and-after exports.

For smaller contractors, this audit ties into Small Business IT, Cloud Infrastructure, Office 365 Migration, Cloud Management, and Cybersecurity Services. I also connect it to Endpoint Security, Device Hardening, Secure Cloud Architecture, and Business Continuity & Security.

That same discipline supports Managed IT for Small Business and a practical IT Strategy for SMBs. A Business Technology Partner may blend Technology Consulting, Infrastructure Optimization, Data Center Technology, and Digital Transformation with Tailored Technology Services and Innovative IT Solutions. Even mixed operations, such as Restaurant POS Support and Kitchen Technology Solutions, benefit from the same access rules.

A SharePoint permission audit checklist won’t certify you. Still, it gives you something better than guesswork, a repeatable way to reduce exposure and support your CMMC story.

If I were tightening a CUI site this week, I’d start with inheritance breaks, link types, direct user grants, and audit evidence. Those four checks catch most of the trouble before an assessor does.