Access reviews are unfinished until the permission changes

“Remove access” can be a valid review decision without being a completed access change. Microsoft Entra’s access-review documentation makes the distinction concrete: applying results does not change groups managed in an on-premises directory, and a user whose access comes through a nested group can retain it because the review does not remove that nested membership.

For an identity governance lead, the implication is straightforward. A campaign needs to produce a justified decision and carry it to the place where permission is actually granted. Reporting only reviewer completion leaves the most consequential part of the work outside the result.

Give the reviewer a decision they can make

A manager shown a group code and a name has little basis for deciding whether access is necessary. Translate the entitlement into its operational meaning: which application or data it reaches, what actions it permits and why the person was given it. Include the relevant role, assignment or project and its expected end date where one exists.

Choose the reviewer for the decision. A line manager may understand the employee’s current work but not the powers hidden inside an application role. The application owner may understand those powers but not whether the employee still performs the task. For consequential access, arrange the two perspectives so neither has to guess.

In a hypothetical finance review, a manager sees an employee assigned to FIN-AP-L3. The useful description explains that the role permits supplier-bank-detail changes, identifies the process that requires it and shows that the employee has moved to another team. The reviewer can now ask whether that responsibility moved with them, rather than approving an opaque label.

Use activity information as supporting evidence. No recorded use may reflect seasonal work, emergency duties or incomplete telemetry. Recent use establishes activity, not an ongoing business justification. Ask whether the work still requires the entitlement and whether a narrower role would support it.

Give uncertain decisions a route. “Investigate” should reach a named resource owner or specialist with a deadline. It should remain visibly unresolved until that question is answered. Relabelling uncertainty as approval makes the campaign look complete by discarding the problem it was meant to find.

Make silence an explicit policy choice

Set a review period that allows a meaningful decision, with reminders and an escalation route to a deputy or accountable owner. Before launch, establish what happens if nobody responds. An unnoticed default can either leave unnecessary access in place or interrupt legitimate work.

Entra’s review settings include several non-response outcomes: no change, removal, approval or taking the system’s recommendation. Microsoft warns that combining removal or recommendations with automatic application can potentially revoke all access to the resource if reviewers fail to respond. These settings express a business policy; they are not merely campaign administration.

Choose the consequence according to the resource and the organisation’s agreed access rules. Temporary project access with a known end date may justify a different treatment from an operational role needed to run a critical service. Where continued access is exceptional, make the exception bounded and accountable rather than silently extending it.

Test the non-response path on a controlled sample. Check who receives the escalation, whether they can understand the request and which action occurs at the deadline. A reminder sent successfully is not evidence that the right decision maker received enough information to act.

Trace the decision to effective access

Map how each entitlement reaches the resource before promising automated removal. Direct assignments, inherited groups, rules and permissions inside the application may require different actions. The review platform can only change the objects and relationships its implementation supports.

For an on-premises group, send the approved change to the team that manages that directory and verify the resulting membership. For nested access, identify the granting path and assess the effect of changing it: removing membership may affect other resources as well. Do not make a broad group change blindly when the review concerned one application.

Entra also distinguishes a completed review from applying its results: if automatic application was not enabled, someone must apply the decisions manually. Treat that step, any failed application and the subsequent target-system result as part of the campaign’s work.

Use a small operational record for each removal: person, resource, granting entitlement, decision and reason, change owner, expected completion and confirmed result. Preserve exceptions and failures separately. The aim is to make outstanding access visible, not to produce another document that says a request was sent.

Confirm the state at the relevant boundary. Group membership may be the right check for one resource; another may require application-role inspection and a controlled access test. Consider alternative assignments and existing sessions where they could preserve the capability being removed. The scope of the verification should match the entitlement’s consequence.

Report justified retention, confirmed removal and unresolved remediation alongside reviewer completion. A removal count is not a target to maximise: correctly retained access is also a legitimate outcome. The stronger measure is whether the campaign can explain and demonstrate the resulting state.

Start with a consequential application whose granting paths you can inspect, repair the process and then expand. Where the identity decision still fails to reach the application, continue with closing SaaS lifecycle gaps at the application boundary. That is where a tidy review result becomes an effective control.