SOC 2 on Google Cloud
Google Cloud gives you two audit controls for free: encryption at rest and 400 days of Admin Activity logs. The SOC 2 work is identity, organization structure, Data Access logging and keeping service account keys out of the picture.
A SOC 2 on Google Cloud needs every project inside your organization under a production or non-production folder, no Owner or Editor roles granted to individuals, service account key creation disabled by organization policy, Data Access audit logs on for services holding customer data, an aggregated log sink with a retention lock, and a routine for Security Health Analytics findings. Encryption at rest and Admin Activity logging are already done for you.
Which SOC 2 criteria does Google Cloud configuration answer?
| Criterion | What it asks | Google Cloud services involved |
|---|---|---|
| CC6.1 | Access restricted, data encrypted | Cloud IAM, Cloud Identity, default encryption, Cloud KMS |
| CC6.2, CC6.3 | Access granted and removed through a process | Groups in Cloud Identity or Workspace mapped to IAM roles |
| CC6.6 | Boundary protection | VPC firewall rules, Cloud Armor, VPC Service Controls |
| CC6.7 | Data protected in transit | Google Front End TLS, SSL policies on load balancers |
| CC6.8 | Malicious software controls | Artifact Analysis vulnerability scanning, Binary Authorization |
| CC7.1 | Configuration monitoring | Security Health Analytics, organization policy |
| CC7.2, CC7.3 | Anomaly detection | Event Threat Detection (Premium), Cloud Monitoring alerts |
| CC8.1 | Changes authorized and approved | Cloud Build or another pipeline, Admin Activity logs for out-of-band changes |
| A1.2 | Backup and recovery | Cloud SQL backups, Backup and DR, bucket versioning |
IAM on Google Cloud: the basic roles problem
The single most common Google Cloud finding is people holding the basic Owner or Editor role on production projects. Editor grants write access to almost every service. Replace basic roles on individuals with predefined roles granted to groups, and use the IAM Recommender to see which permissions each principal actually used over the last 90 days.
- Groups, not people. Grant roles to Google groups. Joiners and leavers are then handled in one place, and the group membership export is the access list.
- Service account keys. Enforce the organization policy constraint that disables key creation. Pipelines authenticate with Workload Identity Federation. Existing keys go on a retirement list with dates.
- Folder-level grants. Set production access on the production folder so new projects inherit it and nobody grants access project by project.
Audit logging on Google Cloud
Admin Activity logs are always on and kept for 400 days. That covers administrative changes for almost any audit period. Data Access logs, which record reads and writes of data, are off by default for most services. Turn them on for Cloud SQL, Cloud Storage buckets and BigQuery datasets holding customer data. They can be voluminous, so start with the services the auditor will ask about. Route everything through an aggregated sink at the organization to a bucket with a retention policy and bucket lock, owned by a separate logging project.
Organization policies that produce evidence
| Constraint | What it stops |
|---|---|
iam.disableServiceAccountKeyCreation | Long-lived service account keys |
gcp.resourceLocations | Resources created outside Canadian regions |
storage.publicAccessPrevention | Public buckets |
iam.allowedPolicyMemberDomains | Access granted to accounts outside your domain |
compute.skipDefaultNetworkCreation | The permissive default network in new projects |
sql.restrictPublicIp | Cloud SQL instances with public IPs |
Constraints are preventive controls, which auditors value above detective ones: the evidence is that the bad configuration could not be created. The SCC and organization policy guide covers the full set.
The Google Cloud evidence request list
| Request | Source |
|---|---|
| Projects and purpose | Resource hierarchy export |
| Users with production access | IAM policy at folder and project, group membership |
| MFA enforcement | Admin console 2-Step Verification enforcement, or IdP policy |
| Audit log configuration | Audit config, sink, bucket retention lock |
| Configuration monitoring | Security Health Analytics finding history |
| Backups and restore test | Backup configuration and restore record |
| Change samples | Pull requests and pipeline runs |
Does Google Cloud encrypt data at rest by default?
Yes. All data at rest in Google Cloud is encrypted with Google-managed keys without any configuration. For SOC 2 that is usually sufficient evidence of encryption at rest. Customer-managed keys in Cloud KMS are only needed if a contract or regulation asks for them.
Do we need Data Access logs on every service?
No. Turn them on for services that hold customer or personal data, where an auditor or an incident would need to know who read what. Enabling them everywhere produces large volumes of logs at a cost without adding audit value.
We use Google Workspace. Does that count as our identity provider?
Yes. Workspace accounts are Cloud Identity accounts, and enforcing 2-Step Verification in the Admin console is the MFA control. If Workspace is also where email lives, it is a subservice organization in your system description as well.
Get quotes for SOC 2 on Google Cloud
Organization cleanup, policy baseline and readiness.
Get matched