SAP RISE with SAP Security: What Companies Often Misunderstand
Is SAP RISE secure by default?
RISE with SAP is marketed as a simplified way to move SAP workloads to the cloud. Infrastructure, technical operations, and hyperscaler management are handled by SAP, which leads many organizations to believe that security is also fully covered.
That assumption creates risk.
RISE with SAP follows a shared responsibility model. While SAP manages parts of the platform, customers remain responsible for securing their SAP systems at multiple critical layers.
Misunderstanding this model is one of the most common security gaps in SAP RISE environments.
Understanding the SAP RISE shared responsibility model
In a RISE setup, security responsibilities are divided across:
- SAP
- The hyperscaler
- The customer
SAP ensures infrastructure availability and baseline platform controls. The hyperscaler secures the underlying cloud environment.
However, SAP application security remains largely the customer’s responsibility.
This includes:
- User and role design
- Authorizations and segregation of duties
- Custom ABAP code security
- Secure configuration and hardening
- Logging, monitoring, and incident response readiness
RISE does not remove these responsibilities. In many cases, it makes them harder to manage.
Why SAP RISE increases security complexity
RISE accelerates cloud adoption, but speed often comes at the cost of visibility.
Many organizations migrate existing SAP systems into RISE without fixing long-standing issues such as:
- Overprivileged users
- Poorly designed roles
- Insecure custom developments
- Missing monitoring and alerting
Once in RISE, teams often discover they have less direct access to the system, while attackers still target the same SAP attack surfaces.
Security challenges do not disappear in the cloud. They evolve.
Common SAP RISE security gaps
Across SAP RISE projects, the same problems appear repeatedly.
1) Access and authorization risks
Legacy roles are frequently migrated without redesign. This leads to excessive privileges, segregation of duties conflicts, and weak access governance.
2) Lack of SAP-specific monitoring
Native logs and cloud provider tools are not designed to detect SAP-specific threats. Without specialized monitoring, attacks can go unnoticed.
3) Custom code exposure
Custom ABAP code remains a major attack vector in RISE environments. Cloud hosting does not reduce this risk.
4) Configuration drift
Security settings change over time. Without continuous validation, systems slowly drift away from secure baselines.
5) False sense of responsibility transfer
Many teams assume SAP handles controls that are still fully owned by the customer.
.
SAP RISE security is not just a compliance topic
A common mistake is treating SAP RISE security as a compliance exercise.
SAP systems process some of the most sensitive data in the enterprise, including financial records, HR data, and business-critical transactions.
A security incident in SAP is a business impact event, not just a technical issue.
Effective SAP RISE security must address:
- Prevention
- Detection
- Continuous monitoring
- Incident response readiness
Building a realistic SAP RISE security strategy
A strong SAP RISE security approach should include:
- Pre-migration security assessments
- Role and authorization redesign
- Custom code security reviews
- Continuous SAP-level monitoring
- Regular security posture assessments
Security should be treated as an ongoing process, not a one-time migration task.
RISE with SAP simplifies infrastructure management, but it does not simplify security.
Customers remain responsible for protecting their SAP systems, even when those systems run in the cloud. Understanding the shared responsibility model and implementing independent SAP security controls is critical for any organization running SAP under RISE.