Identify solutions to support regulatory and compliance requirements

Implementing auditing and data privacy controls means proving who accessed database systems and protecting sensitive data inside them. In Google Cloud, Cloud Audit Logs (opens in a new tab) records customer administrative activity, Access Transparency (opens in a new tab) records Google personnel activity, and Sensitive Data Protection (opens in a new tab) discovers and redacts sensitive fields. Together these controls move evidence from database and platform services to centralized, retained, and monitored storage to support GDPR and HIPAA requirements.

1.1Cloud Audit Logs Coverage

Cloud Audit Logs is the centralized auditing service in Cloud Logging that answers who did what, where, and when on Google Cloud resources. Activity flows from Google Cloud services to Cloud Logging, and from Cloud Logging to a log sink for long-term analysis and retention. Centralizing logs in one place lets compliance teams review administrative activity across projects without checking each service separately.

Enable comprehensive coverage across these related sources:

• Admin Activity audit logs for control-plane changes such as creating or modifying database instances
• Data Access audit logs for read and write access to data and configuration
• Cloud Identity audit logs shared from Google Workspace or Cloud Identity to Google Cloud for login and user management events
• VPC Flow Logs, Firewall Rules Logging, Cloud DNS logging, and Cloud Storage bucket logging for network and storage activity around databases

Sharing Cloud Identity audit logs to Google Cloud is important because those logs are otherwise managed separately in the Google Admin console. Once shared, user login events sit alongside database administrative events in Cloud Logging, so one review shows both identity activity and resource activity.

1.2Access Transparency for Provider Activity

Access Transparency is the logging service that records actions taken by Google personnel on customer resources. Cloud Audit Logs sits on the customer side of the trust boundary and records what customer administrators and service accounts do, while Access Transparency sits on the provider side of the boundary and records when Google support or engineering accesses the same environment. This separation gives regulators clear accountability for both sides of access.

Enable Access Transparency logs alongside Data Access audit logs for regulated databases. Data flows from Google internal systems to the customer project, where the logs can be exported to the same sink as other audit logs. For GDPR and HIPAA workloads, retaining both sets of logs proves that neither customer users nor provider operators accessed protected data without oversight.

1.3Database-Level Auditing for Cloud SQL

Database-level auditing for Cloud SQL for PostgreSQL captures activity inside the database engine that platform audit logs do not see. Platform logs record that an instance was changed, while database flags record connections, statements, and internal events within PostgreSQL itself. Both layers are needed because compliance reviews must link an administrative change to its effect on data access.

Configure PostgreSQL database flags to generate detailed audit records:

• Log connections, disconnections, and duration to track session activity
• Log statements, minimum error statements, and lock waits to track queries and failures
• Log checkpoints and temporary files to track storage and performance events
• Turn off verbose planner, parser, executor, and statement statistics that add noise without adding accountability

These flags write events to database logs that flow to Cloud Logging. From there the same retention, access restriction, and alerting controls that apply to platform audit logs apply to database audit records.

1.4Retaining and Securing Audit Evidence

Retaining and securing audit evidence is the lifecycle that keeps logs complete, immutable, and available for review. The lifecycle moves in order from generation to long-term preservation:

1. Generate: Enable audit logs for Google Cloud services and define security logging policies that state which metadata and system events must be logged.
2. Allocate and export: Allocate audit log storage capacity and export logs to a log sink for long-term storage outside the default short-term viewer.
3. Retain and lock: Retain audit records and configure retention policies on log buckets using Bucket Lock so records cannot be deleted early.
4. Restrict: Restrict audit log access to authorized personnel so each read of the logs itself provides unique access accountability.

Storage sits under Cloud Logging and the destination sink, while access control sits under Identity and Access Management. Because locked retention prevents modification, auditors can trust that the record of administrative activity has not changed since it was written.

1.5Monitoring Activity and Protecting Sensitive Data

Monitoring activity and protecting sensitive data turns stored logs and discovered data into timely compliance action. Monitoring continuously compares security audit logs against typical patterns, and Sensitive Data Protection scans for sensitive elements such as personal identifiers so they can be redacted or masked before broader use. Logs detect misuse of access, while redaction limits exposure of regulated data in the first place.

Create log metric filters and alerts for high-risk administrative changes:

• Project ownership assignments and changes
• Audit configuration changes
• Custom role changes
• VPC network firewall rule changes

When a matching event flows from Cloud Logging to Cloud Monitoring, an alert is sent to responsible stakeholders for review and timely response. Combined with redaction of sensitive fields, this monitoring supports GDPR principles of accountability and data minimization and HIPAA requirements for access auditing and protection of health information.

