Moving From Google Workspace to Microsoft 365

A Google Workspace to Microsoft 365 migration is the process of moving an organisation’s mail, calendars, contacts and files out of Google’s tenancy into a Microsoft 365 tenant, then repointing the domain’s mail flow and identity to Microsoft. Microsoft supplies free first-party tooling that handles the bulk of the copying. The difficulty is not the copying. It is the handful of things Google does that Microsoft has no equivalent for, and the two weeks afterwards when users discover them one at a time.

This post is about mechanics only. If you are still deciding, read which platform suits your business first and come back.

Microsoft’s own tools do most of the copying, and they are free

There are two separate tools and they do not talk to each other.

Mail, calendars, contacts, mail rules and tasks move with the automated batch migration tool in the Exchange admin center. Per Microsoft Learn, it “can transfer your organization’s mail, rules, calendars, and contacts from Google Workspace to Microsoft 365”, and Microsoft recommends the automated method because it completes several of the required Google admin console steps for you.

Files move with Migration Manager, reached from the Microsoft 365 admin center under Setup, then Migration and imports. Microsoft’s own FAQ is blunt about the alternatives: “Currently, Migration Manager is the tool to use for migrating Google content.” For tenants with fewer than 300 licences at the time the project is created, Microsoft enables a cut-down version called Migration Manager Lite, which skips the scan, destination-mapping and identity-mapping steps. On anything beyond a handful of users, that is the wrong tool. You want the scan report and you definitely want identity mapping.

Third-party migration tools still have a place, mostly for tenant-to-tenant work, Google Sites, or when you need reporting Microsoft does not produce. For a standard 10 to 200 seat move, the native tooling is adequate.

What migrates cleanly

• Mail content and folder structure, including Gmail labels rendered as Exchange folders.
• Calendar events on users’ primary calendars.
• Contacts, up to three email addresses per contact.
• Mailbox delegates, Send As, and mail rules.
• Google Tasks, if you pass -MigrateTasks when you create the batch. Task lists become task folders. Note that incremental sync is not supported for tasks that have already migrated.
• Rooms and resources, if you enable the Admin SDK API and add the resource calendar read-only scope to domain-wide delegation. Google resources map to Exchange resource mailboxes and Google buildings map to distribution groups.
• Drive files and folders, including version history, and shared drive permissions if you map identities properly first.
• Google Docs, Sheets and Slides, converted on the way through.

What does not migrate, and what users will complain about

This is the section to read to your leadership team before you commit to a date.

Gmail labels are not folders. Google’s own help documentation states plainly that “labels are different from folders” and that you can apply several labels to one email. Exchange has folders, and a message sits in exactly one. Anything labelled three ways has to become three copies or one copy in one folder. Neither answer is what the user had. Microsoft’s guidance is to use the -ExcludeFolder parameter when starting batches from Exchange Online PowerShell to strip out labels that apply to large numbers of messages, which reduces both duplication and mailbox size. Decide this per label, with the business, before you migrate. Do not discover it afterwards.

Google Docs stop being Google Docs. During migration the Google Export API converts .gdoc to .docx, .gsheet to .xlsx and .gslide to .pptx. The originals in Drive are untouched. What does not survive the conversion is everything that was never a document feature to begin with: suggestion mode history, Apps Script attached to a Sheet, IMPORTRANGE and other cross-document live links, and add-ons. Any spreadsheet that is really a small application needs to be rebuilt, not migrated. Find those first. There are always two or three and they are always load-bearing.

Shared calendars and calendar delegation. Microsoft’s documentation is explicit that shared calendars and event colours are not migrated, and that room bookings are not migrated. More significantly, as of June 2024 the option to migrate permissions and delegates for calendars is turned off worldwide. Mailbox permissions and delegates still migrate. Calendar permissions do not. Every executive assistant who manages a principal’s diary will need that relationship rebuilt by hand on day one.

Vacation and auto-reply settings are not migrated. Trivial until you cut over the week someone is on leave.

Google Sites and Google Maps cannot be exported, so Migration Manager does not move them. Google Drawings come across as PNG files. Google Forms migrate, but only if you designate a Forms destination on the task. Shortcut files are skipped entirely.

Orphaned files. Microsoft does not scan unorganised or orphaned files in Google, so they are neither migrated nor reported. If a departed employee’s content ended up unparented, it does not appear in any report. It just is not there afterwards.

External sharing links break. Migration Manager does not recreate external sharing links and does not share content with external collaborators, deliberately. If your clients or suppliers have bookmarked a Google Drive link, every one of those links dies at cutover and has to be reissued from SharePoint.

Google Groups do two jobs at once. In most Workspace tenancies a group is simultaneously a mailing list, a Drive permission holder, and sometimes a calendar. Microsoft splits those across distribution lists, Microsoft 365 groups, security groups and shared mailboxes. Before you migrate files, work out for each group which job it is really doing, then recreate the file-permission side as a Microsoft 365 group with matching membership and map it in Migration Manager’s identity mapping. Microsoft’s FAQ makes this a prerequisite for shared drive permissions to land correctly, not an optimisation.

Anything authenticated with Google SSO. This is the one that catches people. Where Google Workspace is acting as the SAML or OIDC identity provider for third-party SaaS, or staff have been signing in to a tool with “Sign in with Google”, that trust relationship does not migrate. Each application has to be reconfigured against Microsoft Entra ID, which means touching each vendor, and some of them will want a plan upgrade to support SAML. Separately, check API controls and domain-wide delegation in the Google admin console for service accounts that read Workspace data on behalf of users. Those integrations are invisible to end users right up to the moment they stop working. Inventory both lists before you set a date.

Identity and domain handling decides your sequencing

Microsoft 365 identity runs on Microsoft Entra ID, Microsoft’s cloud-based identity and access management service. Your users need to exist there before anything can be delivered to them.

The mail migration requires a specific and slightly counter-intuitive DNS arrangement. Microsoft’s prerequisites call for two routing subdomains: one added in Google Workspace pointing at Microsoft 365 (for example o365.yourdomain.com.au), and one added in Microsoft 365 pointing back at Google (for example gsuite.yourdomain.com.au). Both must verify and go Active. Microsoft warns that using the built-in tenantname.onmicrosoft.com domain for routing instead of a subdomain of your primary domain “occasionally causes issues that Microsoft is not able to assist with”.

Every user is provisioned in Microsoft 365 as a mail user first, with an ExternalEmailAddress pointing at their Google routing address, before being converted to a mailbox by the migration itself. Get the primary addresses matching across both platforms. Where they do not match, the user needs a proxy address at the primary domain.

Microsoft also recommends disabling messaging records management and archive policies during the migration, because retention and archiving actions during a copy make messages look missing during verification when nothing has actually been lost.

Two cutover approaches, and the one most businesses should pick

Staged coexistence. The dual-subdomain routing above exists so mail keeps flowing to both platforms while batches run. You migrate in groups, the MX record moves once, and the remaining Google users receive their mail via forwarding until their batch completes. This is the approach the Microsoft tooling is built around and it is the right default for anything above about 20 users. The trade-off is a period of split-brain where free/busy lookups across the boundary do not work properly and internal replies occasionally take an odd path.

Single cutover. Everything migrates over a weekend, MX moves once, Google goes read-only Monday morning. Cleaner conceptually, and fine for small tenancies with modest mailboxes. The risk is entirely on throughput: contact and calendar throughput is capped by your Google tenant’s service account quota, and individual messages are limited by default to 35 MB (configurable up to 150 MB). If a large mailbox does not finish, you have no fallback because the MX has already moved.

Pick coexistence unless the tenancy is genuinely small. The extra fortnight of dual routing costs less than a failed weekend.

Realistic sequencing

1. Audit and inventory. Super admins, third-party OAuth grants, domain-wide delegation, SSO applications, forwarding rules, shared drives with no manager, Google Groups and what each one actually does. We cover this in detail in audit the Google tenancy before you touch anything.
2. Take an independent backup of the Google data before you change anything. Migration tools copy rather than move, but a rollback point that does not depend on either vendor is cheap insurance. See a proper backup of the Google data.
3. Build the Microsoft 365 tenant. Licensing, Entra ID, groups, SharePoint site structure, security baseline.
4. Provision mail users and verify both routing subdomains.
5. Migrate rooms and resources first. Microsoft recommends starting resource onboarding before regular mailbox onboarding and finishing it after all mailboxes are done.
6. Run a pilot batch. Include at least one executive assistant, one heavy label user and one person with a spreadsheet that does something clever.
7. Scan Drive, map identities, pre-create the Microsoft 365 groups that will hold shared drive permissions.
8. Migrate files ahead of mail. File migration is slower and tolerates delta syncs. Mail cutover is the hard deadline.
9. Move mail in batches, then move MX.
10. Delta sync files, rebuild calendar permissions, reissue external links, repoint SSO applications.
11. Leave Google Workspace running, read-only, for at least one billing cycle. Do not cancel the subscription on cutover day.

For the Microsoft-side build, our general Microsoft 365 migration guide covers the tenant configuration that applies regardless of where you came from.

The parts that always cause grief

Delta syncs punish tidiness. Migration Manager treats a renamed file or folder as a brand new object, so reorganising Drive between passes duplicates everything below the renamed folder. Freeze the source structure for the duration.

