SAP GRC Risk Management and Process Control - first and second level authorisations explained

[Xenia]

As an SAP authorisations expert working with SAP GRC, you will most likely come across first and second level authorisations. These concepts are crucial for working effectively with GRC components such as Process Control and Risk Management. They differ from the standard role-based access control (RBAC) logic used in SAP ERP.

So what are these differences and how do first- and second-level authorisations differ?

Common features of the first and second level authorisation concept

Both first- and second-level authorisation concepts work with entities that are assigned to roles. This approach provides a dynamic authorisation management system compared to the more static PFCG role assignment, which only changes when a user changes job roles. In the GRC application, these roles are assigned directly via the user interface, bypassing the need for transactional assignments such as PFCG or SU01. This is known as the Entity Level Authorisation (ELA) concept and is technically enabled by the GRFN_USER authorisation object.

GRFN_USER interacts with the authorisation object GRFN_API, which provides further refinements for object and information authorisations within SAP GRC. GRFN_API helps to link entities (i.e. controls) to entity roles. As a result, entity mapping for business users can be adjusted directly through user interfaces, eliminating the need for mapping at the PFCG level!

This diagram illustrates the interaction between standard SAP authorisations and ELA:

If you would like to know more about ELA, in particular how the interaction of GRFN_USER and GRFN_API works, please refer to the SAP note: https://me.sap.com/notes/1572360/E

Differences between the first and second level authorisation approach

Now that you know that both the first and second level authorisation concepts work with entity-level authorisations, what are the differences between the two? The main difference is the flexibility of assigning entities to users. In first level authorisations, which is the default in SAP GRC, the assignment of entity roles is quite flexible. Therefore, all users assigned to entity roles can perform actions based on the permissions of the entity roles.

On the other hand, second-level authorisation is less flexible and therefore needs to be activated in Customizing if it's to be included in SAP GRC (accessible via SPRO: Governance, Risk and Compliance -> General Settings -> Maintain Authorisation Customizing).
Specific application roles, such as 'Cross Regulation Organisation Owner' and 'Cross Regulation Control Owner' are assigned directly to users, segmenting them into separate entity-user role groups. This setup defines the entities that a user can control. Only entities associated with a particular application role can be manipulated by a user with that role.

If this sounds confusing, just remember: Entity data mappings in first-level authorisations can be managed by any business user (with the assigned entity role). In contrast, second-level authorisations restrict Entity Data Assignments to users with the corresponding application roles.

SAP Help is a good reference for this if you need more information: https://help.sap.com/docs/SAP_PROCESS_CONTROL/791a2c3c1e4b449bb64a209d0b4ce128/8d589fc682bb40a7affec... (the link refers to SAP Process Control, but is equivalent to SAP Risk Management).

Since you cannot use the first and second level authorisation concept in parallel, but have to choose between the two when working with SAP GRC, this blog post may help you to make an informed decision on which concept to choose.