What to take away
A user access review checks whether each verified account still needs its current access. A complete review defines the scope, names the reviewers, records decisions, applies required changes, and retains evidence of the outcome. Use this checklist to keep those stages connected.
1. Define a review that people can complete
Choose the applications, accounts, and roles under review. Name the accountable application owner, the people making decisions, a deadline, and the process for unanswered items. Decide how to handle guests, privileged accounts, shared accounts, and service accounts before sending the review to employees.
Microsoft’s access-review planning guidance emphasizes the review scope and appropriate stakeholders. For a cross-application review, make the same choices explicit in your tracking system. Choose recurrence according to risk and your organization’s requirements; one fixed calendar does not fit every application. A departure or role change may need action before the next scheduled review.
References: Microsoft — Plan an access reviews deployment
2. Start from verified accounts
Collect accounts and roles through a trusted connector or an authoritative export from the application. Retain the source and snapshot date. Match accounts to current employees where possible and route unmatched or non-human accounts to someone who understands them. Verify an imported list before treating it as the review population.
Discovery signals can help you find applications that deserve attention, but observed use and confirmed access are different evidence. A browser visit cannot establish a user’s role or whether a revoke action is valid. Likewise, an application may have accounts outside its single sign-on assignments. Record what your source includes and what requires another check.
3. Give reviewers enough context to decide
For each account, show the application, current role, owner, relevant employment or project context, and available activity evidence with its date. Ask whether access remains necessary, whether the role is appropriate, and whether any exception has a current justification. Record a reason alongside the decision.
Inactivity is useful context, not a decision by itself. Microsoft documents that activity-based recommendations depend on the reviewed resource and the information available when the review starts. A fictional contractor whose project ended and a finance employee who uses a system only at year-end may both appear inactive but require different outcomes. Ask the responsible owner to verify the need.
| Decision | What to establish | What happens next |
|---|---|---|
| Maintain | Current need and appropriate role | Record the reason and any exception expiry |
| Revoke | Access is no longer required | Assign removal and verify the source state |
| Change role | A different level of access is justified | Apply the role change and check the result |
| Needs investigation | The account, owner, or evidence is unclear | Assign an investigator; keep the item unresolved |
References: Microsoft — Review recommendations and activity evidence
4. Follow decisions through to source changes
A recorded revoke decision and a removed account are separate states. Microsoft’s access-review workflow similarly distinguishes collecting decisions from applying changes. Give every required change an assignee, due date, and completion record. Keep unapplied removals visible even after the reviewer has finished their part.
Use a supported direct action when the connection and account allow it. Complete other changes in the application itself and record what was done. Before revoking a shared or service account, identify dependent work and the person responsible for continuity. After a role change, check that the resulting permissions match the decision rather than relying only on a submitted request.
- Record the decision, reason, and reviewer separately from implementation.
- Assign each revoke or role-change task to someone who can act in the source.
- Verify the resulting source state and capture the date and evidence reference.
- Escalate failed changes and unanswered items instead of silently closing them.
References: Microsoft — Manage user access with access reviews
5. Keep a review record that explains the outcome
A reusable review sheet can contain: application, account, role, evidence source, snapshot date, business owner, reviewer, decision, reason, change assignee, due date, completion evidence, verification date, and exception expiry. Keep sensitive account details available only to people who need them.
At closure, retain the completed decisions, verified changes, exceptions, and clearly identified unresolved work. Microsoft provides downloadable review-history reporting for its own reviews; for a broader SaaS process, keep equivalent decision and completion evidence in your chosen system. An export supports an audit trail but does not itself establish compliance.
Measure reviewed accounts, outstanding decisions, unapplied changes, and overdue exceptions separately. Those measures reveal where the process needs attention. Carry the application scope into the next review, while refreshing account evidence and checking whether ownership or business use has changed.
References: Microsoft — Download access review history
How access reviews work in Elba
Elba reviews use connector-confirmed accounts or a validated CSV or screenshot import. Reviewers can record maintain, revoke, or role-change decisions and follow the required changes. Browser-only observations remain separate and cannot create a review decision or revoke action.
Direct access revocation is human-triggered and depends on the integration. Role changes are completed in the source application, and other unsupported changes are tracked after source-side completion. Elba can export a completed review and reuse its scope for a later one. Check each integration’s actual capabilities; for example, the documented Okta connection provides read-only context.
Reusable user access review checklist
Your checks stay on this page and reset when you reload it.
Common questions
How often should access reviews run?
Choose a cadence based on application risk, account types, organizational policy, and applicable requirements. Handle departures, role changes, and urgent exposure when they occur rather than waiting for the next review.
Is inactivity enough to remove access?
No. Check the quality and scope of activity evidence alongside the business need. Seasonal work, emergency access, or a source that cannot see all activity may explain an apparently inactive account.
Can we review applications without a connector?
Yes. Obtain an authoritative account list and validate it with the application owner. Elba supports validated CSV or screenshot imports; changes that cannot be performed directly still need to be completed and verified in the source.
When is a review complete?
Use explicit closure criteria: decisions recorded, required changes verified, and exceptions or unresolved items handled under your process. A finished questionnaire alone does not prove that unnecessary access was removed.
Sources & further reading
Primary documentation used to review this guide. Product settings and edition requirements can change; check the linked documentation before making changes.