FAQ on Access Requests in SAP GRC

Angelika
21 December 2020
0 Comments

In this blog post, we cover common questions we get from users of GRC Access Control who are involved in the management of access requests. These users may be GRC officers, approvers, reviewers, or those in similar roles, and they take part in the process which assesses and helps end-users get access to other SAP system (for example S/4 HANA or BW).

We hope this blog post is useful for those readers who are in these roles or anyone who would like to understand more about how access requests work in SAP GRC.

Sections to explore:

Raising an access request form (click here)
Fields in the access request form (click here)
Passwords (click here)
Roles (click here)
Approvals (click here)
User deprovisioning (click here)
Access request logging (click here)
Risk analysis in access requests (click here)
Mitigating controls (click here)

Raising an access request form

Q1: What happens if a user has two requests – a new request and a change request – raised at the same time?

A: GRC only allows one open access request for the same user at the same time. If multiple requests are required for the same user, then one request must be finished until a next request can be entered.

Q2: Can I make changes to my own account?

A: Any changes to the access of existing users require the request type ‘change account’ to be selected. If the change is for your own user-ID, you need to select ‘own account’ in the field ‘request for’.

The rest of the request should be prepared in the same way as for ‘other user’.

Fields in the access request form

Q3: What is the standard way for filling in ‘First Name’ and ‘Last Name’ in the access request form?

A: The User Details tab of the access request form contains the fields ‘First Name’ and ‘Last Name’. You may choose to make any of these fields are mandatory.

This goes hand-in-hand with the way that you want your users’ user names to be organised. For example, you may want the ‘Last Name’ field to contain only the user’s official surname, while the ‘First Name’ field contains all of the user’s given names (including Chinese name as necessary). Once this policy has been determined, it should be communicated to all the relevant stakeholders in order to ensure that your user logging is systematically organised.

In case an Identity Management or other user management system interfaces into your GRC system, from which your users’ details are completed automatically, the full username may be saved into ‘Last Name’ only. In this case, you may decide whether or not to allow the users to make any manual changes to the fields ‘First Name’ and ‘Last Name’.

Q4: What is the relevance of user parameters?

A: User-IDs in the ECC or S/4 HANA system can be assigned to one or more user parameters. User parameters are default values for frequently occurring fields in the system such as ‘plant’ and ‘cost centre’. These default values are relevant mainly for user convenience and to reduce the risk of accidental incorrect values being entered. These user parameters have no significance whatsoever to authorisation.

If you choose to use these parameters, they will need to be manually entered in the access request. In order to ensure that these fields are completed, they can be made to be mandatory.

Q5: What is the relevance of cost centre field on the User Details tab of the access request form?

A: Cost centre is often used to determine the routing of various notifications and workflows in the ECC or S/4 HANA system. If so, this field should be made mandatory on the User Details tab of the GRC access request form. This ensures that access for a new user-ID will not be provisioned without adding a cost centre value in the ECC or S/4 user master data.

The cost centre value in the User Details tab has no effect whatsoever on authorisation. Authorisation to display/change cost centres is controlled by role assignments only.

Unfortunately, there is no mechanism to look up and copy the cost centre value directly from the S/4 user master to GRC; there is also no validation check available.

Q6: What is the relevance of User Group?

A: User group is a standard field in SAP and is used to group users in the user master record. The purpose of this field is to group users for the purpose of SAP security management. For example, some user-IDs belong to the user group ‘SUPER’ which indicates that they are SAP super users.

Some practical uses of the user group field are:

Some administrators can be given access to reset passwords for users in selected user groups only;
User reports can be run by user group, allowing reviewers to only get reports for users they are responsible for.

Q7: Can I change the email ID of the access request approver? If so, how do I do it?

A: There can be multiple approval stages configured for an access request – for example, a GRC Approver may provide approval from a risk point of view (i.e. whether there is any access risk violation) and a Role Approver may approve on the roles requested for the user.

All GRC users are setup in the GRC system’s user master. GRC Approvers are defined by assigning a user ID to the user group ‘GRC Approver’. Role Approvers are defined). The user’s email address is also configured within this table. Therefore, any changes to the approver’s email address requires a change to be made in the user master table.

