How to turn on organization-wide audit logs in Google Cloud

• Permissions: a role with resourcemanager.organizations.setIamPolicy to change the audit configuration, and getIamPolicy to read it. To create organization sinks you need Owner, Logging Admin or Logs Configuration Writer.
• Reading the logs later: Private Logs Viewer (roles/logging.privateLogViewer). Google notes that the Editor role does not include the permissions to view Data Access logs.
• Tools: Google Cloud console and the gcloud CLI. Find your organization ID with gcloud organizations list.
• Know the defaults: Admin Activity audit logs are always on and cannot be disabled. Data Access logs are off by default for most services (some BigQuery logs are on and cannot be disabled).
• Cost: Google warns that Data Access log volume can be large and may add charges. Review Cloud Logging pricing and decide on a retention plan first.

1. Read the current state first. Run the read-only commands in the next section so you know what is already enabled.
2. Open the audit log settings. In the console go to IAM & Admin > Audit Logs and select your organization at the top.
3. Choose services. In the Data Access audit logs configuration table select the services you want, or all of them, then on the Permission types tab tick Admin Read, Data Read and Data Write as needed and click Save.
4. Set defaults for future services. Click Set Default Configuration, choose the log types and save, so new services are covered automatically.
5. Optional: use the CLI instead. Export the policy, edit only the auditConfigs section and write it back (see Change 1 below). Keep bindings and etag intact.
6. Collect the logs centrally. Create an aggregated sink at organization level with --include-children, pointing at a log bucket, Cloud Storage bucket or BigQuery dataset that your security team controls (Change 2 below), then grant the sink's writer identity access to the destination.
7. Alert on audit changes. Create a log-based metric and alert for changes to the audit configuration so nobody can quietly switch logging off.

These commands only read. Replace ORGANIZATION_ID with your numeric organization ID.

gcloud organizations get-iam-policy ORGANIZATION_ID --format="yaml(auditConfigs)"

gcloud logging sinks list --organization=ORGANIZATION_ID

What good looks like: the first command shows an entry for allServices (or each service you chose) with ADMIN_READ, DATA_READ and DATA_WRITE, and the second lists your aggregated sink. Also run gcloud projects get-iam-policy PROJECT_ID --format="yaml(auditConfigs)" on a few projects, because folders and projects can carry their own audit configuration. Then open Logging > Logs Explorer and confirm Data Access entries arrive in the destination.

Changes (these modify your Google Cloud organization)

Change 1: enable all Data Access logs for all services. Export, edit, write back:

gcloud organizations get-iam-policy ORGANIZATION_ID > /tmp/policy.yaml
# edit /tmp/policy.yaml: add or change only the auditConfigs section
#   auditConfigs:
#   - auditLogConfigs:
#     - logType: ADMIN_READ
#     - logType: DATA_WRITE
#     - logType: DATA_READ
#     service: allServices
gcloud organizations set-iam-policy ORGANIZATION_ID /tmp/policy.yaml

Warning: if you drop the bindings section from the file, the command removes the bindings and can cut off all access. Keep the etag line so concurrent changes are detected. If the command reports a conflict, start again from the export.

Change 2: create an organization-wide sink.

gcloud logging sinks create SINK_NAME SINK_DESTINATION --include-children --organization=ORGANIZATION_ID --log-filter="logName:cloudaudit.googleapis.com"

Then read the sink's writerIdentity with gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID and grant it the matching writer role on the destination project (for example roles/logging.bucketWriter for a log bucket) with gcloud projects add-iam-policy-binding.

• Overwriting the policy. Editing the exported file and losing bindings or etag can remove access for everyone.
• Assuming Data Access logs are on. Only Admin Activity logs are always on. Most services need Data Access logging enabled.
• Skipping the cost check. Enabling everything on high-traffic services can produce very large volumes.
• Forgetting future services. Without a default configuration, newly added services are not covered.
• A sink that cannot write. Without the writer identity role on the destination, no entries arrive.
• Only checking the organization. Folders and projects can have their own audit configuration, so spot-check them.
• Nobody can read the logs. Grant Private Logs Viewer to the people who need Data Access entries.

ConfigCobra is read-only and never changes your Google Cloud organization. It connects with a read-only service account with viewer-level roles, scans every project in the organization or a selected list, and shows a Google Cloud resource inventory. Findings are based on the CIS Google Cloud Platform Foundation Benchmark v5.0.0 (93 controls), including the logging checks linked below. Every connected cloud is scanned automatically every day, you can start an ad hoc scan any time, and you can be alerted when a control regresses. Start with the 14-day free trial, which has full access.