Google Cloud compliance in Canada
Google Cloud gets several audit controls right by default: Admin Activity audit logs are always on and kept for 400 days, and data is encrypted at rest without asking. The gaps are in identity, Data Access logging and project sprawl.
To pass an audit on Google Cloud you need an organization node with folders separating production from everything else, human access through Cloud Identity or Google Workspace with 2-Step Verification enforced, organization policy constraints restricting resource locations and service account keys, Data Access audit logs switched on for services that hold customer data, and a log sink to a locked bucket. Encryption at rest is already on. Admin Activity logs are already on. Most of the remaining work is identity and structure.
What Google covers and what you cover
Google publishes SOC 1, SOC 2 and SOC 3 reports and ISO 27001, 27017 and 27018 certificates for Google Cloud, available through the Compliance Reports Manager. Your auditor relies on them for the physical and platform layers.
Google describes its model as "shared fate" rather than shared responsibility: it publishes secure defaults and blueprints and says it wants customers to use them. The division of duties is the same in substance. You own identity, resource configuration, data classification and who can reach what. The shared responsibility page puts it next to AWS and Azure.
Canadian regions on Google Cloud
| Region | Code | Location |
|---|---|---|
| Montreal | northamerica-northeast1 | Montreal |
| Toronto | northamerica-northeast2 | Toronto |
The organization policy constraint for resource locations
(gcp.resourceLocations) restricts where new resources can be
created. Set it to the Canadian regions at the organization or production folder
and residency becomes a control with evidence rather than a promise. Some
global services and multi-region storage classes place data outside Canada, so
the constraint also stops those being picked by accident. The
Canadian regions guide compares all three
providers.
The controls auditors test on Google Cloud
| Control | Google Cloud implementation | Evidence the auditor accepts |
|---|---|---|
| Unique identities, MFA | Cloud Identity or Workspace, 2-Step Verification enforced, SSO from your IdP | Admin console enforcement setting, user list |
| No user-managed service account keys | Organization policy disabling key creation, Workload Identity Federation instead | Policy constraint export, key inventory |
| Least privilege | Predefined or custom roles on groups, no basic Owner or Editor roles on people | IAM policy export per project, access review sign-off |
| Audit logging | Admin Activity on by default, Data Access enabled for data services, aggregated sink | Audit config, sink definition, bucket retention lock |
| Location restriction | gcp.resourceLocations constraint | Constraint at org or folder, attempted-violation denial in logs |
| Encryption | Google-managed keys by default, Cloud KMS keys where required | Default encryption statement, CMEK configuration where used |
| Configuration monitoring | Security Health Analytics findings | Finding history with resolution dates |
| Backups | Cloud SQL automated backups, Backup and DR service, bucket versioning | Backup configuration, restore test record |
| Change management | Terraform through Cloud Build or another pipeline with approvals | PR history, pipeline service account roles |
The SOC 2 walk-through is on SOC 2 on Google Cloud.
Logging defaults, and the one to change
Admin Activity and System Event audit logs are always written and kept for
400 days in the _Required bucket. You cannot turn them off. Data
Access logs, which record who read or wrote data, are off by default for most
services and are kept for 30 days in the _Default bucket once on.
An auditor asking who accessed customer data needs Data Access logs on the
services that hold it, and a retention period that covers the audit window.
The audit logging guide has the settings.
Native evidence tooling
Google Cloud's security command console (Security Command Center) runs Security Health Analytics against your resources and reports findings mapped to CIS, PCI DSS, NIST SP 800-53 and ISO 27001 controls. The Standard tier is included; the Premium and Enterprise tiers add threat detection and compliance reporting at a price that scales with usage. The SCC and organization policy guide covers what each tier produces and which organization policy constraints matter most for an audit.
Organization structure
The structure that passes cleanly is an organization node, a folder for production and a folder for everything else, projects inside them, and IAM and organization policies set at the folder so new projects inherit them. Projects created under individual accounts, outside the organization, are the most common finding on Google Cloud. Move them in before the audit.
Is Google Cloud SOC 2 compliant?
Google Cloud holds SOC 2 reports and ISO certifications for its infrastructure and services. They cover Google's side. Your auditor still tests your identity setup, IAM roles, logging and change process directly.
Are Cloud Audit Logs enough for SOC 2?
Admin Activity logs are enough for administrative changes and are kept for 400 days by default. For access to customer data you need Data Access logs enabled on the relevant services and routed to a bucket with retention that covers your audit period.
Which Google Cloud region should a Canadian company use?
Montreal (northamerica-northeast1) or Toronto (northamerica-northeast2), with the other as the disaster recovery region. Enforce the choice with the resource location organization policy so it holds for every new project.
Do we need SCC Premium for an audit?
No. The Standard tier with Security Health Analytics findings is enough configuration evidence for most first audits. Premium adds threat detection and compliance reporting that a larger estate may justify.
Get quotes for Google Cloud compliance work
Organization structure, policy baseline, or SOC 2 readiness on Google Cloud.
Get matched