Q8: What happens if the GRC officer completes the field ‘Company’ incorrectly while filling in the user details in the request form?

A: The field ‘Company’ is used to determine the approval workflow in GRC (depending on your workflow configuration). If it is incorrectly completed, the access request will not be routed to the correct approver. The access request would either (1) be approved inappropriately (by an approver who does not have the authority to approve the request); or (2) be rejected and has to be resubmitted.

Passwords

Q9: What are the applicable criteria for an initial password?

A: The ECC or S/4 HANA Production system has a set of password parameters defined. Any password which does not meet these parameters is considered invalid. The initial password specified in the GRC access request form should meet these parameters; otherwise the user will not be able to log into the ECC or S/4 HANA system. When this happens, the access request form should be resubmitted with a valid initial password.

Unfortunately, GRC allows you to enter any initial password into the access request form, without any mechanism to check whether this meets the parameters. Therefore, it is advisable and practical for a uniform, valid initial password to be given to all users, with the exception of critical user-IDs. Critical user ID-s should be given a unique, dedicated, secret initial password which is communicated to the user in a secure manner.

Q10: If I forgot to add the initial password in the access request for a new user, can I still add it to the access request after it has been approved?

A: Once a user access request is submitted, it is not possible to change anything in the request, including the initial password. However, the access request can still be approved and processed. User access will be provisioned with the password ‘deactivated’.

The solution depends on whether single sign-on is used or not:

If external single sign-on is used, the SAP password needs to remain deactivated (i.e. the user-ID should not be assigned a password), in order to allow authentication to take place through the external application.
If single sign-on is not used, the initial password will need to be manually entered in the SAP user master.

In order to ensure that initial password is always filled in on the access request, the field can be made mandatory. In some cases, this cannot be done – for example, when the GRC system is used by a group of companies, some of which use single sign-on to enter their respective SAP systems and some do not.

Q11: When a user requires access to multiple SAP Production systems, does an initial password need to be setup for all systems separately?

A: If all the systems are integrated (e.g. signing-on to ECC will give access to BW), the initial password is only needed for the ECC (or S/4 HANA) system. There is no separate authentication required for BW and hence no initial password for BW is needed when submitting an access request.

If the systems are not integrated (no central sign-on), then the initial password would usually be required for all respective systems.

Roles

Q12: What is a role naming convention and why is it important in access requests?

A: A role-naming convention should be designed for all SAP systems. A role-naming convention simply provides a standard set of rules which should be followed when naming a role. For example, it could require that all roles have the structure XXX_ZZ_AAAA, whereby XXX is the division which owns the role, ZZ is the functional area and AAAA describes the task given by the role.

Understanding the role naming convention is essential to ensure that correct roles are selected when requesting user access.

Q13: How does the access requestor know which role(s) to select for which organisation unit?

A: In a typical best-practice access provisioning process, access request is submitted outside the GRC system by a user (e.g. a department manager), for example via an email or a ticketing system. An access request is then entered into GRC (based on the email/ticket) by an Access Requestor – this is someone who has been designated this task and has been configured as an Access Requestor in GRC.

Again, in a typical best-practice setup, the email/ticket should specify in reasonable detail what kind of access is requested and for which authorised organisation unit. For example, access may be requested for ‘vendor invoice processing for plant ABC’ or ‘employee master data management for cost centre XYZ’.

The Access Requestor would then select the appropriate roles and organisation unit from the role catalogue in the GRC system. If a clear and organised role-naming convention has been followed and if the roles have been designed with appropriate restrictions, this should be a simple translation task between the department manager’s access request to specific SAP role(s). Please refer to Question 12 for more details on role-naming convention.

Q14: What do I need to do when the requested role for a specific unit cannot be found in the role selection screen of the user access request?

A: Roles can only be selected in an access request if the roles are built, deployed to the relevant Production system, and imported into the role catalogue of GRC Production. If the requested role for a specific unit does not show up, then the role is not available for selection. It means it has not been built and/or added to the GRC role catalogue.

A support ticket will need to be raised in order to create and deploy a new role. Once the role has been fully approved, it will be deployed to GRC Production and added to the role catalogue.

Q15: How can a role be removed from an existing user?

A: Any changes to the access of an existing user require an access request to be raised. The request type ‘change account’ should be selected and the user-ID specified.

