# GCP Audit Logging Not Enabled

> GCP projects whose IAM policy carries no auditConfigs block are flagged by RC-1254 as high severity: Data Access audit logs are off, so reads of user data leave no trail. Admin Activity logs stay on regardless, so the gap is data access. Detection fires only on an explicit false from the project scan.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-audit-logging-not-enabled
Updated: 2026-08-19

---

## Admin Activity is always logged, Data Access is not

Google keeps Admin Activity audit logs on for every project and will not let you disable
them, which lulls teams into believing "audit logging is on." What is off by default is the
other half: Data Access audit logs, the records of who *read* what. Without them, a
service-account key used to dump a storage bucket or query a database leaves no entry
anywhere. An auditor asking "show me who accessed customer data in March" gets an honest
answer of "we cannot know", which is the actual finding behind this rule's high severity.

## What a forensics gap looks like

Compromises are usually investigated backwards: an alert fires, then someone reconstructs
what the credential touched before detection. Admin Activity logs show resources created and
IAM grants changed, but the reads, the part that constitutes the breach, only exist if
Data Access logging was configured *before* the incident. Enabling it afterwards documents
the next breach, not this one. That asymmetry is why the rule flags the gap even for
projects that have never had an incident.

## How the project scan proves the condition

During ZopNight's IAM walk of each project (the same read-only pass that powers the
Gmail-account and service-account findings, running under `roles/iam.securityReviewer`),
the project's IAM policy is fetched, and that policy carries the `auditConfigs` section. If
any policy asset in the project has a non-empty `auditConfigs`, audit logging counts as
configured; the result is stamped as an explicit true or false on a synthetic per-project
resource. The rule fires only on the explicit false, so a partially scanned or cancelled
walk abstains rather than accusing a project it never finished reading.

## Read your project's auditConfigs

```bash
gcloud projects get-iam-policy PROJECT_ID --format="yaml(auditConfigs)"
```

Empty output reproduces the finding. A configured project lists services with their enabled
log types (`DATA_READ`, `DATA_WRITE`, `ADMIN_READ`).

## Enabling Data Access logs, and the cost caveat

Turn Data Access logs on per service under IAM & Admin → Audit Logs, or set an
`allServices` block in the policy for blanket coverage. One honest warning: on busy projects
these logs are voluminous: BigQuery and Cloud Storage reads can generate significant
logging volume and cost. Start with the services that hold sensitive data, add exemptions
for known-noisy service accounts, and route entries to a sink with a retention policy so
the trail survives longer than the default 30 days.