User access review from your user exports
Updated
Drop the user lists you exported from Okta, Google Workspace, Microsoft Entra ID, GitHub, the AWS IAM credential report or any other system. The page flags leavers, inactive, admin, MFA-off, suspended, service and external accounts, merges people across systems by email, and builds a review workbook with decision columns and a sign-off sheet. It runs in your browser: files never leave your device.
Your files never leave this browser. They are read by this page on your device: nothing is uploaded, nothing is sent to a server and nothing is stored. Close or reload the tab and the data is gone.
1. Add your user exports
CSV from Okta, Google Workspace, Microsoft Entra ID, GitHub, the AWS IAM credential report or any other system. JSON and Excel files work too. Add as many files as you have.
2. Review settings
Leavers list (optional)
A CSV from HR with an email and a leave date per person (a name helps match accounts that have no email). Accounts that are still active after the leave date are flagged.
3. Review the flags and download the workbook
Add at least one export, or try the sample, to see the results here.
What it flags
Each flag is a rule applied to the export, not a finding. It points the system owner at an account that needs a decision or a reason.
| Flag | When it is raised |
|---|---|
| Leaver still active | Matches someone on the leavers list, the leave date has passed and the account is not suspended or deprovisioned. |
| Inactive 90+ days | Last sign-in or activity is more than 90 days before the review date. |
| Never logged in | The export has a last sign-in column and it is empty or says never for this account. |
| Admin or privileged | An admin, owner or root role. Privileged accounts are reviewed one by one. |
| MFA off | The export says MFA or two-factor is not enrolled for this account. |
| Suspended but still present | Suspended, disabled or deprovisioned, but the account still exists. Decide whether to delete it or record why it is kept. |
| Service or shared account | Looks like a non-human or shared account (no-reply, svc-, bot, ci, shared mailbox names, keys only). It needs a named owner. |
| External domain | The email domain is not one of the company domains you entered, or the account is a guest. |
| Duplicate in system | The same person has more than one account in this system. |
| In several systems | The same person has accounts in more than one system. Shown so a leaver or role change can be followed across systems. |
The inactivity threshold defaults to 90 days and can be changed. The service account rule looks for names such as no-reply, svc-, bot and ci, shared mailbox names such as support@ and info@, Google Cloud service accounts, GitHub bot accounts and AWS users with access keys but no console password.
What auditors expect from an access review
A user access review is a periodic check, system by system, that everyone with an account still needs it and has no more access than their role requires. Auditors test it under the logical access criteria:
- CC6.1 Logical access security: logical access is restricted; the list of systems you export from shows what the review covers.
- CC6.2 User registration and deprovisioning: access is removed when people leave; auditors compare active accounts with the leavers list, which is what the leaver flag does.
- CC6.3 Role-based access and least privilege: access matches each person's role; Remove and Change role decisions, with tickets, show least privilege is kept up, not granted once.
For each review in the audit period, the auditor typically asks for:
- the exported user list for each in-scope system, with the date it was exported;
- the reviewer’s decision for each account, especially admin and production access;
- tickets or system logs showing that the removals and role changes were made;
- the system owner’s sign-off, dated within the period your policy sets.
A common test is to pick people from the leavers list and check that their accounts were gone by the next review. The cadence the auditor tests against is the one in your own Access Control Policy, so review as often as it says. When generator answers are saved in this browser, the workbook quotes that statement on its Instructions sheet.
The workbook
- Instructions: the review date, threshold and domains, the cadence from your policy, the steps, what each flag means and the files used.
- Accounts: one row per account with its flags and the reason for each, then Decision (a Keep, Remove or Change role list), Reviewer, Decision date, Ticket and Notes.
- People: one row per person, with every system they have an account in.
- Summary: counts per flag and per system, with COUNTIF formulas over the Decision column so the counts update as reviewers fill it in.
- Sign-off: one row per system for the owner’s attestation, plus the coordinator and approver.
Values from your files are written as text, so a cell in an export that starts with =, +, - or @ is never run as a formula. A Markdown summary is also available for a ticket or wiki page.
How to export from each system
Okta
In the Okta Admin Console, open Reports and download a user report as CSV; Okta’s help articles point to the User Accounts report and the Okta Password Health report. Column names vary by report, so check the mapping after adding the file.
Google Workspace
Admin console: Menu > Directory > Users > Download users, then all user info columns and CSV.
Microsoft Entra ID
Entra admin center: Users > All users > Download users. For MFA status, add the User registration details report from Authentication methods under the same system name.
GitHub
Organization > People > Export > CSV, as an organization owner. Or, with the GitHub CLI (replace ORG):
echo "login,role" > github-members.csv
gh api --paginate "orgs/ORG/members?role=admin" --jq '.[] | [.login, "admin"] | @csv' >> github-members.csv
gh api --paginate "orgs/ORG/members?role=member" --jq '.[] | [.login, "member"] | @csv' >> github-members.csv
echo "login,2fa" > github-2fa-off.csv
gh api --paginate "orgs/ORG/members?filter=2fa_disabled" --jq '.[] | [.login, "false"] | @csv' >> github-2fa-off.csvAdd both files with the system name GitHub; the rows are merged by login.
AWS IAM
IAM console: Credential report > Download report. Or with the AWS CLI:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csvThe credential report lists IAM users and the root user only. Review IAM Identity Center users and roles separately.
Anything else
Any CSV with an account or email column works. Pick “Other” as the export type, name the system, and map the columns you have.
Related
- Access review template: the blank quarterly review sheet and service account inventory, if you prefer to start empty.
- Access Control Policy: the policy that sets the review cadence and the leaver removal timeline.
- Policy generator: answer the questions once and the workbook quotes your own Access Control Policy.
- Audit Kit: the paid kit includes the access review and service account registers pre-filled with your systems.
Frequently asked questions
- Are my files uploaded anywhere?
- No. The page reads the files with your browser and keeps them in memory in this tab. Nothing is sent to a server, nothing is written to local storage or cookies, and the workbook is built on your device. Reload or close the tab and the data is gone. The only thing the page reads from browser storage is your own generator answers, if you saved any, to quote your Access Control Policy.
- How do I export users from Okta?
- In the Okta Admin Console, open Reports. Okta's help articles describe downloading user lists from there as CSV, for example the User Accounts report and the Okta Password Health report. Report names and columns differ between Okta versions, so after you add the file, check the column mapping: the account, status and last login columns matter most. A JSON list of users from the Okta Users API also works.
- How do I export users from Google Workspace?
- In the Google Admin console, go to Menu > Directory > Users and click Download users. Choose all user info columns and CSV. The tool reads the email address, status, last sign-in and 2-Step Verification enrollment columns.
- How do I export users from Microsoft Entra ID?
- In the Microsoft Entra admin center, go to Users > All users and select Download users. That file has userPrincipalName, accountEnabled and userType, but no sign-in dates or MFA status. For MFA, also download the User registration details report from the Authentication methods area and add it under the same system name: the rows are merged by user principal name.
- How do I export members from GitHub?
- Organization owners can open the organization, click People, then use the Export menu and choose CSV. The export includes each member's role and two-factor status. With the GitHub CLI you can list owners and members with gh api --paginate "orgs/ORG/members?role=admin" and role=member, and members without two-factor authentication with filter=2fa_disabled; the page shows the exact commands. JSON output from gh api works as is.
- How do I get the AWS IAM credential report?
- In the IAM console, choose Credential report and then Download report. With the AWS CLI, run aws iam generate-credential-report, then aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv. The report covers IAM users and the root user, not roles or Identity Center users, and it has no permissions, so admin rights other than root have to be checked in IAM.
- Which columns does the tool need?
- Only an account name or an email. Everything else is optional: status, role or admin, MFA, last sign-in or activity, created date and account type. A flag is raised only when its column exists, so an export without an MFA column shows MFA as blank rather than off.
- How are people matched across systems?
- By email address first. An account with no email, such as a GitHub login or an IAM user name, is linked to a person when its name is the part of exactly one email before the @, or when its full name matches exactly one person. Linked accounts are labeled so the reviewer can confirm them.
- Does this replace the access review?
- No. It prepares it. The flags are simple rules that point at accounts worth a closer look; the system owner still decides Keep, Remove or Change role for each account, the removals still need tickets, and the owner still signs off. The workbook is where those decisions are recorded.
- How often should we run it?
- As often as your Access Control Policy says. SOC 2 does not set a frequency; quarterly is a common choice for production, source code and identity administration, and it is what the Policyseed Access Control Policy commits to for those systems.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.