Defining Scope and Service Levels in Your SAP RISE Agreement

Defining Scope and Service Levels in Your SAP RISE Agreement

Moving to SAP’s RISE (business transformation-as-a-service) model bundles software, infrastructure, and some managed services into a single cloud subscription. But this simplicity can hide complexity.

Enterprises must spell exactly what RISE includes – and doesn’t – to avoid gaps, finger-pointing, or unexpected costs.

Key defining elements are the system landscape (production and non-production environments), performance and uptime SLAs, support boundaries between SAP, cloud providers, and partners, and partner-delivered implementation/AMS services.

In this advisory, we break down the RISE components and dependencies (hyperscaler, SAP Basis, AMS, third parties), highlight common contract pitfalls, and offer practical recommendations for defining scope and SLAs before signing or renewing a RISE deal.

RISE with SAP: Components and Dependencies

RISE with SAP is a subscription bundle. It typically includes the SAP S/4HANA Cloud software (private edition for large enterprises, or public edition for smaller ones) and related SAP tools (for example, process intelligence or readiness-check services).

The contract also covers cloud infrastructure: virtual machines on a chosen hyperscaler (AWS, Azure, Google Cloud, or other) in a selected region. SAP manages the hosting relationship – you select the hyperscaler, but the contract remains with SAP.

RISE also bundles basic cloud-managed services: SAP/Hyperscaler handles server provisioning, operating-system and database patching, backups, and baseline system monitoring.

Additional components often included are starter packs or credits (for example, access to SAP Business Network/Ariba or SAP BTP development credits). However, many advanced services are not included by default.

For instance, RISE provides only standard SAP Basis operations (system health monitoring, applying standard SAP kernel and database patches)—it does not cover custom code remediation, data conversions, or complex integrations, which must be arranged separately with implementation or managed-service partners.

A RISE contract separates SAP’s built-in services from what implementation and application-management partners deliver.

In practice, a RISE setup is a “layer cake” of services: the hyperscaler provides the raw infrastructure; SAP (or its consultants) provides the core platform and SLAs; and your partners or internal team provide the application-specific work (customization, integrations, test/support).

Key RISE components include:

• SAP S/4HANA Software Subscription: A full-edition ERP suite delivered as cloud software, licensed via Full-Use Equivalents (FUEs) instead of named users. (FUEs aggregate user types into a weighted count.) The contract should list which modules and additional SAP cloud services (like IBP or Analytics) are included.
• Cloud Infrastructure (IaaS): Virtual servers and storage on your chosen hyperscaler. You must define region and performance sizing. SAP contracts this on your behalf, but you should confirm data residency and connectivity needs.
• Platform Managed Services: SAP/Hyperscaler handle basic operations – for example, they ensure the servers are running, apply system patches/updates, and maintain availability. In private-cloud RISE, there is more flexibility (for custom development) than in the public (multi-tenant) edition, but still less flexibility than an on-premise system. Any high-level SAP Basis support beyond routine patching (complex configuration, system refreshes, etc.) may require a separate engagement.
• Business Network & Tools: Often, RISE includes an Ariba/Concur “Starter Pack” and SAP BTP or Signavio tools. Clarify which are included or optional add-ons, and what metrics (e.g., document volume for digital access) apply.
• Implementation and AMS Partners: SAP expects you to use partners for migration, integration,n and ongoing application support. The RISE contract should reference these roles: a statement of work (SOW) for an implementation partner and an AMS provider. These partners will handle data migration, custom-code remediation, integration with third-party systems (e.g., CRM, ecommerce), and day-to-day user support – responsibilities not covered by SAP’s baseline RISE services.

Dependencies on third parties must be addressed upfront. If your SAP system integrates with other systems (IoT devices, Salesforce, supply-chain apps, etc.), ensure the contract clarifies how those interfaces are licensed and supported.

In particular, indirect or “digital access” usage (external systems reading or writing SAP data) has licensing implications; discuss with experts whether you need named-user or document-based licensing, and ensure it’s covered to avoid audit penalties.

Documenting Scope Clearly

