Most Google Cloud exposures come from inherited defaults nobody revisited: an organisation created before secure-by-default constraints existed, default service accounts still holding Editor, service account keys in CI pipelines, or Data Access logs that were never switched on. This template is a tickable checklist for verifying the basics across a Google Cloud organisation, grouped as organisation and policy, super admins and human access, service accounts, logging, detection, network and compute, and data. Each check names the organisation policy constraint, Security Health Analytics finding or console setting you can inspect, so it can be verified and evidenced. It follows Google's security foundations blueprint and is designed to sit alongside the CIS Google Cloud Platform Foundation Benchmark (v5.0.1 is the latest version CIS lists). It is for cloud security engineers, platform teams and auditors. For why each control matters, read the Google Cloud Security Guide; this page verifies.
This is an independent guide from NHI Mgmt Group, based on Google Cloud's public documentation as of November 2026. It is not sponsored or reviewed by Google Cloud. Product features change, so confirm settings against Google Cloud's current documentation.
How to use this template
- Replace text in square brackets, such as [Organisation], [organisation ID] and [logging project], with your own details.
- Constraint names are shown in their classic form (for example iam.disableServiceAccountKeyCreation). Google now also publishes managed variants for several of them, such as iam.managed.disableServiceAccountKeyCreation, compute.managed.requireOsLogin and sql.managed.restrictPublicIp. Either form passes the check; record which one you use.
- Finding names in capitals, such as MFA_NOT_ENFORCED, are Security Health Analytics categories in Security Command Center. Where you run Security Command Center, read those findings rather than inspecting each resource.
- For a CIS assessment, map each line to the CIS Google Cloud Platform Foundation Benchmark recommendation in your posture tool. This page deliberately does not quote CIS recommendation numbers, because numbering changes between benchmark versions.
- Mark each line Pass, Fail, Partial or Not applicable, note the folders or projects checked and attach evidence (policy export, finding export, screenshot).
- Run the full list before production workloads go into a new organisation, and at least [quarterly] across the estate.
1. Review record
| Field | Entry |
|---|---|
| Organisation ID and Cloud Identity or Workspace domain | [organisation ID], [domain] |
| Organisation creation date | [date]: before or after 3 May 2024 (see check 2.2) |
| Folders and projects in scope | [All / list] |
| Central logging project and security project | [project IDs] |
| Posture tooling and benchmark version | [Security Command Center tier / other], [CIS GCP Foundation v5.0.1] |
| Reviewer, date, result | [Name], [date], [Pass / Pass with findings / Fail] |
2. Organisation structure and organisation policies
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 2.1 | All projects sit under one organisation resource and a folder hierarchy (for example by environment and business unit); no projects without a parent organisation. | Resource Manager hierarchy export | [ ] |
| 2.2 | Organisations created before 3 May 2024 have had the secure-by-default constraints applied manually. Google enforces seven constraints by default only on organisations created on or after that date. | Org policy export | [ ] |
| 2.3 | IAM allow policies can only grant roles to identities from approved domains. | iam.allowedPolicyMemberDomains (managed: iam.managed.allowedPolicyMembers) | [ ] |
| 2.4 | Essential Contacts are set for security, technical and billing categories, and restricted to approved domains. | essentialcontacts.allowedContactDomains | [ ] |
| 2.5 | New projects do not get the default network and its permissive firewall rules. | compute.skipDefaultNetworkCreation | [ ] |
| 2.6 | Resource locations are restricted where data residency applies. | gcp.resourceLocations | [ ] |
| 2.7 | Exceptions to organisation constraints are granted at the narrowest folder or project, recorded with an owner and expiry, and reviewed [quarterly]. | Exception register | [ ] |
| 2.8 | Infrastructure changes run through version-controlled code and are validated against policy before deployment, as in Google's foundations blueprint. See the Google Cloud Enterprise Foundations Blueprint Guide. | Pipeline configuration | [ ] |
For constraint inheritance, dry runs and custom constraints, see the Google Cloud Organization Policy Guide.
3. Super admins and human access
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 3.1 | Each super administrator uses a separate admin account (for example alice-admin@) that is not used for email or daily work. | Admin console role report | [ ] |
| 3.2 | Super admin and other privileged accounts use 2-Step Verification with security keys. | Admin console 2SV report | [ ] |
| 3.3 | Day-to-day organisation administration is done by an Organization Administrator group that does not contain the super admin accounts. | IAM policy at organisation node | [ ] |
| 3.4 | Super admin self-recovery remains disabled, and the recovery process is documented and known to Organization Administrators. | Admin console setting | [ ] |
| 3.5 | MFA is enforced for every user with Google Cloud access, or users sign in through a federated identity provider that enforces it. | MFA_NOT_ENFORCED | [ ] |
| 3.6 | Roles are granted to groups, not individual users, and basic roles (Owner, Editor, Viewer) are not granted at organisation or folder level. | IAM policy export, role recommendations | [ ] |
| 3.7 | Standing high-privilege grants are replaced with time-bound elevation where available, and unused permissions are removed using IAM role recommendations. | Recommender export | [ ] |
| 3.8 | An alert fires on every SetIamPolicy call at organisation and folder level. | Log-based alert | [ ] |
4. Service accounts and machine credentials
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 4.1 | Creation of service account keys is blocked at organisation level, with exceptions only for documented projects. | iam.disableServiceAccountKeyCreation | [ ] |
| 4.2 | Uploading external key material to service accounts is blocked. | iam.disableServiceAccountKeyUpload | [ ] |
| 4.3 | Existing user-managed keys are inventoried, owned and on a removal plan; workloads outside Google Cloud use Workload Identity Federation, and GKE workloads use Workload Identity Federation for GKE. See How to inventory Google Cloud service account keys and replace them with federation. | Key inventory, Cloud Asset Inventory | [ ] |
| 4.4 | Default service accounts no longer receive automatic Editor grants, and existing grants to default accounts have been reviewed and removed. The constraint stops new grants only. | iam.automaticIamGrantsForDefaultServiceAccounts | [ ] |
| 4.5 | Each application has its own single-purpose service account with an owner recorded in its description. | Service account inventory | [ ] |
| 4.6 | No service account holds Owner, Editor or other admin roles. | ADMIN_SERVICE_ACCOUNT | [ ] |
| 4.7 | Service Account User and Service Account Token Creator are granted on individual service accounts, not at project or folder level, to block impersonation chains. Lateral movement insights have been reviewed. | IAM policy export, Recommender insights | [ ] |
| 4.8 | Unused service accounts, identified with Activity Analyzer, are disabled first and deleted after a waiting period. | Activity Analyzer report | [ ] |
| 4.9 | API keys are avoided where a service account or OAuth can be used; remaining keys are restricted by API and by application. | API_KEY_EXISTS, API_KEY_APIS_UNRESTRICTED, API_KEY_APPS_UNRESTRICTED | [ ] |
See the Google Cloud Service Account Keys Security Guide and the Google Cloud IAM and Service Accounts Guide for depth.
5. Logging
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 5.1 | Admin Activity and System Event audit logs are flowing (they are always written and cannot be disabled); confirm they reach the central destination. | Log Router | [ ] |
| 5.2 | Data Access audit logs are enabled for services holding sensitive data and for IAM. They are off by default for every service except BigQuery. | AUDIT_LOGGING_DISABLED | [ ] |
| 5.3 | An aggregated sink at organisation level routes audit logs from all projects to a central log bucket in [logging project] and to [SIEM]. | Sink configuration | [ ] |
| 5.4 | Retention meets [Organisation]'s requirement. The _Required bucket keeps Admin Activity and System Event logs for a fixed 400 days; the _Default bucket keeps 30 days unless changed, so longer retention needs a central bucket set up to 3,650 days. | Bucket retention settings | [ ] |
| 5.5 | The central log bucket is in a restricted project with access limited to [security team], and retention is locked where tamper resistance is required. | Bucket lock status, IAM policy | [ ] |
| 5.6 | Access logging is enabled on Cloud Storage buckets that hold sensitive data, where Data Access logs do not already cover the need. | BUCKET_LOGGING_DISABLED | [ ] |
| 5.7 | VPC Flow Logs are enabled on production subnets. | Subnet configuration | [ ] |
See the Google Cloud Audit Logs and Log Sinks Guide.
6. Detection
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 6.1 | Security Command Center (or an equivalent posture tool) is enabled at organisation level, not project by project. | Service settings | [ ] |
| 6.2 | High and critical findings route to [ticketing / SIEM] with an owner and a target time to fix. | Notification configuration | [ ] |
| 6.3 | Alerts exist for: IAM policy changes at organisation and folder level, service account key creation, organisation policy changes, sink or log bucket changes and firewall rule changes. | Log-based alert list | [ ] |
| 6.4 | Threat detection for suspicious activity (for example anomalous service account use and crypto mining) is enabled where licensed, and findings are triaged by [SOC]. | Detector settings | [ ] |
7. Network and compute
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 7.1 | VMs cannot get external IPv4 addresses except on an approved allowlist; outbound access uses Cloud NAT. | compute.vmExternalIpAccess | [ ] |
| 7.2 | OS Login is required instead of metadata-based SSH keys. | compute.requireOsLogin | [ ] |
| 7.3 | Serial port access and nested virtualisation are disabled. | compute.disableSerialPortAccess, compute.disableNestedVirtualization | [ ] |
| 7.4 | No firewall rule allows SSH (22) or RDP (3389) from 0.0.0.0/0; administrative access goes through Identity-Aware Proxy or a bastion. | Firewall rule export | [ ] |
| 7.5 | Protocol forwarding is limited to internal addresses, and IP forwarding is enabled only on approved appliances. | compute.restrictProtocolForwardingCreationForTypes, compute.vmCanIpForward | [ ] |
| 7.6 | Workloads do not run as the Compute Engine default service account with broad access scopes. | Instance configuration | [ ] |
| 7.7 | GKE clusters have automatic node upgrades enabled. See the GKE Security Hardening Guide. | AUTO_UPGRADE_DISABLED | [ ] |
| 7.8 | Sensitive projects sit inside a VPC Service Controls perimeter to limit data exfiltration through Google APIs. | Perimeter configuration | [ ] |
See the Google Cloud VPC and Cloud NGFW Security Guide.
8. Data protection
| # | Check | Constraint or evidence | Result |
|---|---|---|---|
| 8.1 | Cloud Storage buckets use uniform bucket-level access (IAM only, no legacy ACLs). | storage.uniformBucketLevelAccess | [ ] |
| 8.2 | Public access prevention blocks grants to allUsers and allAuthenticatedUsers, with documented exceptions for intentionally public content. | storage.publicAccessPrevention | [ ] |
| 8.3 | Cloud SQL instances have no public IP and no authorised networks; connections use private IP or the Cloud SQL Auth Proxy. | sql.restrictPublicIp, sql.restrictAuthorizedNetworks | [ ] |
| 8.4 | Cloud SQL requires SSL/TLS for connections. | SSL_NOT_ENFORCED | [ ] |
| 8.5 | Customer-managed encryption keys (CMEK) are used where policy requires them, with automatic key rotation and separation between key administrators and key users. See the Cloud KMS and Cloud HSM Guide. | Key inventory, IAM on keys | [ ] |
| 8.6 | Backups for critical databases and buckets exist, are tested, and are protected from deletion by the same identities that run production. | Backup test record | [ ] |
See the Google Cloud Storage Security Guide.
9. Findings and sign-off
| Finding | Check # | Risk | Owner | Due date | Status |
|---|---|---|---|---|---|
| [Description] | [e.g. 4.1] | [High / Medium / Low] | [Name] | [Date] | [Open / Accepted / Closed] |
Reviewer: [Name, role]. Approved by: [Cloud security lead / CISO]. Date: [date]. Accepted risks are recorded in [risk register] with an expiry date.
Implementation guidance
- Start with the organisation node. Most checks in sections 2, 4, 7 and 8 are organisation policy constraints. Applying them once at the top is faster than fixing projects one by one, and new projects then inherit them.
- Dry run before enforcing. Use the organisation policy dry run and policy simulation to see what a constraint would block, and apply it first to a sandbox folder. Rollback is removing or relaxing the policy on that node.
- Older organisations first. If your organisation predates 3 May 2024, check 2.2 is usually the biggest gap: key creation, default service account grants and domain restriction may all be open.
- Replace keys before blocking them everywhere. Inventory existing keys, move CI/CD and external workloads to Workload Identity Federation, then enforce the key constraint with a short exception list. See the Workload Identity Federation Guide.
- Centralise logs, then alert. Build the aggregated sink and central bucket before writing alerts, so detections see every project.
- Size to the estate. A small organisation with a few projects can work through this list by hand in a day. A large estate should read findings from its posture tool and review exceptions, not resources.
- Measure. Track the number of user-managed service account keys (falling to the exception list), service accounts with basic or admin roles (target zero), projects outside the central sink (target zero), firewall rules open to 0.0.0.0/0 on 22 or 3389 (target zero), public buckets outside the approved list (target zero) and median time to close high findings.
Common failure patterns
- Assuming secure defaults apply: teams read about default-on constraints, but their organisation was created earlier and never received them.
- Key constraint with a permanent wildcard exception: keys are blocked at the top and re-allowed on the folder where most workloads live.
- Editor still on default service accounts: the automatic-grants constraint was enabled, but existing grants were never removed.
- Logs present but not central: Data Access logs enabled in a few projects, kept for 30 days, and never routed to the SIEM.
- Credentials outside the cloud: key hygiene extends to wherever a key is copied, including personal browser profiles, so keep service account credentials out of them.
Framework mapping
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| 2. Organisation and policies | CM-6, CM-7 | PR.PS-01 | 8.9 |
| 3 and 4. Human and service account access | AC-2, AC-6, IA-2, IA-5 | PR.AA-01, PR.AA-05 | 5.15, 5.17, 5.18, 8.2, 8.5 |
| 5. Logging | AU-2, AU-9, AU-12 | PR.PS-04 | 8.15 |
| 6. Detection | SI-4, AU-6 | DE.CM-09 | 8.16 |
| 7. Network and compute | SC-7, CM-7 | PR.IR-01 | 8.20, 8.22 |
| 8. Data protection | SC-12, SC-28 | PR.DS-01, PR.DS-11 | 8.13, 8.24 |
Attack techniques these checks address include MITRE ATT&CK T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials, T1552.005 Cloud Instance Metadata API and T1530 Data from Cloud Storage.
Standards and references
- Google Cloud: Enterprise foundations blueprint, preventative controls
- Google Cloud: Secure by default organisation resources
- Google Cloud: Organization policy constraints reference
- Google Cloud: Super administrator account best practices
- Google Cloud: Best practices for using service accounts securely
- Google Cloud: Cloud Audit Logs overview
- CIS: Google Cloud Computing Platform Benchmarks
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Google Cloud Security Guide · Top 10 GCP IAM Mistakes · Cloud IAM Review Checklist