Encryption strategies for Google Cloud databases control who holds the keys that protect data at rest and how access to those keys is governed for compliance. By default, data is protected with Google-managed encryption, where Google creates, stores, and rotates the keys without customer action. Customer-Managed Encryption Keys (CMEK) (opens in a new tab) shift that control to the customer by storing the keys in Cloud Key Management Service (KMS) (opens in a new tab) and granting database services permission to use them, which supports industry standards that require administrative control, auditability, and the ability to revoke access.

2.1What Cloud KMS and CMEK Provide

Cloud Key Management Service (KMS) is the Google Cloud service that creates, stores, rotates, and controls access to cryptographic keys used by databases and other services. A key ring groups one or more crypto keys in a specific location, and each crypto key has one or more key versions that actually perform encryption and decryption. Customer-Managed Encryption Keys (CMEK) are keys in Cloud KMS that a customer owns and manages, and the database service calls Cloud KMS to encrypt and decrypt data with those keys. This relationship gives the customer control over the key lifecycle while the database service depends on the key remaining enabled and accessible to read or write data.

2.2Key Location and External Key Options

The Cloud KMS key location must match the location of the database that it protects, because a database can only use a key in the same location. For regional databases, the key ring, key, and database use the same one-to-one location name, such as us-west1 for a database in us-west1. For multi-region databases, the KMS multi-region location maps to the database multi-region, such as the Cloud KMS us location for Datastore mode nam5 and the Cloud KMS europe location for Datastore mode eur3. Keys can be created directly in Cloud KMS or supplied as externally managed keys through Cloud External Key Manager (EKM), which makes an external key available through Cloud KMS. Oracle Database@Google Cloud (opens in a new tab) supports only multi-region symmetric keys for its CMEK integration.

2.3How Database Access to Keys Is Granted

Database access to CMEK is granted through a service identity that acts on behalf of the database when it calls Cloud KMS. Firestore and Datastore mode use a Google-managed service agent, such as service-{project-number}@gcp-sa-firestore.iam.gserviceaccount.com, created with the services identity create command for firestore.googleapis.com. Oracle Database@Google Cloud creates a unique Principal ID for each Exadata VM Cluster, Exascale VM Cluster, or Autonomous AI Database during provisioning, and that principal starts with no permissions by default. The principal or service agent must be granted roles/cloudkms.cryptoKeyEncrypterDecrypter on the key or key ring, and Oracle resources also require the Cloud KMS Viewer role, so the database can encrypt new data and decrypt existing data.

2.4Creating and Verifying a CMEK-Protected Database

A CMEK-protected database is a database whose encryption type and key are selected only at creation time, and the choice determines long-term compliance posture. An existing database protected by Google default encryption cannot be converted to CMEK, and a CMEK key cannot be added or changed later through the database creation settings. The creation workflow moves data and permissions through an ordered dependency chain:

1. Create the service identity: Create the Firestore service agent or provision the Oracle cluster or Autonomous AI Database so its Principal ID exists.
2. Create the key material: Enable the Cloud KMS API, then create a key ring and key in the same location as the planned database, or create a Cloud EKM key for an external key.
3. Grant key permission: Bind the Cloud KMS CryptoKey Encrypter/Decrypter role to the service agent or Principal ID, plus Cloud KMS Viewer for Oracle resources.
4. Create the database with the key: Select Cloud KMS key in Show Encryption Options and supply the full key resource name, such as projects/KMS_PROJECT/locations/KMS_LOCATION/keyRings/KMS_KEYRING_ID/cryptoKeys/KMS_KEY_ID, in the cmekConfig.kmsKeyName field.

After creation, Database details shows the result of that workflow. A CMEK database shows Encryption type as Customer-managed with the Cloud KMS key and active key versions listed, while a non-CMEK database shows Encryption type as Google-managed.

2.5Enforcing CMEK with Organization Policy

CMEK organization policy constraints enforce encryption compliance across an organization, folder, or project rather than relying on each developer to choose correctly. The constraint constraints/gcp.restrictNonCmekServices requires listed services, including Firestore, Datastore mode, and Google SecOps, to use CMEK, so instance creation fails if no valid Cloud KMS key is supplied. The constraint constraints/gcp.restrictCmekCryptoKeyProjects restricts which Google Cloud projects can supply CMEK keys, which keeps key governance centralized. Together, the database depends on the policy for allowed encryption types, and the policy depends on Cloud KMS for approved key projects.

2.6Key Lifecycle, Rotation, and Audit for Compliance

The key lifecycle directly controls data availability, because the service agent automatically decrypts CMEK-protected data on normal reads as long as permission remains and the key version remains enabled. If the service agent loses the Encrypter/Decrypter permission or the key is disabled or destroyed, decrypt calls fail and requests for the data fail. Re-enabling the key versions in use restores access after the change propagates, which typically takes minutes but can take up to three hours, and Oracle resources require switching back to Oracle-managed encryption before a Cloud KMS key is disabled. Rotation is managed in Cloud KMS on a schedule, with multiple active key versions possible during rotation, while Autonomous AI Database rotation requires selecting a new key because Cloud KMS key versioning alone is not supported. Cloud KMS Data Access audit logs support compliance verification by recording Encrypt and Decrypt calls, where the database poller checks the key about every five minutes per database and those polling results appear in Cloud Logging filtered by key ring, key, and location.

