33 Audit-log export to SIEM/BigQuery

Caveats

• Enabling the export backfills history — roughly 180 days of activity data and 450 days of usage data land in BigQuery on first setup; anything older than those windows is gone for good.
• Activity events land in BigQuery within about 10 minutes; usage reports start after a 48-hour initial delay and can then lag 1–3 days — this is an archive and investigation substrate; alerting still comes from Alert center rules (№2, №3).
• BigQuery Export requires Enterprise Standard+, Education Standard+, Frontline Standard+ or Enterprise Essentials Plus — on other editions the Data integrations screen exists but the export card is gated.
• The exported dataset is only as immutable as the GCP project it lands in — a super admin who can delete the project can delete the evidence, which is what the Bucket-Locked sink in №60 is for.

Setup steps

1. 1. Open Data integrations and configure BigQuery Export, pointing it at a GCP project you control (billing enabled).
   open ↗

   

   https://admin.google.com/ac/reporting/bigqueryexport · captured 2026-07-15

   Reporting › Data integrations

   BigQuery Export = On; Project = <dedicated logging project>; grant gapps-reports@system.gserviceaccount.com the project Editor role (or an equivalent IAM editor role) on that project

2. 2. Select the dataset location and confirm the export covers activity events and usage reports.

   Reporting › Data integrations

   Dataset region

   matching your data-region policy (№26)

   export

   the date-partitioned activity + usage tables

3. 3. Sanity-check that the source logs (login, admin, Drive, token) are populated in-console before relying on the export; then wait one full day and confirm the activity table has a partition for that date.
   open ↗

   

   https://admin.google.com/ac/sc/investigation · captured 2026-07-15

   Reporting › Audit and investigation

   Verify the day's partition exists in the activity table (query _PARTITIONTIME)

4. 4. Set the BigQuery dataset/table retention beyond Workspace's own log-retention window (that is the entire point of the export), and feed the WORM archive (№60) and detection rules (№68) from it.

   Dataset default table expiration = never (or > your retention policy); onward sink to Bucket-Locked GCS

Ongoing maintenance

• automatable: script Daily: alert if the newest exported event is older than 24h (fold into №54 heartbeat).

How to verify

1. Query the newest partition and check freshness — an export that silently stopped is the failure mode that matters.

   bq query --use_legacy_sql=false 'SELECT MAX(time_usec) FROM `<project>.<dataset>.activity`'