Skip to content

Role Reports

There are several reports that provide insight into how roles are working in your organization. They can show risk, matching users with roles to identify areas to enforce the least privilege, and identifying active, unassigned roles in the SAP system.

Role Conflicts Matrix Report

The Role Conflicts Matrix report is one of the main reports used to remediate roles or test roles during the design phase. It shows inherent risk within the roles and then overlays utilization data of the users who have that role assigned to give factual and actionable information.

Scheduling the Role Conflicts Matrix Report

When scheduling the Role Conflicts Matrix report, the fields that need to be populated are:

  • Report Name - Defaults to the report type and date/time. It can be customized.

  • Include Types and Statuses - Select what roles will be included on the reports. The default setting is to not include unassigned roles. Select the checkbox to include unassigned roles.

  • Live Utilizations - If selected, the system will run a new utilization extract for any months missing within the period selected to include. Note that SAP stores this data for three months by default, so you will most likely get blank extracts for months beyond those three.

  • Selected Utilizations - Includes all available extracts from the last twelve months. Select the field to see a dropdown menu of the available utilization extracts.

  • Report Type - Allows you to select if you want to use a previously completed analysis file, the raw data file that compares role access to the rulebook, or to run a new one. The options are:

    • Historical Data - You will be provided a list of previously completed analysis files to choose from.

    • New Data - You will run the analysis as part of the reporting job. The additional fields in here are:

      • Email When Done - Email will be sent to this user once the job completes. This will default to the person who is running the job.

      • Security Extract - Select whether to use a new security extract or run the analysis from an existing extract.

      • Rulebooks - Select what rulebook(s) to include in the analysis.

      • Risk Ratings - Select what risks to include in the analysis based on the risk rating.

      • Business Processes - Select what risks to include in the analysis based on the business process.

      • Repeat - You can set up this report to run as a one-time report or recurring monthly basis.

Viewing the Role Conflicts Matrix Report

The Conflict Matrix report shows a breakdown of all roles in the system that have inherent risks. The report shows single, composite, and derived roles and includes whether the transaction codes associated with the risk have been executed by users who have that role assigned to them.

Use Case

This is one of the main reports used when performing remediation actions in the system. It can be used to identify transaction codes that can be removed from roles based on utilization, roles that may need to be split up, and test roles in non-production systems before the roles are transported to production to ensure they are risk-free and compliant.

Two common use cases for remediating inherent risk in production roles are:

  • If there is no utilization within the role, or only on one side of the risk, you can remove the unused transaction codes.

  • If there is utilization data on both sides of the risk, you will need to look at who is using those transaction codes either online or using the Security Role Report.

    • An example of this is if a role has transaction codes being used from each side of the risk. In this case, you need to identify which users are executing these transaction codes using the Security Role Report. Based on those results, there are a couple of available actions:

      • If Different Users Are Executing the Transaction Code - If, for example, user(s) executing FB50, FBV2, or FBV0 are different than the users executing FB02, you can split the role into two separate roles, let everyone keep the access they are using, but put the transactions that are causing risk in the role assigned to the user who needs it.

      • If the Same Users Are Executing the Transaction Codes from Both Sides of the Risk - In this situation, you can split the role up and change job responsibilities for those users so they no longer need to execute from both sides. If that is not an option, and the same user needs to exercise both sides, you can apply a mitigating control to the risk based on any manual processes in place.

Another common use case is when creating a new role in a non-production system. In this scenario, you can run this report for that role(s), understanding that there will not be any utilization data since it is not in production. However, the goal is the role will not be on the report at all if there are no inherent risks built in from the start.

Data Tab

The Data tab contains all the information that was used to generate the pivot table from the Conflict Matrix tab. This includes roles, risks, transaction codes, and utilization data. This can also be used as an easy way to filter through the different risks and see which roles have that access and what specific transaction codes were used.

Reference Tabs

