ServicesHow We WorkOur ProductsBlogsAbout UsGet Started
arrow_backBack to Blogs
Engineering BlogsSeptember 14, 2026

Continuous Monitoring on Google Cloud: How Audit Logs Catch What Point-in-Time Reviews Miss

G

Gagan Kataria

Diagram showing Cloud Audit Logs flowing into Security Command Center and a SIEM for continuous detection on Google Cloud

Every post in this series so far has been about getting something configured correctly: the edge, the network, the identity layer, the API, the background worker. All of that work shares one blind spot. A control that was correct on the day you deployed it says nothing about whether it's still correct six months later, after three engineers have touched the IAM bindings and nobody remembers why a service account got an extra role.

Part 1 covered defense-in-depth for the application itself. Part 2 took the OWASP API Top 10 to the APIs behind it. Part 3 extended that to workers and pipelines nobody puts in front of a pentester. This post is about the layer that sits underneath all three: how you actually find out when one of those controls has drifted, failed, or been quietly bypassed — before an attacker's dwell time outlasts your attention span.

Key Takeaways

  • Global median dwell time rose to 14 days in 2025, up from 11 in 2024, and organizations that caught intrusions themselves still took a median of 9 days — external notification cases took 25 (Mandiant M-Trends 2026, 2026).
  • The gap between initial access and hand-off to a second attacker group fell from over eight hours in 2022 to 22 seconds in 2025 — automated detection has to move faster than a human reading a dashboard (Mandiant M-Trends 2026, 2026).
  • 73% of organizations name false positives as their top detection challenge, and "very frequent" false positives jumped from 13% to 20% year over year — more alerts without better triage makes detection worse, not better (SANS 2025 Detection & Response Survey, via Stamus Networks, 2025).
  • Data Access audit logs — the ones that show who actually read or wrote your data — are disabled by default on GCP for every service except BigQuery, and have to be turned on explicitly (Google Cloud, Cloud Audit Logs best practices, retrieved 2026-09-12).

Why a Correct Control Today Doesn't Mean a Secure System Tomorrow

Here's the uncomfortable math behind this post: mean time to identify and contain a breach across the industry sits at 241 days — the lowest it's been in nine years, and still the better part of a full year (IBM Cost of a Data Breach Report 2025, 2025). Meanwhile, the handoff between an attacker gaining access and a second group weaponizing it dropped to 22 seconds in 2025, down from over eight hours in 2022 (Mandiant M-Trends 2026, 2026). Defense has gotten a little faster. Attack has gotten enormously faster. A quarterly architecture review, however good, is not built for that gap.

This is the part point-in-time security work structurally can't fix: every post in this series described a correct configuration at a moment in time, and every one of those configurations decays. Someone adds roles/editor to unblock a Friday deploy and forgets to revert it. A firewall rule gets widened for a debugging session that never gets narrowed back. None of that shows up in the architecture diagram — it shows up in the audit logs, if anyone's actually looking at them.

We touched on the identity side of this drift in our post on why service accounts are the right way to authenticate cloud workloads — a correctly scoped account on day one is necessary but not sufficient. Isn't it worth asking who's checking that scope stays correct on day 180?

