An Introduction to SAP GRC Access Control

SAP Governance, Risk, and Compliance (SAP GRC) is a powerful SAP security tool that can be used to ensure your company meets data security and authorization standards.


One tool in the solution that helps this is SAP GRC Access Control.



There are a couple of key benefits to this tool: (1) to prevent and identify access and authorization risks in cross-enterprise SAP systems to prevent fraud, and (2) to reduce the cost of continuous compliance and control.


With its integrated risk analysis and workflow engine, SAP GRC Access Control reduces the time required to detect, remediate, and approve access across different IT systems. It offers a centralized request and approval process with integrations to HR systems (such as SAP ERP HCM) to support the user life cycle process from hire to retire. If evaluated access is required for a short time, temporary access can be checked out and evaluated and checked by a supervisor.


Access Risk Analysis

It’s important to separate and control authorizations a user gets to be compliant with Sarbanes-Oxley (SOX) and other laws and regulations. The Access Risk Analysis (ARA) modules let you identify and detect access violations in the entire enterprise. It can check for SoD violations, critical transactions and authorizations, and critical roles and profiles.


To check these violations, the ARA module uses a rule set that contains the definition of the critical authorizations. The system compares the defined rules from the rule set with the authorization in scope (e.g., a user, a role, a profile) and reports any violation that might occur.


Access Request Management

In a traditional organization, access is granted after completing paper forms that were sent through the organization and finally made their way to IT security. The IT security administrator then grants the access manually. Checking for compliance and traceability were both limited. During the manual approval process on paper, how can the signee identify possible threats that an assignment would create? Also, the approval process typically takes several days to complete, depending on the size and complexity of the organization.


With Access Request Management (ARM), a user can request access through a workflow based module. When an access request is submitted, it takes a predefined path and allows for multiple approvals and security checks. Because the ARM module is tied into the ARA module, the approver can execute compliance checks in the form of an access risk analysis to identify possible threats before they even occur.


You can customize the workflow to reflect your company’s policies. Roles and authorizations are automatically logged when the access requests are approved for future reference and audit purposes. ARM ensures corporate accountability and compliance with SOX, along with other laws and regulations.


Business Role Management

With Business Role Management (BRM), an enterprise can implement certain steps involved in the lifetime of a role. From role creation, for which BRM allows you to apply naming conventions, performing role updates with the approval from a role content approver, all the way to providing the attributes for role provisioning, BRM supports the life cycle of a role.


BRM empowers role owners to be involved in the role-building process, to run risk analysis before the role’s deployed, and to document role testing.


With its business role concept, BRM offers the ability to create system-independent virtual roles to simplify the technical role assignment in the backend system. The concept is similar to that of composite roles, but it isn’t restricted to a single system.


The business role construct is only known in SAP GRC Access Control, but it can be shared with SAP Identity Management in an integrated provisioning scenario. When a business role is assigned to a user, the system distributes the technical role assignments to various backend systems, either via the CUA or directly. The backend system, however, doesn’t know that the role assignment comes from a business role.


Emergency Access Management

With Emergency Access Management (EAM), a user can perform emergency activities outside his or her standard roles. The user performs the emergency activities in a controlled and fully auditable environment by checking out a firefighter ID. The application allows for a firefighter ID that grants the user (firefighter) broad yet regulated access. All activities that are performed in the context of the firefighter ID are logged and can be reviewed.


The firefighter ID usually comes into play in emergency situations in which it’s imperative to execute certain tasks. These tasks are mostly irrespective of SoD violations and access risk violations. Integration with the ARM module allows you to control the assignment of firefighter IDs and the log report review workflow.


Segregation of Duties Management Process

The goal of the SoD management process is to eliminate or at least reduce the possibility of errors and fraud. Because a single user won’t have access to several phases of a certain business process, the management of such risks is important.



To achieve separation of duties, a business process must be divided, distributed, and allocated among various individuals. All this is carried out in three separate phases, and SAP GRC Access Control is an ideal tool to support this process:

Phase 1

Risk recognition

In this first step, you define a high-level list of applicable SOD conflicts that allow fraud or generate significant errors. The outcome of this step is that your business has determined what is an unacceptable risk that they want to report on and manage via remediation or mitigation. This step is carried out outside the system and includes a fundamental understanding of business processes and its vulnerabilities.


Rule building and validation

In the second step, you build the technical rule set based on the recognized risks from step 1. The outcome of this step is the technical rule set that allows you to analyze and identify risks on users, roles, or profiles. The technical rule set is built in the ARA module.

Phase 2

Risk analysis

The first step in phase 2 is to analyze the result of the risk analysis. The ARA module allows you to perform a risk analysis against users, roles, profiles, and even HR objects (positions, jobs, etc.). The result of the risk analysis will identify if a single user, a single role, a single profile, or a job/position has the ability to perform any of the conflicting functions defined in step 1. As a security administrator, you can use the results to provide the business insight into alternatives for correcting or eliminating discovered risks.



This is one of the most important steps in the process. The goal is to remediate the occurrence of the conflict on a user level. Please note, the occurrence of an SoD conflict happens the most when assigned to a user. Therefore, evaluate whether the conflicting tasks can be separated to another user.


In this step, role changes and reassignment of roles becomes necessary because only then is a hard remediation of access violations possible. The result of this step is to reduce the number of conflicts to a minimum so that only a few must be mitigated.



If remediation isn’t possible, the remaining risks must be mitigated. Mitigation requires a formal description and action to appropriately mitigate the risk. In most cases, mitigation is achieved by implementing additional monitoring procedures that ensure to compensate the risk after an action happened. Mitigating actions are in most cases performed after an event happened. Therefore, it’s recommended to use mitigations as little as possible.

Phase 3

Continuous compliance

In this final phase, it’s important to establish a continuous process wherein every access request is reviewed against the SoD conflict matrix prior to provisioning. In addition, make sure that all role changes undergo the risk analysis and are remediated before becoming available to end users. The result is that your system remains clean from violations.



In this blog post, you were introduced to SAP GRC Access Control and the ways it can provide authorization to users. This segmenting of access is an important part of any good security landscape—after reading this, you should have a better understanding at how you can provide authorizations on a temporary or indefinite basis.


Editor’s note: This post has been adapted from a section of the book SAP System Security Guide by Joe Markgraf and Alessandro Banzer.


SAP Access Control: The Comprehensive Guide
SAP Access Control: The Comprehensive Guide

Manage on-premise user access with this comprehensive guide to SAP Access Control. Begin with step-by-step installation and configuration instructions. Then implement key SAP Access Control modules, including access risk analysis, emergency access management, and access request management. Learn to manage business roles, review user access, evaluate segregation of duties risks, and configure automation workflows. This is your all-in-one guide to SAP Access Control!

Learn More

SAP PRESS is the world's leading SAP publisher, with books on ABAP, SAP S/4HANA, SAP CX, intelligent technologies, SAP Business Technology Platform, and more!