SAP Role Change Request Form Template
Most SAP access problems start with a role that was edited quickly and never documented. This form puts the business need, the exact authorization change, the risk check and the test evidence on one page.
Fill in
SAP Role Change Request Form Template
Role Change Request RCR-2026-0312
Company: Acme Precision Ltd Role: Z_MM_PURCHASER_PLANT1000 Role type: Single role Requester: A. Patel, Procurement manager Role owner: A. Patel Users affected: 14 Test system: QAS / client 200
Business need
Buyers must be able to display vendor evaluation results to support quarterly supplier reviews. They currently ask a colleague to print them.
Requested change
Add display-only access (activity 03) to the vendor evaluation transaction for plant 1000 and purchasing organization 1000. No change, create or delete access.
Transactions or services: ME6H, ME6G
Authorization detail
| Authorization object | Field | Current value | Requested value |
|---|---|---|---|
Risk and test checks
| Check | Result | Evidence reference |
|---|---|---|
| SoD or access risk analysis run on changed role | ||
| Critical authorization objects reviewed | ||
| Derived roles and organizational values updated | ||
| Tested with a test user in the test system | ||
| Transport request number | ||
| Rollback plan documented |
Approvals
Keep one request per role change so the transport and the approval stay linked. Adjust fields to match your own change procedure. This is a starting point, not legal advice.
Speed up role reviews with read-only SAP insight
Optional: we can look at how role and user data could be summarised for your reviewers without write access.
Optional. The tool and every export work without this. No spam.
How to use the form
The requester states the business need in plain language. The security administrator translates that into the exact authorization objects and field values in PFCG, and fills in the table. The risk reviewer runs an access risk analysis on the modified role before it moves, and the tester confirms the change with a test user. Export the finished form and attach it to the transport or the ticket.
- Describe the need in business terms, not just a transaction code
- Record current and requested values for each authorization field
- Run the risk analysis on the role, not only on a user
- Reference the transport request that carries the change
Why the detail matters
A role is a bundle of authorization objects with field values such as activity, organizational levels and ranges. A change to one value, for example activity 02 instead of 03, changes what a person can do. Derived roles inherit authorization objects from a parent and only differ in organizational values, so a parent change reaches every child. The form forces you to name which roles are affected and who owns them.
Testing and evidence
Test in a non-production system with a user who holds only the changed role plus a baseline, then confirm both the new access and the absence of anything extra. The authorization trace (transaction STAUTHTRACE or ST01) and SU53 for a failed check help show which object a user is missing. Attach screenshots or trace exports as evidence. Auditors sample changes and ask for exactly this trail.
Common mistakes
Frequent errors include adding a full authorization to solve one missing object, editing a role directly in production, skipping the profile generation, and forgetting that a composite role may have other single roles that conflict with the new access. Another is approving without running the risk analysis because the change looks small.
Frequently Asked Questions
Should every role change use this form?
Any change to authorization values in production roles should be documented. Many teams use a lighter version for emergency fixes and complete the full form afterwards, but the record should always exist.
Who approves a role change?
At minimum the role owner, who understands the business need, and a security or risk reviewer who checks access conflicts. The requester should not be the only approver.
Do I need a separate form for derived roles?
Not usually. Name the parent role and list the derived roles affected. If organizational values change for only one derived role, mention that explicitly in the requested change field.
Where do I attach the transport number?
In the risk and test checks table. Linking the request to the transport lets an auditor trace from the approval to the change that reached production.
If your role changes are slow because requests and risk checks live in email, Netray can help design a read-only reporting layer over your SAP security data.
Related Tools
SAP Firefighter Emergency Access Request Template
A fill-in emergency access request and post-use review form for SAP firefighter or privileged IDs. Exports to PDF or Word for your audit file.
SAPSAP SoD Mitigating Control Register Worksheet
An editable register of accepted SoD conflicts and the compensating controls behind them, with risk score and review dates. Exports to Excel.
SAPSAP Profile Parameter Change Log Worksheet
An editable log of SAP profile parameter changes with old and new values, reason, approver and restart requirement.
SAPSAP Go-Live Security Readiness Checklist
A checklist of security and Basis items to confirm before an SAP system or release goes live, with critical items flagged.
More SAP tools
See all- SAP Sales Document Types Reference
- SAP Pricing Procedure Design Worksheet
- SAP Item Category Determination Reference
- SAP Delivery Block Reasons Template
- SAP Credit Management Checklist
- SAP Output Determination Checklist
- SAP Billing Types Reference
- SAP Incompletion Log Checklist
- SAP SD Tables Reference (VBAK, VBAP, LIKP, VBRK and More)