GCP Cloud Audit Logs: Security Monitoring, SIEM Export, and Key Detections for Google Cloud
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
GCP Cloud Audit Logs are the forensic foundation of Google Cloud security. Without them enabled and exported, answering 'what happened?' after a security incident requires reconstructing activity from partial evidence — network flow logs, application logs, and whatever the affected service happens to retain. With a correctly configured Log Sink exporting to a SIEM, the same question is answered with a structured query that returns a timeline of API calls, permission changes, and data access events.
The most common gap: Admin Activity logs are enabled by default and capture configuration changes, but Data Access logs (who read what data) are disabled by default and require explicit enablement. The decision of which services to enable Data Access logging for, and the cost implications of that decision, is the configuration step that most GCP environments have not made deliberately.
Audit log configuration: enabling the right logs without runaway costs
GCP audit log configuration has two distinct parts: Admin Activity logs are always on and require no action, while Data Access logs must be deliberately enabled per service and can generate substantial Cloud Logging ingestion costs if enabled indiscriminately. The goal is comprehensive coverage of high-value services without generating log volumes that make cost prohibitive or signal-to-noise ratios unmanageable. This section covers which services warrant Data Access logging, how to use log exclusion filters to suppress high-volume low-value events within those services, and how to set up organization-level Log Sinks for both compliance retention and real-time SIEM streaming before a compliance deadline forces a retroactive gap assessment.
Enable Data Access logs for high-value services selectively
Enable Data Access logs at the organization level for: Secret Manager (DATA_READ: who is accessing secrets in production?), Cloud SQL (DATA_READ: who is running queries?), BigQuery (DATA_READ: who is reading production datasets?), Cloud Storage for buckets containing sensitive data (DATA_READ with a log filter that includes only specific bucket names). Do not enable DATA_READ for: Cloud Storage buckets serving static web assets (millions of requests per day, near-zero security value), Cloud Logging itself (recursive logging), or Cloud Pub/Sub in high-throughput messaging applications (extremely high volume). The correct implementation: enable Data Access logs at the organization level for the target services, then add log exclusion filters for specific resources within those services that generate high volume but low security value.
Configure organization-level Log Sink before you have a compliance deadline
Set up the organization-level Log Sink during the initial GCP environment setup, not when an auditor asks for 90 days of audit logs and you discover you have 30. An organization-level sink with includeChildren: true captures logs from all projects — including projects created after the sink is configured. The sink routes all audit logs to a Cloud Storage bucket (for archival) and a Pub/Sub topic (for SIEM real-time consumption). Configure both destinations from the same sink using separate sink entries: one sink to Cloud Storage for retention, one sink to Pub/Sub for SIEM. This architecture provides both compliance-grade retention and real-time detection from a single log source.
Detection rules and operational queries
Audit logs have value only when they are actively monitored with rules tuned to GCP-specific attack patterns. The two detection rules covered here — service account key creation and cross-project IAM grants — are high-fidelity indicators because both behaviors are rare in legitimate operations and common in compromise scenarios. Each rule requires understanding the relevant audit log field names (methodName, protoPayload.serviceData.policyDelta) and how to join audit log events against a reference of your project identifiers to identify anomalous cross-project patterns.
Service account key creation as a high-fidelity compromise indicator
Service account key creation (google.iam.admin.v1.CreateServiceAccountKey) is the most common persistence mechanism after a GCP environment compromise: an attacker who gains access to a GCP project creates a service account key for a service account with elevated permissions, exports the JSON key file, and uses it for persistent access even if the compromised user account is disabled. Detection: alert on any service account key creation for service accounts with project Owner, Editor, or any admin role. SIEM query (Splunk format): index=gcp_audit protoPayload.methodName=google.iam.admin.v1.CreateServiceAccountKey | join protoPayload.request.name [search index=gcp_iam | where match(role, 'Owner|Editor|admin')] | alert. Suppression: exclude known automation pipelines that legitimately create service account keys (CI/CD pipelines with a specific service account).
Cross-project IAM role grants as lateral movement indicator
Attackers who compromise a service account in one project frequently attempt to grant that service account access to other projects to move laterally to production or data environments. Detection: alert on any SetIamPolicy event where the principal being granted access (protoPayload.serviceData.policyDelta.bindingDeltas[].member) is a service account from a different project than the project where the policy is being changed. This cross-project pattern — a service account from project A being granted permissions in project B — is rare in legitimate operations and common in lateral movement. The detection query requires joining the binding delta's member field against a list of your project identifiers to identify cross-project grants.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
GCP Cloud Audit Logs are the baseline security data layer for any GCP environment — without them, investigations require guesswork and compliance audits require manual reconstruction of evidence. The configuration gap that most environments have is Data Access logs: Admin Activity is on by default and covers configuration changes, but Data Access for Secret Manager, Cloud SQL, and BigQuery must be explicitly enabled to capture data access events. Export via an organization-level Log Sink to both Cloud Storage (for 12-month compliance retention) and Pub/Sub (for SIEM real-time detection). The five detection rules that matter most — IAM SetIamPolicy, service account key creation, Cloud Storage public ACL changes, firewall rule permissive changes, and permission-denied anomaly spikes — should be active in your SIEM before you need them for an investigation.
Frequently asked questions
What are the three types of GCP Cloud Audit Logs and which are enabled by default?
GCP has three audit log types: (1) Admin Activity logs: enabled by default, always on, cannot be disabled. Capture: IAM policy changes (role grants and revocations), resource configuration changes (firewall rule changes, instance creation/deletion, Cloud Storage bucket creation, project creation and deletion), and API calls that write metadata. Retention: 400 days in Cloud Logging at no charge. (2) Data Access logs: disabled by default, must be explicitly enabled. Capture: reads of user data (Cloud Storage object reads, BigQuery queries, Cloud SQL queries), writes of user data, and data creation. Generating these for high-volume storage significantly increases Cloud Logging costs. Retention: 30 days in Cloud Logging at no charge; longer retention requires export to Cloud Storage or BigQuery. (3) System Event logs: enabled by default, generated by GCP systems, not by user or service account actions. Capture: GCP system maintenance events, live migration events, automatic scaling events. Retention: 400 days. For security monitoring: Admin Activity logs are the most important for detecting unauthorized access and misconfigurations. Data Access logs are required for data exfiltration detection.
How do I enable Data Access logs for my GCP organization?
Enable Data Access logs at the organization level (applies to all projects): in Google Cloud Console: go to IAM and Admin > Audit Logs. Select the organization from the resource selector. In the table, check DATA_READ and DATA_WRITE for the services you want to audit (common selections: Cloud Storage, BigQuery, Cloud SQL, Secret Manager, Compute Engine). Click Save. Using gcloud CLI: gcloud organizations get-iam-policy YOUR_ORG_ID --format json > policy.json. Edit policy.json to add auditConfigs for each service. gcloud organizations set-iam-policy YOUR_ORG_ID policy.json. Important: enable Data Access logs selectively by service rather than for all services. Enabling DATA_READ for high-volume Cloud Storage buckets that serve millions of requests generates enormous log volume and cost. Start with high-value services: Secret Manager (who is accessing secrets?), Cloud SQL (who is running queries against production databases?), BigQuery (who is reading production datasets?). Use log exclusion filters to exclude high-volume, low-security-value logs (static asset Cloud Storage buckets) while keeping logs for sensitive buckets.
How do I export GCP audit logs to a SIEM via Log Sink and Pub/Sub?
Log Sink to Pub/Sub setup: (1) Create a Pub/Sub topic to receive the logs: gcloud pubsub topics create gcp-audit-logs-topic. (2) Create a Log Sink at the organization level: gcloud logging sinks create gcp-audit-sink pubsub.googleapis.com/projects/YOUR_PROJECT/topics/gcp-audit-logs-topic --organization=YOUR_ORG_ID --include-children --log-filter='logName:cloudaudit.googleapis.com'. The --include-children flag captures logs from all projects in the organization. (3) Grant the Log Sink service account publish permission on the Pub/Sub topic: gcloud pubsub topics add-iam-policy-binding gcp-audit-logs-topic --member='serviceAccount:SINK_SERVICE_ACCOUNT' --role='roles/pubsub.publisher'. Get the sink's service account: gcloud logging sinks describe gcp-audit-sink --organization=YOUR_ORG_ID. (4) Configure your SIEM to subscribe to the Pub/Sub topic: most enterprise SIEMs (Splunk, Microsoft Sentinel, Chronicle, Elastic) have a native GCP Pub/Sub input. Configure a Pub/Sub subscription (gcloud pubsub subscriptions create audit-siem-sub --topic=gcp-audit-logs-topic) and point the SIEM to this subscription.
What are the most important GCP audit log detections to configure in a SIEM?
Priority GCP audit log detections: (1) IAM policy change: any change to organization-level or project-level IAM bindings — methodName: SetIamPolicy. Alert on: any role grant at the organization level, any grant of Owner or Editor roles at the project level, any grant of sensitive roles (roles/iam.securityAdmin, roles/storage.admin, roles/bigquery.admin). (2) Service account key creation: methodName: google.iam.admin.v1.CreateServiceAccountKey. Alert on: any service account key creation, especially for service accounts with elevated permissions. Service account keys are a common target for credential theft. (3) Firewall rule changes allowing inbound access: methodName: v1.compute.firewalls.insert or patch where the rule allows ingress from 0.0.0.0/0. (4) Cloud Storage bucket made public: methodName: storage.buckets.setIamPolicy where the new policy grants roles/storage.objectViewer to allUsers or allAuthenticatedUsers. (5) Cryptomining indicator: unusually high Compute Engine instance creation (more than 5 instances in 1 hour from a single service account or user), especially for GPU or high-CPU machine types. (6) Failed authentication surge: protoPayload.status.code = 7 (PERMISSION_DENIED) — a spike in permission denied events for a single principal may indicate credential stuffing or a compromised account attempting lateral movement.
How do I query GCP Cloud Audit Logs in the Console and with gcloud?
Cloud Logging query syntax for audit logs: In Cloud Console Logs Explorer: (1) Find all Admin Activity logs: logName='projects/YOUR_PROJECT/logs/cloudaudit.googleapis.com%2Factivity'. (2) Find IAM role changes: logName=~'cloudaudit.googleapis.com/activity' protoPayload.methodName='SetIamPolicy'. (3) Find actions by a specific user: protoPayload.authenticationInfo.principalEmail='user@example.com'. (4) Find all API calls in the last hour that resulted in changes: logName=~'cloudaudit.googleapis.com/activity' timestamp>='2026-07-10T00:00:00Z'. Using gcloud: gcloud logging read 'logName=projects/YOUR_PROJECT/logs/cloudaudit.googleapis.com%2Factivity AND protoPayload.methodName=SetIamPolicy' --project=YOUR_PROJECT --limit=100 --format=json. For cross-organization queries: BigQuery log sink provides the most powerful query capability — export all audit logs to BigQuery and use SQL to query across projects and time ranges: SELECT protoPayload.authenticationInfo.principalEmail, protoPayload.methodName, resource.labels.project_id, timestamp FROM audit_logs.cloudaudit_googleapis_com_activity WHERE DATE(timestamp) = '2026-07-10' ORDER BY timestamp DESC.
How long are GCP Cloud Audit Logs retained by default and how do I extend retention?
Default GCP Cloud Logging retention: Admin Activity logs: 400 days. Data Access logs: 30 days. System Event logs: 400 days. For compliance frameworks that require longer retention: PCI DSS requires 12 months with 3 months immediately available. HIPAA requires 6 years. SOC 2 requires evidence for the audit period (typically 12 months). To extend retention: (1) Cloud Storage export via Log Sink: configure a Log Sink to export all audit logs to a Cloud Storage bucket with the lifecycle policy set to your retention requirement (1 year, 3 years, 7 years). This is the most cost-effective long-term retention option. (2) BigQuery export: export to BigQuery for retention periods where you need to query historical logs (BigQuery is expensive for pure archival but excellent for investigation queries across large historical datasets). (3) Update Cloud Logging retention directly: in Cloud Console > Logging > Log Storage, select _Default log bucket > Edit retention. You can extend the in-Cloud Logging retention from 30 days up to 3,650 days (10 years) — extended retention in Cloud Logging is charged at the current log storage rate. For compliance: use Cloud Storage export for archival (inexpensive), and keep the Cloud Logging in-console retention at 90 days for fast querying of recent events.
What IAM permissions do I need to view and manage GCP Cloud Audit Logs?
IAM roles for Cloud Audit Logs: (1) View logs: roles/logging.viewer grants read access to non-Data Access logs. roles/logging.privateLogViewer also grants access to Data Access logs and system logs. Assign to: SOC analysts who need to query audit logs for investigations. (2) Configure audit policy (enable/disable Data Access logs): requires resourcemanager.organizations.setIamPolicy at the organization level, or resourcemanager.projects.setIamPolicy at the project level. This is part of roles/resourcemanager.organizationAdmin or roles/iam.securityAdmin. (3) Create and manage Log Sinks: roles/logging.configWriter. Assign to: the identity that sets up SIEM export. (4) View audit log policy configuration: roles/logging.configViewer. (5) Restrict access to sensitive Data Access logs: use Log Views (a Cloud Logging feature) to create a filtered view of logs that exposes only Admin Activity logs to analysts who should not see data access events. Access to Data Access logs for services like Secret Manager (which captures which secrets were accessed) may need to be restricted to a subset of security analysts. Avoid granting roles/logging.admin broadly — it includes the ability to delete logs and modify retention settings.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.