Viewing Excel Reports

In addition to online reports, Access Risk Management also provides several Excel reports that you can download to see the specific details of that report more fully and use it for auditing purposes.

Select EXCEL REPORTS in the left menu to see the available reports.

Note

Reports on emergency access requests are generated from the EAM Dashboard.

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 - This 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 - This will include all available extracts from the last twelve months. Select the field to see a dropdown menu of the available utilization extracts.
Report Type - This 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 - This will default 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 - This will include 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 - This will default 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.

User Reports

User reports show greater detail of risks in the system, users with access to them, and the actions they are taking within risks. You can also refer to the Dormant Users report to view users who have not logged in to SAP within the number of days you select.

User Conflicts Matrix Report

The User Conflicts Matrix report takes the information from the BP Conflicts Summary report and then goes to the next level of detail. Through this report, you can see all the risks in the system, the users who have access, and if they are executing the transaction codes within the risk. This graphical view can help to determine where to focus your time regarding risks and users.

Scheduling the User Conflicts Matrix Report

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

Report Name - This will default to the report type and date/time but can be customized.
Signature - If you choose to include a signature on the report, generally if you are providing to external auditors for completeness and accuracy, there will not be the standard pivot tables.
User Types and Statuses - This allows you to select what users will be included on the reports. The default settings are to include dialog users and locked users due to failed logins (too many incorrect password attempts). You can also choose to include any other combination of user types and lock statuses.
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 - This will include all available extracts from the last 12 months; however, you can include more or less depending on what is available in the system.
Report Type - This allows you to select if you want to use a previously completed analysis file, the raw data file that compares user access to the rulebook or 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 User Conflict Matrix

The Conflict Matrix tab shows the risk at the user level in a pivot table that can be used to identify where the risks are and where you might want to focus your remediation efforts. You can see the business functions that make up the risk, the users who have the access, and if they have executed the transaction codes.

The different colored squares are:

Green (-1) - The user has access to this transaction code, and all required authorizations for the rule, but has not executed the transaction code.
Red (1) - The user has access to this transaction code, and all required authorizations for the rule, and has executed the transaction code.
White/Blank - The user either does not have access to the transaction code or has access to the transaction code but not the required authorization objects.

Double-clicking a square in the table will redirect you to the Data tab with filters applied for the user and transaction code that you chose.

Use Case

This report is used for general reporting purposes and to help identify areas to focus your remediation efforts. Since you do not take transaction codes away from users directly, this is another tool to help focus on specific users, risks, or roles for remediation. With this information, the organization may want to see what roles are giving access and determine if the transaction code can be removed from any of those roles.

Data Tab

The Data tab contains all the information that was used to generate the pivot table from the Conflict Matrix tab. This includes users, risks, transaction codes, the role that gave the transaction code, and utilization data. This can be used to filter through the different risks and see which users have that access and what transaction codes they are using.

Reference Tabs

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

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.
Risk Descriptions - Shows the risks, risk rating, and description that are defined in the rulebook.
Mitigating Controls - Shows the different mitigating controls in the system along with the objective and description defined for those mitigating controls. This is used as reference when you want to know more information about the mitigating control in place for a risk/user since most reports just show the mitigating control code.

Dormant Users Report

The Dormant Users Report shows users who have not logged in to SAP within the number of days you select.

Scheduling a Dormant Users Report

Since the Dormant Users Report does not include an analysis portion or utilization data there are fewer fields needed:

Report Name - This defaults to the report type and date/time and can be customized.
Security Extract - Select the time you want to use for the test. For this report, you cannot use live data.
Days Until Dormant - Define how many days a user has to have not logged into SAP for them to be considered dormant.

Viewing the Dormant Users Report

The Dormant Users report has two tabs:

Users Tab

This shows the usernames and the date they last logged on.

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.

BP Conflicts Matrix Report

