Google SecOps for SAP Goes GA

SAP security data has often lived in a different operational lane from the rest of an organization’s security telemetry. That separation is understandable—SAP logs have their own formats, business context, and administration model—but it can make investigation slower when a suspicious event crosses application, identity, and infrastructure boundaries.

Google Cloud has now made Google SecOps for SAP generally available. The October 30, 2026 Google Cloud release notes describe the release as a way to integrate business-critical SAP telemetry into Google SecOps for unified visibility, threat detection, and response. Google’s official integration documentation explains the before-and-after in more practical terms: SAP logs are extracted, normalized into Google SecOps’ Unified Data Model, evaluated with SAP-specific YARA-L rules, and connected to response playbooks.

What is now generally available

Google SecOps for SAP is designed to bring SAP security events into the same security operations platform used for the broader IT environment. Google says it supports SAP RISE landscapes, self-managed SAP systems in the cloud, and on-premises deployments.

The supported log sources include SAP HANA Audit, SAP ICM, SAP Gateway, SAP Web Dispatcher, SAP Security Audit Logs, and SAP Change Documents. Those sources cover both infrastructure and application activity, giving analysts more context than a single application log stream would provide.

The integration also includes SAP-specific standard parsers and curated YARA-L detections. That matters because a security operations team can work with normalized events and security terminology instead of building every parser and detection from scratch.

The before-and-after for a security team

Before an integration like this, a suspicious SAP event may require coordination between SAP Basis administrators, application owners, and a central security team. The security team may see an identity alert or an unusual network event, while the SAP specialists hold the application-specific evidence in a separate console or log pipeline.

After the integration, SAP telemetry can be analyzed alongside the rest of the enterprise landscape. Google describes the workflow as two connected paths: an inbound pipeline for extracting, moving, parsing, and detecting on SAP logs; and an outbound pipeline for response actions.

A practical example is an unusual SAP account change. A detection rule can identify the event, group it into a case, and give an analyst the surrounding identity, endpoint, and network context in the same investigation. If the response is approved and configured, a SOAR playbook can route a mitigation command back through the SAP RFC Gateway—for example, locking a user in the SAP system.

Why the normalization layer is important

Security teams do not usually struggle because logs are unavailable. They struggle because logs arrive with different field names, timestamps, severity conventions, and application meanings. A parser that turns SAP data into a common event model reduces the translation work analysts must do during an investigation.

Google says its SAP-specific parsers normalize raw SAP data into the Unified Data Model. That gives analysts a common structure for searching and detection engineering, while keeping SAP-specific details available for investigation. The benefit is operational: the team can ask a consistent question across the environment without treating every SAP event as a custom exception.

What the response workflow adds

Detection is only one part of a security operations process. Google SecOps for SAP also connects detections to response playbooks. The documented workflow creates an alert and case, triggers a SOAR playbook, formats a mitigation command as an HTTP request, routes it through a remote agent, and sends it to an SAP RFC Gateway running on Cloud Run. The gateway translates the request into an RFC action in SAP.

Google documents automated response and containment capabilities using the SAP RFC Gateway and SOAR playbooks, while the integration documentation labels the automated response workflow as Preview. That distinction is important. The general availability announcement covers the solution, but individual response components may still have preview terms and operational limits.

A sensible rollout plan

1. Map the SAP landscape. Identify RISE, cloud, and on-premises systems, the SAP log sources available in each environment, and the teams responsible for them.
2. Start with visibility. Ingest and normalize a representative set of SAP logs before enabling automated actions. Confirm timestamps, fields, source identity, and event volume.
3. Review detections. Examine the SAP-specific YARA-L rules and compare them with the organization’s existing alerting, triage, and case-management process.
4. Define ownership. Decide which alerts are handled by SecOps, which require SAP Basis review, and which need application or business-owner approval.
5. Test response in a controlled path. If the team uses SOAR playbooks or the SAP RFC Gateway, verify the command routing, authentication, logging, and failure behavior before allowing production actions.
6. Measure investigation quality. Track whether analysts can reach a decision faster, whether duplicate alerts decrease, and whether SAP context is present when cases cross identity or infrastructure boundaries.

Trade-offs teams should understand

Unified visibility does not eliminate SAP expertise. SAP Basis administrators still configure log extraction and maintain the health of the connection, while security analysts need enough SAP context to interpret detections accurately. Google’s documentation explicitly identifies both groups as target personas.

There are also infrastructure and cost considerations. Google lists Google SecOps ingestion pricing and additional costs for services such as Cloud Run, Cloud Storage, Pub/Sub, Secret Manager, and the hosts used for collectors or agents, depending on the ingestion path. A team should model log volume and retention before assuming that centralization is cost-neutral.

Finally, automated containment should be introduced gradually. A playbook that locks a user or changes an SAP state can be valuable during a real incident, but it should have clear approval rules, audit logs, rollback steps, and an understanding of what happens if the remote agent, gateway, or SAP system is unavailable.

What this milestone changes

Google SecOps for SAP gives organizations a more direct way to connect SAP telemetry with the security operations processes they already use. The meaningful shift is architectural: SAP logs become part of a common detection and response workflow rather than a separate evidence pool that analysts must join manually.

The best starting point is not automated containment. It is reliable ingestion, understandable normalization, and a small set of detections that SAP and SecOps teams can validate together. Once that foundation works, response playbooks can be introduced with the controls and testing they deserve. General availability opens the door; the quality of the operating model will determine what teams can safely do with it.

This article is a general information summary based on the cited public sources. It is not legal, cybersecurity, or compliance advice.