XenonStack Blog Google Cloud Security: Services, Layers and Best Practices

Google Cloud security works in two layers. Google secures the infrastructure underneath every service: custom hardware with the Titan security chip, cryptographic service identity, encryption of stored data by default, the Google Front End for TLS and denial-of-service defence, and tightly controlled staff access. On top of that, customers choose and configure the security services: Security Command Center for posture and threats, Google Security Operations for SIEM and SOAR, Google Threat Intelligence and Mandiant for intelligence and response, plus Cloud Armor, VPC Service Controls, Cloud KMS and Chrome Enterprise Premium for specific controls.

For a CISO or cloud architect in 2026, the decisions that matter are which Security Command Center tier to run (the Enterprise tier is being shut down on 21 May 2027), how the security operations centre (SOC) will use Google Security Operations and its AI agents, and which controls your own team must still own, from mandatory 2-step verification to service perimeters around sensitive data. This guide maps each GCP cyber security service to the decision it supports. If you run more than one cloud, compare it with our Azure security services checklist and AWS security services guide.

What are the main Google Cloud security services in 2026?

Google groups its security portfolio under Google Unified Security, which it describes as combining threat intelligence, security operations, cloud security, secure enterprise browsing and Mandiant expertise, with agentic AI triage and investigation of alerts. The table lists the services most enterprises evaluate, what each does and its current status.

How does Google secure its own infrastructure?

Google's infrastructure security design overview describes a layered model that every Google Cloud customer inherits. Google notes that the overview reflects the state of things when it was written (last updated June 2024), so treat it as the design baseline rather than a feature list.

For Compute Engine and Google Kubernetes Engine, the same overview lists further options: encrypted virtual networking traffic, Confidential Computing to protect data in use, and sole-tenant nodes for workloads that need dedicated hardware.

What has changed in Google Cloud security since this guide was first written?

Several product names and requirements in older GCP security guides are now out of date. The table lists the changes that affect enterprise plans.

Which Security Command Center tier should you choose?

Security Command Center (SCC) is the posture and threat dashboard for Google Cloud. Its service tiers page (updated 9 November 2026) describes four tiers. Because the Enterprise tier is retiring, new programmes should plan around Standard or Premium.

Security Health Analytics detectors map to the controls of common benchmarks such as NIST, HIPAA, PCI-DSS and CIS, which makes SCC findings useful evidence for audits. If you relied on the Enterprise tier for AWS and Azure posture, the deprecations page does not name a multicloud replacement, so ask your Google account team how Wiz or Google Security Operations will cover those clouds before you renew.

How do Google Security Operations and Mandiant fit into the SOC?

Google Security Operations is a cloud SIEM built as a layer on top of Google infrastructure. It normalises, indexes, correlates and analyses security telemetry so analysts can search months of history, and the SOAR component runs response playbooks. Google says the platform applies its threat intelligence and more than 4,000 curated detections. On the agentic SOC page, Google describes three agents: a Triage and Investigation agent, which Google says reduces a typical 30-minute manual analysis to 60 seconds; a Detection Engineering agent that creates and tests detection rules; and a Threat Hunting agent. Google pairs these agents with deterministic playbooks so analysts keep control of high-impact actions.

Mandiant, now part of Google Cloud, supplies the human side: incident response and consulting, Managed Defense for continuous monitoring and threat hunting, Security Validation to test whether controls actually work, Attack Surface Management, Digital Threat Monitoring of the open, deep and dark web, and the Mandiant Retainer. When our teams design agentic SOC workflows, we follow the same split: agents gather evidence and propose a verdict, the analyst is notified and approves containment, and every step is recorded against frameworks such as NIST, ISO 27001 and SOC 2. MetaSecure applies this pattern as an agentic SOC built on modular AI agents and protocol-driven automation.

Video: an AI SOC workflow that detects and contains a privilege escalation with analyst approval (ElixirClaw).

Which security controls do Google Cloud customers still own?

Google secures the infrastructure, but identity, configuration, network boundaries and data access remain your responsibility. Google's own 2SV page puts it plainly: the control plane is affected by the requirement, not the data plane, so workloads and service accounts need their own controls. The table maps common GCP risks to the service and setting that addresses each.

For a wider view of identity-first access, see our guide to implementing zero trust, and for estates that span providers, our multi-cloud security guide.

How should you secure AI workloads and agents on Google Cloud?

