SAP's RISE with SAP support model questions are rarely answered voluntarily. SAP's commercial teams are trained to present RISE as a simplified, all-inclusive subscription — and the support model is a key part of that narrative. What they omit is what costs you money: the embedded support percentage, the escalation restrictions, the AMS gap, the SLA exclusions, and the permanent removal of third-party support rights.
The only effective approach is to ask specific, written questions before contract execution and to demand specific, written answers. Verbal commitments from SAP's account team are commercially worthless. What matters is what the Order Form, Master Agreement, and General Terms and Conditions actually say — and the only way to force clarity is to ask explicitly and document the response.
This article provides the exact questions your team should put to SAP in writing before executing any RISE contract. For the full context on why each of these matters, see our complete enterprise guide to the RISE with SAP support model.
The first category of questions targets cost transparency. SAP bundles support into the RISE subscription price and actively resists decomposing that price. Forcing a written breakdown before signature is essential for any meaningful commercial analysis or renewal negotiation.
SAP will resist answering this directly. The standard response is that "support is included in the subscription and not priced separately." Push back: request the internal rate card allocation, or ask SAP to confirm in writing that the support component falls within a stated range. Any reluctance to confirm the support cost percentage should be treated as a commercial red flag.
Why it matters: If you cannot identify the support cost component, you cannot benchmark it, challenge it at renewal, or model the true TCO of RISE versus alternatives.
SAP's standard RISE subscription escalation is contractually defined — typically 3–5% annually. What is less clear is whether the support component escalates at the same rate, a different rate, or is excluded from escalation clauses. Demand written confirmation of the exact escalation mechanism applied to the support element of the subscription.
Why it matters: A support component escalating at 5% annually doubles in 15 years. Understanding the escalation mechanism is essential for long-term cost modelling.
The answer from SAP's commercial team will almost always be "no" or "that's not how we structure RISE." The question nevertheless serves two purposes: it signals your awareness of the cost dynamic, and in competitive deal situations or large contract sizes, it creates opening for negotiation. Independent advisors regularly negotiate escalation caps below SAP's headline rate.
Why it matters: Caps on support escalation are achievable in practice — SAP simply won't offer them unless asked.
SAP's commercial team is experienced at deflecting questions that expose their pricing structure. Our RISE with SAP advisory service supports enterprises through the pre-signature question process, ensuring SAP's responses are binding and that gaps are identified before you sign.
Get Expert Support →SAP's SLA documentation commits to response times. Resolution timelines are typically described as "best efforts" or referenced to a process rather than a contractual timeline. Push SAP to define, in writing, what their maximum resolution timeline commitment is for P1 incidents affecting core business processes. If the answer is "it depends," that is commercially unacceptable for a critical ERP platform.
Why it matters: Your operations team does not care about response times. They care about when the system comes back. Without a resolution commitment, SAP has no contractual obligation to prioritise your outage.
SAP's SLA exclusions are extensive and often buried in the General Terms and Conditions rather than the RISE-specific Order Form. Key exclusions typically include: custom ABAP developments, third-party integrations, issues caused by customer configuration changes, performance issues attributable to customer infrastructure, and scheduled maintenance windows. Demand a complete written list of exclusions before signature.
Why it matters: A majority of real-world incidents in complex SAP environments involve at least one element that can be characterised as an SLA exclusion. Understanding the exclusion list reveals the true operational risk of the standard support tier.
SAP's standard RISE availability SLA excludes maintenance windows and planned updates from the uptime calculation. In practice, mandatory quarterly updates, testing environments, and planned system activities can consume most of the "permitted" downtime allowance, leaving very little margin for actual incidents before the SLA threshold is technically breached. Force SAP to define this calculation explicitly.
Why it matters: The advertised 99.5% SLA is not the operational availability you will experience in a complex RISE deployment. Understanding the true calculation reveals the gap between marketing and reality.
SAP's account team will typically confirm this orally when pressed but will not volunteer it in writing. Requiring written confirmation serves two purposes: it creates a documented record of a significant commercial restriction, and it quantifies the cost differential that should be reflected in your commercial analysis (typically the 50–60% saving that third-party providers would otherwise deliver).
Why it matters: Written confirmation of the third-party prohibition is the foundation of any legitimate TCO comparison between RISE and continued on-premise operation with third-party support.
SAP's support sales organisation has specific triggers for recommending support tier upgrades: complex custom code estates, large user populations, critical business process dependencies, and historical incident volumes are all commonly cited. Understanding these triggers before signature allows you to assess whether standard support is genuinely sufficient or whether SAP's own criteria suggest you will be upsold post-signature.
Why it matters: Identifying that your environment meets SAP's own criteria for Premium Engagement creates the basis for negotiating inclusion of those features at the standard RISE price.
SAP's RISE model requires enterprises to adopt SAP's release updates, but the cadence and mandatory adoption timeline are contractual details that vary by contract vintage and negotiation. In practice, most RISE customers face quarterly mandatory updates with defined adoption windows. Each update can require testing, custom code remediation, and change management — costs that fall entirely on the enterprise and sit outside SAP's support scope.
Why it matters: The AMS cost burden generated by mandatory SAP updates is a significant and systematically underestimated element of total RISE cost. Quantifying the update cadence before signature enables accurate AMS cost modelling.
SAP's support scope under RISE covers SAP-delivered code and SAP-delivered cloud infrastructure. Everything the enterprise builds, configures, integrates, or customises sits outside SAP's support remit. This boundary definition is critical for AMS scoping — and SAP's written definition of the boundary is frequently narrower than what enterprises assume from the sales presentation.
Why it matters: Without a clear written support boundary, enterprises routinely discover post-go-live that a substantial proportion of their incidents are not SAP's problem. This discovery generates unbudgeted AMS demand at the worst possible moment.
SAP's support boundary definition directly determines your AMS cost. Our SAP support cost reduction service includes AMS scope modelling based on your specific RISE deployment profile — ensuring your AMS budget reflects the true post-go-live support demand rather than SAP's optimistic projections.
Model Your AMS Cost →Asking the right questions is necessary but not sufficient. SAP's written responses — whether from the account team, the legal team, or embedded in contract annexes — need to be assessed with equal rigour. Specific warning signs in SAP's responses include: references to "standard terms" without quoting the specific applicable clause; phrases like "subject to system resource availability" applied to resolution commitments; definitions of support scope that include broad exceptions for "customer-caused issues" without defining the threshold for causation; and availability SLA definitions that reference "scheduled downtime" without a defined limit on scheduled downtime volume.
For enterprises without internal SAP contract expertise, assessing the adequacy of SAP's responses requires independent specialist support. SAP's legal and commercial teams produce contractual language specifically designed to appear comprehensive while preserving maximum operational flexibility for SAP. The devil is consistently in the defined terms — and the defined terms are typically buried in multi-hundred-page General Terms and Conditions documents that SAP does not encourage customers to read carefully.
For guidance on the negotiation process that follows the question phase, see our companion article on RISE with SAP support model negotiation strategies. For a comprehensive overview of all aspects of the RISE support model, our complete enterprise guide provides the full context.
SAP's account teams will typically answer some questions in writing and redirect others to "standard contract terms." Any question that receives an "it's in the standard terms" response should be followed up with a request for the specific clause reference. If SAP cannot or will not provide specific written answers to cost and SLA questions, that is itself commercially significant information about the adequacy of the contractual protections being offered.
Yes — that is the purpose of asking. SAP's initial answers reveal the gaps in their standard proposal, which creates the basis for negotiation. Enterprises that ask no questions before signing accept every default term. Enterprises that ask systematically and document the responses have a foundation for commercial negotiation on the specific points that matter most to their operational requirements.
Ideally, these questions should be submitted at least 8–12 weeks before the target signature date. SAP's response cycle for complex contractual questions is typically 2–4 weeks. Negotiating changes to standard terms adds further time. Enterprises that initiate this process in the final weeks before a deadline have no negotiating leverage and accept whatever SAP offers.
📬 SAP Licensing Intelligence
Expert analysis on RISE with SAP, contract negotiation, audit defence, and support cost reduction.
SAP Licensing Experts Advisory Team
Former SAP executives, auditors, and contract managers — now working exclusively for enterprise buyers. Learn about our team →
Independent SAP licensing advisory — not affiliated with SAP SE.
Our RISE with SAP advisory team has supported 50+ enterprises through RISE contract negotiations. 100% buyer-side. Zero SAP affiliation.
Book a Free Consultation →