The Business Process Conflicts Summary report is a business-friendly report that provides summaries of risk in the system along with high-level usage information that can be used to drive decisions. Those decisions will then be used by the more technical users and teams to start making changes.

Scheduling the BP Conflicts Matrix Report

When scheduling the BP Conflicts Summary report, the fields that need to be populated are:

Report Name - This will default to the report type and date/time but can be customized.
Signature - If you choose to include a signature on the report, generally if you are providing to external auditors for completeness and accuracy, there will not be the standard pivot tables.
Live Utilizations - If selected, the system will run a new utilization extract for any months missing within the period selected to include. Keep in mind 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 - This will include all available extracts from the last 12 months; however, you can include more or less depending on what is available in the system.
Report Type - This allows you to select if you want to use a previously completed analysis file or the raw data file that compares user access to the rulebook, or if you want 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.

Viewing the BP Conflicts Matrix Report

The different tabs of this Excel report are the following:

Risk Overview Tab

The Risk Overview tab is like the User Risks by Rating report on the dashboard and shows all the risks in the environment broken down by the risk rating defined in the rulebook and then separated by the utilization of the users with access to those risks. The different colored buckets of the graph are:

Not Executed - A risk where the user has access to all business functions defined for that risk (one for a sensitive access risk and two, or more, for an SoD risk) but has not executed transactions from any of those functions.
Partially Executed - A risk where the user has access to all business functions associated with an SoD risk and has executed transaction codes associated with some, but not all, of the business functions.
Fully Executed - A risk where the user has access to all business functions associated with an SoD risk and has executed transaction codes from all of the business functions.
Sensitive Access Utilized - A sensitive access risk. This requires access to only one function where the user has executed transaction codes associated with that function.

Use Case

This summary level report is often used by managers or business owners to get insight into users who pose the most risk to the business. They can view the different levels of risk and see which users have that access on additional tabs of this report. This can help to determine if the expected users have access to the risks that might be expected of them, and then they can use that information to determine if they should remediate the risk or apply mitigating controls.

Risk Summary Tab

The Risk Summary tab breaks down all the risks within the environment and then separates them by the risk rating. It also includes summary details around how many users have access to that risk and then separates those users into the different columns based on their utilization.

Use Case

This report is used to focus on the risks that you are most interested in. If you are addressing the easiest to remediate risks, you might look at those that don't have users in the Fully Executed section so you can focus on finding ways to take away the unused access. If you want to focus on those risks that may be acted upon, you can look for risks with the most users in the Fully Executed section to then use other reports to remediate by cleaning up roles or changing processes internally.

User Conflict Summary Tab

The User Conflict Summary tab is a breakdown of the risk in the system. This will give proportions of risk being executed to overall risk and some additional identifiers. This report can be used to provide key risk indicators (KRIs) to management.

Conflicts Tab

The Conflicts tab gives you the most detailed view of the users who have access to the risks, along with some additional data points to help drive decision making. The other information you can see on this tab of the report includes Risk Rating, Rule Name, User Group, Utilization Bucket, Recommendation on how to approach the risk, any mitigating controls in place, and summary-level utilization count for each of the business functions.

Use Case

The conflicts tab is the main portion of this report that business owners will use to make their decision on how to approach remediation. The Recommendation column helps the business process owner approve removal of access, in the case of a Not Executed or Partially Executed risk. Or it can be used to identify a scenario where remediation is impossible since the user must perform both sides of the risk and they can then discuss mitigating controls that are in place. The approval to remove access would be provided to the security team to identify how that it can be removed, either by removing unused roles or by cleaning up roles.

Reference Tabs

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

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.
Risk Descriptions - Shows the risks, risk rating, and description that is defined in the rulebook.
Mitigating Controls - Shows the mitigating controls in the system along with the objective and description defined for those mitigating controls. This is used as a reference when you want to know more information about the mitigating control in place for a risk/user since most reports just show the mitigating control code.
User Info - Shows additional information about the users that is 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.