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.