To remove an existing role: Click the button ‘existing assignments’ on the main screen of the access request. A new screen will open, showing the existing role assignments of the user. Select the roles to remove and select the provisioning action for these roles to ‘remove’.

Approvals

Q16: Are approvals needed for automatically-assigned roles?

A: In some organisations, there are default roles which are assigned to all end-users, for example roles to run their own timesheet, manage selected fields in their employee master record, etc. In order to streamline the process, these roles are automatically assigned. Depending on the workflow configuration, their assignments can be subject to approval or otherwise can be auto-approved.

The assignment of these roles take place when an access request is submitted for a user; hence they do not have to be selected in the access request. Instead, upon submission of the request: When the requested role(s) are assigned to the user, automatically-assigned roles will be assigned too.

Q17: After an access request has been submitted for second-stage approval, can the first-stage approver remove a requested role?

A: Once an access request is submitted, requested roles can still be removed from the request by any approver; however, the approver can only do this during their respective approval stage, before the request is submitted for further approval (as applies).

Therefore, where there are two stages of approval: The first-stage approver can remove a requested role before submitting it for second-stage approval. Once it has been submitted, they cannot change the request anymore. At this point, only the second-stage approver can remove a requested role. However, if they are approving as a Role Owner, they can only remove roles which they own.

Q18: If roles from two different organizational entities are requested for a user, who will the access request be routed too?

A: As an example, let’s say that 3 roles belonging to Cost Centre A and 2 roles belonging to Cost Centre B are requested for a user who belongs to Cost Centre A.

Upon submission of an access request, two approval stages may be applicable (depending on the configuration):

For the first approval, the request will be routed to the GRC Officer(s) belonging to Cost Centre A, as it is where the user is from.
The second approval stage will be the approvals for all requested roles from their respective Role Owners. Therefore, roles belonging to Cost Centre A will be routed to one/more Role Owner(s) from Cost Centre A. Similarly, roles belonging to Cost Centre B will be routed to one/more Role Owner(s) from Cost Centre B.

If the Role Owner(s) from Cost Centre B finds the request for Cost Centre B roles inappropriate, they may reject the request or part of it as follows:

They can reject the request as a whole. In this case, a new request will need to be raised with all the appropriate roles.
Alternatively (and a more helpful course of action) would be to reject only the assignment of Cost Centre B’s roles and still submits the request. This means that only the approved roles will be provisioned and further delay can be avoided.

Please see the next question for more details.

Q19: How can I respond to an access request with incorrect roles requested?

A: There are two options to respond to an access request with incorrect roles requested:

The request can be rejected as a whole, which means a new request will need to be raised with the correct roles requested only; or
The incorrect roles can be removed from the request and the request then approved. This is done by selecting the incorrect roles and selecting ‘Reject’. This will change the status of these roles from ‘Provisioning’ to ‘Remove’. Next, click ‘Submit’ to approve the request.

The second option may be preferable if the request contains correct roles as well. With this option, at least the correct roles would still be provisioned to the user and no new request would need to be raised.

Q20: Can changes be made to the request after the first approval has been given?

A: Typically, the first approval (after submission of the request) would be given to verify compliance with access rules (e.g. by the GRC Officer) and the second approval would be given by Role Owners.

Once the GRC Officer has given their approval, only Role Owners can make changes to the access request (i.e. only subsequent approvers can change the access request). However, changes after submission are in any case limited to the removal of role assignments (and no addition of role assignments), as well as some fields in the User Details tab, e.g. user group and initial password. Additionally, the Role Owners can only remove roles which belong to them (i.e. roles for which they are assigned as role owner).

Once all the relevant Role Owners have approved the request, no more changes can be made and the approved roles will be provisioned to the user.

Q21: If a role is mapped to two Role Owners, will both get notified at the same time?

A: Each role is assigned to one/more Role Owner(s) and (optional) one/more alternate Role Approver(s).

After the first approval (i.e. by the GRC Officer), all Role Owners assigned to each requested role will receive a message in the Work Inbox (or, optionally, a notification with a link) to approve the request for that role only. Once this role has been approved, the link to approve the role will disappear from the Work Inbox of all its Role Owners. If none of the Role Owners approve the request within a specified number of days, then the alternate Role Approver(s) will get the link in their Work Inbox for approval.