A well-defined scope statement is the foundation of a successful RISE engagement. Write explicitly what’s included: every deliverable, environment, and service.

Key items to specify are:

• System Landscape: List each system by name and purpose. For example, 1× Production (high availability), 1× Quality Assurance (QA), 1× Development, 1× Sandbox, and 1× Recovery system. If possible, specify sizing or CPU/RAM targets. Clarify whether multiple production instances or legacy systems (e.g., an older Oracle DB adjacent to SAP) are in scope since complex landscapes can require extra integration layers.
• Environments Covered: Indicate which environments are included in the base subscription. A common trap is leaving out a required non-production system and discovering it only later. For example, if you need a fourth test sandbox for training, that should be budgeted upfront or marked out-of-scope.
• Licensing Metrics: Record the number of FUEs (and breakdown by user type or document volume). Note any user-count assumptions (e.g., “500 FUE for direct users, including 400 core and 100 advanced” or “indirect access covered via 10M digitals per month”). Make sure escalation rules are clear: if users or usage grow, how and when will you pay more?
• Functional Modules: List which SAP modules and solutions are contracted (e.g., Finance, Manufacturing, Warehouse Management, etc.), and confirm if any are explicitly excluded. If you plan to add an industry solution later, note the upgrade or add-on process.
• Customizations and Extensions: Document expected custom development. For example, if you have 200 existing ABAP programs or custom reports, state that the contract covers analysis and remediation of those up to a certain point. (Private cloud allows more custom code than public, but requires justification and rework for S/4 compatibility.)
• Partner Services: The split between SAP’s remit and partner responsibilities must be spelled out. It helps to create a responsibility matrix (RACI) listing tasks and who is accountable. For instance: Service / TaskSAP/RISE RolePartner/Customer RoleSoftware Licensing (S/4HANA, BTP)Provides as per contractPays subscription per FUEsCloud InfrastructureProvision VMs, storageDefine sizing, regions, networkOS/DB MaintenanceApply system patches, manage backupsConfigure settings, schedule jobsSAP Basis OperationsBasic system monitoring, emergency fixesConfig changes, transports, system refreshesData Migration– (migration services separate)Execute data loads/cleansing (partner)Custom Code Remediation–Analyze and refactor (partner)Third-Party IntegrationProvide connectivity (network)Develop/configure interfaces (partner)User Support & AMSPlatform (basis) support onlyOngoing helpdesk, functional support (partner)Disaster Recovery (DR)Optionally provide DR site (extra cost)Develop DR plan, run drills This kind of breakdown helps avoid “gaps” where each party assumes the other will perform a task. Make sure no task is missing or ambiguous. For example, if database performance tuning isn’t listed under SAP’s tasks, assume it’s on your partner or in-house team.
• Performance and Capacity Planning: Document expected workloads and performance targets. If you have 1,000 users running 5,000 transactions/day, state that. This informs sizing and avoids complaints of “slow system” after go-live. If SAP’s SLA is based only on uptime, consider adding explicit response-time or throughput benchmarks (for critical reports, for instance).
• Security and Compliance: Note any compliance requirements (like data residency, encryption, or audits). Ensure they are addressed. For example, RISE may allow you to pick a hosting region, but confirm that data remains in that location for GDPR or other regulations.

In summary, the scope section of your contract or SOW should read like a detailed checklist of everything you need, with definitions for each item.

Whenever possible, use exact numbers and definitions instead of vague terms. For example, define “production hours” (e.g., 8 am–6 pm GMT) and what constitutes a “critical incident.” This clarity will protect you later when SLAs and responsibilities are enforced.

Defining System Environments and Service Levels

An SAP RISE contract typically guarantees certain service levels, especially for system availability. Review and document these carefully:

