Cyber Essentials for Google Cloud (GCP): configuration guide

Cyber Essentials v3.3 treats your Google Cloud project (and any Workspace tenant acting as your identity provider) as in-scope cloud services. Verify human cloud MFA, needed privileges, applicable firewall protection, supported software and timely required fixes. Organization Policies, Security Command Center and VM Manager are implementation choices rather than a universal product bundle.

• Google Workspace or Cloud Identity - the identity plane for GCP
• Every GCP project in your Organization
• Compute Engine VMs you operate (IaaS - OS-level security is yours)
• GKE clusters you administer (the node side; control plane is Google's)
• VPC networks, firewall rules, Cloud Load Balancers you configure

Google implements the relevant underlying controls; confirm the applicable contractual/shared-responsibility commitments. Provider responsibility does not remove the cloud service from scope.

• Enforce 2-Step Verification for every user in your Workspace / Cloud Identity domain. Security keys/passkeys can strengthen administration; a hardware-key policy is not the scheme's only recognised MFA route.
• Apply full password controls and an applicable quality route: MFA, twelve-plus characters or eight-plus with a common-password deny list. A fourteen-character Workspace policy can be local hardening.
• Check current supported access methods. Google retired password-only less-secure-app access on 1 May 2025; do not rely on its old admin toggle. Verify OAuth-supported clients and effective MFA; a protocol name alone does not determine authentication.
• Admin role segregation: give only needed access and keep administrative work separate from daily work; three is not a universal scheme maximum.

Evidence: Workspace Admin Console 2SV enrolment report, password policy screenshot, Admin audit log showing role delegations.

Organization Policies can be among GCP's strongest preventive controls for a suitable design. The following are optional implementation examples; verify the current constraint identifier, applicability and inheritance:

• constraints/iam.disableServiceAccountKeyCreation - prevents long-lived service account keys
• constraints/compute.requireOsLogin - every SSH session goes through OS Login with IAM + optional 2FA
• constraints/compute.vmExternalIpAccess - deny VM public IPs by default
• constraints/sql.restrictPublicIp - no public Cloud SQL
• constraints/storage.publicAccessPrevention - all buckets default to private

Export the Organization Policy yaml as evidence - it reads like an assessor's wishlist.

• Consider Security Command Center where the current tier, price and capabilities fit your needs. It is not a mandatory scheme purchase/tier or a substitute for malware protection.
• Resolve all HIGH and CRITICAL findings in the Security Health Analytics module before assessment: default firewall rules, weak SSL policies, public datasets.

• Delete the default VPC in new projects, or lock down its default firewall rules.
• Custom VPCs with deny-by-default ingress. No 0.0.0.0/0 rules on 22, 3389, 3306, 5432 on production firewalls.
• Use IAP TCP forwarding for admin SSH instead of public SSH. Restrict ingress from Google's IAP TCP forwarding range to the required target ports and configure IAM. Google documents the required firewall rule; IAP does not eliminate target-port ingress requirements.

• OS Patch Management (VM Manager) enabled on every zone where you run VMs.
• Apply vendor-approved vulnerability fixes within 14 days of release when the vendor calls the vulnerability high/critical, its CVSS v3 base score is 7 or above, or the vendor gives no severity details. Enable automatic updates where possible. Cover OS, applications and other in-scope software; a patch-level age or deferral setting alone does not establish compliance. A weekly maintenance window needs installation/restart and offline-device evidence.
• Container-Optimised OS/GKE: verify the exact image, channel, supported lifecycle and actual node update/auto-upgrade configuration; do not assume every deployment auto-updates promptly.
• Remove end-of-support images. Check exact releases and active qualifying vendor extended support, such as ESM or ESU; a family name alone is not a support verdict. Unsupported software must be removed or excluded through a defined sub-set preventing all internet traffic.

• Cloud Audit Logs: choose retention and enabled log categories for your risk, access model and current Google service limits. Four hundred days is not a universal scheme retention requirement.
• Sink to a separate log-retention project with more restrictive IAM - demonstrates tamper-resistance.

1. Service account keys downloaded to developer laptops. Replace with Workload Identity Federation.

2. Default VPC still active in production projects with permissive firewall rules.

3. 2SV enforcement not yet cutover for a small tail of contractor accounts.

4. A pinned image without qualifying vendor vulnerability-fix support. Check actual extended-support entitlement and installed fixes, including Ubuntu ESM where applicable.

The readiness check supports preparation. Share scoped identity, policy, support and update evidence when requested. Exact integration/import capability and first-time percentages need service/cohort records; enrolment reports and diagnostic scores cannot guarantee a pass.

Start Cyber Essentials - from £299.99 + VAT | Compare tiers | Book CE Plus