Is Google Workspace SOC 2 Compliant?
Google Workspace holds a quarterly SOC 2 Type 2 report covering its infrastructure, but that report says nothing about how you've configured your tenant.
Security questionnaires have a way of flushing out every service in your stack. Google Workspace shows up near the top of almost every one — it's where your email lives, your documents, your calendar, often your entire productivity environment. The question that comes back is always some version of: "Is Google Workspace SOC 2 compliant?"
The short answer is yes. The longer answer explains what that actually covers and, more usefully, what it leaves squarely on your plate.
Google does hold a SOC 2 Type 2 report
Google issues SOC 2 Type 2 reports for both Google Cloud Platform and Google Workspace, and the program is one of the more disciplined in the industry. A few things are worth knowing up front.
Quarterly cadence. Where many vendors publish SOC 2 reports once or twice a year, Google issues them quarterly, with bridge letters available for the periods in between. That means the most recent report is rarely more than a few months old, which matters when a customer's security team asks how current your vendor coverage is.
Type 2 only. Google publishes only SOC 2 Type 2 reports, not Type 1. That's the right approach: Type 2 covers operating effectiveness over time, not just a snapshot that anyone can stage for a single day. The distinction between Type 1 and Type 2 matters both for your own audit and for evaluating what a vendor's report is actually proving.
Independent auditors. The reports are issued by Ernst & Young LLP and Coalfire, both established audit firms in the technology compliance space.
How to get the report. Go to Google Cloud Compliance Reports Manager and sign in with any Google account (a Workspace account works). The reports are available on demand at no cost, without a formal sales process. Google also makes SOC 3 reports publicly available without authentication. The SOC 2 requires a sign-in but no NDA or gating beyond that.
What the report actually covers
Google's SOC 2 report covers the infrastructure and operations Google controls: the physical data centers, the network backbone, hypervisor isolation between tenants, and the systems that keep Gmail, Drive, and the rest of Workspace available. The Trust Services Criteria covered include Security, Availability, Confidentiality, and Privacy.
What it doesn't address is anything inside your Admin Console. How you've configured 2-Step Verification, who holds super admin access, which OAuth applications you've approved, what data loss prevention rules you've set for Drive sharing: none of that is in Google's report. That configuration layer is yours.
This isn't a flaw in Google's report. It's how shared responsibility works at every major cloud and SaaS provider. The infrastructure belongs to them; the configuration belongs to you. An auditor evaluating your company's SOC 2 will look at both halves, and Google's report only covers the first.
The Admin Console: the half that belongs to you
The configuration gaps I see most often in Workspace environments during audit prep are fairly consistent. Here's where findings tend to cluster.
2-Step Verification enforcement. Workspace doesn't enforce MFA by default across a tenant. You have to enable it in the Admin Console and set it as mandatory for all users. If it's only enabled for individual users who happened to turn it on themselves, not enforced at the organizational policy level — that's an audit gap. Auditors test this specifically and will pull evidence of the enforcement policy, not just whether some users have 2SV set up.
Super admin minimization. The number of accounts with super admin access should be small. Super admins hold unrestricted control over the entire Workspace tenant: they can access any user's email, reset any account, approve any application. Scoped administrative roles (User Management Admin, Groups Admin, and equivalents) should handle day-to-day tasks. This is the same principle that underlies any least-privilege access model, and auditors apply it to Workspace just as they do to cloud IAM.
OAuth application controls. By default, third-party apps can request broad Google account permissions through OAuth without administrator approval. In a compliance environment, you should restrict which applications are allowed, either through domain-wide policy or an explicit allowlist. OAuth sprawl is one of the more common access control findings in Workspace audits. The attack surface is real, and the admin control to address it is straightforward.
Drive sharing policies. Public and external sharing from Drive should be configured deliberately, not left at permissive defaults. This applies especially to data in regulated categories: financial records, customer information, anything governed by HIPAA or GDPR. The default settings are built for collaboration; your compliance posture needs settings built for control.
Audit log retention. Google Workspace generates admin activity logs, login events, and Drive audit logs. Make sure retention is set for a duration that covers your audit window, and that you have an actual process for reviewing anomalies, not just collecting logs. The log data exists; what auditors test is whether you're using it.
Gemini for Google Workspace
If you've enabled Gemini for Google Workspace (the AI features in Gmail, Docs, Drive, Sheets, and Slides), those features are now included in Google's SOC 1, SOC 2, and SOC 3 compliance scope. Google added Gemini to the compliance program in 2024, and that coverage carries forward in the quarterly reports.
This matters for two reasons. Customers and auditors increasingly ask whether AI features processing their data fall under a vendor's compliance report. For Workspace with Gemini, they do. It also means you don't need to carve Gemini usage out of your control environment description. It sits inside the same compliance scope as the rest of Workspace.
How to use Google's report in your own SOC 2 audit
When you go through your own SOC 2 audit, your CPA will ask about controls you've delegated to subservice organizations like Google. This is the "complementary subservice organization controls" section, and it requires more than naming Google Workspace as a vendor.
Specifically, you need to:
- Obtain Google's SOC 2 Type 2 report from the Compliance Reports Manager
- Review which controls you're relying on Google to operate (physical security, network redundancy, hypervisor isolation)
- Confirm those controls are included in the report and operated effectively during the covered period
- Document that review as a formal vendor risk activity
Step three is where teams get tripped up. You can't assume Google's report covers what you need; you have to verify it and record that you did. If your own system description states that "physical security is managed by our cloud productivity provider," your auditor will ask to see evidence that you checked the provider's report and confirmed it says so.
The same process applies to every significant vendor in your stack. A structured vendor risk assessment checklist makes this repeatable across vendors and audit cycles without rebuilding from scratch each year.
How to verify any vendor's SOC 2 status
The approach for Google is worth internalizing as a general practice. For any vendor:
- Go to their compliance or trust page directly; a sales deck is not verification
- Confirm they issue Type 2 reports and check the most recent audit period
- Download or request the actual report; many vendors require an NDA, Google does not
- Check whether the specific services you use are in scope for that report
- Note the next report date and build a reminder to refresh the review annually
For Google, the SOC compliance page lists what's in scope and how to access the current reports. The quarterly cadence means you can almost always pull a reasonably current document, which puts Google ahead of most vendors on this dimension.
If you're building a vendor review program from scratch, the vendor risk guide covers how to structure those reviews and what auditors expect to see in your documentation.