GCP Security Checklist: Score Your Google Cloud

Projects live under one organization, grouped into folders by environment, and no production project sits outside the hierarchy.

Preventive organization policy constraints are set at the organization or folder level, not project by project.

New projects skip the default network (constraints/compute.skipDefaultNetworkCreation) and existing default networks are removed.

Resource locations are restricted (constraints/gcp.resourceLocations) wherever data residency matters.

Infrastructure changes go through version control, review and a pipeline with policy-as-code checks.

Users come from a central identity provider with single sign-on, and IAM roles are granted to groups by job function, not to individuals.

Domain restricted sharing (constraints/iam.allowedPolicyMemberDomains) limits who can be added to IAM policies, and outside accounts have been reviewed.

Basic roles (Owner, Editor, Viewer) are not used for people or workloads in production; narrower roles are used instead.

IAM role recommendations are reviewed on a schedule and applied or dismissed with a reason.

Humans have view-only access to production; changes go through a pipeline that uses privileged service accounts.

Service account key creation and upload are disabled by organization policy, with narrow documented exceptions.

External and Kubernetes workloads use Workload Identity Federation instead of exported keys.

Every external workload identity provider has an attribute condition, and access is not granted to all identities in a pool.

Default service accounts do not hold Editor or Owner, and workloads do not share the default Compute Engine service account.

You know what to do when a key leaks: delete it quickly, and detect keys unused for 90 days or more.

Projects holding sensitive data in Cloud Storage, BigQuery and similar services sit inside a VPC Service Controls perimeter.

Perimeter changes are tested in dry run mode before enforcement, and perimeter edits are monitored.

Network resources are centrally managed (for example Shared VPC) and separated by environment.

External IPs on VMs are denied by policy (constraints/compute.managed.vmExternalIpAccess) and OS Login is required.

No firewall allows SSH or Cloud SQL connections from all addresses; OPEN_SSH_PORT and PUBLIC_SQL_INSTANCE findings are clear.

Audit logs from every project are routed by organization-level aggregated sinks to a central logging project.

Data Access audit logs are enabled for services holding sensitive data.

Security Command Center is activated at the organization level and its findings reach a team with owners.

Findings are exported to your SIEM or SOC through Pub/Sub or BigQuery.

You have rehearsed the response to a leaked key and a compromised workload identity.

Public access prevention (constraints/storage.publicAccessPrevention) is enforced for Cloud Storage.

Uniform bucket-level access is required (constraints/storage.uniformBucketLevelAccess) so IAM alone controls access.

Where required, CMEK is used with a plan for key disablement, and organization policy controls which services and key projects may be used.

Cloud KMS keys are rotated and none is publicly accessible (KMS_KEY_NOT_ROTATED, KMS_PUBLIC_KEY clear).

Keys and application secrets live in centralized projects managed and audited by a dedicated team.