SaaS access reviews: A checklist for IT teams

A SaaS access review checks whether people still need the accounts and permissions they hold. Use this checklist to decide who should keep access and verify the changes made after each review.

A directory export is a useful starting point, but it may omit direct app grants and guests invited inside the app. A completed review also needs more than an approval record: someone must carry out each change and check the result.

The process is periodic. It supplements the access changes you make when employees join, move roles, or leave.

1. Define the scope and review policy

Start with a named set of apps and resources. Identify the kinds of access included: ordinary user accounts, privileged roles, guests, shared accounts, and service identities. Microsoft highlights privileged access, business-critical applications, policy exceptions, and guest access as areas to consider in review planning.

Set the review cadence with the people responsible for security and compliance. Base it on the risk of the access and the requirements that apply to your organization. Record where each required interval comes from. Do not assume that every app needs the same schedule or that a quarterly review is sufficient for every purpose.

Before launching, agree on the deadline, available decisions, who implements changes, and what happens when a reviewer does not respond. These are policy decisions; Microsoft's planning guidance similarly asks teams to settle review scope, frequency, reviewers, follow-up actions, and communications.

Make the workload realistic. A reviewer who understands a small, well-scoped list can make more useful decisions than one asked to approve an unexplained dump of every account.

2. Reconcile app permissions with the directory

Build the app list from the SSO catalog, purchasing and expense records, and information from app owners. Include tools that are not connected to the identity provider.

For each app, compare its user and permission records with the directory. Check the actual role and resources a person can reach. An account in a billing system might allow viewing invoices, issuing refunds, or administering every user; those are different review decisions.

Look for each path that grants access:

• Directory groups, including any nested or dynamic group behavior.
• Roles assigned directly inside the app.
• Project, folder, page, or other resource shares.
• Guest invitations and temporary exceptions.

Microsoft advises planning application access reviews when users have direct access to an app outside a group or access package. It also notes that its sample script for external identities will not show assignments made outside Entra, such as direct rights to SharePoint resources granted without groups. Check the app's own records to fill those gaps.

Compare the app's grant records with the directory so direct and resource-level access is included.

Investigate unmatched records, including old email addresses and duplicate accounts. Find an owner for each account before closing its review. Do not drop a row simply because it cannot be matched automatically.

Review service identities separately with a named technical or business owner. They may need access for a scheduled job even when no employee signs into the account. Microsoft includes reviewing programmatic access through service principals among IT administration's access review responsibilities.

3. Assign the decision and the follow-up

The reviewer decides whether the access is still needed. The remediation owner makes the approved change and verifies it. One person may perform both jobs, but record both responsibilities.

Choose reviewers who understand the business purpose and the resource. Depending on the resource being reviewed, Entra supports resource owners, managers reviewing their direct reports, individually selected reviewers, and users attesting to their own access.

Do not make a manager guess what an unfamiliar role permits. Give them an explanation of the role and a route to the app owner for questions. Self-attestation can provide context, but decide whether the risk calls for an independent reviewer.

Also check who has authority to implement changes. For example, Entra access reviews cannot directly change membership in groups synchronized from on-premises Active Directory; the change needs to happen at the source. A recorded removal decision needs an owner who can act there.

4. Keep a record for each grant

Use a record that connects the decision to the exact access under review. A spreadsheet or ticket can work if it preserves that connection.

Use activity data to prompt questions. A recent login does not by itself justify an administrator role, and an account used only for a periodic business task may have a legitimate reason to be quiet. Ask for the current business reason and the permissions that task needs.

Apply the agreed non-response policy when a deadline passes. Escalation, temporary retention, and removal have different consequences. The choice should be explicit and traceable rather than an accidental default in the review tool.

5. Apply changes and verify effective access

For every change or removal, check the result in the app. Keep evidence such as a dated permission export, administration event, or effective-permissions check. A review log proves that someone made a decision; it does not necessarily prove that the destination app changed.

Check overlapping grants. Removing a person from a group can leave a direct assignment in place. That assignment may preserve some or all of the access you intended to remove. Verify the permissions the person actually has after the change.

Where the decision requires access to stop, also consider existing sessions, tokens, and shared credentials. Deprovisioning an account does not necessarily end sessions or tokens issued before the change. They can remain usable until expiry or revocation. Check each app's revocation behavior and assign any additional work needed.

For example, imagine a review of a billing app:

• A support lead still needs a refund-approval role. The reviewer retains it with the business reason recorded.
• A former contractor has a direct app grant. The owner removes it and checks the account's remaining access.
• An analyst no longer needs administration rights after a migration. The owner changes the role and verifies the analyst can view reports but cannot administer users.
• A service account has no known owner. The review stays open while the team identifies its purpose and decides whether to retain or retire it.

An entry is complete only when it has a decision and, where action is required, evidence that the change took effect. The service account entry is not complete yet.

Link completion evidence back to the grant and decision it verifies.

6. Pilot automation on a limited scope

Before allowing automatic removals, test the review on a small set of lower-risk resources. Microsoft recommends starting with reviews whose results are not applied automatically, and documenting any access removed during the pilot so it can be restored quickly if needed.

Use the pilot to find unclear role descriptions, absent owners, unmatched accounts, and changes that require manual follow-up. Confirm that the tool can act on every grant type you intend to automate. Keep manual steps for access outside its authority.

7. Close the review cycle

After each review cycle, count unresolved decisions and overdue changes as unfinished work. Assign owners and dates for those exceptions, then update the next review's scope and instructions based on what caused delays. The useful outcome is a reliable record of who needs access and what the apps now allow.