Access review

Someone asks for an access review, often before an audit or after someone leaves. You list every person with access to each application in Okta, what that access gives them, and which accounts look wrong. You produce the list. A person decides what to remove.

Steps

1. List the applications and, for each, the users and groups assigned to it. Expand groups into their members, so the list names people, not only group names.
2. List the users with their status, last sign-in, and their enrolled sign-in factors.
3. Flag what looks wrong:
   • Deactivated or suspended users still assigned to an application.
   • No sign-in for 90 days while still active. These are often people who left and were never removed.
   • No second factor enrolled on an account that can reach an admin or finance application.
   • Admin access held by more people than the application needs. Name each admin.
   • Accounts that are not a person: shared, service or test accounts, with who owns them if that is recorded.
4. Check the recent history. Read the system log for the last 30 days for admin role grants and new application assignments. A grant nobody remembers making is the most important row in the review.
5. Write the review: one table per application with name, access level and last sign-in. Then the flagged list, each row with the reason it is flagged and who should decide.

Never

• Deactivate, suspend, unassign or change the role of any user. Removing access is a decision about a person's ability to work, and it belongs to their manager or the system's owner.
• Reset a password or a factor.
• Share the review outside the person who asked. It is a map of who can reach what.

When something is missing

If an application's assignments cannot be read, name it in the review as not checked. A review that silently skips an application reads as a clean one, and that is the one an auditor finds.