• Availability/Uptime: SAP’s published baseline SLA is about 99.7% uptime for production systems and 95% for non-production systems. (This means roughly 24.8 hours of allowable downtime per year in production.) If your business requires higher availability (for example, “five 9’s” or 99.999%), you must negotiate it and be prepared for significantly higher costs. Confirm how uptime is calculated (e.g., excluding scheduled maintenance) and how violations are credited.
• Maintenance Windows: Clarify how SAP/Hyperscaler will schedule maintenance. Typically, periodic downtime (e.g., late-night patches) will occur. Stipulate how far in advance these windows are announced and ensure they don’t coincide with your business-critical periods.
• Performance SLAs: Beyond uptime, consider response-time or throughput metrics. For example, you might require critical transactions (order entry, invoicing) to have a response time under X seconds. These metrics are often not part of the standard RISE SLA, so if needed, you should add them contractually or via a separate performance testing covenant.
• Incident Response and Resolution: Define how quickly support will respond to and resolve issues of varying severity. The RISE package may specify that SAP will respond to platform outages within a certain time, but ensure similar commitments from your integration/AMS partners for application issues. List business hours for support coverage and define criticality levels (for instance, “Severity 1 – production down; Severity 2 – major loss of functionality,” etc.).
• Disaster Recovery: Check if DR is included. Many RISE contracts treat DR as an optional add-on. If disaster recovery (a separate standby system) is needed, clarify its availability SLA (e.g., “RTO of 4 hours, RPO of 1 hour”) and cost.
• Monitoring and Reporting: Decide who will monitor system health (SAP’s tools vs third-party AIOps). If you use a monitoring service, ensure it can access SAP metrics. Include any regular reporting frequency (e.g., quarterly SLA reviews, performance reports).
• Storage and Growth: Specify included storage (e.g., database size, backups) and what happens when data grows beyond initial estimates. Without a cap, extra storage can incur surprise charges.

Bullet-checklist for SLAs and environments:

• Prod vs Non-Prod Systems: State exactly how many of each.
• Uptime Targets: e.g., “99.7% production monthly; 95% non-prod.”
• Response Times: e.g., “High-severity issues: 2-hour response, 4-hour restoration.”
• Maintenance Windows: e.g., “Typically Sundays 12–4 am local; windows to be communicated 15 days in advance.”
• Disaster Recovery: e.g., “Hot-standby DR in alternate region, with failover tested annually.”
• Capacity/Performance: e.g,. “System must support 500 concurrent users with <2s average transaction response.”
• Data Backups: e.g,. “Daily backups retained 30 days; retention policy included.”

Clear definitions ensure that “performance” expectations are contractual and measurable, not left to chance. Without them, you may later discover that the service quality falls short of your needs, with limited recourse.

Support Boundaries and Partner Responsibilities

In a RISE environment, multiple parties collaborate: SAP (via RISE), the chosen hyperscaler, your implementation partner, and your internal IT/AMS team.

It is crucial to define “who does what” to avoid finger-pointing. Commonly:

• SAP (RISE) controls the software platform and underlying cloud environment. This means SAP guarantees the core system is up and patched, and will honor the agreed SLAs. SAP’s scope typically does not include functional application support, custom developments, or business-process consulting. It will also handle upgrades to the S/4HANA software and standard enhancement packages. SAP may provide tools or limited consultation for custom code remediation, but you or your partner usually does the bulk of the code changes.
• Hyperscaler (Cloud Provider), contracted through SAP, provides the raw data center services: servers, networking, and physical security. You should define the region and availability zones. The hyperscaler guarantees platform-level SLAs (power, cooling, network uptime) to SAP, but those details often become SAP’s problem to manage. You may still want visibility into the hyperscaler SLA (e.g., AWS promises 99.99% for certain services) because it affects your overall service. If you have a direct relationship with the cloud provider (outside of RISE), note how the RISE services will interface with it.
• Implementation Partner (could be a global SI or boutique SAP consultant) handles the migration project. Their responsibilities include project management, solution design, data migration, integration development (linking SAP to other systems), and any custom configuration. This partner should deliver according to a detailed SOW. Their scope ends at go-live (unless you also engage them as an AMS provider). Document which deliverables are theirs – e.g., “migrate 10 years of historical data,” “build 5 custom interfaces,” etc.
• Application Management Services (AMS) Partner or Internal Team: Post-go-live, day-to-day support shifts to an AMS provider or your IT organization. They handle user help-desk calls, minor enhancements, configuration changes, and possibly batch job monitoring. Ensure your contract clearly states whether AMS is part of RISE or a separate engagement. (Often it is separate.) For instance, if your staff will not support the new system, ensure an AMS partner is in place, with clearly defined SLAs and support hours.
• Customer (Business & IT Users): You are responsible for defining business requirements, testing, user training, and change control. The business must provide timely feedback during the project. Also, the customer bears the costs of user training, change management, and any hardware or networking on the user’s side. For example, if you need high-speed VPN connections to the cloud or special endpoints, list who provides and supports that.