Data volume never matches the admin console. Google only started counting the size of its own proprietary file types on 2 May 2022, so anything created or modified before that date returns a scanned size of one byte. Your scan report will understate the job.

Path length and file names bite late. Destination URLs over 400 characters fail, drives with a forward slash in the name are unsupported, and duplicate file names in the same folder get renamed with (1), (2) suffixes.

And the cultural one, which no tool solves: Google’s sharing model is permissive by default and SharePoint’s is not. Users who were used to sending a link to anyone will find themselves blocked, and will describe this as the migration breaking things. Decide your external sharing policy before cutover, communicate it as a deliberate change, and staff the help desk properly for the first fortnight.

If you are keeping some Google services rather than leaving entirely, running both platforms side by side is a supportable position, but it needs to be a decision rather than a leftover.

Worth saying plainly, because this post points one direction: we are a Microsoft partner, and we also administer Google Workspace tenancies as daily work. We do not treat a move to Microsoft 365 as automatically correct, and a fair share of the businesses that ask us about this migration are better off staying where they are. If yours is one of them we will tell you, which is the only reason the rest of this advice is worth reading.

Book a scoping session before you commit to a cutover date. We will run the inventory, produce the list of things that will not migrate, and give you a sequenced plan you can put in front of your board. Call 1300 028 324 or get in touch at https://techassist.au/contact/.

Yes, mostly, and the honest answer is that six of the eight have almost nothing to do with which email platform you chose. The Essential Eight is a set of controls for endpoints and networks, not for productivity suites. Choosing Google over Microsoft changes how you satisfy two or three of the strategies and changes nothing at all about the rest.

Where it does bite is real, though, and it is not where most people expect. Read on before you answer that cyber insurance questionnaire.

The eight strategies, named exactly

The Australian Signals Directorate publishes the Essential Eight as part of its Strategies to Mitigate Cyber Security Incidents. The eight mitigation strategies are: patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening and regular backups.

Four maturity levels are defined, Maturity Level Zero through to Maturity Level Three. Maturity Level Zero signifies weaknesses in an organisation’s cyber security posture. ASD’s guidance is that Maturity Level One may generally be suitable for small to medium enterprises, Maturity Level Two for large enterprises, and Maturity Level Three for critical infrastructure providers and organisations in high threat environments. The current version of the Essential Eight Maturity Model is the November 2023 release, with a supporting FAQ last updated in October 2024.

Two rules matter more than any individual control. First, organisations should achieve the same maturity level across all eight strategies before moving to a higher level. There is no partial credit for being excellent at backups and absent on application control. Second, ASD states that seeking to use risk acceptance without compensating controls, or risk transference such as buying cyber insurance, as justification for not implementing an entire mitigation strategy means the organisation “will be considered to have not protected themselves against a specific class of cyber threat” and will be assessed as Maturity Level Zero for that strategy and for their overall implementation. You cannot insure your way past a control.

If the model itself is new to you, start with what the Essential Eight actually asks for.

Why the model reads as Microsoft-shaped

It reads that way because it largely is. The maturity model names Internet Explorer 11, Microsoft Office macros, Microsoft’s recommended application blocklist, Microsoft’s vulnerable driver blocklist, Windows PowerShell 2.0, Constrained Language Mode, Credential Guard, Local Security Authority protection and memory integrity. ASD’s own definition of a workstation is “any device that uses a desktop operating system, such as Microsoft Windows or a Linux distribution”, and the FAQ’s answers on hardening, privileged access management and passwordless deployment all point at Microsoft documentation.

That is not bias so much as history. It also means a Google-centric business has to do more explaining, not necessarily more work.

One point in Google’s favour is worth quoting. ASD’s FAQ says that where an organisation cannot rapidly scan and patch its own online services, it “encourages all organisations to consider moving their online services to mature and trustworthy cloud service providers”, noting this can deliver significant security benefits such as rapid identification and patching of vulnerabilities. Running Gmail instead of an on-premises mail server is the outcome ASD is asking for.

Working through the eight

Patch applications

Google Workspace itself is patched by Google, and ASD’s definition of an online service explicitly includes cloud services. That part is genuinely easier than running your own.

What is not easier is the rest of the requirement. Maturity Level One asks for an automated method of asset discovery at least fortnightly, a vulnerability scanner with an up-to-date database, daily scanning for vulnerabilities in online services, and weekly scanning for office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Critical or actively exploited vulnerabilities in online services get 48 hours. That whole category gets two weeks otherwise.

Note the phrase “web browsers and their extensions”. This is where Google-centric businesses fail assessments. Chrome updates itself, so people assume they are covered. Chrome extensions do not manage themselves, and in most Workspace tenancies staff install whatever they like. Force-install an approved extension list and block the rest through Chrome Enterprise policy, and keep an inventory of what is installed. Without that you have no asset discovery and no scanning across a category ASD names explicitly.

Verdict: achievable, but only if you manage the browser as a managed application rather than as something that came with the laptop.

Patch operating systems

Nothing about this control changes because you use Google. If your staff run Windows laptops, this is a Windows patching control. If they run Macs, it is a macOS patching control, and the same mapping problem on macOS applies. Maturity Level One requires unsupported operating systems to be replaced, patching within one month for workstations and non-internet-facing servers, and 48 hours for critical vulnerabilities in internet-facing servers and network devices.

ChromeOS devices are the interesting case. They update automatically, and update policy is enforceable from the admin console. The evidence problem is that an assessor wants to see the scanning and reporting, not a claim that the platform handles it. Chrome Enterprise reporting gives you version data. Use it.

Verdict: unaffected by Google. Judge yourself on your endpoint fleet, not your email.

Multi-factor authentication

This is where Google is strong and where most Workspace tenancies are still weak.

Maturity Level One requires multi-factor authentication for users of your organisation’s online services that handle sensitive data, for third-party online services holding your sensitive data, and, where available, for third-party services holding non-sensitive data. The November 2023 update removed a common shortcut: biometrics alone, security questions and “Trusted Signals” are not recognised as valid factors. ASD accepts two combinations: something users have together with something users know, or something users have that is itself activated by something users know or are, such as a PIN or a fingerprint releasing a credential held on a device.

Google Workspace supports all of this through 2-Step Verification, and Google’s own admin guidance names security keys as the most secure method and recommends them for super admins. Maturity Level Two raises the bar to phishing-resistant multi-factor authentication for online services and for users of systems, and ASD’s FAQ points at FIDO2 certification. Security keys and passkeys in Workspace meet that.

There is even an argument that a Google-first business has an easier path to Maturity Level Two here than a Windows shop, because on a ChromeOS device the workstation sign-in is the Google account sign-in, so a phishing-resistant factor covers both at once. On Windows the equivalent is Windows Hello for Business or smart cards, which is a separate project.

What fails audits: enforcement gaps. Optional 2-Step Verification is not multi-factor authentication. Neither is 2-Step Verification with SMS left enabled as a fallback for the executives who complained. See phishing-resistant multi-factor authentication for the practical rollout.

Verdict: the strongest of the eight on Google. Fully achievable to Maturity Level Two.

Restrict administrative privileges

Google’s admin role model maps well. Maturity Level One wants privileged access requests validated when first requested, dedicated privileged accounts used solely for privileged duties, separate privileged and unprivileged operating environments, and unprivileged accounts unable to sign in to privileged environments.

Google’s published administrator security best practices ask for exactly this pattern: more than one super admin, each managed by a separate individual, and each super admin holding two accounts, one for admin work and one for daily activity. That is the ASD requirement stated in Google’s own words.

The requirement that used to break on cloud platforms is the one preventing privileged accounts from accessing the internet, email and web services. The November 2023 update amended this specifically to support cloud management: accounts explicitly authorised to access online services are permitted, but must be explicitly identified and strictly limited to what is required. A Workspace super admin account is exactly that case. Identify it, document the authorisation, restrict it.

Two things to actually check. Delegated admin roles accumulate silently, so review them. And domain-wide delegation is a privileged access path most businesses have never audited: Google’s own documentation warns that with domain-wide delegation “the app has access to the data belonging to all of your users” and recommends a regular review of service accounts, deleting any no longer in use. An assessor who knows Google will ask about this. Most do not, which is not a reason to skip it.

Verdict: achievable, and the November 2023 wording change made it cleaner than it used to be.

Application control

This is the hardest of the eight for a Google-centric business, and anyone telling you otherwise has not read the requirements.

Maturity Level One requires application control implemented on workstations, applied to user profiles and temporary folders used by operating systems, web browsers and email clients, restricting the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.

If your staff use Windows laptops with Google Workspace, nothing here is different: you need Windows Defender Application Control or AppLocker, and Google is irrelevant to the control.

If your fleet is ChromeOS, the position is genuinely ambiguous. ASD defines a workstation as any device using a desktop operating system, giving Windows and Linux as examples rather than an exhaustive list. ChromeOS arguably qualifies. It also has no application control mechanism in the sense the model describes, because it does not execute those file types in that way. What it has instead is verified boot, per-process sandboxing and policy-enforced allowlisting of apps and extensions.

