Cybersecurity oversight. The shared model needs active buyer work.

Cybersecurity inside RISE with SAP is a shared responsibility model. SAP operates the infrastructure security, the platform security, and the operating system security. The buyer operates the application configuration security, the identity and access management, the data classification, the integration security, and the operational governance. The model is documented but rarely read. The result is a familiar pattern. The buyer security team assumes that SAP covers everything because the environment is described as managed. The SAP team assumes the buyer covers the application and identity layers because the contractual language places those responsibilities on the customer. The gap between the assumptions becomes the attack surface. This article walks through the structural model, the specific controls each party owns, the BTP attack surface, the certification framework, and the contractual provisions that produce a defensible cybersecurity posture across the contract life.

The shared responsibility model in operation.

The SAP responsibility set covers the physical security of the data centre, the infrastructure layer including the hyperscaler controls inherited from the underlying provider, the operating system patching, the database security, the network perimeter controls at the SAP managed boundary, and the platform monitoring. The buyer responsibility set covers the application configuration including authorisation profiles and role definitions, the identity provider configuration and the federation setup, the data classification including any sensitive data tagging, the integration security for any system connected to the RISE environment, and the operational security governance for the buyer side of the relationship.

The boundary between the responsibility sets is not always obvious. Authorisation profiles in S/4HANA are the buyer responsibility, but the underlying authorisation framework that the profiles operate within is the SAP responsibility. Identity federation is the buyer responsibility, but the SAP cloud identity service that supports the federation is the SAP responsibility. The buyer security team must therefore understand the model in detail, with explicit documentation of every control that touches the responsibility boundary. The documentation should be reviewed annually and updated whenever the SAP product team changes the platform configuration.

The application configuration as buyer responsibility.

The application configuration is the largest single area of buyer responsibility and the most common source of security issues. Authorisation profiles that grant excessive privilege, role definitions that violate segregation of duties, custom code that introduces vulnerabilities, configuration parameters that disable native security controls, and reporting configurations that expose sensitive data outside the intended audience all sit within the application configuration layer. The SAP managed services team does not manage the configuration on behalf of the buyer, except in very specific scenarios that the contract names explicitly.

The buyer security operations should therefore include configuration review as a recurring activity, with the review covering the authorisation profiles, the role definitions, the segregation of duties matrix, the custom code base, and the configuration parameters that affect security posture. The review should produce a documented baseline against the current SAP security recommendations and an action plan for any gaps identified. The cadence should be at least annual, with deeper reviews triggered by major SAP releases that introduce new controls or modify existing ones.

Identity and access management.

Identity and access management is the second principal area of buyer responsibility. The buyer manages the user provisioning, the role assignment, the access certification, the de provisioning at departure, and the integration with the corporate identity provider. The buyer also manages any privileged access into the RISE environment, including the access used by the implementation partner during the original deployment and the access used by any third party that retains operational responsibility for specific configurations.

The privileged access category deserves specific attention. RISE environments routinely accumulate dormant privileged accounts that were created for original implementation and never removed, third party accounts that retain access beyond the period the third party requires, and emergency access accounts that were activated during specific incidents and not deactivated afterwards. Each of these creates an attack surface that the buyer security team is responsible for managing. The annual access certification should cover every privileged account in the environment, with confirmation from the responsible account owner that the access remains required.

The gap between the assumptions about who owns what becomes the attack surface. The buyer security team is the only party with both the visibility and the responsibility to close it.

The BTP attack surface.

BTP introduces an attack surface that is structurally different from the application layer attack surface. The platform layer hosts custom extensions, integrations to external systems, analytical data stores, and process automation workflows. Each of these introduces specific security concerns that the application security model does not address. Custom extensions may include code that bypasses the application authorisation framework. Integrations may carry credentials that grant external system access into the RISE environment. Analytical data stores may include data exports that fall outside the application data protection controls. Process automation workflows may include privileged operations that escape the operational logging.

The buyer security oversight should engage the BTP attack surface explicitly, with the same rigour applied to the platform as to the application. The engagement starts with a documented inventory of every BTP service in use, the custom artefacts deployed, the integrations active, the data flows present, and the credentials in use. The inventory should be reviewed quarterly, with the changes since the prior review identified and the security implications assessed. The engagement should also include security testing of the platform layer specifically, with penetration testing scoped to cover the BTP attack surface rather than only the application surface.

SAP certifications and operational evidence.

SAP maintains a suite of security certifications including SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, and various regional certifications for specific operating jurisdictions. The certifications cover the SAP responsibility set within the shared model. The buyer security team should review the current certifications at least annually, validate that the scope of certification covers the specific services the buyer consumes, and identify any gaps between the certification scope and the buyer regulatory requirements. The certification reports are typically available to the buyer under NDA and should be requested formally as part of the annual security review.

The certifications are necessary but not sufficient. They demonstrate that SAP operates a documented security programme against a defined standard. They do not demonstrate that the specific operational instance the buyer is using complies with the buyer specific requirements. The buyer security team should supplement the certification review with operational evidence requests, including the latest penetration testing summary, the most recent independent assessment, and the breach notification history. The supplementary evidence produces a fuller picture of the operational reality than the certification alone.

Contractual provisions for cybersecurity governance.

The contract should support the cybersecurity governance with specific provisions. Audit rights drafted to permit security testing of the buyer environment, with clear scope and reasonable notice. Breach notification drafted to require notification within twenty four hours of SAP awareness, with cooperation in any subsequent investigation. Cooperation obligations drafted to support regulator inquiries and forensic investigation at no incremental cost. Documentation obligations drafted to provide updated security documentation when SAP makes changes that affect the buyer environment.

The contractual provisions should be operationally testable. A breach notification clause that the buyer cannot verify is decorative. A cooperation obligation that the buyer cannot exercise during a regulatory inquiry is decorative. The annual cybersecurity review should include a tabletop exercise that walks through a hypothetical incident from initial detection through regulatory notification, and that tests whether the contractual provisions actually deliver the protection they describe. The exercise routinely surfaces drafting issues that should be addressed at the next renewal cycle.

Conclusion.

Cybersecurity oversight in RISE is not a passive activity that the buyer can delegate to the SAP managed services team. The shared responsibility model places material work on the buyer side, particularly in application configuration, identity and access management, and the BTP attack surface. The model also requires active engagement with the SAP responsibility set through certification review, operational evidence requests, and contractual provision testing. The work is non trivial. The investment in a structured cybersecurity oversight programme typically costs two to four percent of the RISE annual cost. The investment in not having the programme is occasionally catastrophic, with breach response costs, regulatory penalties, and reputational damage that compound quickly. Buyers who treat the shared responsibility model as a working framework, with explicit ownership and recurring activity on both sides, produce defensible cybersecurity posture. Buyers who treat it as documentation that the security team will read when something goes wrong produce the conditions for the incident that the framework was designed to prevent.