The main objective of this article is to explore how to adopt an authorization strategy based on best practices in SAP GRC Process Control. As mentioned in previous articles, Process Control plays a fundamental role in ensuring compliance with various regulations. In this context, the management of access to information according to the roles and responsibilities of each user becomes particularly relevant.
Entity Level Authorizations
Restricting access to information maintains the integrity of the monitoring environment. Since the Process Control tool works with information from the entire organizational system, it is of vital importance to keep this in mind.
That is why SAP GRC has identity-level authorizations, known as “Entity-Level Authorizations,” which function as an extension of the authorization standards already present in SAP itself.
This concept arises in response to the need to restrict access to information by departments or entities within the same company.
Furthermore, it offers a user-friendly management model as it allows for actions through the GRC portal’s front-end, SAP NetWeaver Business Client (NWBC).
Roles & Entity-level Assignments
To better illustrate the functioning of “Entity level,” we will use the organizational chart shown, based on two scenarios depending on whether the system has “Role Inheritance for Organizations” active for organizations or not.
CASE A:
- Role Inheritance for Organizations: Disable.
- Role Assigment: “Organization Owner”.
- Activity: Change or modification
- Entity Type: Organizational Unit.
- Assigned Entity: Org A2.
The boxes outlined in red are where the user can make changes to the data within their own organizational level. This is important because if there are lower levels, the user can only view them, as the nature of their role prevents them from making changes outside of their assignment level.
In the case of the black boxes, the user can view data from higher hierarchical levels but cannot modify them.
It is worth noting that they also cannot view data from other organizations that stem from a higher hierarchical level, as would be the case with Org B in this scenario.
CASE B:
- Role Inheritance for Organizations: Enable,
- Role Assignment: “Organization Owner”.
- Activity: Change or modification.
- Entity Type: Organizational Unit.
- Assigned Entity: Org A1.
In this case, the user will have the ability to view and modify data within their organization (red box) and also have the ability to view and assign subprocesses and controls (gray box) as long as they are at a lower hierarchical level within the same branch of the organizational chart.
Again, in the case of higher levels, the ability to view information from those levels will be present, but no changes can be made to it.
Before continuing, it is relevant to highlight that there is an exception to this scenario, which is corporate-level roles:
- This type of role is not affected by the “Role Inheritance for Organizations” option; however, its authorization functions the same in both cases.
- In this case, users can perform tasks such as making changes at the organizational levels to which they have been directly assigned, as well as all subordinate organizations within the same corporate level.
- The type of access to related object types, such as subprocesses or controls, will be determined by the authorizations added to that role.
All of the above is configured in the SPRO, in the “General Settings” section and the sub-section of “Maintain Authorization Customizing.”
In summary,
- If “role inheritance for organizations” is active: o Users manage objects assigned directly and in subordinate organizations in the same sub-branch (access to related objects depends on role authorizations in the back-end).
- If “role inheritance for organizations” is NOT activated: o Users can manage objects assigned directly (organizations, processes, controls), but they can only view subordinate organizations (not manage them).
Role Types
Authorizations for a final user to view, change, or create Process Control data are determined in three areas, each with its own type of function:
- SAP “back-end”: This group includes standard roles created in SAP (technical roles), created through the PFCG transaction; it also includes base roles that grant access to the application, as well as functional roles for PC (“Process Control”) that provide access to certain actions and specific entity types.
- GRC UI Application: These are the roles specific to the PC application (business roles) assigned to a user through the GRC UI.
- SAP “Enterprise Portal”: This case only applies if this mode is used in the company. This portal has its own roles assigned to a final user and determines the number and order of workplaces that can be accessed, as well as other variables.
Within the category of Technical Roles, there are three roles that must be assigned to all PC users in the back-end environment:
- SAP_GRC_NWBC: Provides access to the SAP Netweaver Business Client through the T-Code, NWBC, and also through certain Web Dynpros workplace types.
- SAP_GRC_FN_BASE: Grants the technical authorizations necessary to perform PC tasks.
- SAP_GRC_FN_BUSINESS_USER: Enables a final user to be eligible for the assignment of a user and entity role in the GRC UI. It also activates activity “16” (execute) in the GRFN_USER object.
Like technical roles, business roles also have certain particularities that are manifested through what are called “functional roles”:
- These roles are equivalent to the technical part of business roles.
- These versions must exist in the PFCG, but their assignment must be done through the GRC UI.
- SAP comes with a list of standard PC functional roles with preconfigured authorizations for certain specific entity types.
- These roles can be modified through the UI configuration options.
Additionally, there is also an advanced user role: GRC_SAP_GRC_FN_ALL: A technical role that can only be assigned in the Back-End (but provides access to the PC content in the GRC UI). Similar to SAP_ALL but for the Process Control part. It allows viewing all information in the Process Control system.
Below, we present the configuration method considered best practice:
Each of these steps has a series of recommended criteria that we will discuss below. All these parameters can be configured through the SPRO transaction in the SAP back-end.
Step 1: Role Definition in GCBP
SAP provides a set of standard roles (both technical and functional) that are readily accessible through the GCBP. It is advisable to create customized or “Z” versions of these roles to safeguard the original status against potential modifications over time.
Step 2: Initial and Secondary-Level Authorizations
This segment bears significant importance as it governs the eligibility criteria for a user to be assignable to a business role within the GRC UI.
This parameter is regulated through the GRFN_USER object and the “16” activity (Execute), which is seamlessly integrated into the foundational SAP_GRC_FN_BUSINESS_USER role.
The system inherently activates initial-level authorizations by default.
In practical terms, this signifies that even in the absence of a technical role assignment in the back-end, a user equipped with the authorization object encompassing the aforementioned activity will qualify for potential assignment to a business role within the GRC UI.
To circumvent this predicament, the activation of secondary-level authorizations within our system is imperative. Consequently, if a user lacks the requisite technical role in the back-end, the system will abstain from proposing them as a candidate during the user-to-business-role assignment process via the NWBC interface.
The activation of secondary-level authorizations serves as an added layer of security, effectively mitigating errors and confining the responsibility of authorizing access to SAP system administrators exclusively. Conversely, if the intention is to empower end-users with the capacity to manage access, it is advisable to retain the activation of initial-level authorizations.
Step 3: Role Assignment to Entities
At this juncture, certain considerations merit attention: All users assigned to business roles are linked to relevant entity levels (organizations, sub-processes, controls, etc.) through the configuration procedure. This instructs the system regarding the roles to make available to these users through the entity-user relationship.
The BC Sets provided by the SAP system automates the assignment of business roles to corresponding entity levels. When a role is designated as “unique,” it can exclusively be assigned to a singular user within that entity. Any customized role, whether created from scratch or derived from a standard role, must be meticulously configured to avert potential issues.
Step 4: Custom Regulation Definition
Leveraging the Multi-compliance Framework (MCF), the system affords the capability to manage compliance-related activities across multiple regulations.
Regulations must be defined through the configuration process to facilitate their assignment to specific entities and roles.
The system defaults to SOX and FDA regulations.
Roles specific to regulations are assigned based on the interplay of entities (controls, etc.) and regulations (SOX, FDA, etc.), pre-configured during the configuration phase.
This delineates that a role can be assigned to a particular entity type and regulation.
For example, Role X may be assigned to Control A under the SOX regulation, while Role Y is allocated to Control B under the FDA regulation.
During this phase, it is advisable to confine the generated roles to specific regulations.
Step 5: User Assignment to Roles
Upon the completion of the authorization configuration within the system, the assignment of roles to end-users can commence. This entails both technical roles in the “Back-end” and business roles within the GRC UI.
Technical (“Back-end”) Roles:
- This category encompasses three fundamental role types.
- With the activation of secondary-level authorizations, the technical versions of these roles become imperative.
Business Roles (GRC UI): User assignments shall be executed in accordance with the appropriate entity-regulation combinations.
Conclusions
Within the realm of SAP GRC Process Control, an authorization strategy grounded in Entity-Level Authorizations emerges as a pivotal component for ensuring controlled information access in compliance with regulatory standards. This approach enables the assignment of roles based on user responsibilities, thereby streamlining the efficient and secure management of regulatory compliance.
The optimal configuration of authorizations, achieved through role definition, level authorizations, and customized regulations, fortifies consistency and security in compliance-related activities. Concurrently, it empowers users through user-friendly interfaces like the SAP NetWeaver Business Client.