That is a compensating controls argument, and ASD permits compensating controls. The FAQ is clear on the terms: system owners must demonstrate that compensating controls provide an equivalent level of protection, and if an assessor judges them unsuitable, the strategy is assessed at the next lowest maturity level it qualifies for, or Maturity Level Zero. Write the argument down before the assessment, not during it.

Verdict: the control most likely to hold you at Maturity Level Zero. Get the scope and the compensating control position agreed in writing early.

Restrict Microsoft Office macros

The strategy is named after a Microsoft product. If Microsoft Office is not deployed anywhere in your organisation, the Maturity Level One requirements (macros disabled for users without a demonstrated business requirement, macros in files from the internet blocked, macro antivirus scanning enabled, macro settings not changeable by users) have nothing to attach to.

Two warnings.

First, “we do not use Microsoft Office” is almost never true. Someone in finance has Excel. Someone received a .docm from a client. The requirement bites on any Windows device where Office is installed, whatever your email platform is. Check before you claim it.

Second, and more importantly, the risk the control exists to mitigate does not disappear. Google Apps Script is embedded executable code in Sheets, Docs and Forms, triggered by the document, capable of calling out to the internet and touching Drive and Gmail through the user’s own authorisation. It is the same class of threat. The Essential Eight does not mention it, so satisfying the control literally does not protect you from it. Restrict Apps Script through the admin console, control which third-party apps can access Workspace data via API controls, and document that you have done so. It will not earn you a tick, but it is the right answer, and a competent assessor or insurer will be more impressed by it than by the tick.

Verdict: likely out of scope, but get the scoping decision agreed with your assessor in writing rather than assuming it. And treat Apps Script as the equivalent risk it is.

User application hardening

Maturity Level One requires Internet Explorer 11 disabled or removed, web browsers not processing Java from the internet, web browsers not processing web advertisements from the internet, and browser security settings that users cannot change.

All four are achievable in Chrome through Chrome Enterprise policy, and the ad-blocking requirement is the one people forget. Note that ASD’s FAQ clarifies this requirement does not extend to JavaScript, only Java.

Where the mapping genuinely breaks is Maturity Level Two and above, which requires web browsers and office productivity suites to be “hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur”. ASD publishes hardening guidance for Microsoft 365 and Office. It does not publish an equivalent Google Workspace hardening guide. There is nothing to comply with, which sounds convenient and is actually a problem: you cannot evidence compliance with guidance that does not exist.

The workable position is to apply vendor guidance from Google, apply ASD’s browser hardening guidance to Chrome, document the absence, and be ready to explain it. See hardening the Workspace tenancy itself for the configuration.

Verdict: Maturity Level One is achievable. Maturity Level Two requires a documented argument rather than a checklist.

Regular backups

Google Workspace is not a backup, and this is the control where Google-centric businesses are most often quietly non-compliant.

Maturity Level One requires backups of data, applications and settings performed and retained in accordance with business criticality and business continuity requirements, synchronised to enable restoration to a common point in time, retained in a secure and resilient manner, with restoration tested as part of disaster recovery exercises. Unprivileged accounts must not be able to access other users’ backups, or to modify and delete backups.

Google Vault is retention and eDiscovery. It holds data against deletion and it supports legal hold. It does not restore a Drive folder structure to a point in time, and it will not help you after a ransomware event that encrypts files synced from an endpoint. The requirement to test restoration as part of a disaster recovery exercise is the one nobody does.

This needs a third-party Workspace backup product with independent retention and its own access control. Google is not backing up your Workspace data covers the options and the Australian data residency question.

Verdict: fully achievable, and the most common real gap.

What an assessor or insurer will actually say

Three things, in our experience.

They will ask for evidence, not assertions. ASD notes there is no requirement to have an Essential Eight implementation certified by an independent party, but that assessment may be required by a government directive or policy, by a regulatory authority, or under contractual arrangements. Cyber insurers increasingly require it contractually. Screenshots of admin console settings, exported policy configurations and dated restoration test results are what gets accepted.

They will run a questionnaire written for Microsoft environments. Answering “not applicable” three times looks like evasion even when it is correct. Answer with the compensating control and the reasoning, not with a blank.

And they will treat application control and backups as the two that decide the outcome. Everything else tends to be tidy-up.

If your fleet is genuinely mixed, which most Australian businesses of this size are, the assessment scope is the fleet and not the productivity suite. A mixed Windows, Mac and Google fleet is assessable, it just needs the mapping written down once, properly.

We do Essential Eight uplift and assessment work for businesses running Google, Microsoft, Apple or all three, and we will tell you where you actually sit before you sign anything. Call 1300 028 324 or book a review at https://techassist.au/contact/.

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:

1. 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.
2. 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.
3. Kill unexplained forwarding, delegation and routing rules. Document what you removed and tell the client, because occasionally one of them is legitimate and undocumented.
4. 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.
5. Remove domain-wide delegation entries that do not map to a live system.
6. Enforce 2-Step Verification, with security keys for every administrator.
7. Assign a manager to every shared drive that lacks one.
8. 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 a client or an insurer asks where your data lives, the honest answer for most Australian businesses is: the files sit in an Australian data centre, the company that runs it is American, and the people who administer it could be anywhere. Those three facts are separate questions, and most providers answer only the first one and call it sovereignty. Getting the distinction right matters, because the Privacy Act holds you responsible for what happens to personal information after it leaves your hands.

Data residency is where your data is physically stored. Data sovereignty is whose laws apply to it. Jurisdiction is which courts and agencies can compel its production. A data centre in Sydney settles residency. It does not settle the other two.

Residency, sovereignty and jurisdiction are three different questions

Residency is a fact about geography. Microsoft or Google can tell you which metropolitan area holds your mailboxes and files, and both publish that information.

Sovereignty is a question about law. A US-headquartered provider remains subject to US law wherever its servers sit, and an Australian subsidiary does not change the parent company’s obligations. A local region does not create a legal firewall.

Jurisdiction is the practical version of the sovereignty question: who can lawfully order the data to be handed over, and under what process. That question is answered by the provider’s corporate structure and the contract, not by the postcode of the building.

Providers who blur these three are usually selling a data centre tour. Ask which of the three they are actually addressing.

APP 8 makes you accountable for what your overseas provider does

Australian Privacy Principle 8 governs cross-border disclosure. Before an APP entity discloses personal information to an overseas recipient, it must take such steps as are reasonable in the circumstances to ensure that the recipient does not breach the APPs. Section 16C then makes the disclosing entity accountable for acts or practices of the overseas recipient that would breach the APPs. In plain terms: if your offshore provider mishandles the information, you are treated as having breached the APPs yourself.

The OAIC’s expectation is that “reasonable steps” normally means an enforceable contract requiring the recipient to handle the information in accordance with the APPs, requiring the same terms to flow down to subcontractors, setting out complaint handling, and requiring the recipient to notify you of suspected breaches so you can meet your obligations under the Notifiable Data Breaches scheme.

There is an important wrinkle that changes the analysis for cloud storage. The OAIC’s APP Guidelines say that providing personal information to an overseas contractor may be a use rather than a disclosure where you do not release the information from your effective control. The example given is a cloud provider engaged for the limited purpose of storing the information and making it available to you, where a binding contract limits the provider to those purposes, binds subcontractors to the same obligations, and leaves you with effective control over access, security and deletion. In that case APP 8 does not apply.

That is not a free pass. The Guidelines are equally clear that where the arrangement is a use, you still hold the information, so you can still breach APP 11 and the other APPs if the provider mishandles it. You have changed which principle you are judged under, not whether you are responsible.

There are also two exceptions worth knowing. APP 8.2(a) applies where you reasonably believe the recipient is subject to a law or binding scheme substantially similar to the APPs with an accessible enforcement mechanism. APP 8.2(b) applies where the individual consents after being expressly told that if they consent, you will not be accountable and they will not be able to seek redress under the Privacy Act. Consent-based offshoring is legally available and commercially unattractive, because you have to say that sentence out loud to the customer.

Before any of this is workable you need to know what you actually hold. That is why we ask clients to classify your data first and to keep a documented record of where each system stores data. Without it, the APP 8 question cannot be answered honestly for any given system.

Microsoft 365 in Australia: what the commitment actually covers

Microsoft treats Australia as a Local Region Geography, with Microsoft 365 data centre locations in Melbourne and Sydney. For a tenant whose Default Geography is Australia, Microsoft’s Privacy and Security Product Terms provide a durable data residency commitment for Exchange Online, SharePoint and OneDrive, Microsoft Teams, and Microsoft 365 Copilot and Copilot Chat.

Four things about that commitment are routinely misunderstood.

The Default Geography is set when the Microsoft Entra ID tenant is created and cannot be changed afterwards. If someone signed your business up for a trial with the wrong country years ago, that decision is still governing your data location today.

The commitment covers a defined list of services, not everything with a Microsoft logo. Coverage for Microsoft Defender for Office P1, the Microsoft 365 web apps, Viva Connections and selected Microsoft Purview services requires the Advanced Data Residency add-on, which must be applied to 100 per cent of paid licences in the tenant. Services outside the covered list follow their own provisioning logic.

Where there is no durable commitment for a service, Microsoft’s own documentation states that the data is not committed to reside in any particular data centre and that the storage location is subject to change without notice.

