The Google Workspace Security Audit Checklist That Catches the Findings Your IT Vendor Missed
Alexander Sverdlov
Security Analyst
Key Takeaways
- Most Google Workspace tenants we audit have five categories of finding in common, and four of those five cost nothing to fix once you know where to look
- The single highest-impact lever is Context-Aware Access combined with phishing-resistant 2-step verification. Together they neutralize the most common 2026 attack pattern: session token theft after a successful phishing event
- "Anyone with the link" sharing in Drive is the finding auditors flag most often, and it is the easiest one to triage with the new Drive shared link inventory report
- Marketplace apps with OAuth scope access to Mail, Drive, or Calendar are the silent supply-chain vector. A tenant with more than 25 third-party OAuth grants is statistically at higher risk of a data-leak event in the next 12 months
- An honest Google Workspace audit for a 30 to 150 person company costs $4,500 to $14,000 and ships in 8 to 14 business days. The same audit done by the in-house IT generalist tends to miss 6 of the 14 domains
- Three controls (advanced 2SV, external sharing restriction, marketplace allowlist) close roughly 70 percent of real-world findings. The other 11 domains catch the long tail that turns a "low risk" tenant into a real incident
A CFO at a 64-person logistics SaaS forwarded us a one-line email from her largest prospect in February. The subject line read "Tenant security evidence requested." The body asked for a current Google Workspace security review, signed within the last 12 months, by a party independent of the company's IT vendor. The deal was $1.1M in year one. The renewal cycle on the prospect's incumbent provider closed in 21 business days.
Her IT vendor sent back a one-page memo. Microsoft 365 grade A, Google Workspace grade A, no findings of concern. The vendor had been her managed-service provider for four years. She had no reason to doubt them.
We pulled the same tenant on a Wednesday afternoon. Sixteen findings in three hours. Two of them were the kind of finding that ends a deal if a careful procurement reviewer reads them out loud: a marketplace app with full Drive scope last used in 2022 still mapped to a former CTO whose account had been "suspended" but not deleted, and 3,847 Drive items shared with the link-anyone setting, of which 41 were folders containing customer payment records.
She closed the deal on Day 18. Not because the tenant was perfect on Day 1, but because the audit report named every finding, ranked it, gave the prospect a 30-day remediation timeline, and was signed by an independent party. That report is the artifact this checklist exists to produce. Below is the long version of what is inside it.
Domain 1
What a Google Workspace Audit Actually Examines
Before we walk through the controls, agree on what a Google Workspace audit is. It is not a vulnerability scan. It is not the Secure Score number in the admin console. It is not a screenshot of "2-Step Verification: On" delivered to a procurement reviewer. It is a structured review of 14 control domains, each one mapped to a real misuse pattern we have seen turn into a security incident in the last 18 months.
The 14 domains below are not arbitrary. They come from 31 real engagements run on Workspace tenants between 14 and 410 seats over the last 18 months, cross-checked against the CIS Google Workspace Benchmark v1.4, the Google Workspace Security Best Practices guide updated this year, and the controls a SOC 2 Type 2 auditor will actually ask about during fieldwork. If you build your audit around these 14, you will hit roughly 95 percent of what an experienced reviewer will flag.
A note on what the audit is not. It is not a Google Workspace re-implementation. We do not rewrite your organizational units, replatform your groups, or replace your IT vendor. The output is a findings register and a remediation plan that your team or your MSP can execute. The audit takes a snapshot. The remediation is yours to schedule.
Domain 2
Identity: The Five Checks That Close Most Real Incidents
Identity findings account for roughly 28 percent of all findings we record. They are also the cheapest to fix and the highest in real-world impact. The single most common 2026 attack pattern against a Workspace tenant starts with a successful phishing email that captures a valid session token. Standard 2-step verification (SMS or TOTP) does not stop this attack. Phishing-resistant 2SV (security keys or device-bound passkeys) does.
2.1 Admin accounts
Every super admin account is a single failure away from total tenant compromise. The control we look for: every super admin uses a dedicated, named account that does no daily work and is protected by two hardware security keys. No service email, no calendar, no Drive use. We see this implemented correctly in roughly 1 in 5 audited tenants.
2.2 Phishing-resistant 2-step verification
The Google Workspace control is "Allow only security keys" under Authentication. Set it for the super admin OU at minimum. Apply it organization-wide if your fleet supports it. In 2026, SMS-based 2SV is functionally end-of-life for any account with admin scope.
2.3 SSO and SAML
If you run Okta, Entra, Google as IdP, or JumpCloud, your Workspace SSO setup is the single point that decides who gets in. We check SAML response signing, session lifetime, NameID format, and the presence of a non-SSO emergency admin path. The most common finding here is "SSO enforced but a non-SSO admin account exists that has not logged in for 11 months." That account is a back door.
2.4 Password policy
Long enough (we recommend 14 character minimum where SSO is not enforced), not rotated on a calendar (rotation on suspicion only, per NIST 800-63B), and checked against breach lists. Workspace does this natively. Enable it.
2.5 Session controls
The session timeout for Google services should be 8 hours for sensitive OUs and 16 hours for general staff. The default is 14 days, which means a stolen session token is valid for two weeks. We change this on every engagement and have never had a user complaint that survived a week of normal use.
Common finding: Super admins protected by Google Authenticator (TOTP) only. This passes a casual review but fails against AiTM phishing. The fix is a one-hour project: order two YubiKey 5C NFC per admin, enroll them, set the OU to "Allow only security keys."
Domain 3
Drive Sharing: The Quiet Compliance Killer
Drive sharing is the finding that scares procurement reviewers the most, because it is the easiest one to verify from the outside. The reviewer asks for a sample of files shared with "anyone with the link." If you cannot answer how many you have, the audit is over.
The good news: the new Workspace Drive shared link report gives you a tenant-wide inventory of every shared-anywhere link, who owns it, when it was last accessed, and what is inside. The bad news: most admins have never opened it. Of the 31 tenants we have audited in the last 18 months, the median count of "anyone with the link" Drive items at audit start was 1,847. The maximum was 18,402.
The fix is not to set "internal only" on every OU on Monday morning. That breaks the business by Thursday. The fix is a phased migration: inventory, triage, restrict-by-default for new shares, sweep the legacy backlog by category, then enforce.
The DLP layer is what catches the next leak. Configure Workspace DLP for at minimum: payment card numbers, US SSN, EU national ID patterns, and the words "confidential" or "do not share" in a document title. Action: warn on external share, block on link-anyone. Build it once, audit it quarterly.
Domain 4
Gmail Hardening and SPF, DKIM, DMARC
Two questions tell you 80 percent of what you need to know about a Workspace tenant's mail security. Is DMARC at policy reject? Is Advanced Phishing and Malware Protection turned on for every OU?
The DMARC question is the easier one. Most tenants we audit are at p=none, which is functionally "log only, do nothing." The reason is usually political: someone is afraid of bouncing a legitimate sending source they have not yet inventoried. The fix is a 6 to 10 week migration: start at p=none with reporting, inventory sending sources (Workspace, your CRM, your marketing platform, your billing system, the developer who set up a Mailgun account in 2022), align them via SPF and DKIM, ramp to p=quarantine for 30 days, then p=reject. We have completed this on 23 of 31 audited tenants without a single legitimate bounce.
Advanced Phishing and Malware Protection is a Workspace setting. Turn it on. Set actions to "move to spam" for both inbound spoofing and impersonation. Add the executive name list for "protect against impersonation in employees." This is a 15-minute project that catches the single most common BEC vector.
| Gmail control | What it costs | Impact |
|---|---|---|
| DMARC at p=reject with aligned SPF/DKIM | 8 to 24 hours of admin time | Eliminates direct domain spoofing |
| Advanced Phishing and Malware Protection | 15 minutes of admin time | Catches roughly 60% of BEC attempts |
| Confidential mode and S/MIME for executive OU | 2 hours of admin time | Reduces accidental forwarding of sensitive threads |
| Pre-delivery URL detonation (default in business plans) | Verify on, not extra spend | Catches malicious links missed by static scanners |
| Group-based moderation for high-risk distribution lists | 1 hour per protected group | Stops external-mail-to-allhands attacks |
Domain 5
Marketplace OAuth Apps: The Supply-Chain Vector Nobody Watches
Open Admin Console, Security, API controls, Domain-wide delegation. Read the list. Every line is a third-party app that has been granted ongoing access to your tenant's data. We have audited tenants with 4 entries on this list and tenants with 137. The median is 22.
Now go to App access control. Read the list of apps with restricted scopes. Read the "Trusted, Limited, Blocked" status of each one. In about 70 percent of audited tenants, the access control mode is "Unrestricted," which means any user can grant any third-party app any scope at any time, with no admin review.
The single most common high-severity finding in the 18-month engagement window was a marketplace OAuth app last actively used by an employee who left the company more than 12 months ago, with read-write scope to Drive or Mail, and a vendor company that had since been acquired, renamed, or disappeared. The data egress is invisible. The data is gone before you notice.
The fix is a 5-step process: inventory current third-party OAuth grants, classify each one as Required for business / Maybe needed / Unknown, switch access control to "Restricted with allowlist," allowlist the Required and Maybe Needed apps with the smallest scope they can run on, revoke everything else, and audit quarterly.
Real audit example: A 90-person Workspace tenant had 71 marketplace apps with active Drive scope. After triage, 19 were business-required, 7 were "maybe needed" (resolved by asking the owner), and 45 were never going to be used again. Revoking the 45 took two hours. The "active scope, dormant user" subset of the 45 was the highest-risk finding in the entire audit.
Domain 6
Endpoints, Context-Aware Access, and the 2026 Zero-Trust Workflow
Workspace endpoint management is free at the basic tier and a real control at the advanced tier. The check we run: are mobile devices wiping work data only on offboarding, or are they wiping personal photos with it? The most common misconfiguration is "Advanced management" pushed to personal Android devices without a documented BYOD policy, which has produced two awkward HR conversations in our engagement history.
Context-Aware Access is the real 2026 control. It lets you say things like "Drive web access only from a device with screen lock under 5 minutes, OS version current, encryption on, and a corporate IP or VPN." The configuration is fiddly. The payoff is the single largest single control improvement we measure in audited tenants: a properly tuned Context-Aware Access policy reduces the attack surface for stolen session tokens by roughly 80 percent compared to a baseline of "2SV on, no posture check."
We do not turn on Context-Aware Access on Day 1 of an engagement. It is a 30 to 45 day project for a 60-person tenant: define posture conditions, build the policy on a pilot OU, observe block events in dry-run mode for 14 days, tune, expand. Done correctly, it lands without user complaints. Done wrong, it locks out the CEO at 22:40 on a Sunday.
Domain 7
Audit Logging, Alerts, and the Six Findings That Hide in Plain Sight
Google Workspace generates more than 30 categories of audit logs. The default Alert Center surfaces about 12 alerts out of the box. Most tenants we audit have never customized the alert rules and have nobody assigned to review them. The result is that real signals (a user logging in from a hosting-provider IP at 3am, a sudden surge of OAuth grants, a flood of external shares from a single account) sit unread in the admin console for weeks.
The audit checks here are unglamorous and high impact. Is the Alert Center rules list customized? Is at least one human assigned as alert recipient and reading them? Are audit logs being exported to a long-term store (BigQuery is free up to the always-free tier for most SMB volumes)? Is the data retention long enough to satisfy your contracts (90 days is the minimum we see in customer agreements, 12 months is the median, 7 years is the regulated maximum we have seen in healthcare and finance)?
The six findings that hide in plain sight: dormant super admin accounts with active hardware keys, OAuth grants to unverified apps, login events from impossible-travel IP pairs, mass external file downloads, mailbox auto-forward rules created by the user (a classic compromise indicator), and the disabled-but-not-deleted user pattern (an account that still owns Drive items and still appears in shared mailbox ACLs because the admin only suspended it).
| Alert | What it catches | Action when fired |
|---|---|---|
| Suspicious login | Impossible travel, new device, anonymous proxy | Suspend session, force re-auth, contact user out-of-band |
| Mass external file downloads | Insider exfiltration, compromised account | Open ticket, pull Drive access logs for the user |
| Auto-forward rule created | Mailbox compromise, BEC reconnaissance | Review the rule, talk to the user, force password reset and 2SV re-enroll |
| OAuth grant to unverified app | Phishing-as-a-service consent fraud | Revoke the grant, audit the user's sessions, review marketplace allowlist |
| Drive DLP rule triggered | Regulated data shared externally | Review the share, confirm with owner, evaluate breach notification clock |
Domain 8
What an Honest Audit Actually Costs and Takes
Independent Google Workspace audits sit in three honest price bands depending on company size and the formality of the report. Below is the engagement model we run and what each band buys, drawn from 31 engagements over the last 18 months.
The remediation phase is separate and depends on what we find. The median remediation budget across the 31 engagements was $3,200 for foundation, $8,400 for standard, and $19,600 for regulated. The single largest item, in nearly every case, was the time to triage and migrate legacy Drive shares. That work is unglamorous, takes a person 25 to 80 hours, and is the thing that closes the most procurement objections.
Domain 9
A 30-Day Plan If You Are Starting Today
If the audit report lands on your desk on Day 0, this is the plan we use to close roughly 70 percent of the typical findings within 30 days. The remaining 30 percent is the long-tail OU work that is genuinely a quarter to execute. Most procurement reviewers accept a 30-day plan with a named owner and a written attestation that the rest is in flight.
FAQ
Six Questions We Get on Every Audit Call
Is a Workspace audit a substitute for SOC 2 or ISO 27001?
No. A Workspace audit is a control review on a single platform. SOC 2 and ISO 27001 are program audits across your whole company. A Workspace audit is what closes most one-off procurement questions and gives your SOC 2 readiness a 6 to 10 week head start. It is not, by itself, a SOC 2 report.
Our IT vendor says they already audit our tenant quarterly. Why pay for another one?
Two reasons procurement teams ask for an independent review. First, your IT vendor cannot independently audit their own configuration work; that is a conflict of interest that careful procurement reviewers catch. Second, in 27 of 31 audited tenants in the last 18 months, the in-house IT vendor's quarterly review was either missing 6 of the 14 domains entirely or was a screenshot of the Secure Score number with no underlying analysis. Both are common. Both fail an enterprise review.
We use Microsoft 365 for some teams and Google Workspace for others. Do we need two audits?
Yes, but the report can be unified. The control domains map closely across both platforms (identity, sharing, mail, OAuth, endpoints, audit logging) but the specific settings are different. We ship one combined report when both platforms are in scope. The findings register flags which platform each item lives on.
How much access do you need to the tenant?
A read-only super admin scope is the cleanest. Where the customer's policy does not allow that, a scoped service account with permission to read the Reports API, Admin SDK, and Drive sharing report covers about 85 percent of the audit. We document the access requested, the time it is open, and revoke at the end of the engagement.
Will the audit cause user complaints?
The audit itself is invisible. The remediation work, done correctly, is also invisible. Done incorrectly (a hard switch to "no external sharing" on a Monday, or Context-Aware Access deployed without dry-run), it generates real complaints. The 30-day plan exists to avoid this. We have not generated a user complaint storm in the last 22 engagements where the customer let us drive the rollout cadence.
How often should we re-audit?
Annually is the floor. Twice a year is the right cadence for regulated industries (healthcare, finance, defense supply chain) and for any company that has had a material change in the last 12 months (acquisition, layoff round, new product line, new regulated customer). After a material incident, an audit should be on the remediation calendar inside 30 days.
Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.