To illustrate common splits of responsibility: SAP will guarantee the infrastructure and platform availability (e.g., “SAP ensures the servers hosting S/4HANA run continuously at 99.7%”). Your implementation partner or AMS provider will guarantee application uptime and performance in practice (for example, monitoring interfaces or fixing bugs). Use a RACI chart or table in your contract annex so there are no “blind spots.”

Finally, consider the hyperscaler relationship carefully. Under RISE, you do not contract directly with AWS/Azure, giving SAP control of that relationship.

This can limit your flexibility (you might not be able to change the cloud region or provider easily if business needs change).

If you have internal cloud expertise, you could negotiate clauses giving you more say in the cloud layer or plan for future exit (see recommendations below).

Avoiding Scope Creep and Misaligned Expectations

Preventing scope creep and expectation gaps starts with thorough planning and governance. Some best practices:

• Cross-Functional Involvement: Ensure that IT architects, business leaders, procurement, legal, and compliance all review the proposed RISE scope before signing. A common pitfall is to let only purchasing or finance handle the contract and later discover that IT requirements were missed. Involve end users as well: if a manufacturing manager expects a certain shop-floor interface, define it up front rather than improvising later.
• Lock Down the Baseline: Once requirements are set, resist making changes without formal review. Any new business requirement or technical change should undergo a controlled change process with clear impact analysis. For example, if mid-project someone requests an extra reporting dashboard, assess time/cost, and amend the contract rather than absorbing it as “already agreed.”
• Align Marketing Claims with the Contract: SAP’s RISE marketing may emphasize benefits like “simplified operations” or “embedded AI.” Don’t assume these are free or fully included. Always verify what was promised in pitches actually made it into the SOW. For instance, if the sales pitch implied advanced analytics, ensure there’s a line item for it. Oversimplified brochures can mask the real contract scope, so do the due diligence: quote actual product names and version numbers in the contract language.
• Governance and Communication: Set up a steering committee or regular check-ins. As Redress Compliance advises, maintain a centralized repository of all SAP-related contracts and specifications. Review progress against the contract milestones and SLA reports quarterly. This catches any deviations early. Assign an internal contract “owner” who understands the RISE terms and monitors performance.
• Train Stakeholders on RISE Boundaries: Sometimes, business teams think “SAP will fix any issue” because they outsourced to the cloud. Make sure all stakeholders know that certain tasks are on their side. For instance, your users should know that adding a new module (like SAP IBP) later requires a project, not something SAP just turns on.

Enforcing these practices minimizes the chance that the project balloons beyond the agreed scope or that responsibilities slip through the cracks. Clear documentation and change control will keep your RISE adoption on schedule and budget.

Common Pitfalls in RISE Contracts

Even seasoned IT teams can be caught off guard by recurring issues in RISE agreements. Watch out for these pitfalls:

