A google workspace admin access review is the list of people who can change users, groups, or the tenant itself. Super admin, user admin, and groups admin are the three labels auditors ask for by name. The painful version is a screenshot of the admin console taken the week the request arrived. The screenshot misses roles granted through a security group, and it misses a custom role that suspends users under a friendly name.
Rutagon builds the export from role assignments and files it in the GRC platform you already run. The client is the one in the audit. Rutagon builds the evidence pipeline. A manager still decides whether each admin is right. The pipeline makes the indirect grant visible before the sample.
What we treat as admin
The population is assignments that confer super admin, user admin, or groups admin, plus custom roles that carry the same privileges. Super admin is the system role whose API name is _SEED_ADMIN_ROLE, with the super-admin flag set and the SUPER_ADMIN privilege. Groups admin is the system role _GROUPS_ADMIN_ROLE, described as Groups Administrator, which includes GROUPS_ALL. User admin is the system role whose privileges include creating users and suspending users. Google documents those privilege names on the Manage roles guide: user create sits with USERS_CREATE, and suspend sits with USERS_SUSPEND. We label that row user admin even when the console wording and the API role name differ.
A custom role named for a team, if it includes those privileges, is in the same population. A review that filters on the three prebuilt display names will bless "ops helper" while that role resets passwords. Custom roles that match none of the three privileges are outside this pack. They belong in a broader admin review, not in a silent drop.
Prebuilt roles are organization-wide unless the assignment says otherwise. When an assignment is limited to an organizational unit, the unit is a column. A user admin over one department is not the same grant as a user admin over the tenant. The reviewer needs the scope on the row.
Google Workspace admin access review rows
We list assignments with the Directory API and we follow pagination until the page token is gone. The guide warns that a page can come back empty and still carry a token. Stopping on the first empty page drops admins. That bug looks like a clean review.
Direct assignments and indirect assignments are both in scope. Indirect means the role is on a group the person belongs to. The call that includes indirect assignments is the one we keep. Google allows group assignment for roles other than super admin, and the group has to be a security group. Super admin stays a direct user assignment. If we ever observe it any other way, the row is an exception, not a footnote.
Each row carries the role label (super admin, user admin, or groups admin), the API role name, the stable assignee id, whether the assignee is a user or a group, whether this person received it indirectly, and the scope. We resolve the id to an email for the reviewer and we keep the id, because email changes and the assignment does not. Privilege-creep across ordinary apps is a different sheet, covered in privilege creep access review. This pack is the tenant admin roles.
role_label: groups-admin
role_name: _GROUPS_ADMIN_ROLE
assignee_id: stable-id
assignee_type: group
indirect: true
scope: tenant-or-unit
decision: pending
A groups-admin role on a security group expands to every member. The row records the group and the member. Reviewers who only see the group object certify one line and miss fifty people. Expansion is the point of the indirect flag. Nested group expansion is the same discipline we use in nested group access review, applied here to admin roles rather than to an ordinary application group.
Decisions, tickets, and the next export
The reviewer marks keep or remove on each person, not on the group object alone. Removing a person from a security group is a different ticket from deleting a direct role assignment. We store which change was requested. The next export is the test. If the person is still an admin, the row reopens, including when they remain admin through a second group we did not edit.
A keep on super admin needs a named reason. We do not auto-close super admin because the person is in the security team. Headcount in a security alias is not a privilege justification. User admin and groups admin get the same standard with a narrower question: does this person still create users, suspend users, or edit groups? A help-desk role that only needed password reset should not be carrying user create. When the privileges are bundled inside a prebuilt role, the remediation is a custom role with the smaller set, and the old assignment comes off. We record that as a ticket, then we read the assignment list again.
Service accounts can hold role assignments. They are rows with a service owner, not invisible infrastructure. An unowned service account with user admin stays open until a person owns it. The same owner rule we apply to human admins applies here.
What we refuse to file as evidence
A console screenshot is not the export. It shows the accounts someone scrolled to, at the moment they scrolled. It does not show indirect membership, and it does not show the privilege set on a custom role. We keep the API extract, the time it was pulled, and the ticket id from the GRC you already run.
Scope mistakes are filed as open rows. An assignment we cannot resolve to a person or a service stays unmapped. Unmapped admin is worse than a long list of named admins. We do not drop unresolved ids to make the count match an expectation.
OU-limited user admin is easy to misread as "only a local helper." The privileges on that unit still include suspend and create when the role says so. The reviewer sees the unit name beside the privilege label. A keep decision that ignores the unit is sent back.
This collector is part of the security automation we put under access reviews. Workspace remains the system of record for the grants. We read assignments, expand groups, and write a stable row. The next audit window should be the same export with a new pull time, not a new spreadsheet shape.
Frequently Asked Questions
Does a google workspace admin access review include custom roles?
Yes, when the custom role carries super-admin, user-create, user-suspend, or full groups privileges. The row is labeled with the matching admin class. A custom role that has none of those privileges stays out of this pack.
How do security groups become admins?
The Directory API can assign a role to a security group, except super admin. Members inherit the role. We list indirect assignments and expand the group so each person is a row. A single line that names only the group is not the review.
Why follow an empty page token?
The roles guide says the assignment list can return an empty page and still include a page token. Stopping there omits later assignments. We page until the token is absent, then we file the export.
Is super admin ever granted through a group?
The documented rule is that group assignment covers roles other than super admin. We expect super admin on a user. Any other shape is an exception row that stays open until someone explains it.
Where is the sign-off stored?
In the GRC you already run, with the ticket id written back onto the export. Removal happens in Workspace, either on the direct assignment or on the group membership. The following export confirms the person is gone.
See what an Access & Credential Governance Diagnostic finds in your environment. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.