How to investigate GCP Audit Log anomalies without a SIEM

1. Identify which audit-log type can contain the evidence

Google Cloud separates audit activity into Admin Activity, Data Access, System Event, and Policy Denied logs. Admin Activity records configuration changes. System Event records changes made by Google Cloud systems. Policy Denied records access rejected because of a security-policy violation. Data Access records access to user-provided data and can require separate enablement and authorization.

A missing Data Access entry is not proof that no access occurred. Verify that the relevant service and permission type were configured to produce the log and that your identity can read it.

Google Cloud references: Cloud Audit Logs overview and Enable Data Access audit logs

2. Bound the query by resource and UTC time

Select the relevant project, folder, or organization in Logs Explorer. Translate the reported time into UTC, add a deliberate buffer, and constrain the timestamps and log name before searching broad text.

log_id("cloudaudit.googleapis.com/activity")
timestamp >= "2026-09-02T14:00:00Z"
timestamp <= "2026-09-02T15:00:00Z"

Use exact comparisons on indexed fields when you know them. Google documents logName, timestamp, resource.type, and resource labels among the indexed fields.

Google Cloud references: Logging query language and sample query library

3. Reconstruct who acted, what changed, and where

Who?

Inspect protoPayload.authenticationInfo, principal email, and service-account delegation.

What?

Use serviceName and methodName to identify the API operation.

Target?

Review the resource type, labels, resource name, request, and authorization details.

Where?

Compare caller IP and request metadata with expected offices, VPNs, workloads, and proxies.

Result?

Check status, response, policy-denial details, and asynchronous completion.

Context?

Inspect nearby entries for token creation, IAM changes, failures, and cleanup.

4. Prioritize combinations of signals

• IAM and service-account changes: role grants, key creation, or impersonation outside an approved change.
• New administrative behavior: a principal using a new API, project, resource type, or sensitive method.
• Policy-denial bursts: repeated denied calls can indicate broken automation or attempted discovery.
• Security-control changes: logging, firewall, organization-policy, or security-product modifications.
• New network plus new action: caller IP is context rather than proof, but combinations deserve review.

5. Validate intent outside the log entry

Compare the event with deployment records, infrastructure-as-code changes, tickets, administrator activity, and the resource owner’s expectations. Preserve the entry, insert ID, UTC timestamps, resource scope, and exact query. If the action remains unexplained, follow your incident process to restrict exposed credentials or sessions and retain wider evidence.

Worked example: an unexpected IAM change during a deployment

Example investigation: the following timeline is invented to illustrate an investigation. It is not a customer incident, a captured Flare result, or evidence of detection performance.

A small team notices a service account changing project permissions during a release. The identity is familiar, but that action is not part of its usual deployment. Start with the question “was this specific change authorized?” rather than assuming that unusual means malicious.

1. 14:05 UTC — release begins. A deployment record names the expected automation identity and target project. This is context from the release system, not proof that every later API call is legitimate.
2. 14:08 UTC — an IAM policy change appears. Preserve the original audit entry, resource name, principal, method, status, and any recorded delegation information. Inspect the actual policy change where available; a method name alone does not identify which permission was added.
3. 14:12 UTC — the owner checks the change. Compare the target and intended permissions against the approved infrastructure change. A matching timestamp or familiar caller network is supporting context, not sufficient authorization.

Keep two explanations open

Expected administration: the approved release explicitly includes the same permission change, the executing identity matches, and the owner independently confirms it. Record those references and the reason for closing the finding.

Unexplained privilege change: the release does not include that grant, the target differs, or the owner cannot account for it. Escalate through the incident process, preserve evidence before making changes, and have an authorized responder decide whether to revoke access or roll back the grant.

What this evidence cannot establish

An administrative change does not prove that application data was read. Check relevant Data Access coverage and permissions before making that claim. Conversely, absent Data Access logs cannot establish that no access occurred. A bounded search also cannot rule out activity in another project or outside the selected time window.

A useful handoff to the next responder

Include the project and UTC window, exact query, original audit-entry identifiers, policy-change details, release or ticket references, owner confirmation, and unresolved questions. Keep facts separate from hypotheses. Do not place credentials or unredacted customer logs in public issue trackers.

Explore Flare’s demo to see the investigation interface; this worked example is a separate educational scenario.