13.2 Monitor & Respond to Access Reviews

From configuration to living campaigns

Section 13.1 planned and created access reviews. Section 13.2 is the runbook: how identity administrators monitor open series, how reviewers respond to email prompts, what Approve / Deny / Don’t know mean, when and how results apply, how inactive guest cleanup plays out, and how audit proves the control. SC-300 items often describe a completed review where “nothing changed”—the correct diagnosis is usually results not applied or auto-apply off with no manual apply, not “access reviews are broken.”

/practice/azure-sc-300Practice questions with detailed explanations

Monitor review progress

In the Microsoft Entra admin experiences for Identity Governance, each review (and recurring series) exposes status that admins must interpret.

What to watch on the dashboard

• Percent of users reviewed vs total in scope.
• Reviewers who have not responded — especially for manager-based reviews with out-of-office leaders.
• Decisions skew — 100% Approve on a guest-heavy high-risk app may indicate rubber-stamping; investigate.
• Recommendations accepted vs overridden — useful for tuning whether automation should be stronger next series.
• Recurring series health — last instance applied cleanly; next instance still has valid owners/managers.

SC-300 cue: “Review ends tomorrow and only 20% of managers responded” → remind/escalate reviewers, consider if reviewers don’t respond policy for the series design, do not assume silence equals deny unless that fallback is configured.

Email prompts and the reviewer experience

Reviewers typically receive email notifications when:

• A review starts and they have users to decide.
• Reminders fire for incomplete work.
• Optionally when the review ends or requires attention.

They complete work in the My Access review experience (or admin-assisted paths where roles allow). Good operations treat these emails as governed tasks, not optional surveys.

Non-responsive reviewers

Operational playbook:

1. Confirm notifications are enabled on the review.
2. Check spam/security gateway filtering of Microsoft governance mail.
3. Verify the reviewer still exists, is enabled, and is the correct person (manager attribute drift is common).
4. Use admin capabilities to nudge, reassign, or complete decisions where the product and role allow—or accept the configured don’t respond outcome.
5. For chronic non-response on critical scopes, change reviewer type (for example from managers to selected compliance team) or add multi-stage with a reliable second stage.

Reviewer decisions: Approve, Deny, Don’t know

Decision quality guidance

• Use recommendations (inactive sign-in, unused access) as input, not as an excuse to skip reading high-privilege rows.
• Prefer Deny for departed contractors still in partner groups when business confirms project end.
• Prefer Approve only with a real ongoing job function—not “might need someday.”
• Use Don’t know sparingly; route to someone who knows (resource owner stage, helpdesk escalation)—repeated Don’t know on privileged scopes is a process failure.
• Batch decisions carefully: “Approve all” without insights defeats least privilege and shows up in audit culture reviews.

Multi-stage decision flow (runtime)

1. Stage 1 reviewers decide for their population.
2. Stage 2 reviewers decide for users still requiring the second attestation (per multi-stage design).
3. Final outcomes feed apply / auto-apply.
4. Denied at any required stage should not survive as lasting access once results are applied according to the review rules.

Apply results (the enforcement step)

Applying results writes review outcomes into Microsoft Entra ID: denied users are removed from the group, application assignment, access package assignment, or role assignment in scope.

Verification after apply

1. Spot-check denied users: group membership gone, app assignment removed, package assignment ended, role eligibility/active assignment adjusted as designed.
2. Confirm approved users still have access.
3. Check sign-in only if needed—removal of group/app assignment is directory state; CA still governs any remaining pathways.
4. Watch for shadow access: user denied on package but still in a direct group add outside the package will retain that direct path—clean residual access.
5. For guests fully done with collaboration, consider block sign-in, session revoke on risk, and delete or entitlement automatic guest removal when no packages remain (Chapter 12).

Hard exam trap: Admin creates a perfect guest review; all reviewers Deny inactive guests; auto-apply is off; nobody clicks Apply → guests still have access. Correct fix: apply results (or enable auto-apply for next series), not “create Conditional Access to all users deny.”

Inactive guest cleanup scenario (end-to-end)

A full SC-300 storyline:

1. Discover guest sprawl (many guests in partner security groups / apps; some with no sign-in for 90+ days).
2. Create access review: resource = partner group or app; scope = guests only; enable recommendations for inactive/unused access; reviewers = group owners or selected sponsor team (not self for high-risk data); duration 14 days; recurrence quarterly; if reviewers don’t respond = take recommendations or remove access (risk-based choice); auto-apply on for mature pilots.
3. Notify owners; monitor progress daily near the deadline.
4. Reviewers Deny clearly inactive guests; Approve active partners; Don’t know escalated to project lead.
5. Apply results (if not automatic).
6. Validate removals; optionally run entitlement lifecycle so guests with no remaining packages are removed from the directory.
7. Audit export: who denied whom, when applied.
8. Tune next series: shorter package durations, better owners, fewer permanent group adds outside packages.

Audit trail and compliance evidence

Access reviews support demonstrate control narratives for internal audit and external regulators.

Capture and retain:

• Review name, scope, start/end, recurrence.
• Reviewer identities and decision timestamps.
• Approve/Deny/Don’t know per user.
• Whether recommendations were shown/followed.
• Apply timestamp and actor (system auto-apply vs admin).
• Post-apply membership/assignment proof for samples.

Use Microsoft Entra audit logs and Identity Governance reporting experiences for “who changed what.” For sign-in impact after removal, use sign-in logs—different blade, different question.

Common exam traps (monitor & respond)

Wrong reviewer type—worked examples

• Stem: “Guests in Project Falcon group; many have blank manager; need quarterly cleanup.” → Group owners or selected project sponsors, guest-only scope—not managers as sole reviewers.
• Stem: “Recertify who can activate Privileged Role Administrator.” → PIM access review with appropriate privileged reviewers—not a random team’s self-review on an M365 Everyone group.
• Stem: “Employees should confirm they still need the cafeteria menu app.” → Self or managers may be acceptable for low risk; do not over-engineer multi-stage PIM-style reviews.

Operational checklist every series

1. Confirm series still targets the correct group/app/package/role.
2. Confirm owners/managers/selected reviewers are current.
3. Open instance starts; notifications sent.
4. Mid-cycle: completion %; chase laggards.
5. End: all required stages done or fallback engaged.
6. Apply results if needed.
7. Spot-check denials and unexpected removals.
8. File audit evidence; note lessons for next recurrence.
9. Feed findings into entitlement package durations and joiner/mover/leaver processes so the same stale access is not recreated next week by manual group adds.

How monitor/respond ties to Zero Trust

Zero Trust assumes breach and verify explicitly. Access reviews are the periodic verify for authorization state:

• Grant with least privilege (packages, app roles, PIM eligible).
• Enforce session and auth strength (Conditional Access).
• Re-attest with access reviews.
• Detect unused and risky paths (recommendations, Identity Protection, logs).
• Respond by denying, applying, blocking, and removing guests.

An unread review email is not Zero Trust—it is documentation of intent without enforcement.

Summary of section 13.2

/practice/azure-sc-300Practice questions with detailed explanations