The question usually arrives after a phishing email lands or an insurer sends a questionnaire, and the honest answer is a reading, not a yes or no. This checklist is the reading worth taking for each customer, grouped in the order worth taking it: identity before mail, mail before apps, evidence at the end. It assumes nothing beyond admin access to the customer's tenant and a DNS lookup tool.
Identity first
Almost everything else on this list can be undone by one unprotected admin account, so start here.
- Check 2-Step Verification coverage, and check admins before anyone else. Aim for a named list of who is not enrolled rather than a percentage: percentages hide the one account that matters.
- Count the super admins. Decide what the right number is for this customer before you look, then treat any difference as a finding to explain rather than a fact to accept.
- Check whether daily work happens in super-admin accounts. Day-to-day email and documents belong in an ordinary account: the super-admin account is for administration, signed into when needed.
- Review recovery options on admin accounts: whoever controls a recovery address or phone number can end up controlling the account. Confirm each one still points at the right person.
Mail exposure
Mail settings are where quiet compromise lives: nothing looks broken, and messages still arrive.
- List automatic forwarding to external addresses, mailbox by mailbox. Users set forwards up for convenience and forget them; attackers set them up to keep reading after a password reset. Every external forward needs an owner who can say why it exists.
- Look for delegates you cannot explain. Delegation is easy to grant and easy to forget, and a forgotten delegate is standing access to the mailbox.
- Review send-as addresses and aliases for entries nobody recognises: stale ones let mail leave under a name nobody is watching.
- Decide whether legacy IMAP and POP access is still needed anywhere. Keep older protocols only where a real dependency exists, and write down what that dependency is.
Forwarding deserves a deeper pass than one meeting allows: the Gmail forwarding audit guide covers it end to end.
Third-party access
- Review which third-party apps hold OAuth grants into the customer's Workspace, starting with anything that can reach mail or files.
- For each app with broad access, ask three questions: who uses it, for what, and when it was last needed. Remove grants nobody can vouch for.
- Treat unused apps as findings even when they look harmless: an unused grant is risk with no offsetting benefit.
- Give domain-wide delegation its own pass. It is a separate, customer-approved grant made at domain level rather than by an individual user, so an app can hold it without any user remembering a consent screen. The domain-wide delegation guide explains what to look for.
Sharing and data
- Check the external sharing defaults for Drive. Decide what this customer's policy should be first, then compare the setting to the policy: a default that is right for one business is wrong for another.
- Look at what is shared broadly today: files available to anyone with the link, and files shared outside the domain, are worth a named owner's confirmation.
- Establish who owns what before people leave. Ownership questions are cheap to answer while the owner still works there and expensive afterwards: pair this check with a proper leaver process, as set out in the offboarding checklist.
The domain itself
- Check that SPF, DKIM and DMARC records exist for every domain that sends mail, secondary domains included.
- Check alignment as well as presence: a record can exist and still not cover the services that actually send on the customer's behalf. Use a reputable checker rather than reading records by eye, and re-check after any change of mail provider or marketing platform.
- Resist asserting from memory what any record must contain. The right policy depends on what legitimately sends mail for this customer: list those senders first, and let the records follow from the list.
Evidence and follow-up
- Write findings down per customer, and date every entry. An undated finding cannot show improvement or decay, and reviews compound when each one starts from the last one's notes.
- Record what you decided not to fix as well as what you fixed: a known, accepted risk is a decision, and an unrecorded one is a surprise waiting for an incident.
- Agree what gets fixed by when, with a named owner, before the review meeting ends. A list of findings without owners and dates is a mood, not a plan.
A review is a point-in-time reading, not a property of the customer: settings drift, staff change and new apps arrive the week after you leave. Schedule the re-check before you leave the meeting, while the findings are fresh and the calendar is open.
How CrossTenant helps
This checklist works with nothing but admin access. CrossTenant, a multi-tenant console for MSPs running Google Workspace, exists to make it repeatable across a whole book of customers. It scores each customer's security posture and sorts the fleet worst-first, so the customer who most needs this review sits at the top of the page. Checks aligned to CIS Google Workspace Foundations guidance return per-control verdicts with the evidence behind each one, per-domain SPF, DKIM and DMARC checks read the live records for you, and findings export as branded PDF reports under your own logo: the evidence step above becomes a by-product of the review rather than an extra job. Read how MSPs run security reviews with it, or see the security posture feature in detail.
Field guides
Run the review across your whole book
CrossTenant runs these checks across every tenant you manage: read-only if you want, guided consent that names every scope, and no Workspace content stored at rest. Get in touch and run them against your own tenant first.