• Vague SLA and Support Terms: Default RISE SLAs (e.g., 99.7% uptime) may not meet critical business needs. We have seen enterprises that assumed near-100% uptime for their ERP, only to find the contract allowed more downtime than expected. If your outage tolerance is low, explicitly tighten the SLA or add credits/penalties. Also, check if the SLA covers only unplanned downtime; it may exclude security patches or disaster events, which you might want to negotiate.
• Unspecified Environments: If the contract doesn’t enumerate all required systems, you could later be surprised by exclusion. For example, a company once deployed RISE expecting a full testing environment but later discovered the agreement only covered one QA box. They had to pay extra to provision another environment mid-project, delaying the go-live.
• Responsibility Gaps (Hand-Offs): Omissions in the RACI can lead to “no-man’s land.” For example, an organization assumed its implementation partner would tune the database for peak load. Still, SAP’s team treated it as out of scope, saying performance optimization wasn’t in the contract. Neither party addressed it until performance issues appeared in production. Always double-check that someone owns every critical task.
• Lock-In and Exit Barriers: Under RISE, you switch from perpetual licenses (owning software) to a subscription. Without careful planning, you might lose certain rights. For example, if the agreement lacks clear exit clauses, you could be stuck without easy access to your data or an option to buy perpetual S/4HANA licenses if you leave. Negotiate for data-export provisions and transition assistance at the end of the term. Also, cap price escalations – RISE contracts often allow 3–5% annual hikes, so locking into a maximum increase (say CPI+1%) is prudent.
• Oversimplified Bundles: RISE often includes enticing bundles or discounts on extra SAP products. Be wary of “shelfware”—products you don’t need now but are bundled into the price. Always ask for breakouts: What is the cost of the core RISE elements versus optional modules? Don’t let a discount on a bundle persuade you to take unnecessary items.
• Digital Licensing Surprises: If your SAP environment has many external interfaces, clarify how “indirect users” are handled. Historically, customers have faced massive fines (tens of millions) for unlicensed indirect access. RISE is no different: ensure your digital access model is defined (either by SAP’s document model or named-user approach) and that your contract covers the expected volume of digital documents or API calls.
• Neglecting Partner SLAs: Your implementer or AMS partner’s responsibilities need their SLAs and KPIs. Clients often focus only on the SAP-provided SLA and forget to enforce the partner’s deadline for ticket response or change delivery. Document these separately to avoid “hand-off” delays.
• Inadequate Custom Code Management: Moving to S/4HANA typically requires significant custom code cleanup (“clean core”). If you underestimate this effort, your project schedule (and costs) will blow out. A scope pitfall is treating code remediation as “free” or trivial; instead, treat it as a defined work package with its timeline and budget.
• Hubris of Hyperscaler Choice: As noted above, RISE makes SAP the broker of your hyperscaler services. If you fail to negotiate control, SAP may not easily agree to change your cloud provider later. If cloud flexibility is a priority, try to carve out terms (or consider self-managed on a cloud as an alternative).

These pitfalls have real consequences. For instance, one government entity’s £7.3M RISE project missed go-live deadlines due to scope increases and delayed change approvals. In another case, a company had to negotiate a mid-project upgrade of SLA from 99.5% to 99.7% (with downtime credits) to meet its uptime needs. Learning from these examples, insist on complete, unambiguous contract language before you sign.

Examples of Unclear Definitions Causing Issues

• Availability vs. Expectation: A retailer moved its ERP to RISE expecting “always-on” capability. After going live, scheduled maintenance took down the production system during a peak sales weekend, exactly the day their board had expected zero interruptions. The underlying RISE SLA allowed that maintenance window (it was only guaranteed that SAP would give advance notice), but the business impact was severe. The lesson: when downtime is unacceptable for your operations, specify blackout periods or bump the SLA, and negotiate credits for any unplanned downtime that affects your business.
• Environment Scope Surprise: A mid-size manufacturer assumed their subscription included one DEV and one QA system. During testing, they realized they needed a second QA box to parallelize integration and user-acceptance testing. Because the contract only covered one QA system, provisioning the second required emergency procurement (and extra monthly fees) well into the project. Listing all required systems (and headroom for temporary sandboxes) up front would have avoided this cost.
• Support Handoff Confusion: A healthcare company thought their managed service partner would field all Level-1 support calls. However, the RISE contract only obligated the partner to cover business hours; after-hours incidents defaulted to SAP’s platform support line. This mismatch wasn’t caught early, so late-night production issues waited until morning. The root cause was an undefined “support coverage” clause: only when the incident caused major complaints did they revise contracts to a 24/7 support calendar.
• Digital Access License Audit: In one scenario, a utility company integrated SAP with its customer web portal without updating its license model. After transitioning to RISE, SAP’s auditors noted that thousands of customer-initiated transactions were “digital access” events beyond what their subscription covered. The company had to renegotiate a larger digital access package post-migration. This underscores the need to list all data flows at contract time and determine licensing up front.