What Cloud Audit Logs Actually Give You (and What They Don't by Default)

Google Cloud generates four categories of audit log: Admin Activity and System Event logs, which are always on and free; and Data Access and Policy Denied logs, which are configurable and, critically, not on by default for most services (Google Cloud, Cloud Audit Logs best practices, retrieved 2026-09-12). Data Access logs are the ones that actually tell you who read a row in a database or downloaded an object from a bucket — the exact evidence you'd want after a suspected data pipeline compromise like the one we covered in Part 3. If you haven't explicitly turned them on, that evidence doesn't exist.

In every environment we've onboarded that hadn't had a security review before, Data Access logging was off somewhere it mattered — usually Cloud Storage or a sensitive BigQuery dataset. Nobody had disabled it on purpose. It was simply never turned on, because it isn't the default, and defaults are what most teams ship with.

The second half of the equation is retention and routing. Google lets you configure log retention anywhere from 1 to 3,650 days, but logs sitting in a bucket aren't monitoring — they're an archive. The best-practice pattern routes audit logs through sinks to Cloud Storage for long-term retention, BigQuery for ad hoc investigation, and Pub/Sub for real-time downstream processing into a SIEM (Google Cloud, Cloud Audit Logs best practices, retrieved 2026-09-12). Logs you never route anywhere are logs nobody will read until after the incident, when someone finally goes looking.

Audit log flow from GCP services through sinks into detection and storageAdmin Activityalways onData Accessoff by defaultLog Sinkroutes the streamPub/Sub → SIEMSecurity Command CenterBigQuery (investigation)
Source: Google Cloud, Cloud Audit Logs best practices, retrieved 2026-09-12

From Logs to Detection: Security Command Center and Log-Based Alerts

Collecting logs and detecting threats are two different problems, and GCP's answer to the second is Security Command Center. It runs Security Health Analytics for misconfigurations, and Event, Container, and VM Threat Detection for active threat indicators, checked against frameworks like CIS Benchmark, ISO 27001, NIST 800-53, and PCI DSS — and Google's own guidance is to enable all of the built-in services rather than picking a subset, specifically because new resource types get continuous coverage automatically (Google Cloud, Security Command Center best practices, retrieved 2026-09-12).

What actually makes this useful day to day is triage, not coverage. Security Command Center scores findings by attack exposure against a "high-value resource set" you define — the datasets and services that would actually hurt if compromised — and supports dynamic mute rules that suppress low-priority findings temporarily rather than forever, so noise doesn't quietly become a permanent blind spot (Google Cloud, Security Command Center best practices, retrieved 2026-09-12). Findings export continuously to Pub/Sub and stream into BigQuery, and connect natively to Splunk, Elastic Stack, QRadar, and several other SIEMs if your team already lives in one of those tools.

None of this replaces the log-based alerting Cloud Logging offers directly — a narrower, cheaper tool for the specific events you already know matter: a particular IAM role being granted, a firewall rule being loosened, a Data Access log appearing on a dataset that should never see reads outside business hours. Start there. It's a smaller lift than a full SIEM rollout and it catches the exact class of drift this whole post is about.

The Alert Fatigue Problem

More monitoring is not automatically better monitoring. 73% of organizations now name false positives as their number one detection challenge, and the share reporting "very frequent" false positives climbed from 13% to 20% in a single year (SANS 2025 Detection & Response Survey, via Stamus Networks, 2025). An alerting setup that pages someone for every Data Access log entry will get its alerts muted within a week — not because the team doesn't care, but because a human can't sustain triage at that volume.

The pipelines we've seen actually get watched long-term are the ones with a short, deliberate alert list: privileged role grants, changes to VPC firewall rules, service account key creation, and access patterns on a named set of sensitive resources — not "alert on everything Cloud Audit Logs produces." A five-item watchlist someone actually reads beats a fifty-item one that gets muted by month two.

It's worth asking, before adding another alert: will someone actually act on this at 2 a.m., or will it just add to the 20% climbing toward "very frequent" noise? If the honest answer is the latter, that alert belongs in a weekly review dashboard, not a page.

How We Configure Continuous Monitoring at Enerasoft

For every GCP environment we stand up, monitoring isn't a separate project bolted on after launch — it's part of the same deployment. We enable Data Access logs on anything touching customer or regulated data from day one, not as an afterthought once something goes wrong. Security Command Center's built-in services run against a defined high-value resource set so attack-exposure scoring actually means something, with dynamic mute rules doing the noise reduction instead of a human scrolling through hundreds of low-priority findings. Audit logs route through sinks to BigQuery for investigation and Pub/Sub for anything that needs a downstream SIEM or a Cloud Run function to act automatically. And the log-based alert list stays short and specific — role grants, firewall changes, key creation — because a watchlist nobody reads is worse than no watchlist at all.

If you're trying to figure out what to actually turn on versus what will just generate noise, we'd be glad to talk it through.

Frequently Asked Questions

Do we need a full SIEM, or is Security Command Center enough on its own?

For most GCP-only environments, Security Command Center plus targeted log-based alerts covers the bulk of detection needs without added tooling cost. A SIEM earns its place when you're correlating signals across multiple clouds, on-prem systems, or a security team that already standardizes on one — Security Command Center is built to feed that SIEM rather than compete with it.

Why enable Data Access logs if they cost extra and generate huge volume?

Because they're the only log type that shows who actually touched your data, and that's precisely the evidence a Data Access log absence can't retroactively provide after an incident. Scope them to the datasets and buckets that matter rather than turning them on universally, which keeps both the cost and the noise manageable.

How often should we review Security Command Center findings versus just alerting on them?

Reserve real-time alerts for a short list of high-severity, well-understood events — privileged role grants, key creation — and route everything else into a weekly or biweekly review. Mandiant's data shows self-detected intrusions still take a median of 9 days to find (M-Trends 2026, 2026), so a weekly cadence isn't a compromise — it's already faster than the industry median as long as it actually happens.

Does this apply the same way to the background pipelines covered in Part 3?

Yes, and arguably more urgently. Part 3 covered scoping the identities those pipelines run as; this post covers verifying those identities haven't quietly picked up extra permissions since. Pipelines are exactly the workloads nobody watches manually, which makes audit-log-driven alerts on their service accounts more valuable than the equivalent alerts on a user-facing service someone's already staring at.

Closing Thoughts

This post closes the loop this series opened with defense-in-depth: a correctly configured edge, network, identity layer, API, and pipeline only stay correct if something is watching for the moment they don't. Global median dwell time still sits at 14 days, and even organizations that catch problems themselves take a median of 9 days to do it. Audit logs, Security Command Center, and a short, deliberate alert list are how that gap closes — not by adding more alerts, but by watching the right small number of things consistently.

Together, VPC, service accounts, application security, API security, pipeline security, and this post on detection form a complete pass over how we think about securing a GCP application end to end. Future posts in this series will likely return to sharper, more specific topics as they come up — compliance mapping, incident response playbooks, or whatever the next architecture review surfaces.

Sources

Written by Gagan Kataria, Founder & CEO at Enerasoft Technologies LLP — an AI-powered software and cloud engineering company based in Hisar, Haryana, India. This is Part 4 of the Cloud Security series.

Continuous MonitoringCloud Audit LogsSecurity Command CenterGCPDetection and ResponseSIEM