SAP Rise Migration Security: What Changes and What Does Not

What SAP RISE Actually Changes in the Security Model

SAP RISE with SAP is not a single product but a bundled service that includes SAP S/4HANA Cloud (private edition), Business Technology Platform (BTP) access, infrastructure management, and technical application management. From a security perspective, the most significant change is the redistribution of responsibilities under a shared responsibility model.

The Shared Responsibility Boundary in RISE

In an on-premises or customer-hosted SAP environment, your organization owns the entire stack — physical servers, virtualization, operating system, database, SAP application layer, transport management, and user administration. Under RISE, SAP takes ownership of infrastructure (compute, storage, networking), the operating system, database management, and the SAP application stack installation and patching.

Your organization retains full ownership of:

• User identity and access management (IAM) — including SAP user IDs, role design, and authorization objects
• Segregation of duties (SoD) rules and compliance validation
• Custom ABAP code security and code vulnerability management
• Application-level monitoring for unauthorized transactions and privilege escalation
• Configuring and enabling security audit logging within the SAP application layer
• Responding to application-level security incidents

What Security Controls Remain Unchanged After RISE Migration

Understanding what does not change is essential to avoid incorrectly assuming that RISE automatically enforces security policies that previously required your active management.

Authorization Management and Role Design

SAP RISE does not alter how authorization objects, profiles, or roles are structured. Your SAP role-based access control (RBAC) model — including composite roles, derived roles, authorization object class assignments, and field-level authorizations — functions identically in the RISE environment. The SUIM (System User Information Management) tools, PFCG (Profile Generator) configuration, and authorizations trace (SU53) work the same way they did before.

What changes is the level of access you have to underlying system tables and configuration parameters. In the RISE private cloud edition, SAP restricts certain backend access to maintain platform stability. This can affect your ability to run custom authorization reporting or directly query certain security-relevant database tables. For enterprises that relied on custom ABAP reports for authorization cross-checks, this restriction requires adopting approved tools or APIs that work within the RISE boundary.

Segregation of Duties Requirements

SoD is purely a function of authorization design and business process configuration — it has nothing to do with where the SAP system is hosted. Your SoD ruleset, conflict detection matrices, and user risk scoring must remain active and maintained after migration to RISE. SAP provides limited SoD analysis capabilities through SAP Access Control (GRC), but many enterprises supplement this with third-party tools to achieve continuous monitoring coverage.

The risk of SoD violations increases during and immediately after a RISE migration because role redesign, user re-mapping, and transport management during cutover often introduce temporary over-provisioning. Without dedicated monitoring, these gaps can persist into production.

ABAP Code Security and Custom Development Risk

RISE systems remain fully capable of executing custom ABAP code, including custom transactions, BAdIs (Business Add-Ins), user exits, and enhancement points. The security risk vector for custom code — hardcoded credentials, SQL injection vulnerabilities, authorization bypass — does not change. In fact, it can be harder to scan and monitor custom code in RISE due to reduced backend/database access.

Enterprises must ensure their ABAP code scanning and vulnerability detection processes work in the RISE environment, or adopt cloud-compatible alternatives. This is a common gap that goes unnoticed until a post-migration audit or incident.

Change Monitoring and Transport Management

The SAP change and transport system (CTS/CTO) operates identically in RISE. Your transport strategy — development → quality → production — and associated approvals remain unchanged. However, your ability to audit transport content and detect unauthorized changes to critical configuration tables or authorization objects remains your responsibility. RISE does not automatically monitor for suspicious transport activity such as emergency changes without proper approval or direct modifications in the production environment.

What Security Controls Change in RISE

Several security-relevant aspects of the SAP environment shift meaningfully under RISE, and organizations that fail to adapt these controls create blind spots.

Infrastructure Logging and Network Monitoring

On-premises, your security operations center (SOC) can deploy agents on SAP application servers, capture raw network traffic between the SAP system and databases, and monitor OS-level audit logs. Under RISE, you lose direct visibility into the OS and database layers. SAP manages these layers and provides aggregated logging via the SAP RISE Monitoring & Insights service.