Data residency and sovereignty requirements control where database data is stored, processed, and moved so it remains subject to a specific legal jurisdiction. In Google Cloud, data residency is achieved through geographic placement of database resources in chosen regions and zones, combined with organizational and network controls that prevent data from leaving those boundaries. For United States workloads under FedRAMP High and Department of Defense (DoD) Impact Level 2 (IL2), Impact Level 4 (IL4), and Impact Level 5 (IL5), this means US-only placement enforced by Assured Workloads and private, regional networking.

3.1Geographic Placement of Database Resources

Geographic placement of database resources is the choice of region and zone where compute instances, disks, and managed database services run and store data. A region is a specific geographical location that corresponds to one or more data center locations in close proximity, and each region contains zones with redundant connectivity, power, and cooling. Placement decisions affect latency, available CPU platforms, and compliance, so workloads should be placed close to users and internal resources, and an application server and its database should be placed in the same region.

For FedRAMP High and DoD IL2, IL4, and IL5 designs, Virtual Private Cloud (VPC) (opens in a new tab) networks are global in control plane but must be constrained for data plane residency by creating subnets only in US regions. Regional load balancers must be used instead of global load balancers because they only support US deployments and keep traffic termination inside the compliant boundary. Use of external load balancers that can be directly accessed by the internet might need extra validation with the Defense Information Systems Agency (DISA) to assure DoD authorization for IL4 and IL5.

Resource scope determines whether data and dependencies can be accessed outside the chosen boundary:

Zonal database deployments keep application and database layers within a single zone in a region, while multi-region designs such as a multi-region Spanner instance synchronously replicate data across all included regions for availability but expand the residency footprint.

3.2Organizational Controls That Enforce Residency Boundaries

Organizational controls that enforce residency boundaries are the framework, product choices, and environment rules that keep all database resources and copies within specified jurisdictions. Assured Workloads is the compliance framework that provides the security controls needed to support FedRAMP High and DoD IL2, IL4, and IL5, and after deployment with Assured Workloads the team remains responsible for setting up compliant and secure networking policies. Regional alignment means verifying that every selected product, feature, and configuration supports the required US-only deployment, and product-level compliance means confirming that each Google Cloud and third-party service meets the same standard.

Third-party producer-consumer services require explicit verification that both the producer service and the data in transit meet compliance requirements, because data flowing to an out-of-boundary producer breaks residency even when the database itself is correctly placed. Other environments such as non-production, testing, and quality assurance (QA) must be provisioned in accordance with the organization's VPC strategy so copies of data in lower environments do not leak outside the boundary. Together, Assured Workloads controls, regional product selection, and consistent environment provisioning ensure data remains within specified legal and jurisdictional mandates.

3.3Private Connectivity That Keeps Data Inside the Region

Private connectivity that keeps data inside the region is the set of network paths that lets database clients and applications reach Google managed services and APIs without traversing the public internet. The database VPC depends on private access to Google managed services within the region, and traffic must flow from VPC subnets to the managed service through a regional private path rather than an internet route.

The three private options serve different access patterns:

• Private Service Connect enables private connectivity from a VPC to Google managed services and to supported third-party producer services within the region.
• Private Google Access (PGA) enables VMs with only internal IP addresses to reach Google APIs and services without using external addresses.
• Private service access (PSA) enables private connectivity from a VPC to Google managed services that use an internally managed service-producer VPC.

Google Cloud Armor security policies apply to supported regional load balancers to help protect applications against external threats such as distributed denial-of-service (DDoS) attacks and cross-site scripting (XSS) while keeping policy enforcement regional. When outbound internet access is still required, such as for operating system updates, traffic flows from internal-only VMs through a Cloud NAT gateway so the database hosts retain no public exposure.

Key Facts

• Cloud Audit Logs records customer administrator activity, while Access Transparency records Google personnel activity on customer resources.
• Cloud SQL for PostgreSQL database flags capture connections, statements, checkpoints, and temporary files inside the engine to complement platform audit logs.
• Customer-Managed Encryption Keys (CMEK) in Cloud Key Management Service (KMS) must be selected at database creation and cannot be added to an existing Google-managed database.
• Disabling a CMEK key version or removing the database service agent permission causes decrypt calls and data requests to fail until access is restored.
• For FedRAMP High and DoD IL2, IL4, and IL5, data residency requires subnets only in US regions, regional load balancers, and private connectivity such as Private Service Connect, Private Google Access, and private service access.