Managing SAP GRC Access Requests Effectively
Best Practices for Cleanup, Escalation, and Troubleshooting
Automation without governance is like speed without direction—it gets you moving fast, but not always where you need to go. In SAP GRC Access Control, Access Request Management (ARM) delivers powerful automation for user provisioning, but without disciplined oversight, it can just as easily create backlogs, compliance gaps, and security blind spots. The real challenge is not just automating requests—it’s ensuring every request is timely, accountable, and controlled. Because in GRC, unattended requests aren’t just inefficiencies; they’re risks waiting to be exploited.
SAP GRC Access Control’s Access Request Management (ARM) module empowers organizations to take control of user provisioning with speed, and precision. By automating access workflows, enforcing risk-aware approvals, and ensuring compliance from the start, Access Request Management transforms what was once a fragmented, manual process into a secure, auditable, and business-aligned access lifecycle.
While ARM brings much-needed automation to access provisioning, it also introduces new challenges—such as requests that remain pending for extended periods, approvals not handled in time, and staled workflows clogging the system. These inefficiencies not only delay business operations, potentially leading to financial setbacks, but also open doors to compliance gaps and increased fraud risk. Managing these exceptions effectively is critical to ensuring that automation truly serves its purpose: secure, timely, and controlled access.
With over 25 years of experience in SAP Security & GRC, I’ve seen firsthand how an unmanaged request lifecycle can quickly snowball into operational chaos and compliance gaps. This article outlines effective strategies for managing SAP GRC requests, ensuring your system stays clean, auditable, and responsive.
1. The Need for a Structured Approach
Automation through Access Request Management (ARM) is a step forward—but without ongoing governance, even the most sophisticated workflows can become a source of backlog and risk. Requests that sit idle for weeks, approvals that never complete, or workflows that fail silently can create blind spots in your access landscape.
A structured approach within ARM involves continuously monitoring the health of request queues—validating pending requests, identifying aging approvals, and escalating items stuck beyond defined thresholds. It ensures accountability at every stage of the workflow and prevents bottlenecks from becoming security loopholes. By embedding periodic checks and automated validations into the process, organizations can maintain a clean, responsive, and compliant access environment—where every request is either progressing or being resolved, never ignored.
2. Key Recommendations
While there are many ways to manage the requests in a better way, I recommend the following based on my experience:
Disabling Approve option for Administrators
Automatically escalate pending requests
Cancel requests of the separated users
Cancel old requests with proper notifications
Archive old requests
Below sub-sections outline each of these heads:
2.1 Disable Approve option for Administrators
The start is disabling “Approve” option from Admin screen. This becomes a backdoor in many cases. SAP GRC AC offers an option to the Administrators to approve requests on behalf of other users from the Admin screen. It is often mis-used especially during in urgencies or during clean-up activities where administrators will either approve/reject the request. See below:
To disable this option, follow the steps mentioned below:
Create a new role with all admin authorizations (instead of using SAP delivered standard role.)
Make sure GRAC_EMPLY with ACTVT 02 is removed.
Assign the role to the Administrator
NOTE: If you don’t find GRAC_EMPLY authorization object in your SAP GRC system, refer to SAP Note1243085. Implement the corrections to get the authorization object.
Important:
It is also recommended to have the Admin Approval authorization through a Firefighter ID to address some urgent requests. Thus, it enables double-check and ensures administrators are seeking right approvals before approving requests on behalf of other users.
2.2 Escalate Requests Older Than x Days
The biggest challenge is following up on requests. When the approvers are occupied with other business priorities, the requests tend to be on hold for more time. While ARM supports configuring SLAs, I see that many of the enterprises doesn’t utilize this option in SAP GRC due to various reasons.
As an alternative, it is recommended to automatically escalate pending requests that are older than a predefined threshold (e.g., 7, 14, or 30 days).
How to escalate?
The easiest way to escalate is to configure MSMP workflows to re-route to alternate approvers or GRC admins when a request is not approved within the stipulated time. Here is how it can be configured.
In the respective stage, select Modify and click on more details
Enable Escalate option under “Escalation Type” and choose Escalate to Specified Agent
Select the escalation time
Select the escalation person. For eg: GRC Admin
Save and Activate the workflow
The standard capability only allows you to specify owners who are involved in the MSMP workflows. As an alternative, it is recommended to create a custom program which can identify the requests that are pending than a predefined threshold and route it to the right escalation level. For eg: If the request is not approved by the current approver in the stipulated time, it can go to his/her manager, and the further level as per the definition. Below is an example on such use case:
The steps are outlined below:
Determine and setup the threshold
Identify the approver’s manager
Send an email on day # 1 (1st reminder) looping approvers manager
Determine the requests that are not approved ~5 days from the 1st reminder
Send 2nd reminder looping managers manager
Determine the requests that are not approved ~5 days from the 2nd reminder
Cancel the requests
Notify the user/requestor
Another alternative is to send consolidated email to the approvers and mention that the requests will be closed automatically that are not approved.
At ToggleNow, we delivered a smart GRC customization for one of our clients. This solution automates the entire approval process by consolidating all GRC requests at predefined intervals and sending a single, easy-to-review Excel report to approvers.
Powered by BOT-based automation, the system automatically identifies requests pending beyond a specified number of days, generates a consolidated summary for each approver, and takes proactive action by cancelling stale requests if no action is taken within the defined timeframe.
This not only reduces manual effort but also ensures faster decision-making, cleaner workflows, and improved compliance across the organization. Check out:
2.3 Cancel requests of the separated employees
What about active requests of employees who have left your organization?
It’s something many don’t consider until it becomes a problem.
Active requests raised by separated users are not automatically cancelled. Even more concerning—if your provisioning option is set to “Create” for Change Requests, the system may actually re-create the user ID once such a request is approved. This poses a serious security and compliance risk.
To avoid this, make sure employee separation includes a checkpoint to review and close any open access requests. You can leverage the standard SAP report GRFNMW_MANUAL_INSTANCE_CANCEL to cancel these requests. That said, a bit of customization is often required to correctly identify separated users in your LDAP or Active Directory, depending on your organization’s onboarding and offboarding processes.
2.4 Cancel Stale Requests (with Notifications)
The standard program GRFNMW_BATCH_STALE_REQUEST identifies requests pending for approval based on their last updated date (The Last update date can be found in table GRACREQ and from the Audit Log of the Request from the Time Stamp of the last action), where the workflow instances are still running.
To cancel stale requests, run the program 'GRFNMW_BATCH_STALE_REQUEST' by providing the MSMP Process ID and a specified period in days.
Note: SAP recommends executing this program with the appropriate user authorizations such as WF-BATCH user—to avoid authorization issues.
However, if the program must be run by any user, ensure that the user has the following authorization:
Authorization Object: GRFN_MSMP
Activity (ACTVT): 70
NOTE: The "Abort if could not cancel” option will Abort the Access Requests which cannot be Cancelled.
For further details on how this program operates with the defined parameters, refer to SAP Note 1939486 – How to Process Stale Requests in Pending Status.
Sending Reminder to the Approvers:
The GRFNMW_BATCH_EMAIL_REMINDER program can be used to send email notifications for requests approval that remain pending in the approvers' work inbox. The Template ID can be customized based on when you plan to run the GRFNMW_BATCH_STALE_REQUEST program, allowing you to notify approvers in advance before the stale requests are cancelled.
Note: For a detailed explanation of how the email reminder program functions, refer to SAP Note 2501859 – GRFNMW_BATCH_EMAIL_REMINDER explained.
2.5 Archive Old Requests
Access requests—whether completed or cancelled—hold audit significance and must not be deleted.
As an alternative, it is recommended to archive the completed requests using SAP’s supported functionality. Refer to SAP Note 2040956 – GRC Access Control – How to archive requests.
SAP standard program GRFNMW_ARCHIVE_WRITE can be utilized for this activity. Execute the program, provide all the relevant details such as the MSMP Instance Finished Date, MSMP Process ID, and MSMP Instance ID (which can be retrieved from the table GRFNMWRTINST).
NOTE: It is recommended to use the “Test Mode” before running in the “Production mode” to identify the impact. When the program is executed in Production mode, all the requests will be archived.
If you need to archive additional objects such as logs, action usage tables, and other Access Control-related data, you can use the SARA transaction. This transaction allows you to archive various objects within SAP Access Control.
For guidance on archiving different objects in GRC Access Control, refer to SAP Note 1719967 – How to Archive in GRC Access Control.
In cases where requests are stuck in the workflow due to some errors and causing dumps when an approver attempts to open them, you may need to cancel these requests manually. This can be done via the Search Request option in NWBC, or by using the SAP standard program GRFNMW_MANUAL_INSTANCE_CANCEL.
This program cancels the stuck request, changing its status to "Aborted", allowing you to submit a new request for the same workflow type.
Important Recommendation
It is recommended to keep at least the last 12 months data in the system and archive rest of the requests. Use auto archival option with customizations.
Conclusion:
Managing GRC requests isn't just a technical exercise—it's a compliance imperative. Whether it’s an aging request, a misrouted workflow, or an archive backlog, ignoring these issues can compromise both operational efficiency and regulatory posture.
With the right approach—cancel, escalate, archive, troubleshoot—you can ensure your GRC environment stays lean, audit-friendly, and responsive.
Don’t let yesterday’s requests become tomorrow’s audit findings.