The additional tabs on the report are for reference purposes. These include:

  • Risk Descriptions - Shows the risks, risk rating, and description that are defined in the rulebook.

  • Properties - Shows the information that was used to create the report. This includes the account information, user who scheduled the snapshot, the rulebook used, along with the dates and times of the security and utilization extracts.

Security Role Report

The Security Role Report is a little different from the other reports because it does not take risk into consideration. It simply looks at a role, or roles, and shows the users with access and what they have used. This is often used in general role cleanup or to see specific usage within roles. The goal of this report is to provide insight on how to achieve the principle of least privileged access.

Scheduling the Security Role Report

The main difference in the Security Role Report is the lack of an analysis step. This report just shows the roles, the access granted, and the users who have that role assigned regardless of risk. When scheduling the Security Role Report, the fields that need to be populated are:

  • Report Name - Defaults to the report type and date/time but can be customized.

  • Security Extract - You can run a new security extract, use the live extract, or use a previously completed security extract.

  • Live Utilizations - If selected, the system will run a new utilization extract for any months missing within the period selected to include. Note that SAP stores this data for three months by default, so you will most likely get blank extracts for months beyond those three.

  • Selected Utilizations - Includes all available extracts from the last 12 months; however, you can include more or fewer depending on what is available in the system.

  • Roles Selections - Select which roles will be included in the report.

Viewing the Security Report

The Role Matrix view shows all the access in the role, the users who have that role assigned, and whether the transaction codes are being used. This will help determine if you can remove roles from users, remove transaction codes from the role, or split the role up based on how the role is being used.

Use Case

This report is used for general maintenance of the roles by determining:

  • If a role can be removed from a user by seeing no utilization (green boxes) for a specific user or in a vertical line on the matrix.

  • If a transaction code can be removed from the role by seeing no utilization for a particular transaction code or in a horizontal line on the matrix.

  • If the role should be split into multiples roles. This can be determined by seeing the different ways users are executing the transaction codes and identifying if there is grouping of usage that more closely aligns to job functions if the role is too widely assigned. You can also choose to split a role based on risk information which is described in the Use Case bucket for the Role Conflicts Matrix report.

Note

For composite roles, you will want to run this report for all single roles that make up that composite role and then review with all roles that make up the composite included. For derived roles, you will want to run this report for all child roles and include them all on the report since decisions will be made at the parent level.

Data

The Data tab contains all the information that was used to generate the pivot table from the Role Matrix View tab. This includes users, roles, transaction codes, and execution data. This can be used to filter through the different roles and see which users have that access and what specific transaction codes were used.

Reference Tabs

The additional tabs on the report are for reference purposes. These include:

  • User Info - Shows additional information about the users pulled in from the USER_ADDR table in SAP. This includes cost center, department, company, and any other information defined in SAP and pulled in with that table.

  • Properties - Shows the information that was used to create the report. This includes the account information, user who scheduled the snapshot, the rulebook used, along with the dates and times of the security and utilization extracts.

Orphaned Role Report

The Orphaned Roles report identifies active roles in the SAP system that are not assigned to anyone.

Scheduling an Orphaned Role Report

The Orphaned Roles report looks for all roles that are not assigned to a user in SAP. The only fields you need to define are:

  • Report Name - Defaults to the report type and date/time but can be customized.

  • Security Extract - Select the time you want to use for the test. For this report, you cannot use live data.

Viewing an Orphaned Role Report

The different tabs of this Excel report are the following:

Roles Tab

The purpose of the Orphaned Roles report is to identify SAP roles that are active but not assigned to any users. This can help determine if you want to remove those roles since there is a chance they can be assigned to users.

Use Case

This report is used periodically by organizations to make sure the roles that are active in the SAP system are roles that are needed. If a role is on this report, and there is no reason for a user to ever have it assigned, the best practice would be to remove it to avoid it being assigned to anyone. Commonly, the SAP standard roles are still present; many of these delivered roles were not designed with SoD considerations.

Properties Tab

This shows the information that was used to create the report. This includes the account information, user who scheduled the report, and the date and time of the security extract.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.