Each of these examples boils down to ambiguity in the contract: unspecified maintenance windows, omitted systems, undefined support hours, or hidden licensing terms. Prevent them by spelling out requirements (even if you assume they’re obvious).

Actionable Recommendations (Before Signing or Renewing)

To ensure your RISE agreement is tight and fair, take these steps before committing:

• Assemble a Cross-Functional Team: Include IT architects, system owners, legal, procurement, and finance. Have them review every aspect of the RISE proposal. Leverage their expertise to spot missing items (e.g., compliance needs, network design, user impact).
• Conduct a Pre-Sign Assessment: Do an internal “Phase 0” assessment of your current SAP landscape, as one industry guide suggests. Inventory every SAP system, each license type, all custom developments, integration,s and interfaces. Know exactly how many users you have, who the indirect users are, and what hardware supports SAP. Identify any redundant or unused licenses (“shelfware”) you can cut, which could reduce your RISE FUE count. Use SAP’s counting tools (USMM, LAW) as part of this audit.
• Clarify the Future Landscape: Define the desired end-state in detail. How many production instances, non-prod environments, and disaster-recovery sites will you need? What are your performance and uptime targets for each? Which specific business processes or custom functions must be migrated? Document all of this as requirements – then ensure the RISE contract’s scope section or an SOW exactly reflects it.
• Detailed License Terms: Work with an independent SAP licensing expert (for example, firms like Redress Compliance or other SAP contract specialists). They can ensure your FUE calculation is accurate and that digital access is covered. They will also help you negotiate license conversion (from perpetual to subscription) at favorable rates. Such advisors often spot clauses that SAP sales reps gloss over.
• Negotiate SLAs and Pricing: Don’t assume the default is good enough. If your business needs 99.9% uptime, start with an SLA of 99.9% and see how SAP responds. Get written credits or remediation for any downtime beyond the target. Cap annual price increases (SAP’s standard is 3–5%) at a level you can accept (e.g., CPI+1%), or request multi-year pricing guarantees. Break down the subscription fee if possible: know what you pay for software vs. infrastructure vs. managed services to benchmark against other options.
• Define Change-Control: Build a clause for scope changes, such as “Any change request will be documented, priced and approved before work commences.” This prevents hidden add-ons. Also, negotiate deadlines and penalty clauses for major milestones (e.g., if SAP fails to migrate by a certain date, you get rebates or extensions).
• Identify Exclusions: Explicitly list what is not included. Common exclusions might include premium support (24/7 SAP support vs. business-hours only), database consulting, custom development effort, or connectivity services. By outlining these, you avoid false assumptions.
• Plan the Transition: Allocate sufficient time for migration and testing. Depending on complexity, RISE moves typically take 6–12 months or more. Include a realistic timeline and milestones. Factor in a “code freeze” period, dry runs, and a rollback plan.
• Exercise Exit Rights: Carve out exit and data-handling provisions. For instance, SAP should be required to provide a full data export at the contract end and reasonable assistance to migrate off RISE. If you might ever leave the RISE model, see if you can lock in a price for perpetual S/4HANA licenses as an exit option (some customers negotiate the right to buy back licenses at termination).
• Lock in Advisory Support: Even after signing, engage in continuous governance. Hold quarterly reviews on SLA compliance, usage metrics, and spending. Update license inventories regularly and reclaim any unused FUEs. Maintain an ongoing relationship with your SAP advisors to flag contract renewals or changes well in advance.

By rigorously defining scope, SLAs, responsibilities, and governance upfront, you turn the RISE contract from a “vendor pitch” into a firm foundation that protects your organization’s needs. Engaging independent licensing and contract experts (rather than relying only on the vendor’s sales team) is a smart move to uncover hidden risks and ensure contractual clarity.

In short: Don’t let the promise of cloud simplicity lull you into vague contracts. Before you sign or renew RISE, document every requirement, quantify every metric, and agree on who will do what. This disciplined approach will minimize surprises, control costs, and align the service delivery with your business goals.