Finally, Microsoft’s documentation notes that a customer request may be handled by servers in a region other than the one where the data is stored at rest. Processing paths and storage location are not the same thing.

On access, Microsoft states that engineers have no standing administrative privileges and no standing access to customer data, that any access is limited, logged and approved by senior management, and that customers licensed for Customer Lockbox also approve it themselves. That is a meaningful control and it is worth turning on. It is not the same as saying nobody outside Australia can ever see the data.

You can check your own position in the Microsoft 365 admin center under Settings, Org settings, Organization profile, Data location.

Google Workspace does not offer an Australian data region

This one surprises people, so state it plainly. Google Workspace data regions let an administrator pin covered data to the United States or to Europe. The third option is “No preference”. Australia is not a choice.

The coverage is otherwise reasonably good where it applies. Data regions cover data at rest, including backups, and data processing for core services including Gmail, Calendar, Drive, Docs, Chat, Meet, Contacts and Vault, subject to edition. Google’s documentation is explicit that data regions cannot be applied to data types not listed, such as logs or cached content, and that users on an unsupported edition are not covered even if a policy is applied to their organisational unit.

Google Cloud, which is a different product, does operate Australian regions. If a vendor tells you their Workspace data is held in Australia, they are either describing something built on Google Cloud rather than Workspace, or they have not read the documentation.

Storage is local. Support and administration usually are not.

This is the gap that catches businesses in a client security review. Your tenant can be pinned to Melbourne and your support model can still involve people outside Australia.

Three things to check. First, the vendor’s own support model: follow-the-sun support desks routinely mean an engineer in another country holds a privileged account in your tenant. Second, subcontractors: a vendor with an Australian front office and an offshore development or support partner has an APP 8 question of its own to answer, and the OAIC expects the obligations to flow down. Third, your own provider: if your MSP uses offshore staff for after-hours triage, that is a disclosure decision you have made whether or not you were told about it.

TechAssist runs an Australian team from our Tecoma head office and Melbourne CBD office, so this is an easy question for us to answer. The point is that it is a question you should be asking of every provider with administrative access, including the ones you have used for years.

Foreign government access, stated factually

The United States enacted the Clarifying Lawful Overseas Use of Data (CLOUD) Act in March 2018. It confirms that US providers can be compelled to produce data in their possession, custody or control regardless of where that data is stored, and it authorises bilateral agreements allowing partner countries to serve orders directly on US providers. The United States and Australia signed a CLOUD Act agreement on 15 December 2021.

Two things follow. Data stored in Sydney by a US-headquartered provider is still within reach of US legal process. And Australian agencies have their own compulsory powers, so the alternative is not an absence of government access, it is a different government’s access.

Both Microsoft and Google publish periodic transparency reports on government requests. If this risk is genuinely material to your business, read those rather than the marketing page, and treat customer-managed encryption keys and Customer Lockbox as the controls that actually change the analysis.

The trade-off is worth naming. Moving to a wholly Australian-owned provider removes the foreign jurisdiction exposure and usually costs you the security engineering, availability and feature velocity of a hyperscaler. For most SMBs that is a bad trade. For a defence supplier it may not be.

When sovereignty is a legal requirement, and when it is a procurement preference

Genuine legal requirements exist, and they are narrower than the sales conversation suggests. Commonwealth and state government contracts commonly impose hosting and data location conditions, and those are contractual obligations you can read. APRA-regulated entities have their own prudential standards on information security and outsourcing.

Health is the example everyone reaches for, and it is the one most often stated wrongly. There is a real Commonwealth localisation rule, and it is section 77 of the My Health Records Act 2012 (Cth). It provides that the System Operator, a registered repository operator, a registered portal operator or a registered contracted service provider that holds records for the purposes of the My Health Record system, or has access to information relating to those records, must not hold or take the records outside Australia, must not process or handle the information relating to those records outside Australia, and must not cause or permit another person to do either. The only carve-out is for the System Operator itself, for operating or administering the system, and only where the records and information contain no personal information about a healthcare recipient or participant and no identifying information. Contravention is a fault-based offence carrying imprisonment for 5 years or 300 penalty units or both, with a civil penalty of 1,500 penalty units.

Now read the list of who that binds, because that is the part clinics get wrong in both directions. Section 77 applies to the operators of the My Health Record system and their contracted service providers. It is not a rule that all Australian health data must stay onshore. A medical, dental or allied health practice is a registered healthcare provider organisation, and registered healthcare provider organisations are not in the section 77 list. So section 77 does not, by itself, prohibit a clinic from using an offshore-hosted practice management system for its own clinical records. If your software vendor or your hosting sits inside the My Health Record system as a repository, portal or contracted service provider, section 77 binds that role directly and you should ask them to say so in writing. If it does not, your offshore hosting question is answered by the Privacy Act, your state health records legislation and your contracts, not by section 77. Getting this backwards means either buying sovereignty you are not required to have, or assuming a protection that does not apply to you.

Everything else is usually a procurement preference: a large customer’s security questionnaire, an insurer’s checklist, or a board that would prefer the answer to be “Australia”. Preferences are legitimate, and they cost money. Meeting them can mean an Advanced Data Residency add-on, an edition upgrade, or leaving a product you otherwise like.

The Privacy Act itself does not require personal information to stay in Australia. It requires you to take reasonable steps and holds you accountable if the recipient mishandles it. A business under the $3 million small business turnover threshold in section 6D may be exempt from the Privacy Act altogether, though the exemptions are narrower than most owners assume. It is worth understanding what the Privacy Act asks of a small Australian business before deciding you are outside it.

Where privacy reform has actually got to

Do not build a data strategy on the small business exemption surviving, and do not assume the second tranche has already landed. Both mistakes are common.

The first tranche is law. The Privacy and Other Legislation Amendment Act 2024 passed Parliament on 29 November 2024 and progressed 23 proposals from the government’s response to the Privacy Act Review Report, including a framework for a Children’s Online Privacy Code. Two of its changes reach ordinary businesses. The statutory tort of serious invasion of privacy commenced on 10 June 2025, and the OAIC notes that it is broader in application than the Privacy Act, extending to individuals and entities that are not APP entities, which means it can reach a business the Privacy Act does not. Separately, from 10 December 2026, an APP entity that has arranged for a computer program to use personal information to make a decision that could reasonably be expected to significantly affect a person’s rights or interests must say so in its privacy policy, including the kinds of information used and the kinds of decisions made. The OAIC has consulted on guidance and said it intends to publish it before that date.

The second tranche is not law, and that is where the bigger changes sit, including removal of the small business exemption. At the time of writing the Attorney-General’s Department’s own privacy page still describes the work as developing draft provisions and engaging on the detail to inform the government’s decisions on next steps, and no second tranche Bill has passed. Treat the exemption as a temporary position, check the position again before you rely on it, and note that it was never a shield against the statutory tort, which does not depend on being an APP entity at all.

The questions to put to a SaaS vendor

Send these in writing and keep the answers with the contract.

1. In which country is customer data stored at rest, and is that a contractual commitment or a current arrangement you may change?
2. Which specific services or modules are covered by that commitment, and which are not?
3. Where are backups, replicas, logs and cached content stored?
4. From which countries can your staff and subcontractors access customer data, and under what approval process?
5. Who are your sub-processors, where are they, and do your contracts require them to meet the same obligations?
6. Under APP 8, do you regard your handling of our customers’ personal information as a use or a disclosure, and why?
7. Will you notify us of a suspected data breach, within what timeframe, and in what form?
8. On termination, how is our data returned and destroyed, and will you provide evidence that destruction occurred?

Question seven is the one that determines whether you can meet your obligations under the Notifiable Data Breaches scheme, which require you to notify the OAIC and affected individuals when a breach is likely to result in serious harm. Question eight is the one everyone forgets until an exit, and it connects directly to secure device disposal and the APP 11.2 obligation to destroy personal information you no longer need. If you want the configuration side handled properly as well, start with cloud security controls that matter for an SME.

If you are filling in a client security questionnaire or a cyber insurance form and cannot answer these questions about your own tenant, we can audit it and give you the documented answers. Call us on 1300 028 324 or get in touch at https://techassist.au/contact/. We will tell you where your data actually sits, not where you would like it to be.

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.

Google guarantees that Gmail and Drive stay available. It does not guarantee that a file one of your staff deleted in March is recoverable in June. Those are different promises, and the gap between them is where Australian businesses lose data they legally have to keep.

Backing up Google Workspace means holding an independent copy of your Gmail, Drive, Shared drives, Calendar, Contacts and Chat data, outside the tenancy and outside the control of the accounts that use it, that can be restored to a chosen point in time. Nothing included with a Workspace licence does that.

The shared responsibility line, stated plainly

Google is responsible for the infrastructure: keeping the service running, keeping the data centres up, protecting against hardware failure, and replicating your data so a disk or a site failure does not lose it.

You are responsible for what happens inside your tenancy: what your users delete, what an attacker who has your password deletes, what a departing employee takes or destroys, and how long you keep records you are legally obliged to keep.

Google’s replication is not a backup, because replication faithfully copies the deletion. If a file is gone from the live system, it is gone from every copy of the live system. The question is never whether Google still has your data somewhere. The question is whether Google will give it back to you, and for how long.

What Google actually retains, and for how long

