| 1 | Classify | Classify the role change type (assign / revoke), role type (BTP role collection, PFCG composite role, single authorization object, cloud service entitlement), and scope (user, group, service account) | Role change type, role type, and scope documented |
| 2 | Confirm target | Confirm the exact target system (BTP subaccount/tenant, S/4HANA SID + client, cloud service instance, environment tier: QA/PPD/PRD) | Target system, subaccount/client, and tier confirmed by user |
| 3 | Criticality assessment | Assess business criticality of the roles being assigned or revoked (financial posting, payment execution, payroll, system administration, integration platform access, compliance-relevant data) | Criticality level: low/medium/high/critical |
| 4 | Requester confirmation | Confirm the name, role, and authorization of the change requester | Requester name and role documented |
| 5 | Approver identification | Identify the authorized approver (security owner or compliance officer — different person from requester — SoD requirement) | Approver name, role, and authorization level |
| 6 | Ticket linkage | Link the role change to a change management or access request ticket (ITSM reference: ServiceNow, Remedy, SAP Cloud Identity Access Governance, GRC access request, etc.) | Ticket number confirmed |
| 7 | Scope documentation | Document the complete list of roles, role collections, or authorization objects to be assigned or revoked, including the target user(s) or group(s) and the validity period | Role list with descriptions, target user/group, and validity period |
| 8 | Read-only current state | Read the current role assignments for the target user(s) or group(s): current role collections, assigned PFCG roles, active authorization objects, last access review date | Live evidence from target system (read-only) |
| 9 | SoD pre-check and diff | Run a Segregation of Duties pre-check against the proposed assignment; produce a diff of effective permissions the user will hold after the change; document any SoD conflicts found — refuse if any conflict exists | SoD pre-check result (pass/fail) and effective-permission diff |
| 10 | Blast radius | Document all transactions, business objects, data sets, and business processes that will become accessible (for assignment) or inaccessible (for revocation) after the change | Blast radius document with affected access scope |
| 11 | Rollback plan | Document the explicit rollback procedure: which roles to revoke or reassign, validity-period reversion, or restore-from-snapshot path | Rollback procedure documented and confirmed feasible |
| 12 | SoD verification | Verify that requester (step 4) and approver (step 5) are different authorized individuals; confirm no self-approval; confirm SoD pre-check from step 9 returned no conflicts | SoD confirmed: requester ≠ approver; SoD pre-check passed |
| 13 | Approval gate | Obtain explicit written approval from the authorized approver for this specific role assignment or revocation | Approval statement on record in this session |
| 14 | Execute approved change | Execute the role assignment or revocation for approved roles only, for approved users or groups only, within the documented validity period | Execution log with timestamp |
| 15 | Verify | Verify post-change state: confirm role assignments are active, run effective-permission check, confirm business process access matches expectations, confirm no unintended SoD conflicts introduced | Post-change log and verification results |
| 16 | Audit | Produce complete audit record: all 17 steps, evidence, commands, timestamps, approvals, SoD pre-check result | Audit record |
| 17 | Report | Deliver final report to requester, approver, security owner, and compliance team | Report delivered and acknowledged |
