Lesson 2 of 5
Reading the responsibility split
9 min
Listen to this lesson
The R&R is long, but a platform team can read it in a structured way: by layer, and within each layer by the questions that cause trouble in practice. Who does it? Who asks for it? Who checks the result? The table below summarizes the tasks that matter most to Basis and testing, as they appear in v.3-2025.
| Task | Category in the R&R | What it means for Contoso |
|---|---|---|
| Database and log backups per policy; monitoring of backups | Standard | Done by SAP; Contoso still validates restored data when it requests a restore |
| Monitoring of system availability and critical system states | Standard | Technical monitoring only; interfaces, jobs and business transactions are not covered by it |
| Kernel patches; updates (support packages, Feature Package Stacks) | Standard | Executed by SAP with scheduled downtime; non-technical post-installation steps are Contoso's |
| Schedule standard housekeeping jobs | Standard | SAP runs basis housekeeping per SAP Note 2190119; business jobs are another matter |
| Schedule, change or monitor application batch jobs | Packaged Services | Contoso's job team, unless bought from SAP |
| Execute transports between systems | Packaged Services | Contoso's release management, unless bought; inform SAP before critical transports |
| Administer customer users, roles and authorizations | Packaged Services | Contoso's security team, unless bought |
| Implement security notes | Packaged Services | Testing of implemented notes is explicitly the customer's |
| Testing and acceptance of object changes | Excluded | Always Contoso |
| Sign-off of incident resolution | Excluded | Contoso confirms that a fix actually works |
Selected tasks from SAP's RISE R&R v.3-2025. Check the version and options in your own contract.
Build Contoso's own matrix
The R&R says what SAP does; it does not say which Contoso team does the rest. Sam turned it into a responsibility matrix for Contoso: for each task that applies, the category, the contracted service (if any), the Contoso owner and the partner's role. Grace reviewed it with the steering committee, because several rows needed budget: either Packaged Services from SAP or staff in Sam's team.
| Task | Category | Contoso decision | Owner |
|---|---|---|---|
| Transports to CMQ and CMP | Packaged Services | Keep in-house | Luis, release manager, with Sam's team |
| Application job monitoring | Packaged Services | Keep in-house with SAP Cloud ALM | Operations analyst |
| User and role administration | Packaged Services | Keep in-house | Security team |
| Security note implementation | Packaged Services | Buy from SAP; test in-house | SAP ECS, then Priya's regression |
| Testing and acceptance | Excluded | In-house | Priya and process owners |
Watch the boundaries inside a single task. Monitoring is a good example: SAP's standard monitoring covers system availability and critical technical states, and the R&R notes that technical monitoring setup does not include solutions, customer configuration, interfaces, connections and jobs. A failed nightly billing job or a stuck IDoc queue is therefore Contoso's to detect, unless it bought a monitoring service. If nobody owns it, the first alert will come from a customer.
One task, several owners
Many real tasks cross categories. A security note is a good example: in the R&R, analyzing and implementing relevant SAP Security Notes in development and transporting them to quality and production is a Packaged Services task, so SAP does it only if Contoso bought that service. Testing the implemented notes is explicitly the customer's. If the note needs a kernel patch, that part is a standard service SAP performs with scheduled downtime. One vulnerability can therefore involve three owners and two request types.
- Note releasedSAP Security Note relevant to CMP identified (Packaged Service if bought, otherwise Contoso's security lead)
- Implement in CMDSAP under a Packaged Service, or Kenji's team; manual steps documented
- Transport to CMQLuis, release manager (transports kept in-house)
- TestPriya's targeted regression of affected processes and roles: always Contoso
- Kernel patch if requiredSAP ECS standard service with scheduled downtime
- Transport to CMPRelease manager, in the agreed window, after sign-off
What would you do?
Maria reports that billing documents were not created overnight. The job failed with an application error at 02:10. Under the responsibility matrix, who should have noticed first?
- Read the R&R by layer: who does it, who asks for it, who checks the result.
- Backups, technical monitoring, kernel patches and updates are standard; business jobs, transports and user administration are Packaged Services.
- Testing and acceptance and incident sign-off are always the customer's.
- Turn the R&R into your own matrix with named owners, and watch boundaries inside tasks such as monitoring.
Check your understanding · not graded
Lesson check
1. In the R&R, how is 'testing and acceptance of object changes' classified?
2. What does SAP's standard technical monitoring not include, per the R&R?
3. Who tests security notes that SAP implements under a Packaged Service?
4. Why must file-based interfaces that used OS access in ECC be reviewed for RISE?