These are Google’s published windows. They are shorter than most business owners assume, and they are not adjustable.

Drive trash: 30 days. By default, Drive permanently deletes files 30 days after a user moves them to their trash. The user can restore them during that window.

Admin recovery after the trash is emptied: 25 days. If a user empties their trash, an administrator can recover deleted Drive items for a further 25 days from the Admin console. After that, Google purges the items and states they cannot be recovered.

Deleted user accounts: 20 days. If you delete a user and do not transfer their files at the time, Google deletes those files 20 days later. Restoring the account inside that window is the only route back.

Deleted Gmail: a comparable window and no more. Admins can restore a user’s permanently deleted email for a limited period after deletion, and after that Google purges it.

Shared drives: deleting a shared drive removes its content, with a limited administrative restore window rather than an indefinite one.

Audit logs: mostly six months. Most log event types are retained for six months. Email log search is 30 days. Chrome reports are 12 months. Administrators cannot delete log event data or change how long it is kept.

Put those together and the practical position is this: you have roughly a month to notice an ordinary deletion, and slightly less if the deletion happened through an account that was then removed. If your only detection mechanism is somebody looking for a file, you will regularly miss the window.

Vault is not backup, and Google says so

This is the most expensive misunderstanding in the Google ecosystem, because Vault is genuinely good at its actual job.

Google Vault is an information governance and eDiscovery tool. It lets you retain, hold, search and export Gmail, Drive, Calendar, Chat, Meet recordings, Groups, Sites, Voice and Gemini data. It is included with Business Plus, Frontline Standard and Plus, Enterprise Standard and Plus, all Education editions, Enterprise Essentials and Enterprise Essentials Plus for domain-verified accounts, and G Suite Business, and it is available as an add-on licence for some other editions. Since 1 November 2025 administrators need a Vault licence themselves in order to use it.

Here is why it is not backup, in Google’s own terms.

Vault does nothing until you configure retention rules. Google states it directly: Vault does not retain data until you set up retention rules, and until you do, users can delete data and services can purge it on their normal schedule. A tenancy with Vault licensed and no rules configured has exactly the same recovery position as a tenancy without Vault.

Vault is not an archive. Google’s documentation says Vault retention rules are applied to the live data systems of the underlying services and that Vault is not a data archive. When a retention period ends and the data is not on hold, it is subject to normal deletion, and once purged it cannot be recovered by users or admins.

Vault deletes as well as retains. Retention rules cut both ways. A rule configured to purge data after a set period will purge it, permanently, on schedule. That is the intended behaviour for a governance tool and the opposite of what you want from a backup.

Vault exports, it does not restore. You can search retained data and export it. You cannot press a button and put a user’s Drive back the way it was on Tuesday. Recovering a mailbox from a Vault export is a manual reconstruction project, not a restore.

Vault dies with the licence. Google’s documentation warns that if you delete a user or a required licence, their data may be irreversibly purged and no longer available to Vault. A backup that disappears when you stop paying for the platform it protects is not an independent copy.

Vault is bounded by the tenancy. If you lose administrative control of the tenancy, you lose Vault along with everything else. That scenario is covered in losing admin access to the tenancy.

Vault is the right tool for legal hold, for eDiscovery, and for enforcing a retention policy. Use it for those. Do not put it in the recovery column of your business continuity plan.

The four scenarios that actually cause data loss

Ransomware and account compromise. The modern version does not encrypt a file server. An attacker takes a password, signs in, and works through Drive and Gmail from inside a trusted session. Files are deleted, shares are changed, mailbox rules are created. Google’s systems replicate every one of those actions correctly, because from the platform’s point of view an authenticated user is doing normal work. Your recovery position is the 30 day trash window and whatever the attacker did not bother to empty.

The malicious insider. Someone resigns badly and spends their notice period deleting or exfiltrating. Because they own the files, most of it is legitimate activity that no security control will block. Detection after the fact depends on Drive log events, which are retained for six months, and recovery depends on those same short windows.

Departing staff and the 20 day clock. This is the quiet one, and it is almost always self-inflicted. An employee leaves, someone deletes the account to stop paying for the licence, and nobody transfers the files. Twenty days later the data is gone, including files that were the only copy of a client project. Google’s own guidance is to transfer ownership of Drive files and Calendar events before deleting, or to suspend rather than delete, or to archive the account. A proper offboarding checklist prevents this entirely, and it is a five minute change to the process.

Ordinary human error found too late. A folder is deleted in the last week of the financial year and nobody notices until the accountant asks for it in October. There is no window left, no matter how good your excuse is.

The Australian angle you cannot configure your way out of

Record keeping. The ATO requires businesses to keep records that explain their transactions, generally for five years. Employment, contractual and industry-specific obligations frequently run longer. Google’s Drive and Gmail recovery windows are measured in weeks. Vault can hold data for five years if you configure a rule to do it, which is a governance answer rather than a recovery answer, and only on the editions that include it.

Privacy Act and the NDB scheme. Under the Notifiable Data Breaches scheme, loss of personal information counts alongside unauthorised access and disclosure. If personal information is destroyed and you cannot recover it, you may still have a notifiable breach on your hands and an assessment obligation the OAIC expects you to complete within 30 calendar days. Being able to say precisely what was lost, and to restore it, materially changes both the assessment and the notification.

Where the copy lives. If you take a third-party backup, ask where the backup itself is stored, because that answer may be different from where Workspace stores your live data. Workspace data regions offer United States, Europe or no preference, with no Australian option, so an Australian-hosted backup can end up being the only Australian copy you have. That question is worked through in where your business data actually lives.

What a real backup covers, and what to look for

We are not going to name a product, because the right one depends on your edition, your data volume and where you need the copy to sit. These are the criteria that separate a real backup from a file sync with good marketing.

Independent credentials and an independent blast radius. The backup must not be accessible with the Workspace admin credentials it is protecting. If compromising your super admin account also lets someone delete the backups, you have one copy, not two.

Coverage of everything, not just Drive. Gmail with labels and folder structure intact, My Drive, Shared drives, Calendar, Contacts, Chat, and Sites if you use them. Shared drives are the common gap, because they are owned by the organisation rather than a user and some tools skip them.

Point-in-time restore, not just latest. You need to restore to the day before the deletion, not to the current state. Daily is the minimum, more often is better.

Granular restore back into the tenancy. Restoring a single message to a single mailbox, or a folder to its original Drive location with permissions intact, without the user having to reimport a zip file. Export-only tools are recovery projects, not restores.

Retention you set, decoupled from your Workspace licence. If you need seven years, the backup should hold seven years regardless of whether the user is still licensed, still employed, or still exists.

Immutability and deletion protection. Backups that cannot be altered or deleted for a defined period, including by an administrator, so that an attacker who gets in cannot destroy the recovery path.

Data location you can specify and evidence. Ask where the data is stored, in writing, and ask what happens on termination.

A tested restore. An untested backup is a hypothesis. Restore something real, on a schedule, and document that you did. Cyber insurers and client security reviews increasingly ask for evidence of the test, not the policy.

The general architecture behind all of this is covered in how business cloud backup should be structured.

What to do this week

Check your Workspace edition and whether Vault is licensed and whether any retention rules exist, because a licensed Vault with no rules is a common and misleading finding. Check your offboarding process for the account deletion step and add a file transfer before it. Confirm someone owns the alerting so a mass deletion gets noticed inside days rather than months. Then decide whether a third-party backup is warranted, and if it is, scope it against the criteria above rather than on price alone.

Tightening the tenancy itself is a separate and complementary job, covered in hardening the tenancy itself and the Admin console settings that matter. Backup reduces the consequence of a bad day. Hardening reduces how often you have one.

We can tell you in one session what your current recovery position actually is, including which retention windows you are relying on without realising it. Call 1300 028 324 or start at techassist.au/contact.

Most Google Workspace tenancies in Australian small business are running close to the settings they had on day one. The good news is that the highest-value hardening steps cost nothing and are available on every edition. The bad news is that several controls your cyber insurer or your client’s security questionnaire asks about are only sold in the Enterprise and Frontline tiers, and no amount of configuration substitutes for them.

Hardening Google Workspace means changing the Admin console settings that govern identity, application access, data sharing and monitoring so that a stolen password, a malicious add-on or a departing employee cannot quietly take your data with them. Do it in the order below, because each phase makes the next one worth doing.

Why this matters in Australia specifically

Under the Privacy Act, APP 11 requires you to take reasonable steps to protect personal information. If you hold personal information and you suffer unauthorised access, disclosure or loss that is likely to result in serious harm, the Notifiable Data Breaches scheme obliges you to assess it and, if it qualifies, notify the OAIC and the affected individuals. The OAIC’s position is that you must take all reasonable steps to complete that assessment within 30 calendar days of becoming aware of grounds to suspect an eligible breach.

Two practical consequences follow. First, you cannot assess a breach you cannot see, which is why logging and alerting sit high in this plan rather than at the end. Second, the reasonable steps standard is judged against what was available to you, and 2-Step Verification is free on every Workspace edition.

Cyber insurance questionnaires now ask the same handful of questions: is MFA enforced on all users and all administrators, is email filtering in place, are backups separate and tested, and can you detect and investigate an incident. Answering those honestly is easier if you have already done the work. Your obligations under the Notifiable Data Breaches scheme covers the reporting side in detail.

