How Securing On-Premise and Cloud SAP Solutions Differ

The SAP environment is a critical component of an organization’s IT environment. However, infrastructure security cannot be treated in a silo.

It extends beyond the SAP application itself to encompass the entire ecosystem: physical facilities, operating systems, virtualization layers, networks, and monitoring frameworks. As the landscape expands to include hybrid and cloud models, infrastructure security becomes a shared responsibility among the cloud service provider, SAP, and the business running SAP in both private and public clouds.

In a company with a hybrid SAP environment, the owner’s responsibility for infrastructure security shifts. For an on-premise system, the business running SAP owns and operates everything, and for the cloud component, they mostly take accountability. The cloud service provider and the software vendor (SAP in this case) bear a lion’s share of the responsibility for infrastructure security. For the on-premise part, they still develop security policies, guidelines, and processes; acquire security systems as needed, implement the design; operate the systems; monitor them; and implement continuous improvement schemes.

To counter advanced exploits used by bad actors, organizations have started adopting measures such as zero-trust architectures, automated patching, and continuous monitoring with SIEM to reduce risk exposure and secure their IT infrastructure.

The process of securing an on-premise SAP environment starts well before user IDs are created, roles are built and assigned to users, or applications are configured. The first step of that security development process is planning: Planning a secure infrastructure means defining and securing the core components of the SAP landscape—servers, network devices, network protocols, operating systems, and the controls that govern their interactions.

A secure architecture must be designed to be free of architectural vulnerabilities. SAP environments are currently highly integrated. Each system must be secure, and the mechanisms to integrate them, the interfaces, and the network must be secured. Security measures like encryption must be adopted to secure data in motion. Business processes must be designed not just from an efficiency perspective, but also with security in mind, reducing risk to the business.

What is your responsibility for the cloud-based component of your SAP environment? Security on the cloud is a joint responsibility among the business, the cloud service provider, and the software vendor (SAP in this case). The table below presents a RASCI chart of this shared responsibility for various tasks; the letters in RASCI have the following meanings:

• R: Responsible. The party that carries out the responsibility
• A: Accountable. The party that is answerable for the responsibility
• S: Support. The party that supports the activity carried out as part of the responsibility
• C: Consulted. The party that provides the expertise to complete the activity
• I: Informed. The party that is informed about the activity carried out as part of the responsibility

When you use SAP S/4HANA on the public cloud, it is a software as a service (SaaS) model, so SAP owns the infrastructure and the platform. SAP is responsible for managing the infrastructure and its security. So the infrastructure security is mostly owned by SAP. However, the customer company is still accountable. If auditors find any exceptions during their audit, it will constitute a valid finding against your organization. To avoid such a scenario, you can rely on System and Organization Controls (SOC) reports.

SOC reports are widely used when an organization outsources its IT services, and so it’s also commonly used for cloud services. A service provider company provides SOC reports to the company that consumes its services. SOC reports are audit reports that certify how well a service provider company manages the protection of its data, security, and internal controls.

There are different types of SOC reports.

• SOC1: This report focuses on financial reporting controls. It’s used when a service impacts a customer’s financial statements. Examples include companies providing day-to-day SAP support or payroll software support.
• SOC2: This report focuses mostly on security, availability, processing integrity, and privacy. It’s the most common report for cloud services.
• SOC3: This report is similar to the SOC2 report, but at a high level; it doesn’t get into the details like SOC2 does, and it’s public-facing.

These reports are available in two formats:

• Type I: This format evaluates if the controls are correctly designed at a point in time to be effective.
• Type II: This is a more comprehensive version of the report, which evaluates whether the controls operate effectively over a period of time.

When a company engages a service provider, the provider can be obligated under the contract to provide SOC reports. Reputable companies like SAP deliver the reports themselves. SAP does not send such reports by email; it uploads them to its trusted site for businesses to download.

SOC reports are important for both the service providers and the customer for multiple reasons:

• They ensure that a provider follows strong security and compliance practices.
• They help customers meet regulatory and audit requirements.
• They reduce the need for individual customer audits.
• They’re essential for cloud services like SAP S/4HANA, AWS, Azure, and SaaS platforms.

Do auditors accept SOC reports as evidence for compliance? The answer is no; these reports don’t exempt auditees from their compliance responsibilities. Auditors take them as part of the available evidence, but they also look for additional proof of compliance.

For example, when auditors are auditing a business using a SaaS service like SAP S/4HANA Cloud Public Edition, where the service provider completely manages the infrastructure, the auditors may look for the following as evidence of compliance:

• SOC 1/SOC 2 Type II reports
• ISO 27001 certificates
• Penetration test summaries
• Data center compliance reports (e.g., ISO 22301, ISO 27017, ISO 27018)
• Cloud provider security whitepapers

Also, the regulations in effect will play a part here. To comply with strict regulations such as Sarbanes-Oxley Act (SOX), General Data Protection Regulation (GDPR), and Payment Card Industry Data Security Standard (PCI DSS), auditors may seek additional evidence to provide a clean sheet to the auditee.

Conclusion

Securing an SAP environment is not a one-time effort or a single team's responsibility—it is an ongoing, organization-wide commitment that spans physical infrastructure, cloud platforms, business processes, and shared accountability with service providers. Whether your landscape is fully on-premise, cloud-based, or hybrid, understanding who owns what is foundational to building a defensible posture.

SOC reports, ISO certifications, and cloud provider documentation are strong starting points, but auditors and the broader threat landscape demand more. Zero-trust architectures, continuous monitoring, and security-minded process design must all work in concert to reduce exposure. Even when SAP manages the infrastructure, your organization remains accountable—treat infrastructure security not as a compliance checkbox, but as a continuous discipline embedded in everything from initial architecture planning to day-to-day operations.

Editor’s note: This post has been adapted from a section of the book SAP System Security by Pradeep Kumar Mishra. Dr. Mishra began his professional journey as a university mathematics teacher before transitioning to computer science. He holds a PhD in public key cryptography, with a research focus on elliptic and hyperelliptic curve cryptography, and later moved into industry to apply his security expertise to real-world challenges. Dr. Mishra has spent more than 13 years working in SAP security and governance, risk, and compliance (GRC), primarily as a consultant supporting Canada’s oil and gas industry. He is a CISSP, CISA, and CRISC-certified professional, through which he has built strong expertise in security and GRC across complex enterprise SAP landscapes. During his academic career, he published over 20 research papers in reputable peer-reviewed journals and conference proceedings. His research contributions are available on Google Scholar here. Beyond his technical work, Dr. Mishra is passionate about explaining technology in simple, nontechnical language for a broader audience. Outside of writing and speaking about technology, he enjoys poetry and spending time outdoors.