Entra ID Privileged Group Review SOP for CMMC Level 2

Stale admin access is one of the fastest ways to fail a CMMC credibility check. If I can’t show who has privileged access in Microsoft Entra ID, why they still need it, and when I last reviewed it, I have a control gap.

I use the SOP below when I need an Entra ID privileged review that is repeatable, audit-ready, and realistic for lean IT teams. It works for automated reviews in Entra ID Governance and for manual reviews when licensing or staffing is limited.

Define the scope before the review starts

My SOP starts with one rule: I define privileged access before I review it. In current Microsoft wording, that means Microsoft Entra ID, formerly Azure AD. I note the legacy term once for cross-reference, then I use Entra ID throughout the rest of the document.

I classify a role or group as privileged if it can change tenant security, identity settings, access paths, device policy, or admin boundaries. That includes built-in Entra roles such as Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator, and User Administrator. It also includes privileged groups, especially groups assigned to roles, groups used for admin portals, groups exempted from policy, and privileged access groups managed through PIM.

This review supports least privilege and privileged account control expected in CMMC Level 2. Microsoft’s CMMC Level 2 access control guidance and its identity access control recommendations line up well with this approach.

I use the same SOP across Small Business IT, Cloud Infrastructure, and Office 365 Migration work. It also fits Data Center Technology projects, Restaurant POS Support, and Kitchen Technology Solutions, because Entra ID often controls the admin plane above the business apps.

At minimum, my SOP names the review owner, the reviewer, the approver, the evidence repository, and the review cadence. If the cadence changes by role type, I write that down. A vague “we review admins regularly” statement won’t help when an assessor asks for proof.

Identify every privileged role, group, and member

A clean review starts with a complete population. If I miss an eligible role, a nested group, or a service principal, the review looks complete but isn’t.

I gather the scope in this order:

1. Export Entra role assignments. I capture both active and eligible assignments. Eligible access in PIM still counts as privileged because the user can activate it.
2. Export privileged group membership. I include direct members, nested members if used, owners, and any group assigned to a role.
3. Identify non-human identities. Service principals, automation accounts, and break-glass accounts need review too, even if a human reviewer can’t sign in as them.
4. Flag external identities. Guest users with admin or admin-adjacent access need stronger scrutiny because contract scope changes fast.
5. Record source and date. I save the export date, tenant name, and tool used so the evidence trail is clear.

If I have Microsoft Entra Privileged Identity Management, I use PIM access reviews for Entra roles. If I don’t, I perform a manual review with exported membership and signed approval records. The control objective stays the same.

I also define what does not count as privileged in this SOP. A user who has standard rights and no security-impacting role is out of scope. A workstation local admin can matter for endpoint risk, but it isn’t an Entra role review unless that access is tied back to Entra-managed privileged groups.

Run the review with audit-ready checks

Once the scope is fixed, the reviewer needs clear decision criteria. I don’t ask for a casual thumbs-up. I require a documented keep, remove, or modify decision for each entry.

My review steps are simple:

1. Validate identity status. Confirm the person still works for the company, still supports the client, or still operates under an active vendor agreement.
2. Confirm business need. Tie the role or group to a job function, system responsibility, or approved ticket.
3. Check least privilege. If a lower role would work, I downgrade the access instead of approving the higher one.
4. Verify account hygiene. Privileged users should use a separate admin account when the environment requires it, and privileged sign-in should follow MFA policy.
5. Review time bounds. Standing access needs a strong reason. Temporary access should have an expiration date.
6. Approve or remove. I record the decision, the reviewer name, and the date. If I remove access, I capture proof that the change happened.

For reviewers, I keep the standard short and direct. They are not judging whether a user is trustworthy. They are confirming whether the access is still needed, correctly scoped, and formally approved.

This matters most for roles tied to Cybersecurity Services, Cloud Management, Endpoint Security, and Device Hardening. A bad change in Conditional Access, Intune, authentication methods, or audit settings can weaken Secure Cloud Architecture in minutes. For recurring reviews, I rely on Microsoft Entra access reviews when possible, then I archive the review output with the supporting approvals.

Assessors don’t want a promise that reviews happen. They want dated evidence that they did.

I treat break-glass accounts as a special case. I don’t remove them during a routine review unless policy changed, but I do verify owner, purpose, credential control, MFA design, monitoring, and emergency-use logging.

Record approvals, removals, and evidence for CMMC Level 2

A privileged review is only as strong as its records. Screenshots alone are weak evidence because they are hard to search, easy to misread, and poor at proving timing.

I retain a small evidence set for every cycle. That keeps the file manageable and still gives an assessor what they need.

Evidence item	What I retain	Why it matters
Scope record	Export of roles and groups in scope, dated	Proves the review covered the full population
Decision record	Access review output or signed review worksheet	Shows keep, remove, or modify decisions
Approval support	Ticket, manager approval, or system owner approval	Ties access to business need
Change proof	Entra audit log entry for membership or role removal	Confirms the action happened
Exception log	Break-glass or service account exception with owner and date	Shows controlled handling of special cases
SOP reference	SOP version and review cadence	Connects the review to policy

For practical examples tied to least privilege and admin activity, I also like the operational advice in this AC.L2-3.1.7 walkthrough.

I store the package in a controlled repository with version history. The retention period should match company policy, contract needs, and the assessment window. For a Business Technology Partner or Technology Consulting team, this matters beyond compliance. Good evidence supports Infrastructure Optimization, Digital Transformation, and IT Strategy for SMBs without weakening controls. It also fits Managed IT for Small Business and Business Continuity & Security programs.

Sample privileged review checklist and SOP template

When I package this work inside Innovative IT Solutions or Tailored Technology Services, I keep the review packet plain and consistent. Fancy formatting doesn’t help. Clear records do.

I use this short checklist during each review cycle:

1. The scope matches the approved SOP.
2. All active and eligible privileged roles are included.
3. All privileged groups and owners are included.
4. Each member’s employment or vendor status is valid.
5. Each access grant has a current business reason.
6. Exceptions have an owner and an expiration or review date.
7. Removals are completed and verified in audit logs.
8. Evidence is saved in the approved repository.

I also keep a short SOP template that teams can adapt:

SOP section	Minimum language to include
Purpose	Review Entra privileged access to confirm least privilege and record decisions
Scope	All active and eligible Entra roles, privileged groups, guests, service principals, and break-glass accounts
Frequency	State the review cadence and any trigger-based reviews after major changes
Roles	Name reviewer, approver, access owner, executor, and evidence custodian
Procedure	Export access, review each entry, record decision, remove or modify access, save evidence
Records	State where evidence is stored and how long it is retained

If I were handing this to a team tomorrow, I’d add one more sentence to the SOP: “No privileged access remains approved without current business need and recorded reviewer sign-off.” That line keeps the whole process honest.

Conclusion

Stale privilege is usually a process failure, not a tool failure. A strong Entra ID review works because the scope is defined, every privileged entry is checked, and every decision leaves evidence behind.

When I can show who had access, why it was approved, who reviewed it, and when it was removed, the control stands up well under CMMC Level 2 scrutiny. That is the standard worth holding.