Shared responsibility in Assured Workloads

This page describes shared responsibility in Assured Workloads. For general information about shared responsibility in Google Cloud, see Shared responsibilities and shared fate on Google Cloud.

Shared responsibility for data

You're the expert in knowing the security and regulatory requirements for your business and knowing the requirements for protecting your confidential data and resources. When you run your workloads on Google Cloud, you must identify the security controls that you need to configure in Google Cloud to help protect your confidential data and each workload. To decide which security controls to implement, you must consider the following factors:

  • Your regulatory compliance obligations
  • Your organization's security standards and risk management plan
  • Security requirements of your customers and your vendors

The protection of your data is a primary design consideration for all of Google's infrastructure, products, and personnel operations. Google Cloud provides strong security for many data types, including Customer Data and Service Data. However, if your workloads must meet specific regulatory requirements or are subject to national standards that require elevated security controls, your internal policies may differ from default configuration options. If you have such requirements, we recommend adopting additional tools and techniques to help maintain your required level of compliance and enable your team to follow the best practices of data management and overall cybersecurity management.

Configure Google Cloud and Assured Workloads for shared responsibility

The following areas are customer responsibilities as a user of any public cloud:

  • Understanding what portions of your data have different compliance and security requirements. Most cloud customers have some IT infrastructure which requires general commercial security, and some customers have specific data, such as health data, which must meet a higher compliance requirement. Assured Workloads can help to meet those higher compliance requirements. Place any sensitive or regulated data with specific access or residency requirements inside appropriate Assured Workloads folders or projects and keep it there.
  • Configuring Identity and Access Management (IAM) to ensure that the contents of your organization are accessed and modifiable by the appropriate personnel.
  • Creating and organizing your organizational hierarchy such that it does not expose personal data.
  • Ensuring you have read all documentation to understand and follow best practices.
  • Sharing information prudently during technical support sessions and troubleshooting, and not placing or sharing sensitive or regulated data outside compliant Assured Workloads folders.

The scope of sensitive or regulated data can vary depending on many factors including regulations you or your customers are subject to and can include:

  • Account information
  • Health information
  • Personal identifiers for customers or users
  • Cardholder data
  • ID numbers

Google's responsibilities in the shared responsibility model

In the shared responsibility partnership between Google and customers, Google takes responsibility for the foundational elements and infrastructure of building a successful cloud business, some of which rely on customers undertaking their responsibilities to configure Google Cloud to adequately protect their data. Examples of Google's responsibilities include:

  • Applying default encryption and infrastructure controls.
  • Enforcing the IAM policies that you set to restrict workload administration and data access to the identities that you identify.
  • Configuring and enforcing any customer-selected Assured Workloads controls associated with your selected compliance regime, for the protected data types in the resources you have configured it for. This includes restrictions on where data will be stored and which Google employees can have access to your data in the course of their appropriate business activities.
  • Providing configurations and controls through Assured Workloads for regulated industries and locationally sensitive data.
  • Providing Organization policies and resource settings that let you configure policies throughout your hierarchy of folders and projects.
  • Providing Policy Intelligence tools that give you insights on access to accounts and resources.

Configuration specific to Europe and the EU

When using Assured Workloads for EU Regions or Sovereign Controls for EU, customers have additional technical controls on top of the GDPR assurances made on Google Cloud that they can use to adjust their data residency and security controls as part of their compliance efforts. Some of these controls include:

  • An EU data boundary as further described in Data residency.
  • Support routing to EU persons in EU locations, including subprocessors.
  • Visibility into Administrative Access requests and accesses.
  • Policy-driven access approvals (Sovereign Controls only).
  • Custom options for data encryption and key management.

Examples of common fields that are not recommended for sensitive or regulated data

We strongly recommend all regulated and sovereign customers to exercise caution when inputting data into Google Cloud services. It's critical to avoid adding sensitive or regulated data into common input fields that may not be protected by technical controls or aren't included in the Assured Workloads technical control boundary. This practice is necessary to maintain compliance with regulatory requirements and safeguards your sensitive or regulated information. To assist you, we compiled a list of examples across various Google Cloud services where extra vigilance is required.

Avoid placing your sensitive or regulated data in the following common fields:

  • Resource names and IDs
  • Project or folder names and IDs
  • Any description fields or labels
  • Log-based metrics
  • VM sizes and similar service configurations
  • URIs or file paths
  • Timestamps
  • User IDs
  • Firewall rules
  • Security scanning configurations
  • Customer IAM policies

What's next