13.1 Plan & Create Access Reviews
Key Takeaways
- Access reviews are Microsoft Entra ID Governance attestations that re-certify who still needs group membership, app assignment, access package assignment, or privileged Entra roles so least privilege does not decay into permanent over-grant.
- Plan reviews by business risk: what is reviewed, who decides (managers, selected users, self, group owners, multi-stage), how often the campaign recurs, and what happens when reviewers stay silent.
- Create reviews with a clear scope (entire group, guests only, inactive users, selected people), duration window, recurrence, optional multi-stage stages, and recommendation/auto-apply settings.
- Guest-focused and inactive-user reviews are high-value SC-300 patterns for B2B cleanup; PIM-linked reviews cover directory roles that packages and static groups should not hold permanently.
- Recommendations (for example unused access) help reviewers, and auto-apply can remove access based on those insights—but only when you deliberately accept automation risk for that scope.
Why access reviews sit in Domain 4
Domain 4 of SC-300—Plan and automate identity governance (about 20–25%)—is not only joiner packages and privileged activation. After access is granted, organizations still accumulate stale group members, forgotten app assignments, long-lived guests, and directory roles that outlived the project. Access reviews are the Entra ID Governance capability that forces a decision: keep, remove, or (in some flows) mark uncertainty for follow-up—on a schedule you control.
What an access review is (and is not)
An access review is a configured campaign that:
- Selects a population (members of a group, users assigned to an app, package assignees, role holders).
- Assigns reviewers for a duration window.
- Collects decisions: typically Approve, Deny, or Don't know (wording may appear as “I don’t know” / unknown in portal copy).
- Optionally applies results so denied users lose the reviewed access.
- Optionally recurs (monthly, quarterly, and so on) so attestation is continuous, not a one-off audit scramble.
| Access reviews do | Access reviews do not |
|---|---|
| Attest existing membership/assignment/role access | Replace Conditional Access at sign-in |
| Drive remove/keep decisions at scale | Invent new least-privilege app roles by themselves |
| Support guest and inactive insights | Replace PIM activation for standing Global Admin need |
| Produce audit evidence of who decided | Automatically fix direct assignments outside the review scope |
Licensing (exam-level): Access reviews are an Microsoft Entra ID Governance capability (commonly discussed with Entra ID P2 / Identity Governance). SC-300 stems that require recurring group/app/package/role reviews assume governance licensing—not “Entra Free + manual spreadsheet.”
Plan first: who reviews what
Exam and real designs fail when admins click New access review without a model. Plan:
- Inventory high-risk access — finance groups, privileged-adjacent security groups, LOB apps with sensitive data, partner packages, standing Entra roles.
- Choose the review type per inventory item (table below).
- Pick reviewers who know the business truth — a random Global Admin rubber-stamping 5,000 members is a false control.
- Set cadence from risk — privileged and guest-heavy scopes more often; low-risk all-company read groups less often.
- Define silent-reviewer behavior — no change vs remove vs take recommendations when nobody answers.
- Decide auto-apply vs manual apply — automation speed versus human gate before revocation.
- Communicate — managers and group owners must know the email prompts are real governance work, not phishing theater.
What can be reviewed (SC-300 map)
| Scope | What is attested | Typical reviewer pattern |
|---|---|---|
| Group membership | Security or Microsoft 365 group members (and often guests in those groups) | Group owners, managers, selected users, self |
| Application assignment | Users/groups assigned to an enterprise application | App owners, selected users, managers |
| Access package assignments | Who still holds a package (often after entitlement management grant) | Package-related owners/sponsors, managers, multi-stage |
| Microsoft Entra roles (via PIM reviews) | Eligible or active/permanent role assignments under Privileged Identity Management | Role-capable admins, selected reviewers, multi-stage for high privilege |
| Azure resource roles (PIM for Azure, conceptual) | Resource RBAC where PIM for Azure is used | Resource owners / subscription governance |
SC-300 cue: “Re-certify who is still in the Finance security group every quarter” → group membership access review. “Confirm who still has the vendor portal app” → application assignment review. “Attest who still has the partner package after extensions” → access package assignment review. “Who remains eligible for Privileged Role Administrator” → PIM access review on the Entra role, not a random M365 group review alone.
Privileged roles vs packages vs groups
| Need | Prefer |
|---|---|
| Temporary elevation for admin tasks | PIM eligible activation (+ optional role access review) |
| Multi-resource project access for guests | Access packages + package reviews |
| App RBAC / licensing / team membership | Groups + group membership reviews |
| Sign-in conditions (MFA, device) | Conditional Access (not an access review substitute) |
Access reviews complement entitlement management and PIM; they do not replace request workflows or just-in-time activation.
Create and configure an access review
Typical creation flow (portal or Microsoft Graph concepts):
- Start a new access review and choose the resource type (group, application, access packages, or role-oriented PIM review path).
- Select the resource(s) — specific group(s), app, packages, or role scope.
- Scope the users — all members/assignees; guest users only; users who meet inactive / recommendation-oriented filters where offered; or selected people.
- Choose reviewers:
- Managers — each user’s manager decides (excellent for large employee populations when manager data is accurate).
- Selected users or groups — a compliance team, resource owners, or named delegates.
- Users review their own access (self) — attestation by the principal; useful but weaker for high-risk access if unsupervised.
- Group owners — owners attest membership of their groups.
- Application owners — for app assignment reviews where owner is authoritative.
- Set duration — how many days the review stays open for decisions.
- Configure recurrence — one-time vs weekly/monthly/quarterly/semi-annual/annual patterns (exact options evolve; know that recurrence exists and is exam-critical).
- Multi-stage (if needed) — stage 1 must complete before stage 2; different reviewer types per stage.
- Show recommendations — surface insights such as user has not signed in recently / unused access so reviewers decide faster.
- Auto-apply results and if reviewers don’t respond outcomes — keep access, remove access, or take recommendations as configured.
- Notifications — email reviewers at start, reminders, and optionally when a review ends.
- Start the review and monitor progress (section 13.2).
Reviewer type decision table
| Reviewer type | Best when | Risk if misused |
|---|---|---|
| Managers | Workforce access tied to employment hierarchy | Stale or empty manager attribute → wrong or missing reviewers |
| Group owners | Owners truly know membership purpose | Orphaned groups with no owner → stalled reviews |
| Selected users | Central identity/compliance or app owner named set | Too small a set becomes bottleneck or single point of failure |
| Self | Low-risk broad attestation / awareness campaigns | Users rubber-stamp their own privileged or guest access |
| Multi-stage | High-risk: manager then resource owner | Over-staging low-risk groups causes fatigue and “Approve all” behavior |
Exam trap: choosing self-review for standing Global Administrator or highly privileged app roles when the stem asks for independent attestation—prefer selected privileged reviewers or multi-stage with non-self stages.
Recurrence and series design
A one-time review is a point-in-time audit. Recurring reviews create a series so the same scope reopens on a schedule without rebuilding policy from scratch each quarter.
| Cadence idea | Common use |
|---|---|
| One-time | Merger cleanup, incident-driven re-cert, pilot |
| Monthly | Privileged-adjacent groups, break-glass exception lists under scrutiny |
| Quarterly | Department security groups, many LOB apps, guest-heavy packages |
| Semi-annual / annual | Broad low-risk collaboration groups |
Design tips:
- Align package expiration (Chapter 12) with review cadence so external access is both time-boxed and re-attested when extended.
- Do not schedule every group in the tenant on the same Monday—stagger to protect reviewer capacity.
- Recurrence without apply results is theater: decisions that never change access fail the control objective.
Multi-stage access reviews
Multi-stage reviews chain independent reviewer populations.
| Stage 1 | Stage 2 | Intent |
|---|---|---|
| Manager | Group / app owner | Business need then resource ownership |
| Self | Selected security group | User claims need; security confirms |
| Group owners | Selected compliance users | Owner proposal with compliance gate |
Configuration concepts:
- Stages run in order; later stages see remaining decisions per design.
- Each stage has its own reviewer type and duration slice within the overall campaign.
- Use multi-stage when a single reviewer type cannot speak for both business justification and resource risk.
- Avoid multi-stage for low-risk bulk guest cleanup if a single guest-only + recommendations review already meets the goal—exam answers should match risk, not maximize clicks.
Guest-focused and inactive-user patterns
B2B sprawl is a classic SC-300 storyline.
Guest-only group or app reviews
Scope the review to guest users only inside a group or app assignment set so employee members are not noise. Reviewers (often group owners or selected partner sponsors) deny guests who left the project; apply results removes membership/assignment.
Inactive insights and recommendations
Entra can surface recommendations such as users who appear inactive (no recent sign-in) so reviewers—or automation—favor Deny. Concepts:
| Concept | Exam meaning |
|---|---|
| Recommendations / insights | System-suggested keep/remove signals (for example unused access) shown to reviewers |
| Reviewer accepts recommendation | Human still decides, guided by insight |
| Auto-apply recommendations | When configured, the system can apply recommended removals under the review’s automation rules (especially powerful with inactive guests) |
| Guest cleanup scenario | Guest-only scope + inactivity recommendation + apply/remove = directory and resource least privilege |
Caution: Auto-removing based on inactivity can hurt seasonal workers, break-glass accounts wrongly in scope, or service-like guest patterns. Exclude emergency accounts; prefer shorter package duration for true service partners; test on a pilot group.
Access package assignment reviews
When packages grant multi-resource access, reviewing package assignments re-certifies the entitlement, not only one underlying group. Pair with connected-organization packages and automatic guest removal lifecycle (Chapter 12) so denied/expired package holders do not linger as useful attackers’ footholds.
Auto-apply results and “if reviewers don’t respond”
Two related automation levers:
| Setting family | Effect |
|---|---|
| Auto apply results | When the review completes, approved/denied outcomes are written to the directory (remove denied members/assignments) without a separate manual apply click |
| If reviewers don’t respond | Fallback: no change, remove access, approve access, or take recommendations (options as product provides) for users never decided |
| Show recommendations | Influences human and/or automated paths |
Exam nuance: Creating a review is not the same as applying results. If auto-apply is off, an admin must apply after completion or access never changes—section 13.2 hammers this trap.
End-to-end planning checklist
- Map scopes: groups, apps, packages, Entra roles (PIM).
- Fix directory hygiene first where possible (owners present, manager attribute populated).
- Choose reviewer type(s) and multi-stage only when justified.
- Set duration, recurrence, guest/inactive scope filters.
- Enable recommendations for large or guest-heavy sets.
- Decide auto-apply and non-response behavior deliberately.
- Enable notifications; brief reviewers.
- Pilot one high-value group; measure false removals; then scale series.
- Document for auditors: what was reviewed, by whom, when applied.
Common exam traps (create/plan)
- Reviewing the wrong object type (group vs app vs package vs role).
- Self-review for high privilege when the stem wants independent control.
- Managers as reviewers when manager data is empty for guests—guests often need group owners or selected sponsors instead.
- One-time review with no recurrence for “continuous compliance” stems.
- Expecting access reviews to enforce MFA—that is Conditional Access.
- Forgetting guest-only scope when the goal is B2B cleanup without bothering every employee member.
Summary of section 13.1
An organization must re-certify every quarter who still needs membership in a high-risk Finance security group, with each employee’s manager deciding. Which configuration best matches?
Which access can Microsoft Entra access reviews commonly attest in SC-300 identity governance scenarios?
A partner collaboration group has both employees and many B2B guests. The goal is to remove only stale guests without requiring decisions on every employee member. What scoping approach fits best?
Why might an admin enable recommendations and consider auto-apply behavior on a large guest access review?