Access reviews work best when they connect technical permissions to real business responsibilities. Use this starting point to organise a focused conversation with your system owners.
Start with a business service
An access review is easier to act on when it starts with a service that matters: customer records, payroll, finance or recovery administration. List the applications and shared resources that support it. Ask the business owner what people need to do, not simply which accounts appear in a directory. Keep the first review small enough that someone can own the decisions.
Separate the identity types
Include employees, contractors, administrators and applications. An integration may have permission long after the person who installed it has left. Record the owner, purpose and approval status of each identity in scope. Avoid putting passwords, secret keys or authentication recovery codes in the review worksheet. The inventory should explain access, not become another store of credentials.
Ask what each permission enables
A role name may conceal several capabilities. Can the account read records, export information, change settings, invite other users or grant further access? Review inherited group membership and delegated permissions as well as direct assignments. Ask the system owner to explain unfamiliar roles. Where a privilege is justified, record the reason and the responsible approver.
Check temporary access and exceptions
Temporary project access often becomes permanent because nobody receives a reminder to remove it. Set a review date or expiry where the platform supports it. Document exceptions with an owner and a reason. A dormant account should be investigated rather than removed blindly: it might support a critical process or an emergency access arrangement that needs separate handling.
Connect access to authentication and recovery
An appropriate role does not establish that the right person controls the account. Review sign-in protection, authentication enrolment and account recovery alongside permissions. Prioritise high-impact accounts and applications. CISA recommends phishing-resistant MFA; consult its guidance and the capabilities of the systems involved. A service-desk reset process must not provide an easier route around stronger authentication.
Make changes deliberately
Before removing a permission, confirm the business impact and who can authorise the change. Consider dependencies, support windows and a recovery path. Keep a record of the decision, implementation and verification. For a critical service account, test the narrower permission in an appropriate environment before making a production change. The goal is justified access that works, not the smallest possible account list.
Close the loop with evidence
A spreadsheet marked complete is not the same as a verified change. Record evidence that the intended access was removed or reduced and that necessary work still succeeds. Assign unresolved items to named owners and agree when they will be revisited. Use the findings to improve joiner, mover and leaver processes so the same gaps are less likely to return.
Use the review as a repeatable conversation
Access changes whenever people, suppliers and applications change. Combine a proportionate review schedule with event-driven checks after role transfers, contract endings and significant platform changes. The most useful output is a short list of clear decisions: retain, reduce, remove or investigate—with an accountable person for each. Start with one service, learn from the process and then expand the scope.