This means your SOC can no longer detect threats at the host or database level — no monitoring of failed OS login attempts, no database query auditing, no network packet inspection on the SAP server segments. All threat detection must shift to the application layer and the SAP-specific security logs you can still export, such as security audit logs, change document logs, and table logging.

Incident Response and Forensic Access

In an on-premises scenario, if you suspect a security incident, your incident response team can image the server, examine process memory, inspect database logs directly, and review OS-level artifacts. In the RISE model, you must submit a request for forensic data through SAP’s support process. This introduces latency into critical incident response workflows.

Organizations with mature SOC operations must establish a pre-agreed forensic data retrieval process with SAP during the RISE contract negotiation phase, including defined service-level agreements (SLAs) for producing the data needed during an investigation.

SAP BTP Security Integration

RISE includes access to SAP BTP, which extends the SAP environment into cloud-native services for integration, analytics, and extension development. BTP introduces its own identity management (SAP Cloud Identity Services), API gateways, and application authentication mechanisms. This creates a hybrid authorization landscape where users may access resources that span the core RISE S/4HANA system and BTP services using different authorization models.

Monitoring this hybrid environment requires visibility into both SAP system logs and BTP audit logs — and correlating events across the two. This is a new security monitoring requirement that on-premises organizations did not face.

The Threat Vectors That Intensify with RISE

While the architecture changes, the primary threats to SAP environments — insider abuse, privilege escalation, SoD violations, and unauthorized transactions — remain. However, the RISE operating model amplifies certain vectors.

Insider Threat from SAP-Managed Access

SAP personnel require administrative access to your RISE systems for operations, patching, and support. This creates a legitimate insider threat vector that did not exist in on-premises environments. While SAP applies background checks and internal controls, your organization has limited visibility into what SAP administrators do inside your system.

Mitigation requires monitoring for actions that originate from SAP support users (typically service IDs) and alerting on any activity that deviates from expected operational patterns — particularly changes to critical authorizations, creation of new users, or direct system access outside of approved maintenance windows.

Configuration Drift During Continuous Updates

RISE includes quarterly feature updates and regular technical patches that SAP applies to your system. These updates can introduce or remove authorization objects, change table structures, or modify business functions — all of which can affect your security configuration. Without change monitoring that tracks these updates and validates them against your authorization and SoD baseline, configuration drift accumulates silently until a compliance audit reveals gaps.

Identity Sprawl Across Hybrid Landscapes

RISE migrations often run alongside existing on-premises SAP systems during a phased transition. This creates a hybrid identity landscape where users may have authorizations in both the legacy system and the RISE system, with different role designs and access levels. Identity lifecycle management — user provisioning, de-provisioning, role changes — becomes more complex, and the risk of orphaned accounts or out-of-sync authorizations increases.

How to Audit and Monitor Security in a RISE Environment

Effective security monitoring in a RISE environment requires shifting your focus from infrastructure-layer signals (which you can no longer see) to application-layer signals (which you still control). The core components of a RISE-compatible SAP security monitoring program include:

Centralized Application-Layer Audit Logging

Configure and enable SAP security audit logs to capture events such as:

• Successful and failed user logons (including dialog, RFC, and system logons)
• Authorization failures (transaction-started-terminated events)
• Changes to sensitive configuration tables (using table logging)
• Changes to authorization objects, roles, and profiles
• Transport import events and emergency change approvals
• RFC call monitoring and privileged user activity

These logs must be exported to a central security platform — either a SIEM or a purpose-built SAP security monitoring solution — because SAP's native audit log is not designed for real-time alerting or cross-system correlation.

Continuous Segregation of Duties Validation

Run SoD checks on a scheduled basis (weekly or more frequently during active system changes) to detect new conflicts introduced by role changes, business process updates, or quarterly feature releases. SoD monitoring must cover both the RISE S/4HANA system and any BTP services that handle sensitive business transactions. Manual periodic reviews are insufficient for RISE environments that receive quarterly updates.

Privileged User and Service ID Monitoring

