As organizations move mission-critical systems to SAP Private Cloud and RISE with SAP, where does SAP’s security responsibility end, and where does the customers’ begin?
During a recent ASUG webinar, SAP cybersecurity leaders addressed this question by outlining the Enterprise Cloud Services (ECS) security strategy, Zero Trust architecture, and the shared responsibility model for private cloud environments.
The panel featured Erin Hughes, Head of Cybersecurity and Compliance Advisory for the Americas; Thomas Gordon, Enterprise Architect – Cybersecurity and Compliance; and Anne-Marie Colombo, Enterprise Cloud Services Security Lead for the Americas.
1. SAP’s Security Philosophy Rests on Three Pillars
SAP’s approach to cloud security is based on three interconnected pillars—build, run, and act— outlined by Gordon.
Build ensures that security is embedded into the software development lifecycle from the start, and every cloud platform solution ships with a secure baseline baked in.
Run focuses on 24/7 cloud operations that stay ahead of emerging threats. Gordon emphasized transparency here, framing it as “trust and verify”: giving customers the tools and documentation they need to confirm that SAP is delivering on its security commitments. Much of that documentation lives on the SAP Trust Center, a resource he encouraged attendees to explore.
Act encompasses compliance activities, internal training, and the feedback loops SAP maintains with customers. The team fields security questionnaires and connects customers with subject matter experts when deeper conversations are needed.
2. Zero Trust Is a Continuous Journey
Colombo discussed the significance of Zero Trust architecture for enterprise architects overseeing digital transformation — referencing NIST 800-207 as the core framework. She emphasized that Zero Trust represents an ongoing process rather than a single, comprehensive overhaul.
“Start where you are,” she advised. Organizations don’t need to tear out legacy systems overnight. Instead, they can begin applying Zero Trust principles (never trust, always verify) incrementally as they modernize.
The reason behind this is that cloud applications, legacy systems, and hybrid architectures have effectively dissolved the traditional network perimeter, expanding the attack surface and making it harder to know who’s truly inside the network. Colombo recommended that enterprise architects focus on data classification, granular access control, session security, and encrypted communications as they weave Zero Trust thinking into their transformation strategies.
On artificial intelligence, Colombo referenced the 2025 Cost of Data Breach study, conducted by Ponemon Institute and sponsored by IBM Security, which revealed widespread gaps in AI ethics and governance. Her advice: confirm a genuine business requirement before adopting AI, and ensure the underlying data is trustworthy.
3. The Shared Responsibility Model Has a Clear Line of Demarcation
For many SAP customers, the biggest learning curve in moving to Private Cloud is understanding exactly where their responsibilities begin.
In practical terms, SAP handles the operating system, database, hyperscaler configuration, and physical infrastructure. Customers retain responsibility for application configuration, business processes, user data, and access control.
"You still need a BASIS team," Colombo clarified. SAP manages the underlying infrastructure, but customers are responsible for planning service activities like kernel upgrades, in collaboration with their assigned Client Delivery Manager and Technical Services Manager. These SAP representatives function as extensions of the customer’s team, coordinating maintenance windows and emergency patches.
Connectivity falls on the customer as well. SAP provisions a Virtual Private Cloud, but getting into that environment is the customer's problem to solve. Internet access is blocked by default, so most customers route traffic through their own VPC and handle filtering there.
4. Understanding What’s Standard vs. What’s Optional Can Prevent Surprises
SAP’s private cloud environment comes with an extensive security stack out of the box: a global SIEM with 24/7 monitoring and incident response, proactive threat hunting using the MITRE ATT&CK framework, vulnerability scanning, and immutable backups. Detection engineers build detections that map to attack phases to identify malicious activity early.
On vulnerability management, SAP uses the Common Vulnerability Scoring System (CVSS). Scores of 9 or 10 trigger emergency patches — SAP will reach out immediately and, if necessary, take downtime unilaterally to protect the shared environment. Scores of 8 and below follow a standard cadence agreed upon with the customer, typically monthly or quarterly. If customers repeatedly decline patching windows, SAP issues formal risk letters to executives, spelling out specific vulnerabilities and potential SLA impacts.
Two optional tools generated significant discussion.
LogServ, available now, provides raw logs (firewall, VPC flow, and other infrastructure-level data) that customers can ingest into their own SIEM. The tool uses object stores (S3, Azure Blob, or GCP Pub/Sub) for data transfer and is included for Enhanced Operational Services (EOS) customers or available as an add-on for others.
Raven, on the 2026 roadmap, takes a different approach. Rather than delivering raw data, Raven is a dashboard solution that surfaces security use cases: vulnerability lifecycle management, compliance posture, endpoint security reports, and more. The two tools are entirely separate; customers don’t need LogServ to use Raven.
Colombo noted that customer preferences vary considerably. Some are satisfied with SAP handling infrastructure security and don’t need additional visibility. Others want everything flowing into their enterprise SIEM. And some just want SAP to hand them a dashboard rather than building visualizations themselves. The tooling supports all three approaches.
5. SAP Keeps Its Own Admins in Check
Cloud operators have no standing access to customer tenants. Access is provisioned just-in-time: administrators request approval, and only after receiving it can they connect through jump hosts with multi-factor authentication. Session recording captures everything they do, and data loss prevention controls follow them throughout.
The environment is highly standardized across customers, supporting both automation and security. Infrastructure-level customization requests are often denied, not due to arbitrary policy, but because such changes might interfere with the automation that ensures consistent, scalable security operations.
SAP does accommodate customer-initiated penetration testing through a rules-of-engagement process: customers submit their testing plan for approval, receive clearance, and proceed. Any vulnerabilities discovered can be submitted to SAP with a tracking number for follow-up.
Verification and Resources
Customers can use the SAP For Me portal to verify SAP’s security status, as well as server IDs, patch status, CVE numbers, and updates. The SAP Trust Center houses SOC reports, compliance documents, and a detailed roles-and-responsibilities guide that Hughes jokingly called “light reading for a Saturday afternoon.”
For organizations using third-party tools like Onapsis, the speakers confirmed that vulnerability management modules generally work within RISE environments, provided they don’t require OS-level access. The recommendation, as always, is to validate specific modules through the Cloud ERP process before deployment.
Security in the private cloud is ultimately a partnership. SAP secures the infrastructure, operating systems, and databases. Customers secure their data, application configurations, and user access. Understanding where that line falls is the first step toward a successful cloud journey.