Skip to content

Commit 3541a45

Browse files
authored
Merge pull request #102731 from flofromm/patch-2
Smaller updates to a few sections
2 parents 44cc8e4 + 6157d50 commit 3541a45

File tree

1 file changed

+14
-11
lines changed

1 file changed

+14
-11
lines changed

articles/active-directory/governance/using-multi-stage-reviews.md

Lines changed: 14 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -24,17 +24,17 @@ Azure AD Access Reviews support up to three review stages, in which multiple typ
2424

2525
Multi-stage access reviews allow you and your organization to enable complex workflows to meet recertification and audit requirements calling for multiple reviewers to attest to access for users in a particular sequence. It also helps you design more efficient reviews for your resource owners and auditors by reducing the number of decisions each reviewer is accountable for. This approach allows for combining otherwise disjoint, separate reviews for the same resource, to be combined in one access review.
2626

27-
:::image type="content" source="media/using-multi-stage-reviews/new-access-reviews.png" alt-text="Screenshot of new access reviews." lightbox="media/using-multi-stage-reviews/new-access-reviews.png":::
27+
:::image type="content" source="media/using-multi-stage-reviews/new-access-reviews.png" alt-text="Screenshot of admin experience to configure multi-stage reviews." lightbox="media/using-multi-stage-reviews/new-access-reviews.png":::
2828

2929
Here are some scenarios you may want to consider:
3030

3131
- **Reach consensus across multiple sets of reviewers:** Let two audiences of reviewers independently review access to a resource. You can configure reviews such that both stages of reviewers must agree on *Approved* without seeing each other’s decisions.
32-
- **Assign alternate reviewers to weigh in on unreviewed decisions:** Let the resource owner attest to access to their resource in stage 1. Then, users for which no decision has been recorded go to a second stage reviewer, such as the user’s manager or an auditing team, who review the undecided requests.
33-
- **Reduce burden on later-stage reviewers:** Reviews can be configured such that earlier-stage-denied users won't be reviewed by later stages, allowing for later stage reviewers to see a filtered-down list.
32+
- **Assign alternate reviewers to weigh in on unreviewed decisions:** Let the resource owner attest to access to their resource first. Then, users for which no decision has been recorded go to a second stage reviewer, such as the user’s manager or an auditing team, who review the undecided requests.
33+
- **Reduce burden on later-stage reviewers:** Reviews can be configured such that earlier-stage-denied users won't be reviewed by later stages, allowing for later stage reviewers to see a filtered-down list. Use this scenario to filter down on users to review, stage by stage.
3434

3535
## Reach consensus across multiple sets of reviewers
3636

37-
Reaching quorum on the right access for users could be difficult. For resources that many users have access to, or for a diverse group or users that need to be reviewed, it's especially hard for any single reviewer to make the right choices for all reviewees. Reaching consensus by giving three different reviewer groups the opportunity to record decisions and by showing what the earlier reviewer audiences said helps drive consensus on who should have access to the resource.
37+
Reaching quorum on the right access for users can be difficult. For resources that many users have access to, or for a diverse group of users that need to be reviewed, it's especially hard for any single reviewer to make the right choices for all reviewees. Reaching consensus by giving up to three different reviewer groups the opportunity to record decisions and by showing what the earlier reviewer audiences said helps drive consensus on who should have access to the resource.
3838

3939
An example would be a review that consists of three stages that determines group membership to a group that governs access to a resource. In the review settings, the administrator chooses to not show decisions of earlier stage reviewers. This configuration allows for every review audience, for example the user’s manager, the group owner and a security officer to review access independently. The three stages are lined up with increased importance of reviewer audience weight, with decisions from the last reviewer audience potentially overwriting earlier-stage reviewer’s decisions.
4040

@@ -52,7 +52,7 @@ The configuration for this scenario would look like this:
5252

5353
## Assign alternate reviewers to weigh in on unreviewed decisions
5454

55-
For scenarios that you need decisions recorded and need to make sure that access is preserved for the right people, multi-stage reviews let you progress a subset of reviewees to the next stage, that potentially needs a second reviewer audience for double-checking or decision making. Customers can use this pattern to ensure that there are fewer unreviewed users or users marked as **Don’t know**, by progressing these reviewees to another stage, and having another group of reviewers take decisions.
55+
For scenarios that you need decisions recorded and need to make sure that access is preserved for the right people, multi-stage reviews let you progress a subset of reviewees to the next stage, that potentially needs a second reviewer audience for double-checking or decision making. Use this pattern to ensure that there are fewer unreviewed users or users marked as **Don’t know**, by progressing these reviewees to another stage, and having another group of reviewers take decisions.
5656

