A Google Workspace tenancy handover is the transfer of administrative control, billing and documentation of a Workspace account from one IT provider or individual to another. Most of them are not handovers at all. Someone gives you a password, the previous provider stops answering, and you spend a fortnight finding out what was actually configured in 2016.
The audit below is what we run on day one. It takes a few hours and it is the difference between managing a tenancy and hoping about one.
Before anything else, prove you can get back in
Do this first, because everything else assumes you have durable access.
Confirm you hold a super admin account that belongs to your organisation, that it has recovery options set (recovery phone and email), that backup codes have been generated and stored, and that at least two security keys are enrolled. Google’s own administrator security guidance asks for more than one super admin account, each managed by a separate individual, and for each super admin to hold two accounts: one for admin work and one for daily activity.
Then check the super admin account self-recovery setting, because the default is not what most people assume. Google’s documentation states that for most current and all new customers, super admin account recovery is off by default, and that it is on by default only for existing customers with fewer than three super admins or 500 users. If self-recovery is off and you lose the account, the recovery wizard asks the organisation questions that a new provider will not know: the date the account was created, the original secondary email address used to sign up, the Google order number, the number of user accounts created, the billing address, and the type and last four digits of the credit card used. It also requires you to verify DNS ownership of the domain.
Which brings up the single most important item on this list.
Confirm who controls the domain registrar and the DNS zone before you touch anything. Not who pays for it. Who can log in and add a TXT record. If the answer is the previous provider, or a former employee’s personal account, you do not control the tenancy no matter what the admin console says. Fix that first. If nobody can get in at all, nobody has admin access at all walks through the recovery path.
The day one audit
Who is an administrator
Go to the user list and filter by admin role. You are looking for three things: ex-employees who still hold roles, accounts belonging to the outgoing provider, and shared generic accounts. Google explicitly warns against sharing administrator accounts, because if multiple people sign in as [email protected] you cannot tell from the audit log who did what.
Then check the Admin log events for the last twelve months. Activity from a super admin appears in the event description as _SEED_ADMIN_ROLE followed by the username. That log tells you who has actually been administering this tenancy, which is frequently not the same as who has the role.
Delegated and custom admin roles are the ones nobody remembers granting. Review each one against a named person and a stated reason. Anything you cannot justify gets removed.
Third-party OAuth grants
This is the largest single blind spot in an inherited tenancy. Go to Security, then Access and data control, then API controls, then Manage Third-Party App Access.
You get two lists. Configured apps are apps with an access policy of trusted, limited or blocked. Accessed apps are third-party apps that users have actually granted access to Google data. For each app you can see the OAuth client ID, user count, the Google service APIs and scopes it is requesting, and whether Google has verified it. Download the list to CSV, because the export includes columns the table does not display.
Two timing quirks to know. Details about third-party apps typically appear 24 to 48 hours after authorisation, and the accessed apps list is updated 48 hours after a token is granted or revoked. So the picture you see on day one is a day or two stale, and your remediation will not show as complete immediately either.
What you are looking for: apps nobody in the business can name, apps holding high-risk Gmail or Drive scopes, and apps installed by people who left. Google publishes the high-risk scope lists for both services, and https://mail.google.com/ on an app nobody recognises is a finding, not a curiosity.
Domain-wide delegation
Same menu, Manage Domain Wide Delegation. This is the one that matters most and gets audited least.
Google’s own documentation describes domain-wide delegation as letting client applications access your users’ data without requiring their consent, and warns that “the app has access to the data belonging to all of your users”. Google recommends a regular review of service accounts and deleting any no longer in use.
In an inherited tenancy you will typically find delegations for a migration tool that ran once in 2019, a signature management product that was trialled, a backup product that was replaced, and one you cannot identify at all. Each entry is a client ID plus a list of scopes. Match every one to a live business system and a current owner. Remove the rest.
Forwarding, delegation and mail routing
Check, in this order:
- Organisation-level automatic forwarding settings in Gmail, and whether users are permitted to set forwarding at all.
- Individual user forwarding rules, particularly on the accounts of people who have left.
- Gmail delegation, where one user has been granted access to another’s mailbox.
- Routing, default routing, and content compliance rules under the Gmail settings. Rules that silently copy mail to an external address are indistinguishable from a mail server working normally, and they survive every password reset you will ever do.
A forwarding rule pointed at a former director’s personal Gmail is the single most common finding in a handover audit, and the one that turns into a notifiable data breach conversation if it is not caught.
Authentication and legacy access
Review the 2-Step Verification policy: whether it is optional or enforced, which organisational units it applies to, which methods are allowed, and whether any exceptions exist. Then look at app passwords. Google’s guidance is that enforcing security keys disables app passwords, so if app passwords are still live somewhere, security key enforcement is not actually in place for that group. App passwords issued to devices and scripts nobody owns any more are a straight bypass of the authentication policy.
Single sign-on, both directions
Two separate configurations, both worth checking. Under Security, then Authentication, then SSO with third-party IdP, you find out whether Google is subordinate to another identity provider. Under Apps, then Web and mobile apps, you find the SAML applications where Google is the identity provider for other systems. Either configuration means the Workspace tenancy is load-bearing for systems outside it, which changes the risk of every change you make.
Shared drives with no owner
Google’s admin tools let you filter shared drives by “No members” and by “No managers”. Run both filters. A shared drive with no manager still holds files, but nobody can administer membership, and access is limited to whoever the items were shared with directly. In a tenancy where the person who set everything up in 2016 has left, expect several. Assign a manager to each one and record who it is.
The redeeming feature of shared drives is that files in them belong to the organisation rather than an individual, so deleting a departed user’s account does not remove them. My Drive is the opposite. Before you delete any account, transfer ownership of its My Drive content. Suspend first, delete later, and never on day one.
Billing and the reseller relationship
Find out whether the subscription is billed by Google directly or through a reseller, and which reseller. This is a commercial trap as much as a technical one.
Transfers between Google and resellers are done with a transfer token generated in the admin console, and the token expires 30 days after it is generated. The constraints matter: a subscription cannot be transferred to a reseller more than twice in a calendar year, and if you move away from a reseller to another reseller or to Google, you cannot transfer any subscription back to the original reseller for 18 months. Transfers are not reversible, and on an annual plan paid yearly there is no refund for the prepaid period and no portion of the payment carries across.
Read that again before you move a client’s billing in the first week of a relationship. Sometimes the right answer is to wait for the renewal date.
Ask the incoming provider the same question you are asking about the outgoing one. TechAssist is listed in Google Cloud’s partner directory, and whoever takes a tenancy on should be able to state plainly whether they intend to resell your licences or leave the billing with Google, before you sign anything.
Everything else worth writing down
Secondary and alias domains. Data region settings. Google Vault retention rules and holds, which are a legal obligation and not an IT preference. Google Groups and whether any of them accept mail from outside the organisation. Whether endpoint or mobile management is configured, and on how many devices. Any linked Google Cloud project and the service accounts inside it.
Remediate these in the first 48 hours
Take an independent backup before you change anything. Most of the actions below are reversible. The one where you revoke a token that turns out to be a live production integration is not, quickly.
Then, in order:
- Establish your own super admin account with a security key, and set up admin email alerts so you are told about suspicious sign-ins and admin changes.
- Remove or suspend admin roles for anyone who has left, and for the outgoing provider once your own access is proven. Do not do this before step 1.
- Kill unexplained forwarding, delegation and routing rules. Document what you removed and tell the client, because occasionally one of them is legitimate and undocumented.
- Block the OAuth apps nobody can name, and set Gmail and Drive to restricted so that untrusted apps cannot request high-risk scopes. Expect a small number of complaints and handle them individually.
- Remove domain-wide delegation entries that do not map to a live system.
- Enforce 2-Step Verification, with security keys for every administrator.
- Assign a manager to every shared drive that lacks one.
- Create a documented break glass super admin account with credentials stored offline. ASD’s guidance on break glass, local administrator and service account credentials is that they should be long, unique, unpredictable and managed, with long defined as a minimum of 30 characters.
Leave the deeper configuration work until after this. Harden the tenancy properly is a project, not a first-week task, and the admin console settings that actually matter will tell you where to spend the effort.
Document it so the next handover is not archaeology
The reason you are doing this audit is that the last person did not write anything down. The fix is not a better memory. It is a documentation set that is maintained as part of ordinary support work rather than produced as a one-off project.
At minimum, record and keep current:
- Tenancy primary domain, all secondary and alias domains, and the customer ID.
- Registrar and DNS host, with the access path and who holds it. Not the password, the path.
- Billing arrangement, reseller if any, renewal date, plan and seat count.
- Every super admin, by name, with the business owner who approved it.
- Every delegated admin role, its scope, and why it exists.
- An approved OAuth application register: app, client ID, scopes, business owner, date approved.
- A domain-wide delegation register with the same fields, plus a justification for each scope.
- SSO profiles in both directions, with the systems that depend on them.
- Shared drive register with a named manager for each.
- Groups, their purpose, and their external posting settings.
- Backup product, retention, and the date of the last tested restore.
- Break glass account details and where the credentials are held.
The register format matters less than the discipline of updating it when something changes. What a proper documentation set looks like covers the structure we use across every client. Tie the OAuth and admin registers into your offboarding process so that removing a person removes their grants, not just their mailbox.
We include documentation and IT asset management as standard on every managed account, because the alternative is billing a client for a fortnight of archaeology every time a provider changes.
If you have just inherited a Workspace tenancy, or you are about to change providers and want the handover done properly, we will run the day one audit and give you the findings in writing before you commit to anything. Call 1300 028 324 or get in touch at https://techassist.au/contact/.
