Google Workspace Security Checklist for a Small Business

Your Google Workspace security checklist already exists, and Google wrote it. There is one for businesses with 1 to 100 users, and it is short on purpose: fourteen items, many of them a setting you change once in the Admin console. This page walks that list in plain words, says which items are one click and which need a decision from you, and marks the settings that can lock your own staff out of their accounts if you rush them.

The item that needs a decision is 2-Step Verification, and Google does not ask a business your size to force it on everybody. Its words on the small-business page: “We recommend that everyone in your business use 2SV, but it’s especially important for admins and users who work with sensitive data such as financial records and employee information. You should enforce 2SV for admins and key users.” Use is the recommendation for everyone. Enforce is the requirement, and it is scoped to admins and key users. Those are two different instructions, and the gap between them is where most of the thinking in this checklist sits.

Everything below is from Google’s own admin help, and Google dates its own pages. Every security page quoted here carries the line “Last updated 2026-08-26 UTC” at its foot. The edition comparison table used further down is stamped 2026-08-14. Check every path against your own Admin console rather than against this page.

The short version of Google’s small-business Workspace checklist, if you are doing this today.

• Work Google’s list in its own order. The account items come first: they stop somebody else signing in as you.
• Turn 2-Step Verification on for admins first, then decide separately who else it is enforced for.
• Generate and print backup codes before you enforce anything, not after.
• The thing that goes wrong: enforcing 2-Step Verification on people who have not enrolled yet, or blocking phone codes while your staff are still using them. Both lock people out on the day the setting takes effect.

Start with Google’s own list, because it is written for a business your size

Google keeps two security checklists, not one, and its index page opens by telling you to pick: “Choose your business size to get started.”

The small-business one covers 1 to 100 users, and it says in its own words why it is short: “If you have a very small business (1-20 users) or small business (21-100 users), you probably don’t have a dedicated IT administrator, so we’ll keep the list short!”

The other one is for 100 users and up. It opens by naming a different reader: “IT administrators for medium and large businesses should follow these security best practices to help strengthen the security and privacy of company data.” Google’s index page adds that those practices “may require using dedicated IT resources”. So a three-person company reading the long list is reading somebody else’s homework.

There is one exception, and it decides which of the two lists you use. Google’s small-business page ends with it: “Your business might have fewer than 10 people but have the information security requirements of a much larger company. For example, small investment and financial planning businesses, and any business that works with health information might have special regulatory, privacy, and security requirements.” If that is your business, Google points you at the 100-plus list instead, and that list assumes somebody whose job this is.

The 14 items, in Google’s own two groups

Google splits the list into account items and service items. The account items apply whatever you use Workspace for. The service items apply if you use Gmail, Calendar, Drive and Docs, which for most small businesses means all of them.

Five of the six service items are an admin changing one setting in the console. The sixth, SPF, is a change at your domain instead. The eight account items are mostly habits rather than switches, which is why a short list is not the same as a quick one.

Who do you actually enforce 2-Step Verification for?

Admins and key users, in Google’s words, and you decide who counts as a key user. Everyone else is a recommendation, not a requirement.

2-Step Verification means a password plus one more thing, usually your phone or a small hardware key. Google’s own explanation is that it “requires users to verify their identity through something they know (such as a password) plus something they have (such as a physical key or access code) to gain access”.

Google’s two checklists give two different answers, and the difference is your business size.

The small-business list scopes it. “We recommend that everyone in your business use 2SV, but it’s especially important for admins and users who work with sensitive data such as financial records and employee information. You should enforce 2SV for admins and key users.”

The 100-plus list does not. Its item reads “Require 2-Step Verification for users”, with no admins-only qualifier, and it adds a second item on top: “Enforce security keys, at least for admins and other high-value accounts.”

So the question Google is really asking is who your key users are. Anyone who touches payroll, invoicing, staff records or the bank is one. In a company of five where the owner does the invoicing and the office manager does the payroll, that is most of the room, and enforcing it for everyone is the simpler policy and the same policy. In a company of eighty with a warehouse team who only ever open a shared roster, it is a real choice, and enforcing it on the warehouse is a support problem you have chosen to buy.

Our advice to our own clients is to enforce it for every admin on day one, without debate, and to treat everyone else as a rollout with a date on it rather than a switch you flip on a Friday. The next section is why.

Enforcing it badly is how small businesses lock themselves out

This is the part of the checklist that Google puts a lockout warning on, and none of it is hidden. It is all on Google’s deployment page, which is where the enforcement setting lives.

The setting sits in the Admin console under Menu, then Security, then Authentication, then 2-step verification. Google notes on that page: “You must be signed in as a super administrator for this task.”

Enrol first, enforce second. Google’s own step 5 opens with the instruction: “Before you begin: Make sure users are enrolled in 2SV.” Enforcement does not enrol anybody. It refuses entry to anybody who has not enrolled.

