GCP Cloud Audit Logs Explained: Types, Retention, and Use Cases

What Cloud Audit Logs are

Cloud Audit Logs capture API activity against Google Cloud services. Every time a GCP service API is called (whether by a human using the Console, a developer running gcloud, a Terraform plan, or a service account in a pipeline), that call can generate an audit log entry recording the identity, the action, the resource, and the outcome.

They answer four questions no other log type answers together: who made the call, what action they took, which resource was affected, and whether it succeeded. This is why audit logs are the starting point for incident investigations, privilege audits, and compliance reporting.

Cloud Audit Logs are distinct from application logs your code writes. If your application calls an internal API and logs the result, that is a workload log. If a service account reads a BigQuery table, that is an audit log entry. Both matter, but they capture different things. For a full picture of all GCP log families, see GCP Log Types.

Why Cloud Audit Logs matter

Consider an investigation where a BigQuery dataset was accessed without authorisation. The attacker had valid credentials. Without Data Access logs enabled for BigQuery, there is no record of which tables were read, from which IP, or over which time period. The investigation stalls. There is no timeline to reconstruct, no evidence to show affected parties, and no way to confirm the scope of the breach.

Audit logs are also the foundation for compliance. SOC 2, ISO 27001, HIPAA, and PCI-DSS all require demonstrable audit trails for privileged operations and data access. A compliance audit that finds gaps in logging coverage is far harder to remediate than one that finds a retention period issue.

Beyond incidents and compliance, audit logs are useful day-to-day: confirming that a config change was applied, tracking which service account created a resource, or understanding why a deployment failed due to a permissions issue.

How Cloud Audit Logs work

When a GCP API call is made, the underlying service evaluates whether to generate an audit log entry based on the type of action. Some actions always generate entries. Others generate entries only if audit logging has been explicitly enabled for that service. The four log types reflect these two categories.

Audit log entries flow into Cloud Logging automatically. No agents need to be installed and no log forwarding needs to be configured. Once an action generates an entry, it appears in Cloud Logging within seconds and is immediately queryable in Logs Explorer or via the gcloud CLI.

Entries are retained for a fixed period depending on log type. After that period, they are deleted unless you have set up a log sink to export them to a longer-term destination. A log sink routes matching entries to Cloud Storage, BigQuery, Pub/Sub, or a custom Log Bucket as they arrive. It does not backfill historical entries, so sinks must be created before you need the data.

Access to audit logs is controlled by IAM. Viewing Admin Activity logs requires roles/logging.viewer or equivalent. Viewing Data Access logs additionally requires roles/logging.privateLogViewer, because those entries can contain sensitive metadata about what data was accessed and by whom.

The four Cloud Audit Log types

Admin Activity logs

Admin Activity logs record API calls that modify the configuration or metadata of a GCP resource. Examples include creating a Compute Engine VM, updating a firewall rule, modifying an IAM policy binding, enabling a service, or granting project-level permissions.

These logs are always enabled and cannot be disabled. They are retained for 400 days at no charge. Admin Activity logs are the non-negotiable baseline: they cover every configuration change in the environment and are the first place to check when something changed unexpectedly.

Example events: SetIamPolicy, CreateServiceAccount, CreateFirewallRule, DeleteBucket.

Data Access logs

Data Access logs record API calls that read configuration or metadata, or that create, read, update, or delete user-provided data. These are the logs that reveal what data was accessed and by whom. Admin Activity logs do not provide this visibility on their own.

Data Access logs are disabled by default for most services. You must enable them explicitly per service. The exception is BigQuery, which enables Data Access logs by default. They are retained for 30 days and incur storage costs at scale. That is why they are opt-in rather than universal.

Data Access logs are split into three sub-types, enabled separately per service:

• ADMIN_READ: reads of resource metadata and configuration, such as GetIamPolicy or ListBuckets

• DATA_READ: reads of user data, such as storage.objects.get or querying a BigQuery table

• DATA_WRITE: writes of user data, such as storage.objects.insert or writing rows to a BigQuery table

For sensitive services like Cloud Storage buckets with PII, Secret Manager, or BigQuery datasets with regulated data, enable at minimum DATA_READ and DATA_WRITE. ADMIN_READ is useful for tracking reconnaissance activity such as listing resources or checking permissions.

System Event logs

System Event logs record Google-initiated administrative actions on your resources. These are events that happen automatically as part of GCP infrastructure operations rather than being triggered by a user or service account. Examples include live migration of a Compute Engine VM to new hardware, automatic scaling of a managed instance group, or scheduled maintenance on Cloud SQL.

These logs are always enabled, retained for 400 days, and cannot be disabled. They are most useful for operational troubleshooting: if a VM restarted unexpectedly, System Event logs can confirm whether Google performed a live migration during that window.

Policy Denied logs

Policy Denied logs are generated when a principal is denied access because of a VPC Service Controls perimeter violation. When a request crosses a perimeter boundary from an untrusted context (wrong network, wrong project, or wrong access level), a Policy Denied entry is written automatically.