Phase 0: find out which edition you are actually on

Before you plan anything, check Billing, then Subscriptions, and write down the exact edition name. Business Starter, Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Frontline Starter, Frontline Standard, Frontline Plus and the Essentials editions all differ, and several of the controls people assume are standard are not.

Also check whether all your users are on the same edition. Mixed tenancies are common after growth or acquisition, and a policy that relies on an Enterprise feature will silently not apply to the Business Standard users sitting next to them.

Phase 1: identity, because everything else is downstream of it

This phase is free on every edition and delivers most of the risk reduction.

Enforce 2-Step Verification for everyone. Not just admins. Set it under Security, then Authentication, then 2-Step Verification, and set a new user enrolment period so joiners are not locked out on their first day.

Move admins to phishing-resistant methods. Google’s own admin security guidance names security keys as the most secure form of 2SV and the one that resists phishing, because a hardware key will not authenticate to a lookalike domain. Codes delivered by SMS or voice call do not resist phishing or SIM swap. Set the allowed methods to exclude text and call codes at least for administrators and anyone who can move money. Enrol a second key per admin and store it separately. The broader case is in phishing-resistant MFA.

Fix the admin account structure. More than one super admin, each held by a separate person. Separate super admin accounts from the daily accounts those people use for email. Delegate routine tasks to limited prebuilt roles rather than handing out super admin. No shared generic admin logins, because the audit log cannot attribute a change to a person if three people use the same account.

Create a break-glass account and prepare recovery. A super admin account that belongs to the business, not used daily, with printed backup codes and a spare security key stored physically. Google’s guidance to keep signup and billing details on hand exists because those are the questions support asks during account recovery. If you skip this, read recovering a locked admin account now rather than later.

Consider the Advanced Protection Program for super admins. Google positions it as applying many of the admin hardening recommendations at once for high-risk accounts. It requires security keys or passkeys and restricts third-party app access to the account, which is exactly what you want on an account that should be doing nothing except administration.

Note the enforcement clock. Google is progressively enforcing 2SV on administrator accounts, with super admins notified roughly 90 days ahead and other admins roughly 60 days ahead, and escalating access restrictions after the date. Getting ahead of that is free.

Phase 2: close the doors nobody remembers opening

Still free on every edition, and this is where most tenancies have never been touched.

Restrict OAuth and third-party app access. Security, then Access and data control, then API controls. Review the accessed apps list first, then move Gmail and Drive to Restricted so that apps you have not explicitly trusted cannot use the high-risk scopes, allowlist the apps the business genuinely uses, and change the Unconfigured third-party apps setting so that unclassified apps get sign-in information only or nothing. Expect breakage: Google states that restricting a service stops previously installed untrusted apps and revokes their tokens.

Block less secure app access. Anything still authenticating with a username and password rather than OAuth is a standing bypass of your 2SV enforcement. Find it, migrate it, then block it.

Set Drive external sharing deliberately. Apps, then Google Workspace, then Drive and Docs, then Sharing settings. Default new items to restricted rather than link sharing, warn users when they share outside the organisation, and leave the external file indicator on. Allowlisted domains is stronger if your external collaborators are stable.

Turn on the Gmail safety settings. Spoofing and authentication protections against domain and employee-name impersonation, advanced phishing and malware protection for attachments, links and external images, and enhanced pre-delivery message scanning. Then publish SPF, DKIM and DMARC in DNS, and check that your DMARC policy is not still sitting at p=none doing nothing.

Audit Gmail routing rules. Attacker-created routing and forwarding rules survive password resets and do not show up in the user’s own settings. Check the list now and check it again after any suspected compromise.

Restrict Calendar and Chat externally. Free or busy only for external calendar visibility, and external chat limited to the people who need it.

The detail on each of these, including the trade-offs, is in the Admin console settings that carry real risk.

Phase 3: be able to see what happened

Set up admin email alerts. Suspicious sign-in attempts, admin role changes, settings changed by another admin, compromised devices. This is available without an Enterprise licence and it is the difference between finding out in an hour and finding out in a quarter.

Use the alert centre. It aggregates Google-generated security alerts in the Admin console under Security. Assign someone to actually look at it weekly, because an alert nobody reads is not a control.

Know your log retention before you need it. Google retains most log event types for six months, Email log search for 30 days, Chrome reports for 12 months, and Vault log events indefinitely. Administrators cannot extend those periods. If your obligations or your insurer require longer, export on a schedule.

Licence reality: the alert centre and the audit and investigation page are broadly available. The security investigation tool, which is what makes hunting across those logs fast, is listed by Google for Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. On Business tier you can still answer a question you know how to ask. You cannot easily go looking.

Phase 4: control which devices get in

Turn on endpoint management. Basic mobile management is broadly available and gets you an inventory, a screen lock requirement and remote wipe of work data. Advanced mobile management and desktop endpoint verification give you more, including the device signals that Context-Aware Access depends on.

Endpoint verification installs on managed desktops and reports device attributes back to Workspace. On its own it gives you an inventory of the computers accessing company data, which is more than most SMBs have.

Licence reality: Context-Aware Access is not on Business Plus. This is the one that catches people out. Context-Aware Access, which lets you allow or block access to Gmail, Drive and other services based on device state, IP address, geography or operating system, is supported on Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. Business Plus does support App access protection, which is a narrower control, but it is not the same thing. If a client questionnaire asks whether you enforce conditional access on managed devices only, and you are on a Business edition, the honest answer is no.

A warning that matters. Applying Context-Aware Access levels to the Admin console itself can create a total admin lockout if the conditions become unmeetable. Google’s documented remedy is a support case through the Customer Care Portal to strip the policies off the Admin console. Test on a pilot organisational unit first, and never apply an untested access level to the top-level unit.

Phase 5: control the data itself

Licence reality: Drive DLP needs Enterprise or Frontline. Data loss prevention rules for Drive, which scan content for things like credit card numbers, tax file numbers and custom patterns and then block or warn on sharing, are supported on Frontline Standard and Plus, Enterprise Standard and Plus, Education Fundamentals, Standard and Plus, and Enterprise Essentials Plus. If you are on Business Standard or Business Plus, you do not have Drive DLP, and the substitute is tighter sharing defaults plus the external shares report, which is coarser but real.

Data regions are US or Europe only. There is no Australian data region option in Workspace. The choices are United States, Europe or No preference, availability varies by edition, and the policy covers a defined list of core services. If your requirement is genuinely that Australian personal information stays onshore, say so plainly to whoever is asking rather than pointing at this setting.

Vault is retention and eDiscovery, and it needs a licence. Vault is included with Business Plus, Frontline Standard and Plus, Enterprise Standard and Plus, all Education editions, Enterprise Essentials and Enterprise Essentials Plus for domain-verified accounts, and G Suite Business, and is available as an add-on for some other editions. Since 1 November 2025 admins have needed a Vault licence themselves to use it. Vault also does nothing until you configure retention rules. It is not backup, and treating it as backup is the single most common mistake in this space. That argument is set out in backup is a separate problem.

Client-side encryption exists for Gmail, Drive, Meet and Calendar in the higher tiers, and is worth considering only if you genuinely hold regulated or high-value intellectual property, because it changes how search and collaboration behave.

The licence tier summary, stated plainly

Free on every edition, and worth more than anything you can buy: 2-Step Verification enforcement, admin role separation, multiple super admins, OAuth and API controls, Drive sharing defaults, Gmail safety settings, SPF, DKIM and DMARC, admin email alerts, and the audit and investigation page with six month retention.

Needs Business Plus or above: Vault for retention and eDiscovery.

Needs Enterprise Standard or above, or the equivalent Frontline tiers: Context-Aware Access, Drive DLP, the security investigation tool, and the more granular data region controls.

If your risk profile genuinely requires the second and third groups, the licence cost is the cheapest part of getting there. If it does not, spend the money on the first group being done properly and on backup, and do not buy Enterprise to tick a box you will never configure.

How this maps to the Essential Eight

The ACSC and ASD Essential Eight is the framework Australian clients, insurers and government buyers actually reference. Several of its mitigation strategies map cleanly onto Workspace controls, particularly multi-factor authentication and restricting administrative privileges. Others, notably application control, patch applications, patch operating systems and macro settings, are endpoint controls that Workspace does not address at all and that you have to solve on the devices themselves. The full mapping, including where Workspace genuinely cannot help, is in meeting the Essential Eight on Google Workspace, and the framework itself is covered in the Essential Eight explained.

Settle who can raise a support case before you need one

This belongs in the plan rather than at the end of it. Contacting Google Workspace support requires the Support administrator privilege and access to the Admin console, so the people most likely to need support during an incident are exactly the people who may not be able to reach it. Standard Support is included with your licence, has 24/7 access and carries a four hour service level objective for P1 cases, and Google’s published hours of operation table lists Australia as 24/7 in English, so there is no overnight gap to design around.

If someone outside the business is going to open cases for you, Google documents two arrangements. A reseller who manages your subscription can access your Admin console and submit support cases for you unless you remove that access, controlled under Account, then Reseller management. Separately, you can assign a Support Partner in the Google Cloud Support Portal, after which Google states that partner can file cases on your behalf and see cases you filed yourself. Both switches need a working admin sign-in, which is the whole point of doing it now.

Do it in this order

Phase 1 in a week. Phase 2 over a fortnight with a change window for the OAuth restrictions. Phase 3 the same week, because it costs nothing. Phases 4 and 5 only after you have confirmed your edition supports them and someone owns the ongoing tuning.

The mistake to avoid is buying Enterprise licences first and configuring nothing. A Business Standard tenancy with enforced security keys, restricted OAuth scopes and tight sharing defaults is meaningfully safer than an Enterprise Plus tenancy running defaults.

We are listed in Google Cloud’s partner directory, and Workspace hardening is ordinary work for us rather than a side project. We do this as a fixed-scope uplift: an audit against the list above, a written plan with the licence implications spelled out, and the changes made in staged windows so nothing breaks unannounced. Call 1300 028 324 or start at techassist.au/contact.

A mixed fleet is a business running more than one desktop platform and more than one productivity suite at the same time, most commonly Windows with Microsoft 365 alongside Macs and Google Workspace. Almost every Melbourne business over about thirty staff is one, whether anyone planned it or not. The design team bought Macs, the accounts team runs Windows because the practice software demands it, and the founder set up Google Workspace in 2016 and never looked back.

Most providers respond to this by proposing a migration. That is usually a sales position rather than a technical one. A mixed fleet is entirely runnable, but only if you are honest about which layer must be unified and which layers should be left alone.

Identity is the only thing you genuinely must unify

Everything else in a mixed environment can be tolerated. Two identity stores cannot.

The moment a person exists as a separate account in Microsoft 365, in Google Workspace and again in Apple’s ecosystem, you have three joiner processes, three leaver processes and three places to enforce multi-factor authentication. When someone resigns on a Friday afternoon, the account you forget is the one that gets used. This is the single most common failure we see in businesses that grew into a mixed fleet rather than designing one.

Unified identity does not mean one vendor. It means one authoritative directory that every other system trusts, and one onboarding and offboarding checklist that closes every door at once.

Make Entra ID the anchor and Google the relying party

If you are running both suites, the direction of federation is not a matter of taste. It is determined by what the two vendors actually support.

Microsoft publishes a first-party integration for using Microsoft Entra ID as the identity provider for Google Workspace, listed in the Entra gallery as the Google Cloud / G Suite Connector by Microsoft, with SCIM provisioning alongside it. Google documents the other half from its side, confirming that Workspace supports single sign-on from third-party identity providers over both SAML and OIDC, and ships a pre-built Microsoft Entra OIDC profile.

The reverse is not a supported architecture. Microsoft’s Google federation feature is scoped to business-to-business guest users, and Microsoft states plainly that it no longer performs validation testing of independent identity providers for compatibility with Entra ID. Anyone proposing Google Workspace as the primary identity provider for a Microsoft 365 tenancy is proposing something neither vendor documents.

One caveat worth writing into your runbook: Google restricts single sign-on for super administrators, and super admins signing in to the admin console must use their Google password rather than federated credentials. Keep at least one break-glass Google super admin outside single sign-on, store the credential properly, and test it. If you skip this, read what happens when you are locked out of your Google Workspace admin account before you find out the hard way.

Apple will federate with one identity provider, not two

Apple Business, the portal formerly known as Apple Business Manager, can federate with Google Workspace, with Microsoft Entra ID, or with a generic provider over OIDC or SCIM. Apple’s documentation is explicit that you can link to one of these at a time, not several.

That single sentence settles a lot of architectural arguments. If your Macs and iPhones are going to draw their Managed Apple Accounts from a directory, you must choose which directory, and in a Microsoft-anchored environment that is Entra ID.

There is a second trap here that catches people badly. Before Apple will federate a domain it must be verified and captured, and turning on Domain Capture gives every staff member with a personal Apple Account on your company domain a fixed thirty days to move their personal data off it. Apple states the date cannot be extended and that turning on Domain Capture cannot be undone. Staff with a decade of personal photos and App Store purchases attached to a work email address will not take this well if it lands unannounced. Communicate before you press the button, not after. The full sequence is covered in the guide to Apple Business, the portal formerly called Apple Business Manager.

Device management does not consolidate, and that is fine

Identity converges. Device management does not, and chasing a single pane of glass here usually costs more than it saves.

Windows provisioning through Autopilot, macOS enrolment through Apple’s Automated Device Enrolment, and Chrome or Android enrolment through the Google admin console are three genuinely different pipelines with three different trust models. One console can hold all three records, but the underlying work is still platform-specific. What matters is that every device is enrolled in something, that the something reports compliance back to your identity provider, and that nothing is unmanaged.

If you already pay for Microsoft 365 Business Premium or E3, you already own Intune, and Intune will manage Macs. Whether it manages them well enough is a real question with a real answer, covered in what Intune can and cannot do on a Mac and in the head-to-head on Jamf and Intune compared honestly. The practical mechanics of enrolling and managing a Mac fleet are a separate discipline again, and it is the one most generalist providers quietly skip. We have written separately about why most Melbourne MSPs cannot support Macs properly, because the gap is structural rather than a matter of effort.

On the Google side, the equivalent baseline work is in the Google Workspace admin console settings that matter, and the day-to-day device story sits alongside your broader approach to mobile device management.

Running both suites costs more than two subscriptions

The licence line is the visible cost. It is rarely the largest one.

Only one system can own your mail. Your domain has one set of MX records. Google documents split delivery and dual delivery as the two ways to run a second mail platform alongside Gmail, and in both cases the second system receives forwarded copies rather than authoritative delivery. You pay for two mail platforms and get one authoritative mailbox store, plus permanent complexity in SPF, DKIM and DMARC alignment on forwarded messages.

Storage entitlements do not travel. Google’s pooled storage is pooled within Google. Microsoft’s mailbox and OneDrive quotas are entitlements within Microsoft. Buying more of one never offsets the other, and staff will keep the same files in both, so you pay twice to store the same bytes. Neither vendor is backing that data up for you either, which is the subject of Google is not backing up your Workspace data.

Policy parity requires an edition uplift on both sides. Conditional Access on the Microsoft side requires Entra ID P1, which is included in Microsoft 365 Business Premium and E3. The nearest Google equivalent, Context-Aware Access, is restricted to the Enterprise, Education and Frontline editions or to Cloud Identity Premium, and Google states that users without a supported edition are simply not subject to Context-Aware Access policies at all. That Google-side uplift is the cost most businesses miss, because it is not a security add-on you buy for a handful of people. It is an edition change across every user.

We are not going to publish a dollar figure here, because the honest answer depends on your exact mix of editions. What we will say is that the second suite is almost never as cheap as the second subscription line suggests.

Your security baseline does not translate across platforms

This is where mixed fleets quietly fail audits and cyber insurance questionnaires.

The Essential Eight is the framework Australian businesses are measured against, and read closely it is shaped around Microsoft products. The current maturity model, last updated in November 2023, contains no mention of macOS, Apple, iOS, Chrome or Google anywhere in the document. One of the eight strategies is restrict Microsoft Office macros, and at Maturity Level Two and above it requires blocking macros from making Win32 API calls, which is Windows-only by definition. Application control at Maturity Level Two and above requires implementing Microsoft’s recommended application blocklist. User application hardening names Internet Explorer 11 and PowerShell logging.

ASD’s own hardening library reflects the same shape. It publishes hardening guides for Windows 10, Windows 11 and Linux workstations. There is no enterprise macOS hardening publication at all, and the only Apple configuration guide covers iOS 14. Its Blueprint for Secure Cloud is described by ASD as having a current focus on Microsoft 365, with no Google Workspace equivalent.

None of that means a Mac fleet cannot be secured to an equivalent standard. It means the equivalence has to be argued and documented rather than assumed, using the model’s own allowance for vendor hardening guidance and its exceptions process. Do that work before an assessor asks, not during. The detail sits in mapping the Essential Eight onto macOS and whether you can meet the Essential Eight on Google Workspace, and the underlying platform hardening in hardening Google Workspace.

One more thing worth knowing if you are planning a multi-year uplift: ASD ran a consultation on the evolution of the Essential Eight that closed on 12 July 2026, proposing a new Essentials series with the current guidance becoming a chapter called Essentials for enterprise IT. ASD says existing adopters can expect strong alignment with their current controls. Build your roadmap anyway, but build it knowing the framework is being rewritten.

When consolidating actually is the right call

Sometimes the migration everyone keeps proposing is correct. The honest triggers are these.

Consolidate when the duplication is at the identity layer and cannot be federated away. Consolidate when a compliance obligation or a client security review requires a single enforceable policy set and you cannot demonstrate equivalence on the second platform. Consolidate when the second suite is used by fewer people than it costs to administer properly. Consolidate when the business is being sold or is acquiring, because two suites double the integration work later.

Do not consolidate because one platform is unfamiliar to your provider. That is their problem to fix, not yours to pay for.

If you do decide to move, move deliberately. The comparison itself is covered where we have already compared the two suites feature by feature, and the actual migration mechanics, including what breaks in shared drives and calendar delegation, are in the mechanics of moving off Google Workspace. If you have inherited an environment and cannot even establish who owns what, start with inheriting a Workspace tenancy nobody documented.