Two of the settings on that page are traps if you skim them.

The first is the method restriction. One option is “Any except verification codes via text, phone call”, and it looks like the right call, because it pushes people off phone codes and towards security keys, which Google calls the most secure form of 2SV. Google’s warning underneath it is blunt: “Users who use texts and phone calls to verify will be locked out of their accounts.” Right setting, wrong order. Move people onto a key or an authenticator app first, then restrict the method.

The second is the strictest option, “Only security key”. Google’s note: “If 2SV is enforced in Only security key mode, users cannot generate their own backup verification codes. An admin must provide these codes to the user.” A one-person business that enforces key-only on itself and then loses the key has removed its own way back in. Google also records that this option now covers passkeys, which are the same idea stored on a phone or laptop rather than on a separate fob: “Since the addition of passkeys, the Only security key option now supports both security keys and passkeys as a 2SV method. Passkeys and security keys both have the same level of phishing protection.”

The same page also gives you two ways to soften the landing. There is a new-user grace period, where you “select a time frame from 1 day to 6 months” and during it “users can sign in with just their passwords”, which stops a new hire being locked out on their first morning. And if you set enforcement by date rather than immediately, Google warns that the date is approximate: “When using the On from date option, enforcement will start within 24-48 hours of the chosen date. If you want a precise enforcement start time, use the On option.”

There is an escape hatch for the person you missed, and Google names it while telling you not to lean on it: “You can give users extra time to enroll by adding them to a group where 2SV isn’t enforced. While this workaround allows users to sign in, it’s not recommended as a standard practice.”

Backup codes are the item on the checklist that exists for exactly this. Generate and print them before enforcement day.

Google is going to require this of your admins anyway

Doing it now is not work Google is about to make pointless. It is the same setting Google has said it will eventually require, on a clock you do not control.

Google’s page on the subject opens: “To better protect your organization’s information, Google will soon require all administrator accounts to have 2-Step Verification (2SV) enabled.” Its instruction is direct: “You should turn on 2SV for the admin accounts in your organization before Google enforces it.”

Where that rollout has reached matters to you, so here is the whole of what Google says about it. “The enforcement will be rolled out gradually over the coming years. Enforcement is now being implemented for organizations with Workspace for Education, Workspace for Nonprofits, Cloud Identity, Android Enterprise, and organizations using a Workspace Enterprise edition with a third-party single sign-on (SSO) provider.” That is education, nonprofits, Cloud Identity, Android Enterprise, and Enterprise editions signing in through an outside identity provider. An ordinary Business Starter, Standard or Plus subscription is not among the org types Google lists there, as that page stood on 26 August 2026. Read it as a queue you are in but have not reached.

You get notice. “Super administrators can expect a notification roughly 90 days before enforcement takes effect. All other admins will be notified approximately 60 days prior, through email and mobile phone.”

Then, if an admin ignores it, Google publishes the ladder: “After 7 days, they will continue to receive reminders in the Admin console to enroll in 2SV. After 15 days, they will not be able to access Workspace apps on mobile devices until they enroll in 2SV. After 30 days, they will not be able to access web apps until they enroll in 2SV.”

If you are the only admin, read the next two sentences twice. “2SV enforcement is applied immediately when a user is made an admin.” And: “Admins subject to the Google-set 2SV enforcement policy cannot bypass it. If an admin cannot enable 2SV, the only solution is to remove their admin rights.” There is no exception for the owner.

The super admin items are the ones people skip

Three of the fourteen items are about the super administrator account, the one that can do anything in your Workspace. They read like paperwork, and they are the ones that decide how bad a bad day gets.

Have two super admins, held by two people. Google: “A business should have more than one super administrator account, each managed by a separate person. If your primary super admin account is lost or compromised, the backup super admin can perform critical tasks while the primary account is recovered.”

Do not use the super admin account for daily work. Google’s admin-account page asks for two accounts each, and gives the shape: “Give each super administrator 2 accounts: Their own super admin account and a separate account for daily activities.” Its examples are [email protected] beside [email protected]. The small-business list gives the reason: “Staying signed in to a super admin account when you aren’t performing specific administrative tasks can increase exposure to potential malicious activity.” The admin-account page also says not to share one admin login between people: “Otherwise, if multiple people use the same administrator account to sign in to the Admin console, such as [email protected], you can’t tell which administrator is responsible for specific activities in the audit log.” That only shows up on the day you need to know who changed something. Where a shared login exists because a shared address like accounts@ or support@ needs covering, there is a way to share an address without sharing a login.

The item that catches people out is not a Google setting at all. If a super admin cannot get back in by email or phone, and no second super admin is around to reset it, the way back is Google’s recovery process. Google asks identity questions about the account: the date it was created, the original sign-up email, the Google order number, the number of user accounts, the billing address, and the type and last four digits of the credit card. And then this: “Google also asks the admin to verify the DNS ownership of the domain, so the admin needs to have the credentials to edit the domain DNS settings with their registrar.”

So your domain registrar login is part of your Google Workspace recovery plan. If your domain was bought years ago by a web designer you no longer work with, that is the thing to fix this week.

Check which recovery setting you are on, because the default depends on when you signed up. Google states it plainly: “For most current and all new customers, super admin account recovery is off by default. If you’re an existing customer with fewer than 3 super admins or 500 users, the setting is on by default, to match previous behavior.” Two businesses side by side can have opposite defaults.

Google’s admin-account page adds a line each on two smaller items. Security keys are, in Google’s words, “small hardware devices that are used for second factor authentication” and “the most secure form of 2SV”, and Google asks admins to “enroll more than one security key for their admin account and store it in a safe place”. And admin email alerts will tell you about “suspicious sign-in attempts, compromised mobile devices, or changes by another admin”, and it is a setting rather than a service you have to buy.

The email item asks for SPF, and stops there

One item on the list is about the mail you send rather than the mail you receive. Google’s wording: “Sender Policy Framework (SPF) is an email security method to authorize legitimate email sent by users at your company. An SPF record identifies which mail servers are allowed to send email on behalf of your domain. If you don’t set up SPF for your domain, some messages could bounce or could be marked as spam.”

SPF is a line of text you add to your domain’s DNS settings, naming who is allowed to send email as you.

The checklist asks for SPF, and none of its fourteen items mentions DKIM or DMARC. Those are the other two records in the same family. Google is not quiet about them: its admin help carries a Set up DKIM page and a Set up DMARC page beside the SPF one, and the small-business checklist links to that whole section from its own sidebar. So they are off the list because the list is short by design, not because they do not apply to you. Our piece on why business email lands in spam covers all three, including how to read the bounce code Gmail sends back so you know which record is missing before you touch anything.

What is not on your list, and why

Several settings on Google’s own 100-plus checklist are not available on a Business edition at all. Chasing them is a way to look for a menu that is not in your console.

Google warns about this itself, at the top of the 100-plus checklist: “Note: Not all settings described here are available in all Google Workspace editions or Cloud Identity editions.”

Read against Google’s own Business edition comparison table, stamped 2026-08-14, that means:

• Context-Aware Access, which allows or blocks sign-ins based on the device, network or country somebody is coming from: not included on Business Starter, Standard or Plus.
• Advanced data exports: not included on any of the three. This one is on the comparison table rather than the checklist. The same table lists “Basic data exports”, included on all three, so the plain export is there and the advanced one is not.
• Client-side encryption, an extra layer of encryption where your organisation rather than Google holds the key: not included on any of the three.
• Google Vault for eDiscovery and information governance, which retains and searches your data for legal purposes: included on Business Plus only, not on Starter or Standard.

Which edition you are on is a decision of its own, and we have set out what Business Starter and Standard actually differ on separately.

One row on that table is a near miss. The table lists a row called “Vault log events” for all three Business editions, and that is an admin log entry about Vault activity, not Vault itself. So “you have Vault” and “you have Vault archiving” are not the same statement. Read the table row, not the product name.

The Advanced Protection Program is the other thing to leave alone unless you mean it. Google describes it as “intended to protect the highest-risk users”, and enrolling somebody has a side effect worth knowing about first: “By default, apps that require high-risk Gmail and Google Drive access are blocked. Exceptions are all Google apps, Apple native iOS apps, and the Mozilla Thunderbird mail client.” Enrolment also needs a fallback, because “you must select a backup sign-in method. This ensures you can securely access your account if your passkey or security key is lost or damaged.”

An admin can approve specific apps around that block. But switching it on across a small business, where somebody’s quoting tool or accounting add-on connects to Gmail or Drive, breaks working software on a Tuesday, for a protection Google says is intended for its highest-risk users.

Is this the same as a security audit?

No. They are different things, and the difference decides what you actually have to do.

A checklist is a list of settings you compare against your own console and change yourself. The word audit appears nowhere in Google’s fourteen small-business items or the text around them. Where Google does use it, it means something narrower and later: on the 100-plus list, reading the admin log to see “a history of every task performed in the Google Admin console, which admin performed the task, the date, and the IP address from which the admin signed in”, and reviewing what people with Vault access have been doing.

So for a business under 100 people, the honest answer is that you need this list and your own Admin console open, not an engagement. What a second pair of eyes adds is the part a list cannot: deciding who your key users are, working out whether your domain DNS is still reachable by somebody who works for you, and picking an enforcement date that does not land in your busiest week.

Where to start

Account items first, in Google’s order, and most of them are one setting each.

Then take the two that need a decision away from the console. Who counts as a key user in your business, and who else holds a super admin account and the domain DNS login. Neither is a setting.

Set the enforcement date last, once backup codes are printed and every admin is enrolled. If you would rather have somebody sit with you while you work through it, that is a conversation about your own setup, and it starts at our Google Workspace page.