These logs are retained for 400 days and require no additional enablement. They serve two purposes: security monitoring for detecting access attempts from unexpected contexts, and dry-run analysis for understanding which requests a new perimeter would block before enforcement is switched on.

Cloud Audit Logs vs other GCP log types

Cloud Audit Logs are one of several log families in GCP. Each answers a different security question. For a detailed breakdown of all log families, see GCP Log Types.

What is inside an audit log entry

Each audit log entry is a structured JSON object. The fields most useful for investigations are in the protoPayload section:

• protoPayload.methodName: the API method called, such as SetIamPolicy or storage.objects.get

• protoPayload.authenticationInfo.principalEmail: the identity (user or service account) that made the call

• protoPayload.resourceName: the specific resource acted on, such as a bucket name or project ID

• protoPayload.requestMetadata.callerIp: the source IP address of the caller

• protoPayload.status.code: gRPC status code. 0 means success, 7 means PERMISSION_DENIED

• timestamp: when the event was recorded

In practice, an investigation typically starts by filtering on methodName to find the relevant action, then pivoting on principalEmail and callerIp to understand who performed it and from where.

{
  "protoPayload": {
    "methodName": "SetIamPolicy",
    "authenticationInfo": {
      "principalEmail": "admin@example.com"
    },
    "resourceName": "projects/my-app-prod",
    "requestMetadata": {
      "callerIp": "203.0.113.42"
    },
    "status": {
      "code": 0
    }
  },
  "timestamp": "2026-03-15T02:14:33Z",
  "logName": "projects/my-app-prod/logs/cloudaudit.googleapis.com%2Factivity"
}

How to view and query audit logs

Audit logs can be queried in Logs Explorer in the Cloud Console or using the gcloud CLI. Logs Explorer is better for exploration and ad-hoc investigation. gcloud is better for scripting and quick terminal lookups.

# Find all IAM policy changes in a project
gcloud logging read \
  'logName="projects/my-app-prod/logs/cloudaudit.googleapis.com%2Factivity"
  AND protoPayload.methodName="SetIamPolicy"' \
  --project=my-app-prod \
  --limit=20 \
  --format='table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.resourceName)'

# Find service account key creation events
gcloud logging read \
  'logName="projects/my-app-prod/logs/cloudaudit.googleapis.com%2Factivity"
  AND protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"' \
  --project=my-app-prod \
  --limit=20 \
  --format='table(timestamp,protoPayload.authenticationInfo.principalEmail)'

# Check which services have Data Access logs enabled on a project
gcloud projects get-iam-policy my-app-prod \
  --format=json | jq '.auditConfigs'

In Logs Explorer, use the Log name filter to separate Admin Activity entries from Data Access entries. You can build complex filters with the query bar and save them as named queries for recurring investigations. For proactive detection, use log-based metrics to count occurrences of high-risk events and trigger Cloud Monitoring alerts.

When to use Cloud Audit Logs

Cloud Audit Logs are the right tool for any question about what happened at the GCP API level:

• Investigating IAM changes: who granted a role, when, and to which principal. Filter on SetIamPolicy in Admin Activity logs.

• Checking who accessed sensitive data: which identity read a Cloud Storage object or queried a BigQuery table. Requires Data Access logs to be enabled for those services.

• Monitoring Secret Manager access: which service accounts or users accessed a Secret Manager secret version and when. Requires DATA_READ enabled for the Secret Manager service.

• Tracking service account key creation: service account keys are high-risk credentials. Every creation event is visible in Admin Activity logs and should trigger an alert in most environments.

• Validating VPC Service Controls denials: Policy Denied logs show exactly which requests were blocked by a service perimeter and why, making them essential during perimeter design and dry-run analysis.

• Supporting compliance audits: auditors typically require evidence of who had access, what they did, and when. Admin Activity and Data Access logs together provide this trail across all GCP services.

• Investigating unexpected resource changes: if a Compute Engine instance was deleted or a firewall rule was modified, Admin Activity logs show the exact API call, identity, and timestamp.

For the detection side, see Detecting Suspicious Activity with Logs for how to build real-time alerts on high-risk events.

Retention and long-term storage

Default retention periods in Cloud Logging:

• Admin Activity, System Event, and Policy Denied: 400 days at no charge

• Data Access logs: 30 days, with storage costs at scale

A log sink routes matching log entries to a destination as they arrive. Supported destinations are:

• Cloud Storage: low-cost archival in JSON format, good for compliance retention where querying speed is not critical

• BigQuery: SQL-based analysis across large log volumes and long time windows; best for structured investigation and reporting

• Pub/Sub: real-time streaming to external SIEM tools or custom alerting pipelines

• Log Buckets: custom Cloud Logging storage with configurable retention up to 3,650 days

# Create a log sink that exports all audit logs to BigQuery
gcloud logging sinks create audit-logs-bq \
  bigquery.googleapis.com/projects/my-security-proj/datasets/audit_logs \
  --log-filter='logName:"cloudaudit.googleapis.com"' \
  --project=my-app-prod

# The sink creates a service account. Grant it write access to the destination.
# gcloud displays the service account identity after creation.