Google Workspace security baseline for small teams

A ten-person Google Workspace tenant can lose the same mail, files, and customer data as a thousand-person tenant. It just has fewer people available to notice the compromised account.

The baseline is not a pile of expensive security products. It is enforced 2-Step Verification, administrators who do not live in Super Admin, conservative sharing defaults, control over third-party applications, and an offboarding process that works on demand. Google’s own small-business security checklist focuses on the same fundamentals.

Admin-console paths and licensed features change, so confirm the options available in your Workspace edition. The order of work below is more durable than any screenshot.

1. Enforce 2-Step Verification

“Users can enroll” is not enforcement. Set an enrollment period, communicate it, and then require 2-Step Verification (2SV) for the organizational units or groups in scope.

For administrators, owners, finance, HR, and anyone with sensitive client data, prefer passkeys or hardware security keys. Google calls security keys its strongest 2SV method and discourages SMS because it depends on carrier networks. Its current 2SV administrator guidance also notes that Google enforces 2SV for administrator accounts.

For a small rollout:

1. Create a pilot group and enroll its users first.
2. Give users at least two viable recovery methods appropriate to policy.
3. Put administrators and high-impact users on phishing-resistant methods.
4. Enforce 2SV for everyone else after the help-desk procedure is tested.
5. Review exceptions; do not leave a permanent password-only group called Temporary.

Keep two individually assigned administrator accounts capable of recovering the tenant. Do not share one recovery phone or one generic admin login between three people.

2. Make Super Admin rare and boring

Google’s administrator-account best practices recommend multiple individually managed Super Admin accounts, separate daily-use accounts, and narrower delegated roles for routine work.

That translates cleanly to an SMB:

• Each administrator gets an identifiable admin account; no shared admin@ credentials.
• Email, browsing, and document work happen from a non-admin account.
• Super Admin is used only for the tasks that require it, then signed out.
• Help-desk staff get specific user-management privileges, not the keys to the whole tenant.
• Admin log events and recovery details are reviewed on a schedule.

Do not make the owner a permanent Super Admin just because they pay the bill. Give them a documented emergency path and use least privilege for daily activity.

3. Decide how Drive may leave the company

External collaboration is usually necessary. Public-by-link sharing is usually not.

In Drive and Docs sharing settings, choose deliberately whether users can share outside the organization, whether only allowlisted domains are permitted, and whether content may be published publicly. Google’s Drive sharing controls can be applied differently by organizational unit or configuration group, so a client-services team does not need the same defaults as payroll.

A practical starting point is:

• Named external recipients allowed where the business needs them
• “Anyone with the link” and web publishing restricted by default
• Warnings enabled for external sharing
• Sensitive departments placed in a tighter group or organizational unit
• A quarterly review of externally shared files and shared-drive membership

Use Shared Drives for team-owned operational material where the edition supports them. Google explains that Shared Drive files belong to the team, so they persist when the person who created them leaves. That is a cleaner ownership model than critical procedures scattered across individual My Drives.

4. Control OAuth and Marketplace applications

“Sign in with Google” can grant an application access to Gmail, Calendar, Drive, or other company data. A familiar login button does not make the application approved.

Under API controls, review both configured applications and applications that have actually accessed Workspace data. Google’s app-access documentation shows the requested services and OAuth scopes and lets administrators mark applications Trusted, Limited, restricted to specific data, or Blocked.

For a small team:

• Block or limit unconfigured third-party applications rather than allowing every consent request silently.
• Give employees a simple way to request a legitimate application.
• Record an owner and business purpose for every trusted application.
• Review high-risk Gmail, Drive, and Calendar scopes at least quarterly.
• Remove applications with no current owner or active users.

This is separate from SSO. SSO controls how a person signs in; OAuth consent controls what an application may do with their data.

5. Put a minimum device boundary in place

If company mail is on a phone, decide what the company can require and remove. “BYOD with nothing” is not a policy.

Google says basic mobile management is available across common Workspace editions and can enforce basic device requirements, show devices, create activity alerts, and wipe the work account from a lost device. Advanced management or a third-party MDM is appropriate when you need stronger application, compliance, inventory, or company-owned-device controls.

Write the human policy alongside the setting: supported devices, minimum OS versions, screen-lock requirements, what happens on a lost phone, and whether IT may wipe only work data or the whole device. Users should know the answer before enrollment.

6. Route alerts to a person who will read them

The alert center is useful only if someone owns it. Configure recipients for suspicious logins, new administrators, user suspension, and important configuration changes. Review admin log events after every unexpected privilege or security-setting change.

Google’s suspicious-login alert guidance recommends confirming the activity with the user, resetting the password when the sign-in cannot be validated, and using 2SV. A suspicious alert is a prompt to investigate, not proof that the person traveled or that an attacker succeeded.

Pair these settings with mail-domain authentication and sensible filtering. Our spam-filter tuning guide covers the operational balance between protection and permanent allow-list holes.

7. Test offboarding instead of admiring the checklist

Pick a test account and run the process: suspend access, terminate sessions, remove group and Shared Drive membership, revoke application access, transfer individually owned business files, and deal with managed devices. The full sequence is in same-day offboarding.

The test should reveal who receives the HR signal, who owns the user’s data, and how quickly a local-password SaaS account gets missed. Fix the process before a real departure makes the timeline urgent.

A defensible 30-day baseline

At the end of the first month, you should be able to prove:

• 2SV is enforced and exceptions are documented
• Super Admin accounts are individual, protected, and not used for daily work
• External Drive sharing has an intentional default
• Third-party OAuth applications have owners and approved access
• Mobile devices have at least a basic management boundary
• Security alerts reach a named person
• One offboarding test completed successfully

Bottom line

Google Workspace security for a small team is mostly disciplined administration. Enforce strong sign-in, keep Super Admin separate, restrict public sharing, review OAuth access, manage devices to the level the data requires, and prove that an account can be removed cleanly. Get those controls working before buying another dashboard.