What a properly run mixed fleet looks like

One authoritative directory. Every other platform federated to it, including Apple. Every device enrolled in a management service appropriate to its platform, reporting compliance back to that directory. One documented joiner and leaver process that touches every system. A written, defensible mapping of your security baseline onto each platform, including the parts where the framework does not fit and you have documented an equivalent control instead. And a hardware lifecycle that does not depend on who happened to buy the laptop, which is the subject of buying, redeploying and disposing of Apple hardware.

That is achievable at 30 staff and at 200. What it requires is a provider who is competent on all three platforms rather than one who tolerates two of them: someone who works with Apple’s business deployment programmes for enrolment and device management, runs Entra ID and Intune as daily work rather than as an escalation, and can open the Google Admin console and tell you what is wrong with it.

TechAssist has run Windows, Mac and Google environments side by side for Melbourne businesses for over 20 years, with 13 certified specialists across the team. We are a Microsoft partner and a Jamf partner, and on the Apple side we are a member of the Apple Consultants Network, Apple’s programme of independent technology partners specialising in Apple solutions for small and medium-sized businesses. That combination is the point rather than the decoration. A provider holding partnerships on both sides of an argument has no commercial reason to steer the answer, and the only honest test of neutrality is whether they ever recommend the option that earns them less. We do that regularly, and you will find us doing it in the posts linked above. If you want a straight assessment of whether your mixed fleet should be unified or simply run properly, call 1300 028 324 or get in touch at https://techassist.au/contact/. We will tell you which of the two it is, including when the answer is that you do not need to change anything.

For most Australian SMEs the honest answer to Microsoft 365 vs Google Workspace comes down to how your team actually works. Google suits lean, cloud-native businesses that live in a browser. Microsoft suits desktop-heavy, Windows-fleet, compliance-driven operations. Both are mature, secure platforms — the wrong fit just costs you in friction.

We’re a Microsoft-centric MSP, so I’ll declare that bias up front. But there are plenty of Melbourne businesses where I’d point a client to Google without hesitation. This is a fair comparison, not a sales pitch, and below there’s a table to cut through the marketing on both sides.

The quick comparison

Pricing changes regularly and varies by term and reseller, so treat those figures as a guide rather than a quote. The real cost difference between the two is usually rounding error compared with the cost of choosing the platform that fights your workflow.

Apps: desktop power vs web speed

This is the clearest fork in the road. Microsoft gives you the full desktop Office suite — the real Excel, with the pivot tables, Power Query, macros and add-ins that finance teams and engineers depend on. If your business runs complex spreadsheets, branded Word templates, or PowerPoint decks that have to look identical every time, desktop Office still has no equal.

Google Workspace is web-first and proud of it. Docs, Sheets and Slides load instantly, autosave constantly, and make real-time co-editing feel effortless. For a marketing agency or a startup where two people are in the same document at once all day, that collaboration model is genuinely better. The trade-off is depth: heavy Excel users hit Sheets’ ceiling quickly, and complex formatting can drift.

Where Google clearly wins: if your team already does everything in a browser and nobody opens a desktop app from one week to the next, paying for desktop Office you’ll never install is waste.

Email: Outlook vs Gmail

Exchange Online with Outlook is the workhorse of Australian business email. Shared mailboxes, delegate access, distribution groups, calendar scheduling across a team — it’s all mature and granular. For a law firm in Hawthorn juggling shared client inboxes and rigid retention rules, Exchange and Microsoft Purview make that straightforward.

Gmail’s strength is search and filtering. Its spam and phishing detection is excellent, the interface is clean, and conversation threading is hard to beat. Smaller teams often find Gmail simply gets out of the way. Either way, email is your single biggest attack surface — we cover that in our guide to business email security and BEC, and the controls matter more than the brand.

Storage: OneDrive/SharePoint vs Drive

Microsoft splits storage into OneDrive (your personal files) and SharePoint (team document libraries). Done well, SharePoint is a proper intranet and document-management system with versioning, metadata and permissions. Done badly, it’s a sprawl of sites nobody can navigate. It rewards structure.

Google Drive with Shared Drives is more intuitive out of the box. Files live where you’d expect, sharing is a couple of clicks, and there’s less to misconfigure. For a business that just wants files in folders without a SharePoint information-architecture project, Drive is the gentler path.

Meetings: Teams vs Meet and Chat

Teams is the centre of gravity in the Microsoft world — meetings, calls, persistent chat, channels and an app platform all in one. For organisations already on Microsoft, that integration is a real advantage; for ones that aren’t, Teams can feel like a lot. Plenty of people find it heavy.

Google Meet and Google Chat are deliberately lighter. Meet is reliable, browser-based and quick to join with no client to install. If your meetings are mostly external and you value “click the link and you’re in”, Meet’s simplicity is a genuine plus. Microsoft’s edge shows up in internal collaboration depth, calling features and telephony integration.

Identity, admin and security

This is where Microsoft pulls ahead for businesses that need it. Microsoft Entra ID (the identity platform formerly known as Azure AD) offers some of the most granular access controls available — you can require multi-factor authentication only from unmanaged devices, block sign-ins from outside Australia, or enforce compliant-device checks. We walk through this in our piece on conditional access policies in Microsoft 365. Defender and Purview add threat protection and data-loss prevention that map neatly onto frameworks like the Essential Eight.

Google’s admin console is more approachable. Fewer settings means less to get wrong, which for a small team without dedicated IT is a real benefit. Google’s identity and security are strong — context-aware access and solid MFA — but Microsoft’s controls go deeper for complex, regulated or hybrid environments where on-premises Active Directory is still in the mix.

Compliance and data residency

For Australian businesses bound by the Privacy Act and the OAIC’s Notifiable Data Breaches scheme, data residency and auditability matter. Microsoft offers Australian data centres for core data at rest and gives detailed control over retention, legal hold and audit logging through Purview — useful for sectors under AHPRA, ASIC or similar oversight.

Google Workspace provides regional storage options and strong compliance certifications, though some processing still happens across its global infrastructure. For most SMEs that’s perfectly acceptable. For a healthcare practice or a firm with strict data-handling obligations, Microsoft’s granular controls usually make the compliance conversation easier — see our notes on healthcare IT and OAIC obligations.

Migration effort

Moving platforms is rarely trivial. Email migrates reasonably well in both directions, but the friction lives in the details: shared mailboxes, calendar permissions, distribution lists, and re-training people on a new interface. Document migration is messier — Google formats don’t always survive a clean trip into Office, and complex Excel or SharePoint structures don’t always land neatly in Sheets and Drive.

The practical rule is to migrate once, deliberately, and stay put. Bouncing between platforms because of a price tweak costs far more in lost time than it saves. Whichever way you go, plan the cutover properly and run the two systems in parallel briefly so nothing falls through the cracks.

A Melbourne example

A construction firm in Box Hill we work with came to us split down the middle — the site teams lived in Gmail on their phones, while the office ran Excel-heavy estimating and project schedules that Sheets simply couldn’t handle. They’d been arguing about it for a year. We standardised them on Microsoft 365 because the desktop Office dependency was non-negotiable for their estimators, then used Teams to pull the field and office staff onto one platform. Had their work been browser-only, we’d have recommended Google and meant it.

That’s the point. TechAssist is a Melbourne-based MSP founded in 2014 with 13 Australian-employed engineers, and most of our client base runs Microsoft because that’s where desktop-heavy, compliance-driven Australian businesses tend to land. But the right answer is the one that fits how your people actually work, not the one your MSP is most comfortable supporting.

Frequently asked questions

Is Microsoft 365 more secure than Google Workspace?

Neither is inherently more secure — both are mature, well-defended platforms. The difference is control depth. Microsoft Entra ID and Defender offer more granular configuration, which helps in regulated or complex environments. Google’s simpler model means fewer settings to misconfigure, which suits smaller teams. Security comes from how you configure either platform, not the logo.

Can I run both Microsoft 365 and Google Workspace?

You can, and some businesses do — for example, Microsoft for email and Office, Google for a specific cloud tool. But running both means two sets of licences, two admin consoles and two security surfaces to manage. For most SMEs the overhead outweighs the benefit. Pick one as your primary platform.

Which is cheaper for a small Australian business?

Entry tiers are close — Microsoft 365 Business Basic and Google Business Starter sit within a few dollars of each other per user per month. The bigger cost is fit: paying for desktop Office you never use, or wrestling with Sheets when you need real Excel, costs far more than the licence-price gap.

How hard is it to migrate from Google to Microsoft?

Email migrates fairly cleanly; documents and shared-drive structures are where the work lives. Expect format conversion, permission rebuilding and user re-training. With a planned cutover and a short parallel-run period it’s very manageable — the mistake is doing it ad hoc without a migration plan.

Getting the decision right

If your business is lean, cloud-native and browser-first, Google Workspace is a strong, often better choice — and we’ll tell you so. If you’re desktop-heavy, running a Windows fleet, or carrying real compliance obligations, Microsoft 365 usually wins, and it’s where our Microsoft 365 support is built to add the most value with security and identity configured properly rather than left on defaults.

Not sure which way to jump? Get in touch and we’ll look at how your team actually works before recommending anything. No pressure to switch, and an honest answer either way.