Implement monitoring specifically for users with SAP_ALL, SAP_NEW, or extensive cross-application authorizations. Alert on any privileged user activity that occurs outside of defined maintenance windows or involves unusual transaction codes. This includes monitoring the activity of SAP support service IDs, whose access patterns should be predictable and bounded.

Common Pitfalls in RISE Security That Organizations Overlook

Based on assessments of enterprises that have completed RISE migrations, the following gaps appear most frequently and are routinely missed during pre-migration planning.

Assuming SAP GRC Covers All RISE Security Needs

SAP GRC (Access Control, Process Control, Risk Management) provides essential SoD analysis and access review capabilities, but it does not function as a real-time security monitoring platform. GRC Access Control does not monitor user activity in real time, detect stolen credentials being used from unusual locations, or alert on suspicious transaction sequences that indicate fraud. Organizations that rely solely on GRC for RISE security leave significant detection gaps.

Not Enabling the Right Audit Log Channels

RISE systems often ship with default audit log configurations that are too narrow to support enterprise compliance requirements. Security audit log levels may be set to minimal, table logging may be disabled for critical configuration tables, and RFC logging may not be active. Enabling comprehensive audit logging after go-live requires downtime in some configurations. This must be addressed during the RISE build phase, not postponed until after cutover.

Overlooking BTP Audit Log Integration

BTP audit logs exist in a separate administrative console (SAP Cloud Platform Cockpit) and require separate export and monitoring configuration. Many organizations that diligently monitor their core RISE S/4HANA system completely ignore the BTP layer, leaving a blind spot where extensions, integrations, and custom applications run outside the visibility of the security team.

BTP audit logs cover events such as service binding changes, API call patterns, identity token exchanges, and extension deployment. These must be ingested into the same monitoring platform as the core SAP logs to enable cross-system threat detection.

Building a RISE-Compatible SAP Security Monitoring Architecture

A monitoring architecture suitable for RISE environments must address the reduced infrastructure visibility while maximizing application-layer detection coverage. The following process outlines a phased approach to establishing this capability.

What Your Auditor Will Ask About RISE Security

External auditors conducting SOX, SOC 2, or PCI DSS assessments on RISE environments typically focus on the following controls. Prepare answers and evidence in advance of the engagement.

• Access management: How are user accounts provisioned, reviewed, and de-provisioned in the RISE system? What is the review cadence for privileged users?
• Segregation of duties: Show your SoD analyzer results and conflict remediation workflow. What role do SoD violations have at the time of the assessment?
• Audit logging: What audit log channels are enabled? How are logs exported and secured? How long are they retained? How are they protected from tampering?
• Change management: How are transports tracked and approved? How are emergency changes authorized and retrospectively reviewed? Can you show a recent transport with the associated approval?
• Incident response: What is your process for detecting and responding to a security incident in the RISE system? How do you obtain forensic data from SAP in a timely manner?
• SAP administrative access: How do you monitor SAP’s own access to your system? What controls prevent SAP personnel from making unauthorized changes?

Long-Term Strategic Security Risks in RISE

Beyond the immediate operational and compliance considerations, enterprises should evaluate the longer-term security implications of operating under the RISE model.

Vendor Lock-In and Security Tooling Compatibility

As SAP continues to restrict backend access in RISE, some traditional SAP security tools that relied on direct system access or database-level integration may become incompatible. Organizations should verify that their security monitoring tools are certified or proven compatible with the current RISE API and log export capabilities before committing long-term.

Shared Tenancy Risks (Private Cloud Edition)

While the private cloud edition uses dedicated infrastructure for each customer, the SAP management layer itself is shared across multiple customers. A vulnerability in SAP’s management tools or a misconfigured tenant boundary could theoretically expose your system. This risk is managed by SAP but cannot be dismissed entirely — and it is not a risk you can independently audit.

Evolving Compliance Framework Interpretations

Regulatory frameworks are still catching up to managed cloud models for ERP systems. Future interpretations of SOX, NIST, or the upcoming EU cybersecurity regulations could impose additional obligations on enterprises using managed services for critical financial and operational systems. Build flexibility into your security monitoring architecture to accommodate these evolving requirements without requiring a re-platforming.