Q22: What should be entered in the field ‘Notes’ while approving the access request?

A: The field ‘Notes’ can be made to be mandatory or optional. It should be completed in a free text format.

If there is a convention for filling in this field for your organisation, it should be followed. Typically, there may not be a requirement to complete this field for an access approval (an ‘OK’ may suffice, for example, unless there are certain concerns or exceptions made); however, in the case of a rejection, the reason for rejection should be documented here with sufficient details.

Q23: How can the user be notified that their requested access has been provisioned?

A: Notifications can be configured in the GRC system to notify GRC users or provisioned users on the completion of their access request process. If notifications are not setup, the GRC users need to manually monitor the statuses of their requests and inform the provisioned user as required.

User deprovisioning

Q24: What are the steps to follow to deprovision a user?

A: A request to deprovision users can be initiated in two ways:

If an identity management system is used, it will automatically trigger the creation of the request upon notification from HR (either through a system or manual integration) that a user is to leave the company. Automated deprovisioning usually means that the user-ID’s validity date will be set on the day that the request is to be processed (e.g. leaving date +1) and all role assignments will be removed.
If an identity management system is not used, the request to deprovision a user needs to be created manually, with the request type ‘delete account’. The following details need to be specified: The system(s) for which the user-ID needs to be deprovisioned, validity date (which can be a future date, e.g. the leaving date) and a selection of roles to be removed.

Note: Depending on the workflow configuration, the submission of a deprovisioning request, whether automated or manual, can be subject to approval. Alternatively, deprovisioning can also immediately be carried out.

Access request logging

Q25: Where can I search for access requests?

A: Usually,all GRC users have the authorisation to search for any access requests and view the status of individual requests. The option ‘request status’ in ‘My Home’ tab, specifically lists the requests submitted and/or approved by the GRC user.

The overall ‘search requests’ function is available on the ‘Access Management’ tab and allows filtering on various selection fields. This function search over all access requests ever submitted on the GRC system; therefore, it is advisable to actively use the selection fields in order to find the relevant requests. You may save frequently used selection criteria in selection variants.

For example: In order to find requests at a particular stage of approval, use the selection field ‘Stage Configuration ID’. Selection fields ‘Instance Approval Status’ and ‘Company’ can be used to find the pending requests.

Q26: How do I check the log of an access request?

A: Usually, all GRC users have the authorisation to search for any access requests and view the status of individual requests. The option ‘request status’ in ‘My Home’ tab, specifically lists the requests submitted and/or approved by you as GRC user.

When a request is selected and open, the tab ‘Audit Log’ can be clicked to view the audit log.

Alternatively, GRC users may use the overall ‘search requests’ function, available on the ‘Access Management’ tab. Where possible, selection criteria should be specified in order to bring up relevant access requests only on the results screen. In order to see the audit log for multiple requests, select the requests and click the button ‘audit log’. This allows viewing of the audit logs of selected requests without having to open them individually.

The audit log gives a chronological, detailed records from the creation of the request up to its current status.

Risk analysis in access requests

Q27: Does a risk analysis need to be performed even if no violations exist for the requested access?

A: Typically, access requests are entered into the GRC system by GRC users (see Question 12). These GRC users act as representatives to other access requestors (e.g. department managers) in their department/unit. A request for access is received by the GRC user in the form of an email/ticket and the GRC user is responsible for entering the request in the GRC system. The GRC user has the option to run a risk analysis before submitting the access request for approval.

There are often two approval stages in an access request process:

The first approval is to verify compliance with the rule set or to assign mitigating controls for request with violations;
The second is to approve the provisioning of roles by respective Role Owners.

The GRC system can be configured to enforce a mandatory risk analysis at each approval stage, whether or not it had shown any violations during pre-approval risk analysis. This is because the content of the requested roles may have changed after the pre-approval risk analysis. Similarly, the second approvers also need to run a risk analysis before giving their approval.

The system can be configured to enforce a mitigating control to be assigned, preventing requests showing a risk violation from being processed.

Q28: How can I run a risk analysis for a single user-ID? How do I run it for an entire department?

