SAP GRC ARM: Access Request Management

In this article we are going to explain what the module of Access Request Management (ARM) of SAP GRC tool is, and the different uses and benefits it has.

Access Request Management belongs to the Access Control (AC) module of GRC tool. SAP GRC Access Control helps organizations and companies to detect, manage and prevent access risk violations and reduce unauthorized access to authorizations, systems, and critical information. This module has different sub-modules to control the Risk generated in a company (Access Risks Analysis), control the automatically reset of passwords (Password Self-service), use of emergency access (EAM), etc.

ARM’s objectives

In general, the objectives of ARM are:

1. Common Repository/tool for raising access requests for changes users: when an employee needs to update its authorizations or user in SAP systems, raise a request which automatically follows a specific workflow
2. Request review by specific users: the requests can be reviewed by managers or approvers (like role approvers or risk approver), and once all steps are completed.
3. The changes in the systema re done by a system user: the changes will be automatically done in the SAP systems by a System user, always the same system user. With this option, all changes in the system related with the update of users are not do it by a nominal user, are do it by a system user, only when the correct approval are done, so the security regulations or SoX are correctly followed.

ARM’s benefits

Before to speak about how it can be configured, it is important to know the benefits of ARM, the most important ones are:

• There is a log with all steps of the workflow. This log can be downloaded from GRC and can give information such the stages name, approvers, time of review or the items approved or reject.
• The workflows can be customized as the company wants, with different stages to review by mangers, role approvers, risk owners, etc.
• The approvers can be mapped, so it is not necessary to have a consultant sending emails asking for review.
• Notifications can be configured for each step and select by default the team which will receive it, and of course the content of the notification.
• All changes in the system will be done by a system user.
• New SoD risks or critical actions generated for the users can be reviewed to decide if are correct and have the number of risks under control.

Of course, there are more, but these are most relevant from my point of view. If we speak about the configuration, there are some key points that are important to understand:

Users Data Base (DB)

ARM Request are raised to create or maintain users, so it is necessary to take the main data of the users from a Data Base. This can be the SU01 of a connected SAP system, an Active Directory or another type of data base of connected systems, like Human Resource systems.

It is possible to take different kind of data from these DB, the typical ones are: name, sure name, email, manager, department, etc. But there are more standard ones, like type of employee, telephone, etc. However, it is also possible to create custom fields to have more data from the data base, like for example license type or specific values.

Type of requests

There are different types of requests, the most useful are:

• Create/modify accounts.
• Lock/unlock accounts.
• Delete accounts.
• Request Emergency users.

Of course, these ones are most common ones, but it is possible to create different types, like HR Triggers, which can be an automatic request when a user will leave the company, or request to update only values of the users, like their parameters or other details.

Notifications

It is possible to configure different types of notifications for every stage. The notifications can be custom, with specific data, custom data, the logo of the company and more.

Also, you can configure to whom these notifications can be sent, for example, to the current approvers, to the security team, to specific approvers or teams, or maybe only to the requester at the end of the request, the possibilities are a lot.

Audit log and instance status

There is an easy way to know at any time the status of a request, checking in the option of “Search request” the instance status. This option gives the main details of the request, which is the status (pending or complete) of all paths of the request, which are the pending approvers (in case that there are) and the log of the request.

Also, it is possible to check and download the log of all movements in the request: assignments, decisions, approvals, comments, etc. And associated user related to these changes can do it and, the time and date of that change. This functionality is very useful during audit periods, supporting the extraction of evidence in an easy way, even with the option to download it in .pdf format.

Items to review

There are different kind of approvers because there are different kind of items to approve:

• Roles: the roles to be assigned o removed from a user can be reviewed by specific approvers.
• Risk: the risks generated at user level (or only the new ones generate because of the request) can be reviewed by specific approvers.
• User details: the details of the user, like name, surname, email, parameters, etc.

Of course, these functionality options are not the only ones of Access Request Management, but considering my experience during the last 6-7 years in different clients, they are the most relevant to be considered when designing GRC ARM from a functional perspective, some of the most relevant ones.