5757
An example for this would be review that contains of two stages that determines access to an application. In the review settings, the review administrator chooses to **Show previous stage(s) decisions to later stage reviewers**. For **Reviewees going to the next stage**, the decisions that need confirmation would be added: to ensure all reviewees have a decision, select **reviewees marked as ‘Don’t know’** and **Not reviewed reviewees**, so that later-stage reviewers only see the undecided or unsure reviewees to retain the right access.
5858

@@ -87,19 +87,22 @@ An example would be a review of a group that grants an IT exception, that an adm
8787

8888
## Guest user reviews
8989

90-
Guest user reviews include organizations that use Azure AD B2B for collaboration, users that are invited from another company into their tenant, guest user accounts created for assigning, and resources for tracking and reviewing access. These guest users’ access should be reviewed regularly to check on whether collaboration is still desired in order to facilitate a cleanup of guest user accounts that are no longer needed.
90+
Guest user reviews help organizations that use Azure AD B2B for collaboration. These guest users’ access should be reviewed regularly to check on whether these guest users have the right access still, and that collaboration is still desired, so revoking access or a cleanup of guest user accounts that are no longer needed is possible.
9191

92-
This scenario can be configured with multi-stage reviews similarly to how the reduce reviewee list by filtering works. First, ask guest users to self-review and attest their continued interest and need for collaboration, and only then letting an internal employee approve or deny continued access or collaboration.
92+
This scenario can be configured with multi-stage reviews similar to how the "Reduce burden on later stage reviewers" scenario works. First, ask guest users to self-review and attest their continued interest and need for collaboration, including the requirement to provide a business justification. Only self-approved guests are progressed to a later stage, where an internal employee or sponsor approve or deny continued access or collaboration.
9393

94-
For guest user review scenarios, Access Reviews supports an extra configuration option: **Action to apply on denied guest users**, which can result in either:
94+
For guest user reviews, also consider leveraging the **Inactive users (on tenant level) only** setting. This will scope the review to inactive external users that have not signed in to the resource tenant in the number of specified days.
95+
96+
In scenarios for guest users, Access Reviews supports an extra configuration option: **Action to apply on denied guest users**, which can result in either:
9597

9698
- Remove user’s membership from the resource
9799
- Block user from signing-in for 30 days, then remove user from the tenant
98100

99-
Depending on your review needs, guest users that aren’t responding to the review request, or decline further collaboration, can be removed automatically from your tenant.
101+
Depending on your review needs, guest users that aren’t responding to the review request, or decline further collaboration, can be removed automatically from your tenant. This results in a blocked B2B guest user account for 30 days, following an account deletion.
100102

101103
| Attribute | Configuration |
102104
|:--- |:---:|
105+
|Inactive users (on tenant level) only|180 days|
103106
|Multi-stage review|Enabled|
104107
|First stage reviewers|Users review their own access|
105108
|Second stage reviewers|Group owner(s)|
@@ -121,7 +124,7 @@ Each review stage will stay open for reviewers to add decisions for the length o
121124

122125
## Application of results
123126

124-
Azure AD Access Reviews can apply decisions about access to a resource by removing no longer needed users from the resource. Decisions are always applied at the end of the review period or when a review administrator manually ends the review. Automatic application of results is defined by the review administrator with the **Auto apply results to resource** setting or manually through the **Apply results** button in the review overview page.
127+
Azure AD access reviews can apply decisions about access to a resource by removing no longer needed users from the resource. Decisions are always applied at the end of the review period or when a review administrator manually ends the review. Automatic application of results is defined by the review administrator with the **Auto apply results to resource** setting or manually through the **Apply results** button in the review overview page.
125128

126129
Decisions are collected by reviewers for every stage. The setting **Reviewees going to the next stage** defines, which reviewees later stage reviewers will see and asked to record decisions for. Only at the end of the overall review, decisions are applied to the resource.
127130

@@ -136,4 +139,4 @@ If the **Reviewees going to the next stage** setting is set such that only a sub
136139

137140

138141

139-
142+

0 commit comments

Comments
 (0)