A: A risk analysis performed within an access request is by definition applicable only to the single user-ID for which the request is processed.

If you want to perform a risk analysis independent of a specific access request, you can run an ad-hoc user risk analysis. If you select an individual user-ID in the selection screen, the risk analysis will be processed for that particular user-ID only. If you select a specific user group in the selection screen, the risk analysis will be processed for all user-IDs of that user group. There is no standard selection field for a specific department/other unit, but it is possible to configure a custom user group for that purpose.

Q29: Can I still submit a request with violations?

A: A risk analysis can be performed on an access request before it is submitted for approval. It is possible for this analysis to identify a risk violation.

Depending on the GRC configuration, an access request with a violation can still be submitted for approval. However, a mitigation control may need to be assigned to the violation during the approval stage. This would typically be done during approval by the first approver, who approves from a compliance point of view.

The assignment of mitigating control can be set as mandatory; without this, the access cannot be approved.

Mitigating controls

Q30: How do I mitigate the violations and submit the request?

A: Mitigating control assignment can be performed before or after access request submission. Before submission, the mitigating control is assigned during the creation of the access request. After submission, the mitigating control can be assigned by any approver. Depending on the GRC configuration, a mitigating control assignment may be required before the access request is approved. This can be configured by making the assignment mandatory.

Mitigating controls are assigned to the specific risks which are violated. In order to assign mitigating controls, go to the access request screen (tab ‘Risk Violations’ and ‘Management Summary’ report view). If the access request shows multiple risks, then mitigating control should be assigned to all of these risks one by one, in the following steps: First, select the relevant risk and click on ‘Mitigate risk’ to see if any mitigating controls are available for that risk. If yes, the control(s) can be selected and saved for the risk. It means that the user in the request is mitigated for this risk.

If no mitigating control is available for the risk, a new mitigating control will need to be created. You will need to follow the specific procedure to do so in your organisation. In the meantime, the access request may need to be rejected or changed (i.e. the role(s) which cause the risk violation will need to be removed).

Q31: Can mitigating controls belonging to a different organisational unit be used?

A: All mitigating controls in the same GRC system are stored in one table. The table could contain mitigating controls belonging to various organisational units, e.g. company.

When selecting mitigating control to assign against a risk in an access request, you will see all mitigating controls available for this risk. For example, for the same risk, Company A and Company B may exercise different mitigating controls (perhaps due to different business processes). Therefore, it is important to only assign mitigating controls which belongs to the correct company.

Having a clear naming convention helps to identify which company a mitigating control belongs to. GRC does not have a mechanism to identify the company to which a mitigating control belongs and therefore cannot enforce that only a mitigating control belonging to the correct company is chosen.

If a mitigating control from an incorrect company is chosen:

The access request can still be approved and requested access will be provisioned to the user.
The ‘Mitigated Users Report’ for the incorrect company will include the user.

Q32: If an access request with a violation is submitted with a mitigating control assigned, can it still be rejected?

A: Yes, a request can be rejected for any reason – a rejection does not necessarily need to be motivated by a risk violation or a lack of mitigating control. For example, the approver may disagree with the roles requested or the request may be incorrect or incomplete.

Q33: If no mitigation control is found to mitigate a violated risk, what should be done?

A: If no mitigating control is available for a violated risk, it needs to be created. The procedure depends on your particular organisation, but it is likely that a change request will need to be raised and the change management process followed.

In the meantime, these are the options available with respect to the access request:

It can be rejected as a whole or partially, where only the role causing the violation is rejected.
It can be put on hold until the mitigating control has been put in place. However, this option will take a longer time.

Q34: If a mitigating control has been incorrectly assigned in an access request, can it be changed before approving the request?

A: Unfortunately, once an incorrect mitigating control has been saved in the ‘Mitigate Risk’ screen, even if the request is not yet submitted or approved, it can be troublesome to correct. An incorrectly-assigned mitigating control can (and should) be deleted, but it will show only in the next approval stage.

Once the request has been completely approved, rectification of incorrectly-assigned mitigating controls will require the involvement of the GRC administrator. A ticket will need to be raised.

We hope this blog post has helped you understand the SAP GRC access provisioning process better. Subscribe to our newsletter here to not miss on any new blog post.

Get in touch