Google positions AI Protection to discover and safeguard models, agents, applications and data, and Model Armor to screen LLM prompts and responses against attacks such as prompt injection. Model Armor includes a free monthly token allotment, and its findings are published to Security Command Center on the Premium and Enterprise tiers. Google's Secure AI Framework (SAIF) and its risk self-assessment give a starting checklist for model risk, security and privacy.

These tools protect the model boundary, but enterprises also need to govern what agents decide and do. AgentGRC keeps autonomous agent actions inside policy, with the audit trail risk teams need, and ElixirData Context OS keeps governed context, versioned policy and decision traces in one decision layer above AI agents.

In what order should enterprises adopt Google Cloud security services?

1. Identity first: enforce 2SV with security keys for all administrators, separate daily accounts from super admin accounts, and review IAM roles for least privilege.
2. Posture visibility: activate Security Command Center at organisation level (Standard at minimum, Premium for production) and assign owners to high-severity findings.
3. Data boundaries: decide where Cloud KMS customer-managed keys are required and put VPC Service Controls perimeters around sensitive projects, starting in dry run mode.
4. Edge protection: place internet-facing applications behind Google Cloud load balancers with Cloud Armor policies.
5. Detection and response: send logs to Google Security Operations, enable curated detections and build playbooks; decide where agents may act and where an analyst must approve.
6. Assurance: use Mandiant Security Validation or an external test to prove controls work, and keep SCC compliance findings as audit evidence.

What are the governance, security and cost considerations?

Governance starts with the resource hierarchy: many Security Command Center features, including CMEK and data residency settings, need organisation-level activation, so security teams need organisation-level roles and a clear owner for each folder and project. Keep a record of which findings you accept as risk and why, because auditors will ask.

On cost, SCC Standard has no additional charge, while Premium is pay-as-you-go or subscription. Some integrated services, such as Cloud Armor and Sensitive Data Protection discovery, are priced separately, and Adaptive Protection needs an active Cloud Armor Enterprise subscription. Agentic features in Google Security Operations use SecOps Security Tokens, an add-on. Check current pricing pages before budgeting, as this guide quotes no prices. Our cyber security services team and Google Cloud managed security services can help with the assessment.

What are the trade-offs, and when is Google's stack not the right fit?

• Multicloud posture: with the SCC Enterprise tier retiring, SCC Premium covers Google Cloud only. If most of your estate is on AWS or Azure, compare Wiz and your existing CNAPP before committing.
• Existing SIEM investment: moving to Google Security Operations means re-mapping parsers and rewriting detections; it pays off when log volume and search speed are the bottleneck, less so for small, stable SOCs.
• Agent autonomy: Google keeps analysts in control of critical actions. Set the same rule in your own playbooks and record every agent decision.
• Perimeter side effects: VPC Service Controls blocks cross-perimeter traffic by default and does not cover third-party internet services or all metadata movement, so it needs careful design and testing.

To map one security decision your SOC agents should make on Google Cloud, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.

Frequently asked questions about Google Cloud security

What is the difference between Security Command Center and Google Security Operations?

Security Command Center manages security posture and threat findings for Google Cloud resources, such as misconfigurations, vulnerabilities and attack paths. Google Security Operations is a cloud SIEM and SOAR that collects telemetry from across the enterprise, runs detections and automates response playbooks.

Is the Security Command Center Enterprise tier being discontinued?

Yes. Google deprecated the Enterprise tier on 21 May 2026 and it shuts down on 21 May 2027. Organisations on Enterprise move automatically to the Premium tier on or after that date, and Premium covers Google Cloud only.

Is 2-step verification mandatory for Google Cloud?

Google requires 2-step verification for user accounts that access the Google Cloud console and Firebase console. For Cloud Identity organisations without SSO created before 3 August 2026 it applies from 20 October 2026, and dates for SSO users are still to be announced.

What happened to Chronicle?

Chronicle Security Operations was rebranded as Google Security Operations on 25 April 2024, as reported by Wikipedia citing Google's release notes. Some documentation URLs still use the chronicle path.

How does Mandiant fit into Google Cloud security?

Mandiant provides incident response, consulting, Managed Defense, Security Validation, Attack Surface Management and Digital Threat Monitoring, and its frontline expertise feeds Google Threat Intelligence alongside VirusTotal.

Does Google encrypt data at rest by default?

Yes. Google's infrastructure encrypts user data by default before it is written to physical storage. Customers who must control their own keys can use Cloud KMS, which supports hardware-backed keys validated to FIPS 140-2 Level 3.