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/.
If nobody can sign in to your Google Workspace Admin console, you are not locked out of an app, you are locked out of your company’s identity system. Every path back in ends at the same question: can you prove, to Google’s satisfaction, that you control the domain name. Some of these recoveries take an afternoon, some take weeks, and a small number never succeed at all.
A super administrator is the Google Workspace role that can reset any password, assign admin roles, and change any setting in the Admin console. Losing every super admin account means losing administrative control of your email, your files and your user accounts, even though the service itself keeps running normally for staff.
Work out which lockout you actually have before you touch anything
The recovery paths are different and the wrong one wastes days. Find yourself in this list first.
You forgot the password and your recovery email and phone still work. This is the easy case. Fix it in ten minutes with the standard recovery wizard.
You know the password but 2-Step Verification is blocking you. The phone is gone, the security key is lost, or nobody printed backup codes. Different path, and slower.
The super admin has left, been dismissed, gone quiet or died. The account may still exist and still be the only super admin. This is the most common serious case in small businesses.
Nobody knows who the super admin is. Often it turns out to be a generic address like info@ or admin@ that nobody has opened in years, or a personal Gmail address used during signup.
The account is suspended. Usually billing, occasionally a policy or abuse action. Recovery is a payment or a support case, not a DNS record.
A contractor, web developer or hosting company set the domain up. They own the Workspace signup, or the domain registration, or both. This is the case that most often fails, because two separate ownership problems have to be solved in the right order.
Being honest about which one you are in is the whole job. Everything below assumes you have picked correctly.
Try the self-service paths in Google’s order, because support will ask if you did
Google’s published position is that support-assisted recovery is only available after you have been through the automated flow. Do not skip it.
1. Ask another super admin. Any other super administrator can reset your password from the Admin console in under a minute. This is the reason Google’s own security guidance says every organisation should have more than one super admin account, each held by a different person. If you have a second one, stop reading and go use it.
2. Standard password recovery. Go to accounts.google.com/signin/recovery, enter the admin address, click Next and then Try another way. If a recovery email or phone number is attached to the account, Google sends a verification code and you reset the password. If you have forgotten the address itself, use Forgot email? and supply the recovery email or phone plus the full name on the account.
3. Check whether self-recovery is even switched on. This is the step almost every guide misses. Super admin account self-recovery is a setting an organisation can turn off, and if it is off, the Forgot password? link tells super admins to contact their administrator rather than offering a code. The control lives in the Admin console at Security, then Authentication, then Account recovery. Google documents the default as off for a list of editions including Business Plus, Frontline Standard, Enterprise Essentials Plus, Education Standard and Plus, G Suite Basic and Cloud Identity Premium, and on for the others. Google’s admin security best practices page states it differently again, that recovery is off by default for most current and all new customers, with existing customers under three super admins or 500 users defaulting to on. If you can still get in, check yours now rather than trusting either summary.
4. Backup codes and a spare security key. If 2-Step Verification is the blocker and the account has printed backup codes or a second enrolled security key, that is your way through. If it does not, note that Google is progressively enforcing 2SV on administrator accounts, so this failure mode is becoming more common, not less.
If none of that works, you are into domain proof.
Proving you own the domain is what actually decides most of these cases
Google’s fallback is not a phone call and not a photo of a driver’s licence. It is a DNS record you place at your domain host, because control of the domain is the only ownership signal Google can verify without a human judgement call.
There are two flows and they use different record types. Most guides conflate them.
The automated wizard asks for a CNAME record. Working through accounts.google.com/signin/recovery and clicking Try another way repeatedly eventually offers domain verification. Google gives you a CNAME record to add at your DNS host. Wait a few minutes, click Next, and if Google finds the record you get straight to a Create Password screen. If it does not find the record immediately, you supply a contact email address that is not the locked account, receive a verification code, and Google emails a password reset link once the record is confirmed. Google’s documented cut-off is that if the CNAME is not found within 48 hours, you get an email telling you the recovery failed and you start again.
The support-assisted flow accepts a CNAME or a TXT record. If the automated wizard cannot resolve it, it may offer Contact support, which sends you to the Apps Admin Toolbox at toolbox.googleapps.com/apps/recovery/form. You give a contact email address that is not the locked account, Google issues a support reference number, and you add either a CNAME built from that reference number or a TXT record at your domain host. Then you click Check Again, select Request for Password Reset, and submit. Google’s documentation says DNS changes can take up to 24 hours to propagate and gives you two toolbox.googleapps.com/apps/dig lookups to confirm the record is visible before you resubmit.
Use those lookups. A large share of failed recoveries are not identity failures, they are a record placed on the wrong zone: added at the registrar when DNS is actually hosted somewhere else, added to a redirect service, or added with the domain name accidentally doubled on the end of the hostname. Google’s own note is explicit that if your hosting provider is separate from your registrar, you must change the record with the provider that is actually answering for the zone.
Then Google asks the account history questions. Expect to be asked the date the Workspace account was created, the original secondary or recovery email address used at signup, the Google order number if there is one, how many user accounts were created, the billing address, and the card type and last four digits. Google states you do not have to answer every question correctly. You do have to answer enough of them, and the answers a departed admin took with them are usually the signup email address and the creation date. Search old email for a welcome message from [email protected] and pull the oldest Google charge off the company card statement before you start the form.
The only elapsed times Google commits to are the ones inside the DNS steps. On the automated flow you have 48 hours for the CNAME to be found, after which Google emails you to say the recovery was unsuccessful and you begin again. On the support-assisted flow Google allows up to 24 hours for the record to propagate before you click Check Again. Past the point where you press Submit Request, Google publishes no timeframe at all. Its documentation says only that the support team will contact you for next steps, and that in some cases you may need to provide additional verification so that access is granted to the rightful owner.
What governs how quickly a human picks the case up is your support tier rather than the recovery flow, and the tiers are set out further down. Plan against the documented floor, not against a promise, and get the DNS record right the first time, because a failed check restarts the whole sequence.
If you are a user and there is no reachable admin at all, you can be promoted
There is a separate path most people never find. A normal user account can be promoted to super administrator with proof of domain ownership, using the same Apps Admin Toolbox form.
You sign in to your own working Google account first, because only active accounts can be promoted. Then enter the domain at toolbox.googleapps.com/apps/recovery/form, click Lookup Recovery Options, choose I am a user and cannot contact my administrator, add the CNAME or TXT record, and submit Request User Promotion.
The important detail: Google then contacts the existing administrators. If they are inactive and unresponsive, Google promotes your account. If they respond, you are offered the option of having Google pass your contact details to them instead. So this path works when an admin has genuinely vanished, and does not work as a way around an admin who simply disagrees with you.
When the registrar login is gone too
This is where recoveries stall. You cannot add a DNS record if you cannot sign in to the registrar or the DNS host, and the person who could is the same person who has gone.
Work in this order.
Find out who actually answers for the domain, rather than who you think does. A public WHOIS lookup gives you the registrar of record. A nameserver lookup gives you the DNS host, which is frequently a different company: the domain sits at one registrar while the zone is served by a web host, a CDN or a previous IT provider.
Then run the registrar’s own account recovery against the registrant email address on the record. If that address is inside the locked Workspace tenancy, you have a circular dependency and you need to break it at the registrar, not at Google.
For a .com.au name, the auDA rules work in your favour more than most people expect. The .au Domain Administration Rules state that a licence confers no proprietary rights in a domain name: a registrant holds a licence to use the name for a period and does not legally own it. Eligibility for com.au requires both an Australian Presence and a Commercial Entity, and auDA’s definitions include a company registered under the Corporations Act 2001 and any entity issued with an ABN. The name itself must be a match or an acronym of the registrant’s company, business, statutory or personal name, or a match or synonym of goods or services that the registrant actually provides. If your business is the genuine registrant, that list is also the evidence pack: ABN, company extract, business name registration, invoice history.
Ask for the authorisation code by name. auDA requires a valid authorisation code from the registrant for a transfer between registrars, and requires the registrar to release it in writing only to the registrant contact recorded in the registry data, unless the registrant has authorised in writing that it go to a third party. That ordering matters. Getting the registrant contact corrected comes before asking for the code, not after.
If the registrar will not act, there is a defined complaints path rather than a dead end. auDA’s rules require the complaint to go to the registrar of record first, give that registrar 30 calendar days to resolve it, and require written reasons plus notice of your right of appeal to auDA for review. It is slow. It is also a real lever, and registrars behave differently once you cite it.
The other lever is the paying party. Whoever’s card is on the domain renewal has standing to ask the registrar to correct the account.
Google’s clock is not the Australian problem here. Google’s published hours of operation table lists Australia as 24/7 in English, the same as the United States and the United Kingdom. There is no overnight window in which nobody is available to take the case. The delays in Australian recoveries come from the registrar side, not from Google’s support hours.
When a third party registered the domain in their own name
If a web developer or agency registered the domain as themselves rather than as your business, you have a commercial problem wearing a technical hat. Google will accept a DNS record from whoever controls the zone, and right now that is not you.
The realistic options are to get the third party to add the record on your behalf, to get the domain transferred into your own registrar account, or to pursue it as a contractual matter. None of those are quick, and the technical recovery cannot start until one of them lands.
If the business is still trading and simply unresponsive, a written request naming the specific record to add, with a deadline, resolves it more often than people expect. If the business has wound up, the registrar becomes the only route.
auDA’s rules are clearer on this than most web development contracts are. A person may use an agent to make a licence application. That agent warrants to the registrar and to auDA that it has the authority to bind the person it is acting for, and the rules require the agent to ensure that the person on whose behalf they are applying is recorded as the registrant in the registry data. A developer who put their own company in that field did not follow the rules. Quote that when you write to them, because it changes the conversation from a favour you are asking for into an obligation they already had.
The correction path exists, and it closes fast. auDA allows a registrant to ask a registrar to correct registrant information, and the listed grounds include a licence incorrectly registered by the registrar in the name of the reseller or other agent who arranged the registration. The catch is in the next rule: the request must be made within 14 calendar days of the licence being recorded in the registry data. Three years after a website build, that route is shut and you are into a change of registrant instead.
A change of registrant is a transfer, not an edit. auDA requires the transfer request in writing from the current registrant to the registrar, requires the incoming party to satisfy the Australian Presence and the namespace eligibility criteria at the date of transfer, to enter a new licence agreement and pay a new licence fee, and requires the registrar to complete the transfer within two calendar days of the request. Read that list again and note where the friction actually sits. Everything except the first line is mechanical. The whole thing turns on the departed developer signing a written request.
Escalation: what Google support can and cannot do for you
Google Workspace support is real, staffed and reachable, and it is also narrower than most people assume.
You need an admin account to raise a case. Contacting support requires the Support administrator privilege and access to the Admin console. That is the trap: the people who most need support are the ones who cannot get in to ask for it. That is exactly why the Apps Admin Toolbox login issues form exists as an unauthenticated channel.
Support tiers change response speed, not eligibility. Google publishes three offerings. Standard Support is included with a Workspace licence, has 24/7 access, and carries a four hour service level objective for P1 cases. Enhanced Support accelerates that to one hour for P1 and adds commercially reasonable help with third-party applications. Premium Support carries a fifteen minute P1 objective, designated technical advisors and a Technical Account Manager. Cases are prioritised P1 to P4, where P1 is a critical service access issue affecting more than one user with no workaround, and Google’s stated commitment is an initial response within one business day or less.
Note what that does not say. A faster tier gets you a human sooner. It does not remove the domain ownership requirement, and it does not let an agent hand over a super admin account because you sound convincing.
If you bought Workspace through a reseller, Google will send you back to them. This is stated plainly in Google’s own troubleshooting documentation, along with links to reseller-specific reset instructions for Wix, Squarespace, Weebly, Automattic, Namecheap, Bluehost, Domain.com, HostGator and iPage. If your Workspace came bundled with a website build or a hosting plan, check this before anything else. Your reseller set the account up and can usually reset the password directly.
What a reseller or a support partner can actually do, according to Google’s own documentation. There are two distinct arrangements and Google documents both. If a reseller manages your subscription, Google states the reseller can access your Admin console, submit support cases and provide other services for you unless you remove that access, and Google’s stated recommendation is to leave the access on so they can troubleshoot for you. Separately, any Workspace customer can assign a Support Partner in the Google Cloud Support Portal, and Google’s wording is that while assigned, the partner can file cases on your behalf and access cases you filed yourself.
Two things follow. Both arrangements are switches inside your own account, under Account then Reseller management in the Admin console, or under Support Partners in the Support Portal. And both require a working admin sign-in to set up, which means neither is something you can arrange after you are already locked out. Turn on the one you want while you can still get in.
What that buys you is a second party who can open and chase the case while you are dealing with the registrar. It does not change the evidence Google requires. The domain proof is identical, the account history questions are identical, and nobody at Google or at a partner can release a super admin account without them.
TechAssist is listed in Google Cloud’s partner directory and we take that second-party role for clients, which means the case gets opened and chased by someone who has run the flow before rather than by an owner reading the form for the first time. It buys you competence and persistence on the process, not a shortcut through it.
Have this ready before you open the case. The domain name. The exact admin address you are trying to recover. Evidence of the signup: the original welcome email, the creation date, the secondary email address used. Billing evidence: the card type and last four digits, the billing address, the Google order number, and the date of the most recent payment. Registrar and DNS host details, with proof you can edit the zone. A contact email address that is outside the locked domain. Assembling this first is the difference between one exchange and five.
Two lockouts that look like this but are not
A suspended account is a billing or policy problem. If you can reach the Admin console but the service is suspended, or if sign-in reports the account is not using Google Workspace, no amount of DNS proof helps. Check the payment method and the billing contact first. Google’s documentation is blunt that if a Workspace or Cloud Identity account has been deleted rather than suspended, the data is not recoverable, and re-signing up the domain 24 hours later gives you a new empty tenancy.
A Context-Aware Access rule can lock every admin out at once. If an access level was applied to the Admin console itself and the conditions can no longer be met, for example a device or IP requirement that no longer exists, you have a total lockout that no password will fix. Google’s documented remedy is to contact support through the Customer Care Portal, and support will remove all Context-Aware Access policies applied to the Admin console. Policies on other apps are untouched. Google is equally clear that the policies must be reapplied immediately after access is restored.
Be honest about the odds
Some of these recoveries simply fail. The pattern is consistent: the further the domain is from your control, the worse the outcome. If you can edit DNS, you will almost certainly get back in eventually. If you cannot edit DNS and cannot recover the registrar account, there is no Google process that fixes that, because from Google’s side you are indistinguishable from an attacker.
The realistic worst case is not that you never recover the tenancy. It is that recovering it costs more elapsed time than the business can absorb, and someone makes the call to stand up a new tenancy on a new domain and accept the data loss. That decision is much easier to make on day three than on day twenty.
There is one structural failure point rather than a list of them, and Google’s documentation makes it obvious. The automated wizard, the support-assisted form and the user promotion path all terminate at the same requirement: a record placed in the zone that answers for your domain. Google offers no documented alternative to it. Whoever can edit the zone completes a recovery. Whoever cannot does not, however obviously they are the rightful owner. Everything worth doing in advance is really about making sure that person is you.
Making sure this never happens again
Every item here takes minutes while you have access and is impossible once you do not.
Run at least two super admin accounts, held by two different people. Google’s own guidance says so. One is a single point of failure attached to a human being who can resign, get sick or lose a phone.
Create a break-glass account. A dedicated super admin account that belongs to the business rather than to a person, not used for daily work, with a long unique password and its own 2-Step Verification enrolment. Store the credentials and the printed backup codes somewhere physical and controlled. Google’s guidance to enrol a spare security key and to generate backup codes in advance exists precisely for this account.
Keep recovery information current and remove it when people leave. Google explicitly recommends stripping a super admin’s recovery phone and email the moment they are terminated, so they cannot recover their way back in. That cuts both ways: the recovery details on your remaining admin accounts need to point at people who still work there.
Separate admin duties from daily accounts. Google’s best practice is that each super admin has two accounts, one for super admin tasks and one for everyday email, and that routine administration is delegated to limited roles rather than super admin. Shared generic admin accounts also destroy your audit trail, because you cannot tell which person made which change. Store the credentials in a business password manager rather than a spreadsheet, and put multi-factor authentication on the manager itself.
Document the registrar, the DNS host and who pays for them. Written down, in your IT documentation, with the account holder named. This one item removes the single most common cause of failed recovery.
Check that the registrant on the domain is your legal entity, and hold the authorisation code. For a .com.au name, confirm the registrant recorded in the registry data is your company and not a developer, an agency or a staff member’s personal name. Ask your registrar for the authorisation code and store it with the rest of the break-glass material. auDA requires that code for any transfer between registrars, and it will not be handed to you at speed during a crisis.
Decide now whether a reseller or support partner should have access. If someone else is going to open the case on your behalf, the switch has to be on before the lockout, not after.
Record the signup facts while someone still remembers them. Creation date, original secondary email address, order number, billing contact. Those are the questions Google will ask, and they are trivial to capture now.
Turn on admin alerts and review the admin log. You want to know when a super admin role is granted, when recovery information changes, and when a new admin appears. Most of that is covered in the Admin console settings that carry real risk, and the wider programme is in hardening Google Workspace properly.
Understand what you would actually lose. Losing admin access and losing data are different problems with different answers. If the tenancy is unrecoverable, or if someone with access deletes at speed, Google’s retention windows are shorter than most owners assume. That argument is set out in Google is not backing up your Workspace data.
If you have just taken over a Workspace tenancy from a previous provider or a departed staff member, do all of the above in the first week. The full checklist is in inheriting a Google Workspace tenancy nobody documented, and if you are also running Macs and Windows machines alongside it, running Windows, Mac and Google in one business covers how the pieces fit together. Being a partner on the Apple, Microsoft and Google sides at once is unusual for a Melbourne provider, and it is the reason we can tell you which platform genuinely suits the business rather than the one we happen to sell.
If you are locked out right now, call us on 1300 028 324 and have your domain name, your registrar details and any old Google billing records in front of you. We will tell you within one conversation which recovery path applies and whether it is realistically going to work. You can also start at techassist.au/contact.
The Google Admin console has hundreds of settings and about seven that will cost you real money if they are wrong. This is those seven, with what each one does, where it sits today, what to change it to, and what you give up by changing it.
The Google Admin console at admin.google.com is the single web interface where a Google Workspace administrator manages users, security policy, device access and every service setting for the organisation. Almost everything below is set per organisational unit, so you can apply a strict setting to finance and a looser one to the warehouse rather than choosing one answer for everybody.
1. 2-Step Verification enforcement decides whether a stolen password matters
Where: Security, then Authentication, then 2-Step Verification.
What it does: Requires a second factor at sign-in. Google’s console lets you allow users to turn it on, or enforce it, and lets you restrict which methods count: any method, any method except verification codes sent by text or phone call, or security key only.
The current position: Google is progressively enforcing 2SV on administrator accounts across editions. Super administrators are notified roughly 90 days ahead of their enforcement date and other admins roughly 60 days ahead. After the date passes, Google applies escalating restrictions: reminders in the Admin console after seven days, no access to Workspace apps on mobile devices after fifteen days, and no access to web apps after thirty days.
What to set: Enforce 2SV for every user, not only admins. Set the allowed methods to exclude codes sent by SMS or voice call, because those are the methods that fall to SIM swap and phishing relay. Security keys or passkeys for admins and anyone handling payments or client data.
The trade-off: Enforcement creates lockouts. A user who loses their phone before enrolling a second method cannot sign in, and someone has to be available to reset them. Set a new user enrolment period so people joining mid-week are not locked out on day one, make everyone generate backup codes, and enrol a second security key on admin accounts. If every admin is locked out at once you are into locked out of your Google Workspace admin account territory, which is far slower than a reset.
2. Admin role assignment is the one setting that is almost always too generous
Where: Account, then Admin roles. Assignments per user under Directory, then Users.
What it does: Grants administrative privileges. Super admin is total control: every setting, every user’s password, all business data. The prebuilt roles below it (Groups Admin, User Management Admin, Help Desk Admin, Services Admin, Storage Admin and so on) are narrower, and you can build custom roles scoped to a single organisational unit.
The default: Whoever signed the account up is a super admin. Everything else is whatever has accumulated since.
What to set: More than one super admin, held by separate people, because a single super admin is a single point of failure. Google’s own guidance goes further: give each super admin two accounts, one for super admin tasks and a separate ordinary account for daily email, and delegate routine work to limited roles. Never share a generic admin account between people, because the audit log then cannot tell you which human made a change. Review the role assignment list at least twice a year and after anyone leaves.
The trade-off: Least privilege generates help desk traffic. Someone who used to fix their own problem now has to ask. That is the point, and it is cheaper than the alternative. Do the work once by mapping roles to actual job functions rather than granting super admin because it is quicker on the day.
3. Third-party app access is where data leaves without anybody noticing
Where: Security, then Access and data control, then API controls.
What it does: Governs which third-party applications can reach your Gmail, Drive, Calendar and other data through OAuth. This is the mechanism behind every “sign in with Google” prompt and every add-on someone installed in 2021.
How it works in the console: Under Manage Google Services you mark each Google service as Unrestricted or Restricted. Restricted means an app cannot use that service’s high-risk OAuth scopes unless you have explicitly trusted the app. Google publishes the high-risk scope lists, and they are the ones that matter: for Gmail they include full mailbox access, read, modify, send and settings changes, and for Drive they include full Drive access and Drive readonly. Under Manage Third-Party App Access you set each app to Trusted, Limited or Blocked. Under the Settings card, Unconfigured third-party apps controls what happens to everything you have not classified, with options to allow any third-party app, to allow only apps that ask for Google sign-in information, or to block them all.
What to set: Start by reviewing the Accessed apps list before you change anything, because you will find integrations that the business genuinely depends on. Then restrict Gmail and Drive, allowlist the apps you actually use as Trusted, and move Unconfigured third-party apps to sign-in information only. Turn on Trust internal apps only if you build your own.
The trade-off: This one breaks things. Google states plainly that when you move a service to Restricted, previously installed apps you have not trusted stop working and their tokens are revoked. Do it out of hours, tell people first, and expect a week of allowlisting requests. Also note the reporting lag: app details typically appear 24 to 48 hours after authorisation, so the list you are looking at is not live.
4. Drive external sharing defaults decide how much of your IP is already public
Where: Apps, then Google Workspace, then Drive and Docs, then Sharing settings, then Sharing options.
What it does: Controls whether users can share files outside the organisation, whether they can create “anyone with the link” files, whether they are warned when sharing externally, and whether external files are visually flagged.
What to check first: Whether external sharing is On or Off, whether sharing is limited to allowlisted domains, what the default access is when a user creates a new item, and whether Highlight external files is enabled. That last one is on by default and shows a warning indicator on files owned by or shared with someone outside the organisation, and it is worth confirming nobody has turned it off.
What to set: For most Australian SMBs, external sharing On but with link sharing defaulting to restricted, warnings enabled when a user shares outside the domain, and the external file indicator on. If you work in a regulated space or handle client files under contract, allowlisted domains is a stronger position and is manageable if your external collaborators are stable.
The trade-off: Turning external sharing off entirely does not stop data leaving, it moves it to personal Dropbox accounts and email attachments where you have no visibility at all. Restricting to allowlisted domains creates friction every time a new client or supplier appears. Whatever you choose, changes can take up to 24 hours to apply and old and new settings can be enforced intermittently during that window, so do not test at 4pm on a Friday and conclude it failed.
5. Gmail routing and spoofing protections are where business email compromise gets in
Where: Apps, then Google Workspace, then Gmail. Safety settings under Safety, routing under Routing and Default routing.
What it does: Two separate risks live here.
The Spoofing and authentication section under Safety controls what Gmail does with mail that impersonates your domain, impersonates an employee name, or arrives unauthenticated from any domain. Alongside it, Advanced phishing and malware protection adds screening of attachments, links and external images, and enhanced pre-delivery message scanning improves detection of phishing that would otherwise get through.
Routing is the quieter risk. Attackers who reach an account frequently create a routing rule or a forwarding rule that silently copies mail to an external address, and it survives the password reset that everyone assumes fixed the problem. Routing rules do not appear in the user’s own settings, so nobody finds them by looking in the mailbox.
What to set: Turn on every option in Spoofing and authentication and in Advanced phishing and malware protection, applying the quarantine or spam action rather than the “keep in inbox with warning” action for the impersonation checks. Then audit the routing and default routing lists and confirm every rule is one you put there. Do that audit again after any account compromise.
The trade-off: Impersonation protections generate false positives, usually on legitimate mail from suppliers with badly configured authentication, on newsletters sent through third-party platforms, and on staff sending from personal addresses. Start with the warning action, watch for two weeks, then move to quarantine.
The part that is not in the console: SPF, DKIM and DMARC are DNS records, not Admin console settings. Google generates the DKIM key for you in the console, but SPF and DMARC are published at your domain host. A DMARC policy of p=none publishes reports and blocks nothing, so if you set one up years ago and never revisited it, it is very likely doing nothing.
6. Data regions are the setting Australian buyers ask about and Google answers narrowly
Where: Data, then Compliance, then Data regions. Availability depends on your edition.
What it does: Sets a geographic policy for where covered data is stored at rest, including backups, for a set of core Workspace services.
What the options actually are: United States, Europe, or No preference. There is no Australian data region option. If your obligation is that Australian personal information stays in Australia, Workspace data regions do not deliver that, and no amount of console configuration will change it.
What to set: If you have a contractual or client-driven requirement to keep data out of a particular jurisdiction, set the policy and record it. If your requirement is genuinely that data must reside in Australia, that is an architecture conversation, not a setting.
The trade-off: Data regions are edition-dependent, with the more granular controls sitting in the Enterprise tier and above, and they cover a defined list of core services rather than everything in your tenancy. Read Google’s covered-data list before you tell a client or an auditor that the box is ticked. If you are being asked this question in a client security review, say what the control does and does not cover rather than answering yes.
7. Audit logging is free, already on, and shorter than you think
Where: Reporting, then Audit and investigation.
What it does: Records log events across Admin actions, user logins, Drive, Gmail, OAuth tokens, devices, Groups, Chrome and more. Administrators cannot delete log event data or extend how long it is kept.
How long you actually have: Google publishes the retention periods and they are worth knowing before an incident rather than during one. Most log event types are retained for six months, including Admin log events, user login events, Drive, Gmail, OAuth token and Context-Aware Access events. Email log search is 30 days. Chrome apps, extension usage and version reports are 12 months. Customer and user usage data retrieved via the API is 15 months. Vault log events are retained indefinitely.
What to set: Nothing to enable, but two things to do. Turn on admin email alerts for the events that matter, including suspicious sign-in attempts, admin role changes and settings changed by another admin. Then decide whether six months is long enough for your obligations, and if it is not, export log events on a schedule to somewhere you control.
The trade-off: The security investigation tool, which is what makes these logs genuinely usable at speed, is not available on every edition. Google lists it for Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. On Business tier editions you have the audit and investigation page and the reports, which is enough to answer a question you already know how to ask, and slower for open-ended hunting.
What to do with this list
Work top down. Identity first, because a compromised admin account makes every other setting irrelevant. Then third-party app access, because it is the control most tenancies have never touched. Then sharing, then mail, then the compliance and logging settings that matter mostly when something has already gone wrong.
If you want the full sequence with licence tiers mapped out, that is in a sequenced hardening plan. If you have just inherited a tenancy from a previous provider, start with taking over a tenancy nobody documented instead, because you need to know what is configured before you change anything. If you are weighing the platform itself rather than the settings, how Microsoft 365 and Google Workspace compare covers that decision, and multi-factor authentication across the business covers the identity piece beyond Workspace. Logging and retention are also not backup, which is the point of what Google actually retains.
We administer Google Workspace tenancies for Melbourne businesses and are listed in Google Cloud’s partner directory. We audit those tenancies against this list and hand back a written report showing what is set, what it should be, and what breaks if you change it. Call 1300 028 324 to book one, or start at techassist.au/contact.