On Google Cloud, Admin Activity audit logs are always written and cannot be disabled, but Data Access logs are off by default for most services. To build a usable audit trail, enable Data Access logs where they matter, route logs to a separate protected destination, and restrict who can read them.
What audit logs does Google Cloud write?
Cloud Audit Logs produces four kinds for each project, folder and organization: Admin Activity, Data Access, System Event and Policy Denied. Google documents that entries written by Cloud Audit Logs are immutable.
Admin Activity logs record API calls and actions that change configuration or metadata, such as creating a VM or changing IAM permissions. They are always written, and even disabling the Cloud Logging API does not stop them. System Event logs, which record Google-initiated changes, are also always on.
Why is Data Access the one that bites?
Except for BigQuery, Data Access audit logs are disabled by default, because they can produce large volumes. Those logs record who read or wrote user-provided data. If a storage bucket leaks and you never enabled them, you can tell who changed the bucket's permissions but not who read the files.
So the setup question is not "are logs on" but "which reads and writes do we need to prove later." A constructed example: a finance team keeps payroll exports in one bucket. They enable Data Access logs for Cloud Storage on that one project and leave them off in a sandbox project, accepting the cost where the evidence has value.
How do logs get stored and routed?
Logging automatically creates two buckets per project, folder and organization, called _Required and _Default, with matching sinks. The _Required bucket stores Admin Activity and System Event logs, and you cannot prevent that. Data Access logs go to _Default unless you change routing.
Routing is done with sinks, which compare each entry against an inclusion filter and send matches to a destination. Aggregated sinks at the folder or organization level can collect logs from every child project. Google also notes that an entry is always sent to the _Required sink in the project where it originated, even when an aggregated sink intercepts it.
Why route elsewhere? Because the project owner can usually change the project. A copy sent to a bucket in a separate, tightly held logging project is evidence that the people being audited cannot easily edit.
Who should be able to read them?
Viewing needs IAM roles. The Logs Viewer role reads Admin Activity, Policy Denied and System Event logs. Reading Data Access logs requires the Private Logs Viewer role. That split is deliberate: Data Access entries can contain sensitive details. Grant the private role to a short, named list.
How to check or apply this
- Decide which services and projects hold data whose access you must be able to prove, and list them.
- Enable Data Access audit logs for those services through the IAM audit configuration.
- Create an aggregated sink at the organization or folder level that sends audit logs to a dedicated logging project.
- Set retention on the destination bucket to match your policy, and confirm the setting rather than assuming the default.
- Restrict Private Logs Viewer and write access on the logging project.
- Once a quarter, pick one past event, such as a permission change, and trace it through the logs to prove the trail answers real questions.
Auditors ask for exactly this kind of evidence. Safeguard's compliance automation can collect evidence from connected systems, but the configuration above is yours to make in your cloud.
Quick check
Can an administrator turn off Admin Activity logs?
No. Google documents that Admin Activity audit logs are always written and cannot be configured, excluded or disabled.
Why route audit logs to a separate project?
So the people whose actions are being logged cannot easily change or delete the copy used as evidence.
Sources
Last reviewed: 18 October 2026.
