What breaks when Cloud Audit Logs are not configured for both Admin Activity and Data Access in GCP?

Why This Matters for Security Teams

Cloud audit logs are one of the few sources that can tie privileged actions to an actor, a time, and a resource in a shared cloud environment. When Admin Activity is on but Data Access is missing, teams still see control-plane changes, but they lose the data-plane evidence needed to answer a basic incident question: what was actually touched. That gap matters for ransomware triage, insider-risk review, KMS misuse, and post-incident scoping. The NIST Cybersecurity Framework 2.0 treats visibility and detection as core capabilities, and that logic applies directly here.

The practical failure is not just “less logging.” It is the inability to prove whether a service account read a secret, whether a storage object was exfiltrated, or whether a decrypt operation was part of normal service behavior or suspicious use. That distinction becomes critical when identity is non-human, because workload credentials often act at machine speed and leave little room for manual reconstruction. In practice, many security teams discover the gap only after a containment decision has already been made with incomplete evidence, rather than through intentional log validation.

How It Works in Practice

In GCP, Admin Activity logs capture management-plane actions such as creating resources, changing IAM policy, or modifying logging settings. Data Access logs cover data-plane events such as reading storage objects, querying datasets, and certain KMS operations. The control value comes from combining both. Admin Activity shows who changed the environment; Data Access shows what was accessed, when, and sometimes by which principal. The overlap is what supports reliable incident reconstruction.

For security operations, this usually means three things:

• Confirm that Admin Activity logs are retained centrally and protected from tampering.
• Enable Data Access logging for high-value services, especially Cloud Storage, BigQuery, Secret Manager, and Cloud KMS.
• Test whether the logging policy actually captures the use cases that matter most to the business, including service accounts and automation.

That third point is where teams often overestimate coverage. A policy may be technically enabled, yet still omit the services that hold sensitive data or the projects where automation runs. For example, encryption or decryption activity may be visible only if the relevant KMS audit category is turned on and routed into the SIEM. Without that, investigators can see a resource was changed, but not whether protected data was ever accessed.

This aligns with logging and monitoring expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and the detection-focused outcomes in CIS Controls v8. For environments using non-human identities, the OWASP Non-Human Identity Top 10 is a useful reminder that service account actions must be observable, not merely permitted. These controls tend to break down when organisations rely on default logging settings in multi-project GCP estates because coverage varies by service, project, and retention path.

Common Variations and Edge Cases

Tighter audit logging often increases storage, query, and operational overhead, requiring organisations to balance investigation depth against cost and noise. Current guidance suggests enabling Data Access selectively for the systems that matter most, rather than trying to log every possible event everywhere. There is no universal standard for this yet, because business impact and data sensitivity vary widely.

Edge cases usually appear in fast-moving environments. Shared service projects can hide the true data owner. Ephemeral workloads may generate legitimate access that looks suspicious without workload identity context. Federated and automated access can also confuse attribution unless the logs are correlated with the identity source, the workload, and the downstream resource. This is especially important when GCP workloads use secrets or KMS keys indirectly through automation rather than through a human operator.

For teams mapping this to governance, the operational question is not whether logging exists, but whether it is sufficient to answer who accessed what, through which identity, and with what impact. That is the standard that matters for resilient monitoring, especially where NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 are being used as control baselines. In GCP estates with many ephemeral service accounts, the guidance breaks down when logs are enabled but not centralized, because the evidence disappears into separate projects before responders can correlate it.

Related resources from NHI Mgmt Group

• What breaks when audit logs do not include access rationale?
• What breaks when serviceData is empty in GCP audit logs?
• What breaks when security teams rely only on cloud audit logs for NHI ownership?
• What breaks when cloud environments cannot produce audit-ready access evidence?