Back to controls

Ensure Cloud Audit Logging is configured properly across all services and all users from a project

It is recommended that Cloud Audit Logging is configured to track all Admin activities and read, write access to user data.

Category

Controls

Low

Applies to

Google Cloud

Coverage

1 queries

Asset types

1 covered

Overview

It is recommended that Cloud Audit Logging is configured to track all Admin activities and read, write access to user data.

Rationale

Cloud Audit Logging maintains two audit logs for each project and organization: Admin Activity and Data Access.

  1. Admin Activity logs contain log entries for API calls or other administrative actions that modify the configuration or metadata of resources. Admin Activity audit logs are enabled for all services and cannot be configured.
  2. Data Access audit logs record API calls that create, modify, or read user-provided data. These are disabled by default and should be enabled.

There are three kinds of Data Access audit log information:

  • Admin read: Records operations that read metadata or configuration information. Admin Activity audit logs record writes of metadata and configuration information which cannot be disabled.
  • Data read: Records operations that read user-provided data.
  • Data write: Records operations that write user-provided data.

It is recommended to have effective default audit config configured in such a way that:

  1. logtype is set to DATA_READ (to logs user activity tracking) and DATA_WRITES (to log changes/tampering to user data)
  2. audit config is enabled for all the services supported by Data Access audit logs feature
  3. Logs should be captured for all users. i.e. there are no exempted users in any of the audit config section. This will ensure overriding audit config will not contradict the requirement.

Remediation guidance

Google Cloud Remediation

Service-wide fix (recommended): enable Data Access audit logs at the organization or folder level where possible, so projects inherit a consistent logging baseline.

Google Cloud CLI

Read the current project IAM policy into a file:

gcloud projects get-iam-policy <project-id> > /tmp/policy.yaml

Edit only the auditConfigs section and preserve the existing bindings and etag values:

auditConfigs:
- service: allServices
  auditLogConfigs:
  - logType: DATA_READ
  - logType: DATA_WRITE

Apply the updated policy:

gcloud projects set-iam-policy <project-id> /tmp/policy.yaml

For organization-wide rollout, use the organization commands instead of the project commands:

gcloud organizations get-iam-policy <org-id> > /tmp/org-policy.yaml
gcloud organizations set-iam-policy <org-id> /tmp/org-policy.yaml

Operational notes

  • Admin Activity logs are always on. This remediation is about Data Access logging coverage.
  • set-iam-policy replaces the current IAM policy document. Preserve bindings and etag, and change only auditConfigs.
  • Enabling Data Access logs can materially increase log volume and cost, so define retention and export strategy before broad rollout.
  • BigQuery is an exception because many BigQuery audit logs are handled differently from other Google Cloud services.

References

  • https://cloud.google.com/logging/docs/audit/
  • https://cloud.google.com/logging/docs/audit/configure-data-access

Query logic

These are the stored checks tied to this control.

Cloud Audit Logging is configured properly across all services and all users from a project

Connectors

Google Cloud

Covered asset types

Connector

Expected check: eq []

GCPLogging1{...AssetFragment}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon