When building detection logic for Google Cloud Platform (GCP), an interesting and practically significant inconsistency surfaced around one specific field: serviceData.
According to Google's documentation, serviceData is deprecated. Newer integrations are expected to use the metadata field for service-specific information instead. In theory, this is a clean migration story. In practice, the situation is considerably messier and if you're writing detection rules against GCP audit logs, it has real consequences.
This post walks through a concrete investigation into how serviceData behaves in real GCP audit logs, where it breaks down and why relying on documentation and certain fields alone is not a sufficient strategy when building security detections.
The investigation started with a simple but high security impact administrative action: removing audit logging across all services in a GCP organization.
This is a high-value event from a detection standpoint. Disabling audit logging is a well-known attacker technique used to reduce visibility and evade detection after initial access.
When this action is performed, GCP generates a Cloud Audit Log entry associated with the SetIamPolicy method on the cloudresourcemanager.googleapis.com service.
In GCP Logs Explorer (Google Cloud’s native log-querying platform), the event appeared exactly as expected. Inside protoPayload, a populated serviceData structure was present, with the policyDelta sub-property describing the policy change in detail:
action: REMOVEservice: allServiceslogType: ADMIN_READ / DATA_READ / DATA_WRITEThese fields are the signal. The action: REMOVE combined with service: allServices is what tells you, unambiguously, that audit logging was turned off.
At this point the event looked perfectly usable for detection logic.
The same log entry was then queried in an analytics platform, where GCP logs are ingested for centralized analysis and long-term retention.
The choice of analytics/log-ingestion platform does not affect this behavior. The root cause lives in GCP's export pipeline,
not in any tool that receives the logs. You'll see the same result in any log analytics platform.
insertIdSetIamPolicy methodHowever, the serviceData’s policyDelta sub-property was completely empty in comparison with what we had previously:
The event existed, but the fields that gave it meaning had vanished somewhere between GCP and the downstream analytics platform.
At first glance this looked like an ingestion bug or a parsing issue in the export pipeline. But the explanation turned out to be more nuanced.
The most immediately available explanation comes from Google's own documentation.
Google states that serviceData is a deprecated field. Some services previously stored supplementary audit data there, but the recommended pattern going forward is to use the metadata field instead. Under this framing, the empty serviceData in log ingestion/analytics platform might simply be the result of the field being phased out of data that once lived there but no longer gets populated.
While this was a reasonable hypothesis, the observed behavior does not consistently support it.
If serviceData were cleanly deprecated and services had migrated away from it, one would expect a predictable pattern: events after the deprecation date would stop populating the serviceData field and would start populating the relevant data in metadata instead.
However, our team’s testing across multiple events revealed this is not what happens. We discovered the following:
serviceData correctly with fully structured policyDelta sub-property objects.serviceData objects. (The @type annotation is present, but the policyDelta payload is stripped.)For example, a different SetIamPolicy event, also originating from the same cloudresourcemanager.googleapis.com, contained a fully populated serviceData structure in the forwarded log ingestion/analytics platform:
This event, a role binding change, was correctly exported with its serviceData intact. However, the initial example of the audit logging removal event did not. Both originated from the same service and the same API method. The difference in behavior is not explained by deprecation alone.
This suggests the field is still actively used in some contexts, but its reliability is not guaranteed and the conditions under which it is or is not populated are not clearly documented.
Google's documentation includes a table listing the services that use serviceData for supplementary audit information.
The list currently includes:
Screenshot date: 05/03/2026 - Current GCP’s services that use serviceData
What's particularly notable is that the list itself appears to change over time.
A snapshot of the same documentation page from 21st January 2026 does not include Cloud Storage as a service using serviceData. Check the WayBack Machine Snapshot.
Snapshot date: 21/01/2026 - Prior to adding Cloud Storage as a service that uses serviceData
Since later version of the same page adds it, this raises a critical question:
If the field is deprecated, why is the list of services relying on it growing?
If serviceData were on a clear deprecation path, one would expect the list to shrink over time instead of expanding. The fact that services are being added suggests this field is not being phased out as cleanly as the deprecation notice implies.
This is not just an academic observation about documentation quality. It has direct operational impact on detection logic and investigative workflows.
Consider a detection designed to alert when audit logging is disabled across GCP services. The relevant signal lives entirely within serviceData:
action = REMOVE
service = allServices These values are the only reliable indicator that logging was removed. Without them, one is left with a SetIamPolicy event that could represent any number of policy changes: a role assignment, a condition update, a permission grant, etc. The action becomes ambiguous.
From the perspective of a downstream analytics platform receiving a stripped serviceData object, two events can appear identical even though one event is enabling audit logging and another event is disabling audit logging. That's a detection gap.
It is also worth noting that Google's own Chronicle detection tooling references these values that previously were located inside the serviceData property. However, instead of directly referencing the old serviceData or metadata properties, these Chronicle rules reference an abstracted object named security_result containing a further abstracted detection_fields object that “represent fields in detections for a security finding.”.
If Google's own detection engineers are building rules that use custom abstracted objects to reference these critical values that (in regular forwarded logs) are incorrectly stripped from the “deprecated” serviceData object but still not present in the documented metadata object, it leaves a detection gap for anyone working directly with forwarded GCP logs outside the Chronicle ecosystem.
The unreliable behavior of serviceData is not merely a logging curiosity. It translates into a concrete set of security risks that span detection coverage, incident response, compliance and attacker advantage.
The most operationally dangerous aspect of this behavior is that it fails silently. When serviceData is stripped during export, detection rules that depend on fields inside it do not throw an error, raise an alert, or produce any indication that they evaluated against an incomplete log. They simply do not fire.
This is distinct from a broken detection. A broken detection is visible: queries fail, pipelines produce errors, engineers investigate. A silently failing detection produces no output at all and can go unnoticed for months or years. The detection appears to be running correctly. Coverage appears to exist. It does not.
This is arguably the most dangerous failure mode in detection engineering: the system appears healthy while the coverage is gone.
The specific event highlighted in this investigation is not incidental. The removal of audit logging across all GCP services is one of the most high-value attacker techniques available in a GCP environment.
Disabling audit logging is a well-documented defense evasion tactic (MITRE ATT&CK T1562.008 – Disable Cloud Logs). It is typically performed by an attacker who has obtained sufficient privilege and wants to operate without leaving a trail before executing the primary objective.
The fact that the auditConfigDeltas payload, the only field that unambiguously signals that logging was removed as opposed to modified in some other way, is the exact payload that gets stripped, means:
The highest-value defense evasion event in GCP produces a degraded log record in downstream analytics platforms.
An attacker who understands this behavior could disable audit logging knowing that the downstream detection system will receive an event it cannot act on and doesn’t even know what happened.
Without serviceData, a SetIamPolicy event carries no reliable indicator of the direction of the change. Both enabling and disabling audit log configurations produce the same method call on the same service.
From the perspective of a detection rule receiving a stripped serviceData object:
An admin enabling logging looks identical to an attacker disabling all logging across all services.
As noted in the investigation, Google's Chronicle detection repository contains production rules that reference serviceData fields, by using Unified Data Model (UDM) schema. This creates a compounding risk:
Organizations that adopt Chronicle community detection rules to their detection platforms (not those who use Google SecOps) as part of their coverage baseline may have inherited detection gaps of which they are unaware. The rule exists. The rule is enabled. The rule references the correct fields. But if those fields are stripped in the export pipeline, the rule will never fire on the events for which it was designed to catch.
This is particularly insidious because the coverage appears to come from a trusted, first-party source, Google's own security engineering team. The assumption is that if Google wrote the rule, it works against GCP logs everywhere. This investigation shows that assumption is unsafe.
The inconsistency described in this investigation, where serviceData is populated for some SetIamPolicy events but stripped for others, even within the same service and method, means that one cannot statically audit their detection coverage.
A conventional coverage audit asks: Does this detection cover this event type? With consistent log structure, that question has a deterministic answer. With serviceData behaving inconsistently:
serviceData populated without testing every specific combination of service, method, and policy change typeThis transforms detection coverage from a binary, auditable property into a probabilistic and continuously shifting one.
As documented here, the list of services relying on serviceData has grown over time, most recently adding Cloud Storage, despite the field carrying an official deprecation notice.
This creates a specific risk: security teams that assessed their serviceData exposure at an earlier date have an outdated picture of their coverage. Services that were not previously affected are now affected. Detections that were not previously at risk are now at risk.
🚨 These security risks can be broader and have a huge impact on companies using security tools to monitor their environments,
because relying on a SIEM, XDR, or any centralized monitoring stack is the normal operating model for teams trying to
maintain security across a distributed cloud footprint. When the source telemetry silently degrades in transit, those tools
do not compensate, they simply ingest incomplete events, and the organization ends up with a false sense of coverage:
dashboards stay green, detections keep “running”, but the visibility needed to catch high-impact actions and investigate
incidents is missing right when it matters most.
Given this behavior, detection engineers working with GCP logs should consider the following:
1. Validate your log telemetry end-to-end. Don't assume that what you see in GCP Logs Explorer is what reaches your SIEM or analytics platform. Deliberately generate test events and trace them through the entire pipeline to confirm field fidelity at every stage, export sink, transformation layer, and final storage.
2. Write detections defensively. If your detection relies on serviceData fields, consider adding fallback logic. For example, alerting on SetIamPolicy events where serviceData.policyDelta is present but empty may itself be a useful signal worth investigating due to its anomalous log shape.
3. Cross-reference metadata. For services that are actively migrating from serviceData to metadata, the relevant policy change information may appear in both fields or exclusively in metadata. Validate which field is populated for each desired service and method combination and update detection logic accordingly.
4. Monitor documentation changes. The list of services using serviceData is not static and definitely services are not getting removed from that list due to the field being deprecated, it seems that actually more services are being added (Cloud Storage was recently introduced in the list). Periodically reviewing it and diffing against one’s existing detection coverage is a reasonable part of detection maintenance hygiene.
The serviceData field in GCP audit logs exists in an uncomfortable middle ground. While it is formally deprecated, it is still actively used by multiple services and its values indirectly referenced in Google’s own production detection rules. Its presence and structure are inconsistent across events, even within the same service and API method. And the documentation describing it has evolved in ways not fully explained by a straightforward deprecation timeline.
For detection engineers, this is a reminder of a principle that applies far beyond GCP: never assume a field behaves consistently without validating it against real log data in every environment in which you consume it.
Documentation describes intent. Telemetry reflects reality. When building detections, the latter is what matters.