# SailPoint Access Risk Management > SailPoint Access Risk Management Documentation # SailPoint Access Risk Management # SailPoint Access Risk Management Use SailPoint Access Risk Management to automate the monitoring and managing of access risks across the enterprise, thereby minimizing potential breaches and fraud, accelerating remediation, and identifying insider-led security breaches. This functionality benefits: - IT teams who need to assess potential separation of duty (SoD) risks before granting access to users - Security teams who complete access reviews and need to manage emergency access workflows with auditable controls - Audit teams who want to lower audit costs by using automated, audit-ready reports - Compliance teams who want to speed up compliance processes Access Risk Management generates over 25 reports to give you both high-level and granular details so you can make data-informed decisions to protect your organization. Prevent risks from developing by simulating role and user changes, managing access reviews, and governing emergency access requests. # Getting Started with Access Risk Management Welcome to Access Risk Management! The first step is [integrating your ERP system](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/index.html), then you can use Access Risk Management for the following: - [Managing Users](https://documentation.sailpoint.com/access-risk-mgmt/help/users/index.html) - [Managing Rulebooks](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/index.html) - [Managing Access Reviews](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/index.html) - [Managing Emergency Access](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/index.html) - [Using What If Analysis](https://documentation.sailpoint.com/access-risk-mgmt/help/whatif/index.html) - [Viewing Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) - [Reporting](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/index.html) ## Supported Systems Access Risk Management supports the following systems: - SAP ECC - SAP S/4HANA - RISE with SAP S/4HANA Cloud, private edition Note Configure Access Risk Management with [SailPoint ABAP Function Module](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/install_custom_module.html) to integrate with SAP applications hosted on private cloud (RISE). The SailPoint ABAP Function Module is an [SAP certified integration solution](https://www.sap.com/dmc/exp/sap-certified-solutions/#/partners?id=p:p9875) for RISE with SAP. ## Supported Languages Access Risk Management supports the following languages, with English being the default: | Language | Locale | | -------- | ------ | | English | en | | Spanish | es | | French | fr | | Japanese | ja | | Mandarin | zh | | German | de | | Korean | ko | | Dutch | nl | Note Access Risk Management does not recognize territory language distinctions in locales. ## Setting a Preferred Language To set your preferred language in Access Risk Management: 1. Select the dropdown arrow next to your username in the top right corner of the screen. 1. Select **My Profile**. 1. On the My Profile screen, select the **Preferred Language** dropdown. 1. Select your preferred language. 1. Select **Submit** at the bottom of the page. # Connecting Access Risk Management to Identity Security Cloud You can connect Access Risk Management to Identity Security Cloud to manage Access Risk Management application entitlement assignments, to automate access to Emergency Access Management (EAM) profiles from Identity Security Cloud, and to allow EAM requests to be made through Identity Security Cloud. ## Prerequisites The following are required before you can connect Access Risk Management to Identity Security Cloud. **Tenant and runtime prerequisites:** - An Identity Security Cloud tenant where the Access Risk Management SaaS connector is already installed, or permission to upload the connector package. - Identity Security Cloud admin or source admin access to create and configure a source. - This is a SailPoint SaaS connector using the Identity Security Cloud connector runtime, so no customer-managed VA or node is required for normal use. - If building or deploying the package yourself for your tenant, you'll need Node.js `20.x`, npm, SailPoint CLI, repo access, and the Identity Security Cloud connector ID with upload permission. **Access Risk Management prerequisites:** - Access Risk Management tenant. - An active user with the following roles: - Emergency Access Profile Administrator - User Account Administrator - Access Risk Management service account credentials, including username, password, and customerId. - The service account must be able to authenticate and have view and management permissions for: - Access Risk Management users and accounts - Roles - Reporting groups - EAM profiles - EAM owners, approvers, reviewers, and requesters - ERP system mappings - The account also needs write permissions to create, update, delete, enable, and disable users, as well as edit entitlement assignments. ## Setting Up the Identity Security Cloud Source 1. In Identity Security Cloud, go to **Admin > Connections > Sources**. 1. Select **Create New**. 1. Search for and select the Access Risk Management connector named **arm-connector**. 1. Select **Configure**. 1. Enter the basic source details: - Source name - Description - Owner, if required by the tenant - Select **Authoritative Source** 1. Open **Source Configuration**. 1. In the Connection Configuration section, enter: - Login URL - For US based customers not using SSO: - For EU tenants not using SSO: - For US and EU tenants with a vanity URL who are using SSO: https://{vanityURL}.arm.sailpoint.com - Setup User URL - For US based customers not using SSO: - For EU tenants not using SSO: - For US and EU tenants with a vanity URL who are using SSO: https://{vanityURL}.arm.sailpoint.com/set-password - Authentication URL - For US tenants: authsvc.erpmaestro.com - For EU tenants: authsvc-eu.erpmaestro.com - Report Management URL - For US tenants: report-management.erpmaestro.com - For EU tenants: report-management-eu.erpmaestro.com - Emergency Access Management URL - For US tenants: eamsvc.erpmaestro.com - For EU tenants: eamsvc-eu.erpmaestro.com - Dashboard Service URL - For US tenants: dashsvc.erpmaestro.com - For EU tenants: dashsvc-eu.erpmaestro.com - Username - Password - Customer ID Note If you are unsure which URL to use, you can ask customer support or check the Network tab on your browser and look at any call to erpmaestro.com. 1. Select **Save**. 1. Go to **Review and Test**, then select **Test Connection** to confirm that Identity Security Cloud can authenticate to Access Risk Management. - If the connection test fails, contact [SailPoint support](https://support.sailpoint.com/csm?id=kb_category&kb_category=33a9f29d4713ba90c1a7e1be536d43e4&kb_id=05ff44289f011200550bf7b6077fcfa3). 1. Once the connection test succeeds, go to **Account Management > Account Aggregation** on the left navigation to import Access Risk Management accounts. Refer to [Manually Aggregating Accounts from a Direct Connect Source](https://documentation.sailpoint.com/saas/help/accounts/loading_data.html?#manually-aggregating-accounts-from-a-direct-connect-source). 1. Select **Entitlement Management > Entitlement Aggregation** to run an entitlement aggregation. Refer to [Aggregating Entitlements for a Direct Connect Source](https://documentation.sailpoint.com/saas/help/loading_entitlements/aggregating_entitlements.html#aggregating-entitlements-for-a-direct-connect-source). - Select **All Types** or **Specific Types** and select the checkbox for the Access Risk Management entitlement types, which may include: - Role - Reporting Group - EAM Requestor - EAM Reviewer - EAM Owner - EAM Approver - Select **Actions**, then **Mark as Requestable**. 1. Review the imported accounts and entitlements. 1. Optional: You can create Identity Security Cloud access profiles from the imported entitlements to bundle entitlements from this new source. Refer to [Creating Access Profiles from Sources](https://documentation.sailpoint.com/saas/help/access/access-profiles.html#creating-access-profiles-from-sourcess). 1. Optional: You can bundle access profiles into Identity Security Cloud roles. Refer to [Creating Roles](https://documentation.sailpoint.com/saas/help/access/roles.html#creating-roles). 1. Go to **Entitlement Management > Entitlements** and review access items. Optionally, you can choose to enable the access items so users can request Access Risk Management access through the Identity Security Cloud Request Center. Refer to [Making Access Risk Management Access Profiles Requestable](#making-access-risk-management-access-profiles-requestable). ## Configuring a Connected Source Once the source is connected, you can configure and review the source name, owner, and basic metadata of an Access Risk Management source. 1. Go to **Admin > Connections > Sources**. 1. Open the Access Risk Management source, **arm-connector**. 1. Go to **Source Setup > Base Configuration**. 1. Confirm the source metadata. 1. From the left navigation, select **Source Setup > Configuration Settings**. 1. Enter or confirm: - Login URL - Setup User URL - Disable an account if it has no access assigned - Authentication URL - Report Management URL - Emergency Access Managements URL - Dashboard Service URL - Username - Password - Customer ID - Customer IDs for delete 1. Select **Save**. Important This page only saves source configuration. It does not create, update, disable, enable, or delete Access Risk Management accounts. ### Validating the Connector Configuration Review and test your source configuration. 1. Go to the **arm-connector** source page. 1. On the left navigation, go to **Review and Test**, then select **Test Connection** to confirm that Identity Security Cloud can authenticate to Access Risk Management. - If the connection test fails, contact [SailPoint support](https://support.sailpoint.com/csm?id=kb_category&kb_category=33a9f29d4713ba90c1a7e1be536d43e4&kb_id=05ff44289f011200550bf7b6077fcfa3). ## Managing Accounts In addition to the pages detailed in the subsections below, these pages support account management for Access Risk Management aggregated accounts: - **Uncorrelated Accounts** - Review Access Risk Management accounts that did not correlate to ISC identities. - **Approval Settings** - Configure approval behavior where applicable. - **Attribute Sync** - Configure attribute synchronization behavior where applicable. - **Native Change Detection** - Configure or review native change detection behavior where applicable. ### Reviewing Account Schema You can review the Access Risk Management account schema imported into Identity Security Cloud. 1. From the left navigation on the **arm-connector** source page, go to **Account Management > Account Schema**. 1. Confirm account attributes such as email, username, roles, reportingGroups, and EAM assignment attributes. ### Correlating Accounts Review how Access Risk Management accounts correlate to Identity Security Cloud identities. 1. From the left navigation on the **arm-connector** source page, go to **Account Management > Account Correlation**. 1. Confirm correlation rules. This connector is configured to correlate by email and display name or full name. ### Aggregating Accounts Use the Account Aggregation page to import Access Risk Management accounts into Identity Security Cloud. 1. From the left navigation on the **arm-connector** source page, to to **Account Management > Account Aggregation**. 1. Select **Start Aggregation**. 1. After the aggregation completes, review aggregation results and account counts. The connector examines Access Risk Management users and returns accounts to Identity Security Cloud. ### Reviewing Imported Accounts Use the Accounts page to review imported Access Risk Management accounts. 1. From the left navigation on the **arm-connector** source page, to to **Account Management > Accounts**. 1. Search for an Access Risk Management account. 1. Select the account name to open the account details page. 1. Review account attributes and assigned entitlements. Best-practice This page should be used primarily to review accounts, not as the normal path for manual access updates. ### Creating Account Policy Use the Create Account page to configure how Identity Security Cloud creates Access Risk Management accounts during provisioning. 1. From the left navigation on the **arm-connector** source page, go to **Account Management > Create Account**. 1. Confirm that the required create fields are mapped: - `email` - `firstName` - `lastName` - `username` - `fullName` - `erpUserId` - `preferredLanguage` 1. Select **Save**. Identity Security Cloud creates an Access Risk Management account when provisioning requires a new one, for example: - A Request Center request for Access Risk Management access where the identity has no Access Risk Management account. - Lifecycle provisioning that grants Access Risk Management access. - API-driven provisioning. Best-practice This page configures account creation. It is not normally the UI path where an admin manually submits a new Access Risk Management account. ### Updating Access Risk Management Access Use the Identity Security Cloud [Request Center](https://documentation.sailpoint.com/saas/user-help/requests/request_center.html#requesting-access-in-the-request-center) for manual, UI-driven Access Risk Management access changes. To configure and complete access requests through the Request Center: 1. Confirm Access Risk Management entitlements have been aggregated. 1. Build Access Risk Management-backed access profiles or roles from the imported entitlements. 1. Publish the access to the Request Center. 1. From the Identity Security Cloud top navigation, select **Request Center**. 1. Select **New Requests**. 1. Choose whether to request for yourself, your team, or others. 1. From the left navigation, select **Roles** or **Access Profiles**. 1. Search for an Access Risk Management role or access profile. 1. Select a target identity. 1. Submit the access request or removal request. 1. Complete any required approvals. 1. Review the provisioning activity. Supported Access Risk Management update areas include: - Roles - Reporting groups - EAM Requesters - EAM Reviewers - EAM Owners - EAM Approvers - Selected writable account attributes such as `erpUserId`. ### Enabling and Disabling Accounts You can enable or disable accounts from the following locations depending on your tenant's configuration: - Direct disable action from an account detail page, if exposed - Lifecycle state change that disables source accounts - API-driven provisioning Caution Not every tenant exposes a direct disable button in the source account UI. ### Deleting Accounts You can delete accounts from the following locations depending on your tenant's configuration: - Direct delete/deprovision action from an account detail page if exposed - Lifecycle termination provisioning - API-driven provisioning Important Use non-production test identities when validating delete behavior. ## Managing Entitlements You can manage the entitlements associated with a source. From the left navigation on the **arm-connector** source page, go to **Entitlement Management > Entitlement Types**. Confirm that the following types of entitlements are available: - role - reportingGroup - EAMRequester - EAMReviewer - EAMOwner - EAMApprover ### Aggregating Entitlements Import Access Risk Management entitlements into Identity Security Cloud. 1. From the left navigation on the **arm-connector** source page, go to **Entitlement Management > Entitlement Aggregation**. 1. Select **Start aggregation**. 1. After the aggregation completes, review totals and sample entitlements. ### Reviewing Imported Entitlements Review the entitlements that you imported from Access Risk Management. 1. From the left navigation on the **arm-connector** source page, go to **Entitlement Management > Entitlements**. 1. Scroll or filter by entitlement type to locate specific entitlements. 1. Confirm the entitlement names and IDs. Note This page does not write to Access Risk Management. Use these entitlements to build access profiles or roles to be requested via the Identity Security Cloud Request Center. ## Making Access Risk Management Access Profiles Requestable Create access profiles that are requestable in the Identity Security Cloud Request Center. 1. Confirm account aggregation has completed. Refer to [Aggregating Accounts](#aggregating-accounts) 1. Confirm entitlement aggregation has completed. Refer to [Aggregating Entitlements](#aggregating-entitlements). 1. From the left navigation on the **arm-connector** source page, go to **Aggregation History and Connections > Access Profiles**. 1. Create or edit an access profile. For details, refer to [Creating Access Profiles from Sources](https://documentation.sailpoint.com/saas/help/access/access-profiles.html#creating-access-profiles-from-sources). 1. Select **Enable Access Profile** in the top right. 1. Select **Save**. 1. Submit access requests from the Request Center. Refer to [Access Requests](https://documentation.sailpoint.com/saas/user-help/requests/index.html). Once a request has been submitted and approved (if configured to require approval) the following takes place: - If the identity already has an Access Risk Management account, Identity Security Cloud provisions or deprovisions the requested access. - If the identity does not have an Access Risk Management account and account creation is required, Identity Security Cloud first creates an account, then provisions or deprovisions the requested access. ## Viewing Aggregation History and Connections You can view aggregation history and connections for the Access Risk Management source. To view aggregation history, go to the **arm-connector** source page and select **Aggregation History and Connections > Access Profiles**. There, you can review recent account and entitlement aggregations and confirm the status, timestamps, and totals on those aggregations. To view source connection references and any dependencies that may be applicable, go to the **arm-connector** source page and select **Aggregation History and Connections > Connections**. # Integrating with Your ERP Systems Overview You can govern access and reduce risk to your ERP systems by integrating with Access Risk Management. Integrating allows you to view and track the [activity](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) in your ERP system. You can automate and secure the governing of access using Access Risk Management's [rulebooks](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/index.html), [access reviews](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/index.html), [emergency access](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/index.html), and [What If analysis](https://documentation.sailpoint.com/access-risk-mgmt/help/whatif/index.html). Access Risk Management supports the SAP ERP. Refer to [Integrating with Your SAP System](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/index.html). # Blocking SAP Users, Roles, and Profiles You can exclude SAP users, roles and profiles from reports, filters, access reviews, and analyses, such as a Risk Analysis and What If Analysis. Block lists help you produce more focused analyses by excluding test accounts or other access items with technical permissions that are not relevant to your compliance reviews. Create up to 1000 block list rules per system. Important Items added to the block list will be excluded by default from all future analyses, simulations, and reports, but not from manually scheduled Security Extracts. Refer to [Risk Analysis NEW](https://documentation.sailpoint.com/access-risk-mgmt/help/schedulejobs/index.html#risk-analysis-new) for information on running an ad-hoc Risk Analysis that temporarily ignores block lists. If you are using Emergency Access Management (EAM), you need to exclude roles assigned as entitlements on any EAM profile for temporary elevated access since there are already controls in place for [managing emergency access requests](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/index.html). Warning If you block a role in Emergency Access Management, do not assign it to users as part of standard access as these roles will not appear in analyses and elevated permissions will be excluded from reports. If you want to use a blocked role in Emergency Access Management, you can run a Security Extract that bypasses the block list and includes all roles. Refer to [Selecting Profile Entitlements](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/select_profile_entitlements.html) and [Scheduling Security Extracts](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_security_extract.html). ## Creating a Block List Admins can create block list rules to exclude SAP users, roles and profiles from Access Risk Management reports, filters, access reviews, and analyses. 1. Go to **Menu** > **Block Lists**. 1. On the Block Lists page, select **Create New Block List Entry +**. 1. Use the dropdown to select a Type. Options include individual users, user name, user group, individual roles, role name, or profile name. 1. If you selected the Individual Roles or Individual Users type, use the dropdown to select the SAP system(s) that this rule applies to. 1. If you selected a type other than Individual Roles or Users, enter the value you want to block. Several options allow you to dynamically exclude access items by using an asterisk to indicate wildcard options. For example, for Role Name, you may enter the value TEST\* to indicate all accounts that begin with TEST. - An asterisk after the value indicates that the item starts with the entered value. - An asterisk before the value indicates that the item ends with the entered value. - An asterisk on each side of the value indicates that the item contains with the entered value. - An asterisk after an initial value and after a second value indicates that the item starts with and contains the entered values. For example, ZS\*TEST\* indicates that the rule blocks all items that start with ZS and contain the word TEST. - An asterisk before an initial value and before a second value indicates that the item contains and ends with the entered values. For example, \*TEST\*2026 indicates that the rule blocks all items that contain TEST and end with 2026. - An asterisk after an initial value and after a second value, followed by a third value indicates that the item starts with and contains and ends with the entered values. For example, ZS\*TEST\*2026 indicates that the rule blocks all items that start with ZS and contain the word TEST and end with 2026. 1. Optionally, add a description for your entry. 1. Search, scroll, or filter to locate roles, users or systems you want to block. Select **+** to add entries. When you are finished, select **X** to close the window. 1. If you selected the Individual Roles or Individual Users type, select **+Add Roles** or **+Add Users** and select the individuals you want to block. 1. If you selected a type other than Individual Roles or Users, select **+Add ERP System** and choose the system(s) that you want to include in the entry. 1. Review the selected roles, users, or systems. To remove an item from the list, select the **Delete** icon . 1. Select **Submit**. The newly excluded item is added as a row to the Block List table. ## Managing Block Lists Admins can manage block list entries from the Block List page. Use the **Filter** icon to filter items based on values in the ERP System(s), Type, and Value columns. To clear a filter, select **Clear Filter**. Details for each rule include: - **Actions** - Edit or delete. - **ERP System(s)** - SAP system that the block rule applies to. - **Type** - Indicates whether the rule blocks Username, User Group, Role Name, and/or Profile Name. - **System Count** - Number of ERP systems that the block rule applies to. - **Value** - Value that is blocked. - **Created Date** - Timestamp of when the entry was added to the block list. - **Created By** - User who added the block list entry. Edit entries by selecting **Actions > Edit Block List Entry**. Make the updates you need, then select **Save**. To delete an entry, select the **Delete** icon >. To delete several items at once, select the checkboxes next to those rows, then select **Delete Selected**. Confirm your choice by selecting **Delete** or select **Cancel**. ## Excluding User Types and Statuses In addition to blocking specific entities, Admins can configure system-level exclusions to omit entire categories of users based on their SAP User Type or status. Configuring these settings ensures that technical accounts, expired users, or locked users do not appear in security extracts or risk analyses for that system. 1. Go to **Menu** > **Block Lists**. 1. At the top right, select **System Details**. 1. In the **System Setting** window, use the **SAP System** dropdown to select the environment you wish to configure. 1. Under **Exclude Types and Statuses**, select the checkboxes for the categories you want to exclude from risk analysis. - **User Types** - Select specific SAP user types to ignore (e.g., A - Dialog, B - System, L - Reference, C - Communication, or S - Service). - **Expired users** - Excludes users who are no longer valid, based on the validity dates defined in the SAP User Master Records, which are in turn based on the GLTGV and GLTGB dates in USR02. - **Users locked by administrator** - Excludes users who have an administrative lock applied, based on the UFLAG status in USR02. Note The **Users locked by administrator** setting only applies to administrative locks. Users who are currently locked due to failed logon attempts will not be blocked. 1. Select **Submit** to apply the configuration. ## Reporting on Block List Exclusions You can report on block list exclusions across all governed SAP systems using the [Block List Exclusions](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_reports/index.html) report. This report includes both the rules applied to each system and the resulting blocked entities, including the SAP users, SAP roles, and SAP profiles that have been excluded from each system. For users to be able to view the block list exclusions reports, you must make them part of the Block List Exclusions reporting group. You can do this individually or by adding the capability to a role that is assigned to those users. To assign individual users to this group: 1. Go to **Settings > Manage Users**. 1. Locate the individual user and select the **Edit** icon in their row. 1. On **User Details > Reporting Groups Selection**, select **+ Add Reporting Groups**. 1. Locate the Block List Exclusions group and select the **Add** icon . 1. Close the window. 1. The Block List Exclusions group is added to the Reporting Groups list on the User Details page. To assign the reporting group to one or more Access Risk Management permission roles: 1. Go to **Settings > Manage ARM Roles**. 1. Locate the role and select the **Edit** icon in that row. 1. In the **Reporting Groups Selection** interaction, **+ Add Reporting Groups**. 1. Locate the Block List Exclusions group and select the **Add** icon . 1. Close the window. 1. The Block List Exclusions group has been added to the Reporting Groups Selection list. 1. Select **Submit**. 1. [Assign the role to users](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/assigning_roles.md). # Configuring SSO You can contact [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to request SSO integration with Access Risk Management. The available integrations are for Azure AD and SAML 2.0 Identity Providers (IdP). After you have configured your SAP account and users in Access Risk Management, those users can log in to the application using their corporate credentials. Before contacting [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport), you will need to gather the following information from your IdP: **Azure AD** - Azure AD Issuer: `https://sts.windows.net/AzureADDirectoryID` - Email addresses or User Principal Names (UPN) for all users in Access Risk Management. **SAML 2.0 Identity Providers** - URL to download your IdP metadata OR the metadata file for Access Risk Management. Ensure the metadata includes the public key of the certificate that will be used to sign the SAML response. - User Name Identifiers for all Access Risk Management users. After you've collected the above information, contact [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to activate the SSO feature on your account. Note If your organization is using a SAML 2.0 IdP and the metadata can only be provided in a file format, include the metadata file in your request to [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport). Warning To ensure seamless authentication, it is **required** to use a single Identity Provider (IdP) configuration for all of your Access Risk Management tenants, including both production and sandbox environments. Reusing the same IdP metadata configuration across multiple tenants is the supported and necessary method to avoid potential authentication failures. # Creating SAP System Users An SAP administrator must create an SAP System User ID within each target system. You will use the SAP username and password to enable Remote Function Call communications between the target system and the Access Risk Management agent. Caution If you use the integration between Access Risk Management and Identity Security Cloud, make sure you are not using the same user to connect Identity Security Cloud to SAP that you are also using to connect Access Risk Management to SAP. They must be unique users or you will be unable to extract data from SAP. You can select any user with proper authorizations, but we recommend the following user specifications: - User: EM_CONNECTOR - User Type: System - Assign the roles: - Download the SAP file for [standard access roles](https://documentation.sailpoint.com/access-risk-mgmt/help/assets/z_sailpoint_arm_aa_2025.sap) and assign them to the system user EM_CONNECTOR. - If you use Emergency Access Management or Access Reviews, you will also download the SAP file for [additional role](https://documentation.sailpoint.com/access-risk-mgmt/help/assets/z_sailpoint_arm_eam_2026.sap) and assign it to the system user EM_CONNECTOR. Note Contact your SAP administrator if you need assistance using transaction PFCG to upload the roles. Upload the necessary roles via PFCG for the implemented features (provided by [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport)): - Access Analysis – z_sailpoint_arm_aa_2025.sap - Access Reviews (Certifications) and Emergency Access Management (Firefighter) – z_sailpoint_arm_eam_2026.sap # Extracting Logs Extracting logs can be a helpful step in troubleshooting an incident or the connection between the agent and SAP. You can start by opening a ticket with [SailPoint Support](https://community.sailpoint.com/t5/Contact-Support/ct-p/Contact-Support). If they determine that the issue relates to the agent connecting to the target SAP system, they may ask you to send a log. 1. Open the agent UI. 1. Select **Logs** from the left navigation. 1. Select a date range for at least several days before the incident up to today. 1. Select **Export**. # Installing and Configuring the Custom SailPoint Function Module Extracting data out of SAP with the Access Risk Management agent relies on remotely enabled function modules to access the SAP database. By default, Access Risk Management calls the SAP function module RFC_READ_TABLE. However, SailPoint created a custom function module replacement that is SAP certified called /SAILPOIN/SAIL_READ_TABLE. This module introduces additional security and improvements. The Access Risk Management agent has a checkbox labeled **Use SailPoint Table Extraction** that should be enabled after installing the custom function module in SAP and correctly configuring it. This allows the Access Risk Management agent to successfully extract data from SAP tables for security extracts or as part of a change log extract for Emergency Access Management (EAM). Refer to [Installation of SAILPOIN Add-On](https://documentation.sailpoint.com/connectors/identityiq8_3/sap/direct/help/integrating_sap_direct_source/install_sailpoin_add_on.html) for prerequisites and installation steps. ## Using the custom SailPoint function module The /SAILPOIN/SAIL_READ_TABLE function module has two layers of security: 1. SAP permissions, assigned via PFCG roles. - [Download the SAP roles](https://documentation.sailpoint.com/access-risk-mgmt/help/assets/arm_sap_roles.zip), including all necessary permissions. Refer to [Creating SAP System Users](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/create_sap_users.html). 1. A custom table in SAP where the Access Risk Management agent SAP user must be authorized for each table and each column in that table. - [Download a script](https://community.sailpoint.com/t5/Access-Risk-Management/Configuring-the-Replacement-for-RFC-READ-TABLE/ba-p/257970) to generate the necessary table entries. ### Configuring custom table entries You can use the custom SailPoint function module script to configure custom table entries that are required for the Access Risk Management agent user. 1. Execute TCODE **SE38**. 1. Enter program **Z_CONFIGURE_SERVICEACCOUNT** and press **F8**. 1. Enter the **SAP username** that the Access Risk Management agent uses to connect to SAP, e.g. EM_CONNECTOR, in the Service Account field and **ARM_EAM** in the second field. 1. Select **Execute** to be authorized to process Change Logs for EAM. 1. Go back and again enter the **SAP username** that the Access Risk Management agent uses to connect to SAP, e.g. EM_CONNECTOR, in the Service Account field and **ARM_STANDARD** in the second field. 1. Select **Execute** to be authorized to process Security Extracts. 1. If you are using the SAP USER_ADDRS table, go back and again enter the **SAP username** that the Access Risk Management agent uses to connect to SAP, e.g. EM_CONNECTOR, in the Service Account field and **ARM_USER_ADDR** in the second field. 1. Select **Execute**. ## Troubleshooting When Security Extract or Change Log jobs fail and you receive an error stating the job exceeded the maximum number of retries, this indicates there is an authorization issue with the agent user related to the new custom security table. Make sure that the agent user is appropriately authorized. 1. Log in to SAP and execute Tcode **SE16**. 1. Enter table name **/SAILPOIN/CONF** 1. Enter the **SAP username** that the Access Risk Management agent uses to connect to SAP, e.g. EM_CONNECTOR, in the Service Account field to verify that the user has access to run Security Extracts. 1. Select **Execute**. 1. Verify that you see UST12 in the Name column of the table. If so, the user has been authorized to run Security Extracts. 1. Verify that you see CDHDR in the Name column of the table. If so, the user has been authorized for EAM. ## Test connection If you are using Emergency Access Management, you must [edit the utilization options](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/set_emergency_access_options.html) to use the SAP Security Audit Log. Select **Test Connection** to check the agent’s connection to your SAP system. # Managing SAP Role Details Once you have used the agent to register your SAP systems, you will run a security extract. When the security extract has completed, you can view and edit role details, role approvers, owners, location, and description within Access Risk Management. Tip The location is not related to the SAP role but can be helpful for filtering by roles. After running a security extract, select the **Menu** icon in the top right and choose **SAP ROLES** to view the roles that have been pulled in from your SAP account. You can edit the role details using an .xlsx file or through the Access Risk Management UI. To edit role details in the .xlsx file: 1. Select **Export** to download the .xlsx template to use. 1. Use the template to update the approvers, owners, location, description, and whether the description should be retained from your .xlsx file or updated the next time you pull from SAP. 1. Save your changes to the template and select **Import** to upload your updated .xlsx file to display those changes in Access Risk Management. To edit role details within Access Risk Management: 1. Select the **Edit** icon next to the SAP role in the SAP Roles. 1. Update the approvers, owners, location, description, and if the description should be retained from your .xlsx file or updated the next time you pull from SAP. 1. Select **Save** to update the role details. If the automatic role update job fails as part of the security extract, select **Refresh from Extract**. This will take you to the [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-activity-history) to view the successful job. # Scheduling Security Extracts Access Risk Management extracts important security metadata from your SAP ERP systems for analysis through Security Extracts. They are used as an important input for [online](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online/index.html) and [Excel](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel/index.html) reports, [managing access reviews](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/create/index.html), [managing SAP role details](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/manage_sap_role_details.html), and [scheduling a WhatIf analysis](https://documentation.sailpoint.com/access-risk-mgmt/help/schedule_whatif.html). To schedule a security extract: 1. From the left-side navigation, select **Schedule Jobs > Security Extract**. 1. In the **Repeat** dropdown, select the frequency that you want to run extracts, or select **Do Not Repeat** if you want to run a one-time security extract. 1. If you selected Daily, Weekly, or Monthly, add details about when you would like security extracts to take place. Enter a name for your report in the **Recurrence Name** field. 1. Select **Submit**. View Security Extracts from the [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) page. # Scheduling Utilization Extracts Access Risk Management extracts utilization metadata from your SAP ERP systems for analysis alongside security extracts through Utilization Extracts. They provide important data for [online reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online/index.html), [Excel reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel/index.html), and [access reviews](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/index.html). To schedule a utilization extract: 1. From the left navigation, select **Schedule Jobs > Utilization Extract**. 1. In the **Repeat** dropdown, select the frequency that you want to run extracts, or select **Do Not Repeat** if you want to run a one-time security extract. 1. If you selected Daily, Weekly, or Monthly, add details about when you would like security extracts to take place. Enter a name for your report in the **Recurrence Name** field. 1. If you selected Daily, Weekly, or Monthly, set the Utilization Period to Previous Month or Current Month. This field defaults to Previous Month. 1. For a one-time extract, select a month and year for your run date. For recurring extracts, select the utilization period you want the extract to cover. 1. Select **Submit**. Important After you first connect the system, you need to validate that utilization extracts have been successfully configured to be sure that Access Risk Management will be ingesting accurate data. You can do this by triggering a utilization extract from the **Schedule Jobs** menu as described above, monitoring the job from **Activity History > Utilization Extract**, then downloading and reviewing the data. Refer to [Viewing Utilization Extracts](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-utilization-extracts). # Setting Utilization Options To provide usage context for evaluating and remediating sensitive and SOD risks, as well as for reporting on activities related to elevated privileges for emergency access management, you must configure utilization options on the agent for each of the SAP systems governed by Access Risk Management. It is your BASIS administrator’s responsibility to correctly enable, configure, and monitor the security audit log so the capabilities that rely on SAP security audit logs can operate properly. Caution If SAP security audit logging is disabled or runs out of disk space, there is no way for Access Risk Management to recover those logs. This could result in audit control failures, particularly for [Emergency Access Management](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html). To enable Security Audit Logs for EAM Utilization reporting: 1. In the Utilization Options section of the SAP system registration page, select the **Expand** icon . 1. Select a STAD option. - If you are running SAP 4.x version, select **STAD – use SAPWL_WORKLOAD_GET_STATISTIC** - If you are running SAP ECC version 5.0 or later, select **STAD – use SWNC_COLLECTOR_GET_AGGREGATES** 1. Follow the logic below to determine which of the following SAP Security Audit Log options to enable as the data source for Emergency Access Management utilization. - Use **SAP BASIS 7.50+ (RSAU_API_GET_LOG_DATA)** if it exists in your system. This option supports recording log data in the SAP database. Note To use this option, you must be on BASIS version 7.50 or higher and the function module RSAU_API_GET_LOG_DATA must exist. If you need to [update the agent](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/connect/index.html#updating-the-agent), it is recommended that you [back up agent configuration](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/setupsap/index.html#backing-up-agent-configuration) before you begin. - By default, all types of message IDs are enabled and collected, but you can select those you do not want to include. CUI (Fiori application starts) and AU3 (transaction code starts) message IDs are not included here because they are required to be enabled, so there’s no option to disable them. Refer to [Enabling Security Audit Logging](#enabling-security-audit-logging) for details about the message ID codes. - Use **RSAU_READ_LOG** if function module RSAU_READ_LOG exists in your system, but you are not using SAP BASIS 7.50+ and/or the function module RSAU_API_GET_LOG_DATA does not exist. This option supports recording log data in the SAP file system. - Use **SM20 - Variable Data Column** for older ECC systems if neither RSAU_API_GET_LOG_DATA nor RSAU_READ_LOG exist, but you can confirm that function module RSAU_READ_FILE exists in SE37 and when you execute SM20 to display transaction starts you can confirm that the transaction code shows up in the Variable Data column. - Use **SM20 - Transaction Code Column** for older ECC systems if neither RSAU_API_GET_LOG_DATA nor RSAU_READ_LOG exist, but you can confirm that function module RSAU_READ_FILE exists in SE37 and when you execute SM20 for transaction starts you can confirm that the transaction code show up in the Transaction Code column. - Use **SM20 - Transaction Code Column - Older 4.x”** if you are on an older 4.x SAP R/3 system. 1. In the Application Server Connections section, select **+ Connection** and enter the Host IP address, Instance Number, and Instance Name of the additional SAP application servers. Repeat for each application server you have. Important You must add every application server connection to ensure that all EAM activity is tracked. Security Audit Log will not work without these connections. Finding your instance name You can find the name of your instance by going to TCode ST03N in your Workload Monitor and looking in the ABAP Instance Name column. 1. Select **Save** to register your SAP system with these utilization settings. ## Enabling Security Audit Logging The SAP Security Audit Log, or “SM20,” enables SAP administrators to log sensitive system activities for security and auditing purposes, including dialog logons, RFC logons, RFC calls, transaction starts, report starts, user master changes, as well as system and other events. Common concerns about switching to SM20 are that it may result in increased storage costs and burden system administrators managing the log volume. In all, administrators have the option to log 90 different event types; however, Access Risk Management does not require you to enable logging of all of these types. The system can extract the following sensitive actions that are not logged as transaction code starts: - Manipulation Flags - Audit Log Changed (AUE) - C-Kernel Debugging Activated (CUK) - Field Content Changes During Debugging (CUL) - Debug Jump (CUM) – Skipping ABAP lines - Debug Stop (CUN) – A process was stopped from the debugger - Debug DB Manipulation (CUO) – Explicit database operation in debugger - Debug Session (CUP) – Non-exclusive debugging session started - System Changeability (EU1) – System changeability updates (SCC4) - Client Setting Changed (EU2) – Client setting changes - Change Document Deleted (EU3) - Audit Log Deletion (EU5) - Administration Flags - User Created (AU7) - User Deleted (AU8) - User Lock Status (AUA) - User Auths Changed (AUB) - User Master Changed (AUD) - Password Change (BU2) - Exfiltration Flags - Data Download (AUY) - Action Executions - Report Started (AUW) - Transaction Started (AU3) - Fiori Application Started (CUI) Common concerns about switching to SM20 are that it may result in increased storage costs and burden system administrators managing the log volume. However, event types AU3 and CUI will take up less than 1% of the entire log volume, meaning that the total disk space consumed by allowing at least these message types will not impact storage costs or create an undue burden on administrators. Another common concern is that turning on SM20 may degrade SAP system performance due to generating a lot of log entries, with a high toll on database performance. You should not see a performance impact on your system for two reasons: 1. The Security Audit Log has been thoroughly optimized by SAP. 1. Both log event retrieval and writing to disk take place in the kernel. If you are concerned, try it out for a day. Work with your BASIS team to request approval to enable and configure the SAP Security Audit Log with configuration to enable logging for all users, but only event types AU3 and CUI. Collect data for a period of time and verify that there are no adverse performance indications and that the overall disk space requirements are reasonable. # Integrating with Your SAP System To integrate your SAP system with Access Risk Management, you will first [create an SAP user](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/create_sap_users.html) with the necessary SAP roles provided by the Access Risk Management team to extract raw user and role data from your SAP system. You can also copy the Access Risk Management roles and create new ones using your organization's naming convention. SailPoint provides an agent you can install on a [Virtual Machine (VM)](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/setupsap/index.html) to [connect your SAP accounts](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/connect/index.html). When your SAP systems are connected, you must run a [security extract](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_security_extract.html) to securely pull down and display data from the connected systems. You can edit your [SAP role details](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/manage_sap_role_details.html) and create [block lists](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/block_sap_users_roles.html) within Access Risk Management. You can also work with [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to [configure SSO](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/configure_sap_sso.html). # Connecting Your SAP Systems Use the agent to register your SAP systems in order to safely extract and transmit security-related data to Access Risk Management. This data is used to identify potential risks and violations. To register your SAP systems: 1. Download the agent to your [VM](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/setupsap/index.html). Reach out to [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to receive the latest agent executable file link. 1. Select **Install** on the VM for the US/EU data server file. 1. Select the **ARM Agent Configuration** desktop icon or go to . 1. Enter your SailPoint-provided user ID and password. 1. Select **Add** to register a new SAP system. Note Only select the dropdown option **SAP System with Fiori** if SailPoint support instructs you to do so. 1. Enter your SAP system details, including the Application Server, Client Number, Instance Number, Time Zone of your SAP system, and the username and password of the [SAP user](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/create_sap_users.html) with the appropriate roles. Caution Time zone is mandatory for Emergency Access Management to function correctly. Failing to set it accurately for each system will result in missed activity that may allow some of the controls to fail. 1. Install and configure the [custom SailPoint function module](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/install_custom_module.html). Caution SAP RISE requires the custom SailPoint function module for table extraction. You must install and enable the **Use SailPoint Table Extraction** option when configuring the ARM Agent for each SAP RISE system or ARM functionality will fail due to duplicated records in the extracted tables. 1. Enable the toggle to **Use SailPoint Table Extraction**. 1. If you are using Emergency Access Management, you must [edit the utilization options](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/set_emergency_access_options.html) to use the SAP Security Audit Log. 1. Select **Test Connection** to check the agent’s connection to your SAP system. 1. Select **Save** to integrate your SAP system to Access Risk Management. ## Updating the Agent To check which version of the agent is currently installed, complete the following: 1. Log on to server where the agent is installed. 1. Use following link on the server browser: 1. Confirm the agent version results displayed inside browser. Update the agent: 1. Reach out to [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to receive the latest agent executable file link. 1. Uninstall the agent from the desktop icon or control panel / program files. 1. Confirm whether agent folders in the locations below are deleted and manually delete any remaining agent folders after uninstalling the old agent, if needed. - C:\\PROGRAMFILES%\\Sailpoint ARM - C:\\Windows\\Temp\\Sailpoint ARM - C:\\Windows\\System32\\config\\systemprofile\\AppData\\Roaming\\Sailpoint ARM - C:\\programdata\\ErpMaestro 1. Download the latest agent to your [VM](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/setupsap/index.html). When you update the agent, you can use the checklist below to confirm that the prerequisites are in place and that the agent is correctly configured. 1. Confirm and test EM_Connector authentication details Username and password on the agent ERP system configuration screen. Request password reset of the RFC User in SAP, if needed. 1. Confirm that EM_Connector in SAP is not locked. 1. Confirm that the roles assigned to EM_Connector in SAP are correct and up to date. 1. Use the following link to confirm that Microsoft .NET is version 4.8: 1. Confirm that the agent .exe install file is the latest and correct version. 1. Confirm whether the client is using a proxy for internet access on the server. The proxy file is found in the **C:\\Program Files\\SailPoint ARM** folder under **icons**. 1. Use the following telnet command to confirm that **hostname/host IP** is reachable: telnet 3300 1. Perform a connection test by selecting **Test Connection** at the bottom of the system setup page in the agent. 1. Check and export agent log files for errors and / or additional information. 1. Confirm that your server meets the [agent host server requirements](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/setupsap/index.html#server-requirements). 1. Confirm whether the client has load balancer(s) set up in SAP. 1. Confirm that the correct Instance Name is used in the agent for all required SAP systems. ## Troubleshooting If you can't log in with the provided sysJob ID and password, you may need to work with [SailPoint support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to set up a [proxy server](#using-a-proxy-server). If you can't validate the connection to SAP, you may need to update your server's [allow list](#updating-your-allow-list). ### Using a Proxy Server If you are required to connect through a proxy server for external communication, such as to the Access Risk Management Cloud Service, and you are running the agent as a Windows service, you may need to manually configure the agent to communicate through it using the command-line interface (CLI). Important Work with [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to set up a proxy using the following directions. **Configuring the agent to use a proxy server:** 1. Stop the SailPoint Agent Service. Ensure it is marked as Stopped. 1. Stop the SailPoint Access Risk Management SAP Connector. Ensure it is marked as Stopped. 1. From a CLI with administrative access, navigate to the Agent binary folder. This folder will have the file SailPoint.Agents.Application.exe in it. 1. Execute the following command: ```text cd\ C:\>cd program files\SailPoint ARM\Agent SailPoint.Agents.Application.exe proxy set --hostname 10.6.222.2 --port 3128 >cdHost} --port {Proxy Server Port} --username {Username (if your proxy server does not require a username, do not include this parameter)} --password {Password (if you proxy server does not require a password, do not include this parameter)}cd\ ``` Note If your proxy server does not require a username or password, do not include that parameter. 1. Restart the SailPoint Access Risk Management SAP Connector. Ensure it is marked as Running. 1. Restart the SailPoint Agent Service. Ensure it is marked as Running. When you have finished using the proxy, you can remove it. **Removing the proxy:** 1. Stop the SailPoint Agent Service. Ensure it is marked as Stopped. 1. Stop the SailPoint Access Risk Management SAP Connector. Ensure it is marked as Stopped. 1. Delete the proxy.settings file from the parent directory of the agent. 1. Restart the SailPoint Access Risk Management SAP Connector. Ensure it is marked as Running. 1. Restart the SailPoint Agent Service. Ensure it is marked as Running. Note The local encryption key for securing the proxy server credentials is autogenerated based upon the machine name and several other factors. If a significant system change occurs, the encryption key may not work. ### Updating Your Allow List If you can’t validate the connection between the agent and SAP, verify that the SAP system info is correct. If it is correct but the connection still fails, add the following URLs to the server’s allow list: | US Tenants | Tenants Outside the US | | ------------------------ | --------------------------- | | app.erpmaestro.com | grc-eu.erpmaestro.com | | dashsvc.erpmaestro.com | dashsvc-eu.erpmaestro.com | | authsvc.erpmaestro.com | authsvc-eu.erpmaestro.com | | api.erpmaestro.com | api-eu.erpmaestro.com | | rulebooks.erpmaestro.com | rulebooks-eu.erpmaestro.com | | jobsvc.erpmaestro.com | jobsvc-eu.erpmaestro.com | # Setting up an Agent on a VM Access Risk Management connects to SAP systems using an agent that lives on a VM in the same network as the SAP environment. The agent runs as a Windows service, started during the system boot process, and keeps running, even without a user login. The agent is designed to be the only agent necessary in a tenant’s infrastructure. The agent can be configured for high availability by installing multiple agents in multiple data centers and connecting them to the SAP system(s). You can then perform disaster recovery by reinstalling the agent from a backup. ## Backing Up Agent Configuration Users with access to the VM can create an encrypted backup of the agent configuration so you can restore it when needed. For example, you may need to upgrade or reinstall the agent. This backup covers all of your systems at once and includes all settings, all passwords, and any job hooks that you have set up. To create an encrypted backup of the agent: 1. Open your VM. 1. On the left navigation, select **Backup**. 1. Create a password and enter it in the **Password** field. 1. Select **Create backup**. To restore the agent from a previously created backup file: 1. Select the checkbox to indicate that you understand that your current configuration will be replaced by the backup file. 1. Select **Choose File** and then select the correct backup file. 1. Enter the password. 1. Select **Restore backup**. ## System Requirements Configure your VM on the same network as your SAP environment with the requirements below. ### Server Requirements | Agent Host Server | | | --------------------- | -------------------------------------------------------------------------------------------- | | CPU | Dual Core Intel | | Operating system (OS) | 64-bit Windows Server 2016 R2 or later | | RAM | 16 GB | | Hard disk drive (HDD) | 30 GB disk space (Exceptionally large or complex ERP environments may need more disk space.) | | Connectivity | 50 Mbps download / 25 Mbps upload | ### Software Requirements Download the following software: - [Microsoft .NET Framework 4.8 or higher](https://dotnet.microsoft.com/download/dotnet-framework/net48) - Microsoft Visual C++ 2010 - Redistributable Pack (x86) - Visual Studio 2010 (VC++ 10.0) Note VC++ 2010 is not mandated, just recommended. If you remove it after installing the agent, there is no impact on Access Risk Management functionality. ### Port Requirements Access Risk Management uses a third-party provider, Cloudflare. The list of possible IP addresses can be found at this [Cloudflare location](https://www.cloudflare.com/ips/). Open the following ports: - Agent VM – 443 - SAP server – 3300-3400 (RFC range) Best Practice The VM server used should be restarted on a monthly basis. It's also recommended to use a dedicated computer for 24/7, multi-user access and faster response times. ### Allow Traffic to Required URLs Add the following URLs to your allow list depending on where the Access Risk management tenants reside. If the tenant is in an EU data center, add the URLs for EU to your Allow list. If the tenant is in a US data center, add the US URLs. You can contact the Access Risk Management support team for tenant residency information. | US Tenants | EU Tenants | | ---------------------------------- | ------------------------------------- | | app.erpmaestro.com | app-eu.erpmaestro.com | | logsvc.erpmaestro.com | logsvc-eu.erpmaestro.com | | dataserver.erpmaestro.com | dataserver-eu.erpmaestro.com | | agents.erpmaestro.com | agents-eu.erpmaestro.com | | utilizationtracking.erpmaestro.com | utilizationtracking-eu.erpmaestro.com | # Managing Users You can add users in Access Risk Management and assign roles to them to determine what actions they can take in the application. For example, users with the Emergency Access Approval role can evaluate whether an [access request](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/evaluate_eam/index.html) should be approved. From the **Menu** , select **Manage Users**. ## Adding Users Select the **Menu** icon and choose **Manage Users** to display the users currently in Access Risk Management. You can add multiple users at once or individually. ### Bulk Importing You can upload an .xlsx file to mass maintain existing users or add multiple users or permission roles at once from your sandbox or another tenant. 1. On the User Management page in your sandbox or other tenant, select **Export** to download the template that you'll use to import an .xlsx file. 1. If any users already existed in production that do not exist in your other tenant, manually add them to the .xlsx file so they will not be deleted when the user list is overwritten. Caution Any users or Access Risk Management role assignments that are not present in the file will be deleted when you upload. 1. Save changes to the .xlsx file. 1. On the User Management page in your production tenant, select **Import**. 1. Select the updated .xlsx file that contains your users’ info. 1. Select **Upload**. The updated user information appears on the User Management page. Note If you don't want to send welcome emails to newly added users, set the **SendWelcomeEmail** column value to False to suppress the welcome email for those users. ### Adding Individuals You can add users individually. 1. On the User Management page, select **+ Add Users**. 1. Enter the user's details. - Include the ERP User ID if the user will be an [access reviewer](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/create/index.html) or be able to request and receive temporary [elevated access](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_view/index.html#creating-an-eam-request). - Add the SSO name if you have [configured SSO](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/configure_sap_sso.html) and expect the user to use the SSO option to log in to Access Risk Management. 1. Select **Submit**. You can also view, add, [assign user roles](#assigning-roles-to-users), and [create access contexts](#creating-access-contexts) from this page. ## Editing User Details You can update user details, such as username, first name, last name, and email. 1. Go to **Menu** > **Manage Users**. 1. Scroll or search to find a user. 1. Select the **edit** icon in that row. 1. On the User Details page, update user information. 1. Select **Submit**. ## Assigning Roles to Users You can assign roles that will determine what level of access a user can have and what actions they can take. To assign a role to a user, select **+ Add User Roles** under User Roles Selection. ### Downloading User Change Logs On the User Management page, select **Change Logs** to be redirected to the [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-activity-history) page. Select **Download** to download a .csv of the logs. It may take a moment for the change log to generate and the **Download** button to display. Select the **Refresh** icon above the Action column to update the Activity History page. ### Creating Access Contexts Access contexts allow administrators to restrict what users see in the online reports. Access contexts can also be used to filter between different sets of users if someone has multiple access contexts assigned to them. To set up access contexts: 1. Select the **Menu** icon and choose **Access Contexts**. 1. Select the toggle to enable access contexts. 1. Select **Add** to create a new access context. 1. Name the access context. 1. Use the **Column** dropdown menu to select the criteria you want to filter users by, such as country or department. To create custom columns, contact Access Risk Management support. 1. Enter the value you want associated with your criteria. For example, you might select "country" as your column and enter "United States" as your value to filter users based on if they are in the US. When creating or editing users, you can select **+ Add Access Context** to restrict the SAP users that the Access Risk Management users can see in online reports. You can edit existing users by selecting the **Edit** icon on the **User Management** page. ### Scheduling Automatic Logouts You can schedule the days, hours, minutes, and seconds after which an idle user will be automatically logged out. Select **Customer Settings**, choose your times, and select **Schedule**. # Managing Rulebooks Rulebooks define the rules for the separation of duties (SoD) and sensitive access (SEN) that you will be testing for within the application. A rulebook is composed of rules and the associated permissions that make up their risk. Access Risk Management provides rulebooks containing more than 240 SoD risks and 8 sensitive access risks. While the default rulebooks cover most organizations' needs, you can customize your rulebooks to create or add a new rule, exclude a rule from analysis, change risk ratings, add custom transaction codes, and more. Important Most implementations define somewhere between 50-500 rules in any given rulebook. If you find you need to define more than 500 rules, you should engage an SAP advisory partner for help clearly defining your security needs and creating a rulebook that meets those needs. Once you understand rulebook logic, you can edit rulebooks using the [Rulebook Dashboard online](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/editing_online.html) or by [editing](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/editing_offline.html) and [importing](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/importing_rulebooks.html) an .xlsx document. # Creating Rulebooks Note This page contains information about the former Creating Rulebooks functionality, which we now refer to as "legacy." It is still supported as we move to the newer version. For latest Creating Rulebooks functionality, refer to [Creating Rulebooks - New](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/creating_rulebooks_new.html). Access Risk Management provides a template you can use to create a new rulebook. 1. Select **RULEBOOKS** and choose **ALL RULEBOOKS**. 1. Select **Import**. 1. Select **Download Template** and enter your rule information in the .xlsx file. Refer to [Understanding Rulebook Logic](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/understanding_rulebooks.html) for guidance. 1. [Import](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/importing_rulebooks.html) the rulebook. # Creating Rulebooks - NEW Note This page contains information for the latest Creating Rulebooks functionality. The former Creating Rulebooks functionality is also still supported. Refer to [Creating Rulebooks](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/creating_rulebooks.html). Create a new rulebook from a template or by editing an existing rulebook that was created in the new format. 1. Go to **Risks - NEW > Rulebooks**. 1. Open and update an existing rulebook or new rulebook template. a. To download a template and create a new rulebook, select **Import**, then **Download Template**. b. To update an existing rulebook, select the **Download** icon in the rulebook’s row. - On the Activity History page, locate your export on the Data Exports tab. - Select Download in the Actions column. c. Update the .xlsx file. 1. In Access Risk Management, return to Risks – NEW > Rulebooks and select **Import**. 1. Use the **Select Files** button or drag and drop files into the File Selection field. 1. Select **Upload**. Important Importing rulebooks will delete all information in that rulebook that is not present in the upload file. Be sure to download a copy of the existing rulebook if there is information you want to retain. 1. In the confirmation dialog, select **Import**. 1. After a successful import, your new rulebook will be listed on the Risks - NEW > Rulebooks > Multi-System Rulebooks page and available to select when evaluating risks and running reports. See [Creating a Risk Analysis - NEW](https://documentation.sailpoint.com/access-risk-mgmt/help/schedulejobs/index.html#risk-analysis-new). ## Finding Data You may notice differences between the format of legacy rulebooks and new rulebooks, including: - **Fewer tabs.** The new rulebook has simplified the number of tabs. - **Manage mitigating controls in the UI.** Information previously found on various mitigating controls tabs in the rulebook can be viewed in the Access Risk Management UI and managed at Risks - NEW > Mitigating Controls. See [Managing Mitigating Controls – NEW](https://documentation.sailpoint.com/access-risk-mgmt/help/mitigatingcontrols/manage_controls.html). - **Rules to business functions mapping.** Data previously found in columns on the Rules tab that map rules to business functions has been moved to a separate Risks to Business Functions tab, with a row for each risk. - **Permission Logic column**. This rulebook column determines how Business Functions with more than one Action / TCode Logic Group will be evaluated. AND logic means that all of the Actions/TCode Logic Groups must be present to be considered a risk, whereas OR logic means that any one of the Actions / TCode Logic Groups must be present to be considered a risk. - **Access Logic column**. For SAP, this rulebook column determines how Authorization Objects will be evaluated when there is more than one for a given Action / TCode Logic Group. AND logic means that all of the Authorization Objects must be present to be considered a risk, whereas OR logic means that any one of the Authorization Objects must be present to be considered a risk. Note If an S_TCODE or an S_SERVICE Authorization Object is specified for an Action / TCode Logic Group, those objects are mandatory and this configuration setting does not impact checks of those special objects. # Editing Rulebooks Offline You can also edit existing or create new rulebooks by exporting and importing .xslx files. This allows you to tailor your rulebooks offline to bring into Access Risk Management. To edit an existing rulebook: 1. [Export](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/exporting_rulebooks.html) your rulebooks and select the **Export All** option. 1. Use the tabs at the bottom to display the different components of the rulebook, such as rule mappings, business processes, and rule mitigations. Refer to [Understanding Rulebook Logic](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/understanding_rulebooks.html) for guidance on editing your rulebook. 1. Make your edits and [import](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/importing_rulebooks.html) the new rulebooks to Access Risk Management. Warning Select **Export All** to ensure nothing is lost or overwritten when importing the new rulebook into Access Risk Management. Use caution when importing new rulebooks as they overwrite all existing ones. # Editing Rulebooks Online The rule hierarchy and details are displayed in the Rulebook Dashboard. Select **RULEBOOKS** and choose **ALL RULEBOOKS**. Select the **View Rulebook** icon next to a rulebook to display the Rulebook Dashboard. In the Rulebook Dashboard, you can change rules, business functions, and transaction codes and their associated authorization objects. Rulebook Dashboard Options - Add a new or existing rule to the rulebook. - Edit a rule’s details. - Remove a rule from the rulebook. - Add a new or existing business function to the rule. - Edit a business function's details. - Remove a business function from a rule. - Add a new transaction code to a rule. - Edit the objects, fields, and values in the transaction code. - Remove a transaction code from a business function. ## Managing Rules The Rule Dashboard shows you the rules in a given rulebook. You can expand each rule to display its business functions, permissions, and authorization objects and their values. - To edit rule details, select the **Info** icon in the rule row, make your edits, and select **Save**. - To add an existing rule to a rulebook, select **+ ADD** and the **Add** icon on the rule row. You can use the search field above to search for rules. - To add a new rule, select **+ New**, enter the rule details, and select **Save**. - To remove a rule, select the **Remove** icon . Note Removing a rule, existing or new, removes the mapping of the rule to the rulebook. Other rulebooks using this rule are not affected. ## Managing Business Functions To display a rule’s business functions, select the **Expand** icon next to a rule name. A sensitive access rule contains one business function. An SoD rule contains more than one business function. - To edit business function details, select the **Info** icon in the business function row, make your edits, and select **Save**. - To add a business function to a rule, select the **Add** icon on the rule row. - To add an existing business function, select **Add Business Function** and choose an existing business function. Select the **Add** icon in the business function row to add it to the rule. - To add a new business function to a rule, select **New Business Function**, enter its details, and select **Save**. - To remove a business function from a rule, select the **Expand** icon on the rule row and select the **Remove** icon . Removing a business function cannot be undone. Note If all business functions are removed from a rule, an alert will notify you that the rule is incomplete. Add a new or existing business function to complete the rule. ## Managing Permissions To display a business function’s transaction codes that manage permissions, select the **Expand** icon next to a business function. - To edit TCode details, select the **Info** icon in the TCode row, select or change the name, and add or delete objects, fields, or values. Select **Save**. - To add a TCode to a business function, select the **Add** icon on the business function row, and select **Add Permission**. - Name and add objects to the TCode. Select **Save** to add the permissions to the business function. - To remove a permission from a business function, select the **Remove** icon in the permission row. Removing a permission cannot be undone. Note If all business functions are removed from a rule, an alert will notify you that the rule is incomplete. Add a new or existing business function to complete the rule. # Exporting Rulebooks You can download rulebooks as .xlsx documents to use outside of the platform. 1. Select **RULEBOOKS** and choose **ALL RULEBOOKS**. 1. To export specific rulebooks, select the checkbox next to individual rulebooks and select **Export Selected**. To export all rulebooks, select **Export All**. Important If you want to edit the rulebook [offline](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/editing_offline.html), select **Export All** to ensure nothing is lost or overwritten when [importing](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/importing_rulebooks.html) the rulebook into Access Risk Management. 1. You will be redirected to the Data Exports tab of the Activity History page. Select **Download** next to the completed report. # Importing Rulebooks If you choose to create a new rulebook or edit an existing one, you must import it into Access Risk Management to provide the information needed to identify and manage risks. Warning Importing new rulebooks overwrites all existing rulebooks. To import a rulebook: 1. Select **RULEBOOKS** and choose **ALL RULEBOOKS**. 1. Select **Import**. 1. Use the Import Type dropdown menu to select the type of rulebook you are importing. 1. Select **Select files…** and choose the .xlsx file to upload. You can repeat this step to import additional rulebooks. 1. Select **Upload** to add your rulebook to Access Risk Management. You can view your rulebook in the [Rulebook Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/editing_online.html). # Understanding Rulebook Logic Rulebooks are a collection of rules that determine what type of access is considered a risk. They can contain both SEN and SoD rules. To determine risks, rules use business functions and their related permissions to identify potentially risky access. ## Rulebook Definitions - **Rules**: The possible combinations of transactions and permissions that compose a business risk. Sensitive access rules are made up of one business function. SoD rules have two or more business functions. - **Business functions**: Collections of access that provide the ability to perform activities associated with part of a potentially risky action. Each business function contains permissions represented through transaction codes and authorization objects that define access. - **Transaction codes**: Transaction codes used when executing a task. Transaction codes, or TCodes, are the first authority check performed as part of an analysis and are used to group the related authorization objects associated with the access in a business function. - **Authorization objects**: Objects containing authorization fields and values that represent data and activities. These are used to grant and check authorizations down to the most granular level. Authorization objects are grouped together and can be edited in the TCode. You can view your rulebook information down to the authorization values in the Rulebook Dashboard. The following logic examples demonstrate how these objects work together to create rules that identify risks. ## TCode Logic TCode logic is used to determine if all, or just one, of the transaction codes are required for a user or role to access the *business function*. To view the TCode and object logic of a business function, select the **Info** icon next to the business function name. For example, if a business function has 2 TCodes and their related authorizations, and the TCode logic is set to OR, then the user or role will have access to that business function if they have the first *or* the second TCode. If the logic is set to AND, then the user or role will need both transaction codes to have access to the business function. ## Authorization Object Logic Object logic is used to determine if all, or just one, of the authorization objects are required for a user or role to have access to the transaction code. If the logic is AND, all authorization objects are required. If the logic is OR, then only one of the authorization objects is required. The example above shows the TCode SE38 and its authorization objects. There are 2 different objects. If the object logic is set to OR, the user or role will have access to TCode SE38 if they have the object S_PROGRAM or S_DEVELOP. If the logic is set to AND they will need both authorization objects. ## Field and Value Logic There is also field and value logic, which is used to determine the field and value criteria for a user or role to have access to the authorization object. Logic is set for the fields and the values as follows: - Within the Same Field Value - A user can have any of the values. The example above shows an OR between ACTVT 01 and 02 for auth object F_BKPR_KOA. - Between Different Field Values - A user needs to have access to a value from each of the fields. The example above shows an OR for ACTVT 01 and 02 and an AND between fields ACTVT and KOART for auth object F_BKPF_KOA. - For this user to be considered as having access to auth object F_BKPF_KOA, they need KOART K AND (ACTVT 01 OR ACTVT 02). # Viewing Rulebook Changes Access Risk Management automatically tracks rulebook changes. You can download a log of changes that occurred during a specified time frame. To generate a change log: 1. Select **Rulebooks > All Rulebooks**. 1. Select the checkboxes next to the rulebooks you want to include in the change log. 1. At the top, enter a date or select the **Toggle Calendar** icon to set the date to begin reporting and the date when the change reporting will stop. 1. Select **Download Logs**. 1. You will be redirected to the Change Logs tab of the Activity History, where the log is queued for generation. When the change log is completed, a **Download** button will appear. Select it to download the change log. Note It may take a moment for the change log to generate and the **Download** button to display. Select the **Refresh** icon above the Action column to update the Activity History page. # Managing Access Reviews Overview The Access Reviewer automates coordination and communication between review administrators and reviewers, making it faster and easier for admins to create and track reviews and simplifying reviewers' experience approving, rejecting, and delegating access to the review items. From **Access Reviewer** in the left navigation, you can: - [Create access reviews](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/create/index.html) - [Manage HR information](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html) - View the [Reviewer Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/review_approve_access.html) - View the Access Review Administrator Dashboard # Choosing Risk to Mitigating Control Review Settings After you enter the [review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html) for the Risk To Mitigating Control type of review, set the rulebook(s), the changes to include based on a prior review, and if you want to hide blank columns. This type of review can only be performed by Risk Owners. # Choosing Role to TCode Review Settings After you enter the [review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html) for the Role to TCode type of review, set the rulebook(s), security extract, and the changes to include based on a prior review. Note This type of review can only be performed by Role Owners. When specifying the review details, select **Role to TCode** under Type of Review. 1. Select the rulebooks to include in the review. Role owners can review and recertify that the transaction codes included in their respective roles are appropriate and if that role's transaction codes should be retained. 1. Choose a security extract. You can select a previously completed security extract or a live security extract where a new security extract is pulled from SAP to run the analysis for the review. Note Previously completed extracts are sometimes used when completing a review for access at a certain point in time, even if that time has passed. 1. Select **Only include changes since** to only include changes made since the chosen review was performed. # Choosing Rulebook Review Details After you enter the [review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html) for the Rulebook Details type of review, set the rulebook(s), the changes to include based on a prior review, and specify if you want to hide blank columns. Note This type of review can only be performed by Risk Owners. # Choosing User to Risk Review Settings After you enter the [review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html) for the User to Risk type of review, set the rulebook(s), security extract, risk ratings, the changes to include based on a prior review, and the roles to exclude. Note This type of review can be performed by Risk Owners and Managers. When specifying the review details, select **User to Risk** under Type of Review. This will change the available settings. 1. Select the rulebooks to include in the review. Risk Owners can review the list of users and the risk associated with their access to determine if that access should be retained. Important Associated risk is identified by determining if any of the transaction codes in the role are associated with access in a risk. This does not mean there is an inherent risk in the role. 1. Choose a security extract. You can select a previously completed security extract or a live security extract where a new security extract is pulled from SAP to run the analysis for the review. Note Previously completed extracts are sometimes used when completing a review for access at a certain point in time, even if that time has passed. 1. Select the risk rating(s) to include: Refer to the [User to Role](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/choose_user_to_role_settings.html) type of review for information on completing this section. # Choosing User to Role Review Settings After you enter the [review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html) for the User to Role type of review, set the time frame for usage data, rulebook(s), the security extract, and what user groups and roles to include or exclude. Note This type of review can only be performed by Managers or Role Owners. 1. Under **Months of utilization**, enter or use the arrows to set the time frame the review will use to identify if the transaction codes in those roles are being used, providing insight into whether a role assignment is appropriate for a user based on usage. Tip You may want to change the months based on the frequency of reviews. For example, if reviews are done quarterly, you may only need the previous three months of utilization. 1. If you have not run a utilization extract job during the access review time frame, we recommend that you select the **Create utilization extracts for missing months** checkbox to automatically pull utilization extracts for months missing from the review time frame. Otherwise, they won't be included in the review. 1. Select the rulebook(s) to include in the review. Reviewers can view the rulebook(s) to see the risk associated with the role, helping them decide if that role's access should be retained by the user. 1. Choose a security extract. You can select a previously completed security extract or a live security extract where a new security extract is pulled from SAP to run the analysis for the review. Note Previously completed extracts are sometimes used when completing a review for access at a certain point in time, even if that time has passed. 1. Select the user group(s) to include in the reviews. For example, you may have contractor and super user groups you can select. 1. Use the **Only include changes since** dropdown menu to create a review that only includes the changes since a previously completed review. Items from previous reviews will appear in the review but will be populated with the response from the last submitted review. This allows reviewers to consider previous decisions when choosing a response. 1. Select the roles to exclude from the review: - **Emergency Access Roles** - These roles can be excluded from most access reviews since there is a separate workflow and control process in place for emergency access, and they do not represent a user's typical access. If you want to detect whether a user happens to have elevated access during the review timeline, then don't exclude these roles. - **Standard User Roles** - These roles are often excluded because they will be approved every single time since all users must have this role. Excluding them reduces the time it takes to complete the review. It also minimizes the chance of reviewers accidentally rejecting the role assignment and having to add the role back to the user to correct the error. 1. Select the **Hide Blank Columns** checkbox to exclude any columns that contain no data from the view. 1. Select the **Enable Group Approvals** checkbox to enable reviewers apply the same decision to all access for an individual user or all the users with a role (instead of being required to review each individual item separately). 1. Select the **Ignore Admin Locked Users** checkbox to exclude admin-locked users from the access review. You can tell if a user has been admin locked if 32 or 64 appear in the PFLAG field. This is based on the table USR02 in SAP. 1. Select the **Ignore Failed Login Users** checkbox, to exclude users who are locked due to failed login attempts from the access review. These users are usually included based on the assumption that they will successfully reset their password and have access again soon. The determination is based on the SAP table USR02 for users with the value of 128 in the field PFLAG. # Generating Access Review Reports In the Access Review Administrator Dashboard, select the **Report** dropdown menu to see the reports you can generate: - **Latest Report** - This report consolidates into one Excel file all of the line items included in a review with the current status of reviewers' responses. - **Reviewer Action Log** - This log is more detailed than the reports and shows every action taken instead of just the final review decision, including delegations of roles or reviews. # Reviewing and Approving Access Reviewers can access the review by selecting the link in their email or by selecting **ACCESS REVIEWER > REVIEWER DASHBOARD** and selecting the **Review** icon . When reviewing access, reviewers can choose from the following options: - Approve the access - ­ Reject the access. When rejecting an item, the reviewer will be required to fill in the comment field with a reason. - Delegate the review of a specific access item. When delegating, the reviewer will be required to select who to delegate the item to and provide a reason for delegating it. Reviewers can also leave a note about the review or delegate the entire review to someone else. When a delegated review includes access items that are assigned to the user who has been newly delegated to complete that review, those items will be automatically reassigned directly to an administrator. This prevents users from approving their own access. The admin can choose to review the items themself or redelegate to a different user. Reviewers will use the information provided to make decisions on access. For example, in the User to Role review, the reviewers may look at the TCodes, TCode usage, and risks associated with each user to decide if their assigned roles are appropriate. Important Associated risk is identified by determining if any of the transaction codes in the role are associated with access in a risk. This does not mean there is an inherent risk in the role. If a role has risk associated with it but no utilization, a reviewer might decide to reject that role since there is risk, and it is not being used. Likewise, if a role has neither risk nor utilization, reviewers might still reject it to follow best practices around least privileged access. Reviewers will select **Submit Review** to complete their review. When all reviews are completed, you can generate audit reports or kick off a job to remove all rejected roles. # Reviewing Rejected Roles To view the list of rejected roles and the users who had those roles assigned to them, scroll to the far-right column on the Administrator Dashboard and select **Remove Roles**. To remove the rejected roles, select **Approve** and Access Risk Management will remove the rejected roles. # Selecting Review Fields After you enter the [review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html), you can select what fields will be included in the review. The default selection is basic user information, roles assigned, and additional risk information. Tip If the SAP table USER_ADDR is maintained, select additional columns to help the reviewer understand a user's responsibilities and what roles are appropriate. Select the down arrow to see an example of how the review will look based on your field selections. # Setting Email Reminders You can choose the cadence and content of the following types of emails sent to reviewers. - **Initial Email** - This will be sent to all reviewers on the start date of the review. - **Reminder Email (optional)** - You can schedule up to three reminder emails. You cannot set reminder emails for the same date as other emails. - **Final Email** - Reviewers who have not completed their review will receive a final reminder email one day before the review is due. Select the tabs to edit the initial email, reminders, and the final email. When you have completed configuring your access review, select **Submit**. On the review's start date, Access Risk Management will generate the review and send all reviewers an email containing a link to complete the access review. # Specifying Review Details Select **ACCESS REVIEWER > CREATE ACCESS REVIEW** to specify the details for the review. *These details are the same for all five types of access reviews*. 1. Enter a name for the review. 1. Use the **Type Of Review** dropdown menu to select one of the review types: 1. Set the time frame: - Enter a start date for when to kick off the review and email reviewers. - Enter an end date for when the review is due. This determines when the system sends out the final email and reminders (if selected). Incomplete reviews after this date are considered overdue. Reviewers cannot complete an overdue review unless an administrator extends the end date. 1. Use the **Performed By** dropdown menu to choose what type of user can review this access. Depending on the type of review, your options are: - Managers - Make sure all users you want reviewed have managers by selecting **ACCESS REVIEWER > MANAGE HR INFORMATION.** - Role Owners - Make sure all roles you want reviewed have owners by selecting the **Menu** icon and choosing **SAP ROLES**. - Risk Owners - Ensure the risks you want reviewed have owners by selecting **RULEBOOKS** and selecting the **Info** icon to view the Risk Owners field. # Creating Access Reviews Creating an access review is the first step to coordinating reviews and reviewers. For each access review, you will: - [Specify the review details](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/specify_review_details.html), including name and type of review, who it will be performed by, and the review time frame. - Specify the settings based on the [type of review](#types-of-access-reviews). - [Select the fields](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/select_review_fields.html) that the reviewer will see. - [Set up email alerts](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/set_email_reminders.html). ## Types of Access Reviews Note If you have worked with SailPoint support to get the latest version of Access Reviewer that supports Fiori enabled for your tenant, the only available type of Access Review is User to Role. This version of Access Reviewer requires the use of a new [Multi-System Rulebook](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/creating_rulebooks_new.html) so you can define Fiori-specific rules. There are five types of access reviews: - **User to Role** - The [User to Role review](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/choose_user_to_role_settings.html) allows Managers or Role Owners to review role assignments and determine whether they are appropriate in the target SAP system. When a review is completed, Access Risk Management deprovisions the access associated with any rejected roles. You can also manually deprovision access outside of an access review. - **Role to TCode** - The [Role to TCode review](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/choose_role_to_tcode_settings.html) allows Role Owners to review and recertify that the transaction codes included in their respective roles are appropriate. - **User to Risk** - The [User to Risk review](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/choose_user_to_risk_settings.html) allows Managers or Risk Owners to review the list of users and the level of risk associated with their access. They can choose to approve or reject that access. - **Risk to Mitigating Control** - The [Risk to Mitigating Control review](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/choose_risk_to_mitigation_settings.html) allows Risk *Owners* to review the risks that are mitigated by each mitigating control. - **Rulebook Details** - The [Rulebook Details review](https://documentation.sailpoint.com/access-risk-mgmt/help/reviews/choose_rulebook_review_details.html) allows Risk Owners to review the details of each risk in the rulebook, such as risk rating, process area, and description. Get started by selecting **Access Reviewer** and choosing **Create Access Review**. # Managing Emergency Access Overview When users need elevated permissions to perform sensitive tasks, including monitoring and reviewing system activities, they can request access using Emergency Access Management (EAM). Granting emergency access includes these actions. 1. A Requestor or Profile Owner must [configure an access profile](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_profile/index.html) to define the permissions and participants for the request. 1. Once access profiles are configured, you can create a [request](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_view/index.html#creating-an-eam-request) by selecting **Emergency Access New** from the left navigation. 1. Review participants can then [view the request](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html) as it moves through each stage, as well as export [emergency access reports](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/generate_reports/index.html). 1. EAM automates and tracks the [approval](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/approve_reject_requests.html) process, as well as the [provisioning](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/provisioning_entitlements.html) and [revocation](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/removing_access.html) of access. Actions taken during a period of elevated access are [collected](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/extract_usage.html) and [reviewed](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html) to determine whether the access was used appropriately. # Approving and Rejecting Requests When an emergency access request is submitted, approvers receive an email notification with the option to approve or reject the request by selecting the related button in the email notification. They must enter authentication credentials to receive confirmation the action was completed. If this is done on a mobile device, their decision is automatically applied to the request, and a comment is added indicating the action was taken from a mobile device. If the approver is on a desktop computer, they will be redirected to the [EAM Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html), where they can expand the Actions dropdown menu next to the request and select **Approve** or **Reject**. When an Approver rejects a request, it is moved to the Completed tab of the EAM Dashboard, and the Requestor is notified. Approved requests will be scheduled to be provisioned at the date and time set on the request, or immediately if a future date was not selected. Approvers can also view, approve or reject, and comment on their assigned requests using the [Reviewer Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html). # Managing Emergency Access (Legacy) Deprecation Notice This document describes the legacy Emergency Access Management feature. You cannot create or approve emergency access requests in the legacy system. You can complete existing requests and view your legacy audit data until December 31, 2023. To update your instance of [Emergency Access Management](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/index.html), contact [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport). ## Reviewing Emergency Access Requests After all utilization data has been collected, an email will be sent to reviewers so they can log in and perform their review activities. Reviewers can access the review screen by selecting **View Request** in the email or **EMERGENCY ACCESS** in Access Risk Management. From the EAM dashboard, reviewers will see the pending review and can download the utilization report by selecting the **Download** icon . After completing their review, they can: - - Select the accept button to verify that the requester used the access as intended. - - Select the contest button if the requester used the access in unintended ways and they want to mark it appropriately for audit purposes. - - Select the history button to see a log of the stages the request has gone through. This log is available throughout the process and shows when the request was submitted, approved, reviewed, and the users who performed those approvals. ## Viewing Emergency Access Requests and Utilization You can view Excel reports detailing how emergency access was used by selecting **EXCEL REPORTS** and choosing the **EAM REPORT** or **EAM REQUEST OVERVIEW REPORT**. # EAM Profile Report You can view and export reports containing Emergency Access Management (EAM) profile data, along with reason codes, to manage compliance and provide to auditors. This data is specific to the profiles and their data. For more information about requests against these profiles, refer to [Exporting EAM Request Data](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/generate_reports.html). You can download an Excel file that contains all EAM profile data along with validating attachments. 1. Go to the Emergency Access Profiles page, **gear icon > EAM Profiles NEW**. 1. Hover over any table visual. Select the **More Options** icon in the upper right corner, then select **Export Data**. 1. Select an export option, such as **Data with current layout**, **Summarized data**, or **Underlying data**. 1. Select **Export**. 1. When the export completes, select **Download**. # Exporting Profile Change Logs EAM administrators, super users, and profile owners can export and download EAM profile change logs detailing the creation, updating, and deletion of profile metadata. To export the changes for an individual profile, select the **Change Logs Export** icon to the left of the profile name you are the owner of or administrator for. This includes records from its creation to the current time. To export change logs for all profiles: 1. In EAM Profiles, select **Change Logs** in the upper-right corner. 1. Enter the Start Date for the reporting period. Logs begin at 00:00:00 AM on this date. 1. Enter the End Date for the reporting period. Logs end at 11:59:59 PM on this date. 1. Select the Time Zone to use for the report. This defaults to your local time zone. 1. Choose to export data from all systems, the current system, or select specific systems. 1. Select **Submit**. You will be redirected to the Change Logs tab of the Activity History page, and your Change Log will be queued for export. 1. When the export completes, select **Download**. You can unzip the file to view the: - Manifest folder with digital signatures for each file. - Properties.csv with metadata about the Change Logs like the ERP systems, period of report, and the user who executed the report. - Change Logs.csv with data about the creations, updates, and deletions that took place in your ERP systems, including the associated EAM profile, user name of the individual who modified the object, old and new values, and a timestamp of the changes in UTC. # Extracting Usage Data Access Risk Management extracts utilization data and change logs from the connected ERP system. Utilization data tracks the actions executed, even if they were not completed or did not change the database. Change log data shows database creation, updates, and deletions. Once data collection for both utilization and change logs is successful, Reviewers will receive an email notifying them to [begin their review](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html#reviewing-usage-data). All Reviewers are notified, but the decision is made by the first Reviewer to complete the review. You can opt out of collecting change log data by selecting the **Change Document Opt-Out** checkbox in your configured SAP system. Please consult with [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) before making this change. Important To ensure accurate utilization data, include all application servers on the [agent configuration settings](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/set_emergency_access_options.html). # Exporting EAM Request Data for Auditors Generate and export information about emergency access requests and the actions that have been taken on them, such as reviews, approvals, provisioning, etc. The export produces a set of the following CSV reports and associated files. | File | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Request Details | Request properties, like who requested, approved, and reviewed requests, when access was provisioned and deprovisioned, and the reviewer's final disposition. | | Utilization Details | Actions taken by requestors, including when they took place, whether they are sensitive or elevated, and what request they relate to. | | Change Details | Changes generated by requestors, including the transaction codes, fields, document type, and old and updated values. | | Workflow Logs | Steps taken in the EAM process from request creation to closure, including comments and error codes. | | Comments | Comments made on requests, including the request state when the comment was left, author, and file attachment names. | | Properties | Metadata about the report package, including who generated it, what system they used, the date parameters, and the number of records in each report. | | Attachments | Files that were added to requests. | | Manifest | Digital signatures for the reports and attachments. | Notes - You can use the Request ID column to connect the data to the relevant request. - Attachment names are formatted as `Request ID-###-Original Filename`, where ### is the number of attachments related to that request. This allows auditors to easily reconcile files to the related request in the order they were posted. You can download reports for [single](#generating-reports-for-a-single-request) or [multiple](#generating-reports-for-multiple-requests) requests that use your EAM profile or are on a system you administer. ## Generating Reports for a Single Request 1. Select **EMERGENCY ACCESS NEW** to view the EAM Dashboard. 1. Go to the Completed tab and select the **Actions** menu dropdown next to the request you want to report on. 1. Select **Perform Review**. 1. Select **Report**. You will be redirected to the Reports tab of the Activity History page. 1. When the EAM reports package has finished generating, select **Download** to download the .zip file. ## Generating Reports for Multiple Requests 1. Select **EMERGENCY ACCESS NEW** to view the EAM Dashboard. 1. Select **Reports** in the upper-right corner. 1. Set the dates and times to include emergency access requests made during that period. 1. Specify the time zone used to determine the bounds of the audit reports. 1. Select **Submit**. You will be redirected to the Reports tab in Activity History. 1. When the EAM reports package has finished generating, select **Download** to download the .zip file. # Managing Profiles After you have created an EAM profile, you can complete the following actions from the Emergency Access Profiles page: - Add another profile by selecting the **+ New** button. - Edit an existing profile by selecting the **Edit** icon . - Delete an existing profile by selecting the **Delete** icon . Warning You cannot retrieve a deleted profile. SailPoint recommends deactivating the profile instead, which will prevent new requests for the profile. To deactivate a profile, clear the **Enabled** checkbox on the EAM profile page. - [Export profile Change Logs](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/export_log.html). - [Create or manage Reason Codes](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/reason_codes.html). # Provisioning Entitlements When a request is approved, Access Risk Management schedules a provisioning request. If the Requestor or Owner [selected a start time](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_view/index.html#creating-an-eam-request) in the request, provisioning will be scheduled at that time. Requests without a specified start time will schedule provisioning immediately. Access Risk Management validates the access has been provisioned as expected by checking the entitlements assigned to the Requestor. If provisioning is successful, the Requestor receives an email notification and a countdown timer is started for the duration selected when the request was created. If the validation check finds that no access was provisioned or if the ERP system returned an error, Requestors receive an email notification that the entitlements failed to provision, and the request is flagged as faulted and must be [resolved and restarted](#resolving-provisioning-errors). ## Resolving Provisioning Errors Requests with errors are displayed in red on the EAM Dashboard. You can [change your view](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html#error-toggle) to display only requests with errors. Approvers, Owners, or Administrators can expand the Actions dropdown menu next to the failed request and select **Restart Provisioning**. If the provisioning continues to fail, contact your ERP system security administrators to identify and resolve the cause of the provisioning error. If the validation discovers that provisioning was partially successful and some entitlements were granted, the request continues as normal so the Requestor's actions are logged and reviewed in a timely manner. Entitlements that failed to provision will be noted in the Request History logs. # Creating and Maintaining Reason Codes Emergency Access Profile Administrators can create a predefined list of Reason Codes. Reason Codes serve as the rationale or purpose for why a specific EAM Profile needs to be used. You can use reason codes to quickly [filter requests](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html#filtering-requests) on your EAM Dashboard or to classify requests for later reporting purposes. 1. Select **Manage Reason Codes > New Reason +** to create a new reason code. 1. Enter a meaningful name and description for the reason code to differentiate it from others. 1. Select **Submit** to create the reason code. Requestors will now use this reason code when they submit requests. If Requestors need to include more information for why they need elevated access, they can add additional text to the **Intention** box of new requests. After a request is submitted, they can include additional explanation by selecting the **Comment** icon on the Reviewer Dashboard or within each tab on the EAM Dashboard next to each request on the page. You can also manage or edit this reason code by selecting the **Manage Reason Codes** button on the Emergency Access Profile page. Select the **Edit** icon next to the appropriate reason code in the Manage Reason Codes window. # Removing Access Access can be deprovisioned automatically after the duration specified when creating the request, or it can be [terminated early](#terminating-access-early) by the Owner, Requestor, Approver, or Administrator. Access Risk Management runs an additional validation check after the ERP system provides a successful deprovisioning response to ensure that all access has been successfully removed. If access is not successfully deprovisioned, you can [resolve errors](#resolving-deprovisioning-errors) and restart the deprovisioning. ## Terminating Access Early If a Requestor has finished their work early, or an Owner, Approver or Administrator want to revoke access before the scheduled end date of the request, they can manually terminate the elevated access early. Users can go to the Active tab of the EAM Dashboard, expand the **Actions** menu next to the request, and select **Terminate Access**. This will immediately revoke the Requestors' access to the elevated entitlements and Access Risk Management will begin collecting usage data. The [data collection progress](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/extract_usage.html) is displayed on the Data Collection tab of the EAM Dashboard. ## Resolving Deprovisioning Errors An Approver, Owner, or Administrator can restart the deprovisioning process by expanding the **Actions** menu and selecting **Restart Deprovisioning**. If deprovisioning continues to fail, contact your ERP system security administrators to identify and resolve the cause of the deprovisioning error. When an automated deprovisioning attempt fails, the request is flagged as faulted and EAM profile Attestors are notified by email to certify that access was successfully deprovisioned. ## Attesting Removed Access If a review must be completed before the cause of the deprovisioning error is resolved, Attestors serve as an emergency backup to provide a manual confirmation that the Requestor used the access appropriately. They can also attest that no access was used if a [utilization extract is blank](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/resolve_usage.html#attesting-blank-extracts). When a deprovisioning error occurs, Attestors will: 1. Go to the Active tab of the EAM Dashboard. 1. Select the **Actions** menu next to the request. 1. Select **Attest Deprovisioning** 1. Submit a [comment](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_add_comments.html) with an attachment to use as audit evidence that deprovisioning occurred. This step is mandatory to ensure an accurate request duration is recorded. # Resolving Usage Data Collection Errors If there is an error collecting usage data, the requests will be marked in red on the Data Collection tab of the EAM Dashboard. You can [change your view](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html#error-toggle) to display only requests with errors. Select the **Request Snapshot** icon to view request details. Reviewers, Owners, Attestors, and Administrators can expand the Actions dropdown menu next to the request and select **Restart Data Collection** to try the process again. If data collection fails repeatedly, contact your ERP system administrators and Access Risk Management agent configuration owners to identify the cause. ## Attesting Blank Extracts When a successful utilization extract contains zero line items, the request is flagged as faulted and the configured EAM profile Attestors are notified by email. This serves as an additional control to prevent Reviewers from performing a review of an inappropriately blank utilization extract. Attestors will certify that access was not used by the Requestor and that the extract is appropriately blank on the Active tab of the EAM Dashboard by expanding the **Actions** menu next to the request and selecting **Attest Blank Extract**. Important If a Requestor *did* use the access, the Attestor should work with an Access Risk Management administrator or [SailPoint Support](https://community.sailpoint.com/t5/Working-With-Support/ct-p/WorkWithSupport) to troubleshoot why the extract was blank. # Reviewing Usage Data When Access Risk Management has successfully collected data on how access was used, Reviewers will receive an email notification to begin their review. Reviewers will use the Reviewer Dashboard to view the Requestor's actions, leave [comments](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_add_comments.html), and decide to [Accept](#accepting-access-usage) or [Contest](#contesting-access-usage) the usage. Reviewers can access the Reviewer Dashboard by selecting **View Request** in the review email notification or selecting the Review tab in the EAM Dashboard, expanding the **Actions** menu next to the request, and selecting **Perform Review**. The Reviewer Dashboard displays the review state as well the [Request Details](#viewing-request-details) and [Change Details](#viewing-change-details), which include information about the request and actions taken. ## Viewing Request Details The Request Details tab in the Reviewer Dashboard displays metadata about the request and usage reports, key events, and a table of the Requestor's actions. - **Request Metadata** includes the Access Profile, intention, reason for the request, and the duration and type of entitlements granted to the Requestor. - **Report Metadata** is information about the report provided to the Reviewer, such as the counts of Utilization Data and Change Logs, as well as the times the report generation began and completed. - **Key Events** is a list of the request's key events, such as when it was created and approved, and when the entitlements were provisioned and deprovisioned. - **Actions Table** displays information on all actions the Requestor took during the period of elevated access, including if it was sensitive, non-sensitive, elevated, or standard. You can select the **Filter** icon in a column header to filter using the selected parameters. ## Viewing Change Details The Change Details tab on the Reviewer Dashboard displays a list and details of the available records of actions, such as the: - Change Number and Indicator - Document Type and ID - User ID - Client - Names and descriptions of Transactions, Fields, and Tables ## Accepting Access Usage If the Reviewer confirms the Requestor used the elevated permissions appropriately, they will select **Accept** in the Reviewer Dashboard. They can choose to enter a comment before selecting **Confirm** to finalize the review. The request will display on the Completed tab of the EAM Dashboard with a disposition of Closed as Accepted. All participants of the request can view the review report by expanding the Actions dropdown menu next to the request and selecting **Open Review**. ## Contesting Access Usage If the usage was not appropriate or the Reviewer would like clarification from the Requestor, they will select **Contest** in the Reviewer Dashboard and enter their reasoning. This explanation is sent to the Requestor in the email notifying them their request was contested and they must provide a formal response. The Requestor will write a [comment](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_add_comments.html) to clarify the actions and retain documentation for auditors. Reviewers and Requestors are notified of responses, and all users configured on the EAM profile can read and submit comments on contested requests. Once the Reviewer is satisfied or the process is otherwise completed, they will select **Close** and choose **Close as Accepted** or **Close as Contested** to finalize and close the review. Closed reviews are displayed on the Completed tab of the EAM Dashboard. All participants of the request can view the review report by expanding the Actions dropdown menu next to the request and selecting **Open Review**. # Selecting Profile Entitlements You can use profile entitlements to control the elevated access that users temporarily receive from approved requests. Warning Entitlements that are included as part of a profile can *not* be assigned to users as part of their standard access. The system will automatically deprovision entitlements from the user that are part of a profile. **To add profile entitlements:** 1. Select **+ Add Entitlements**. 1. Add entitlements individually by selecting the **+** icon next to an entitlement. Select **Add All +** to add all entitlements to the profile. You can also add entitlements by entering entitlement names separated by commas or lines and selecting **+ Add**. To remove an entitlement from the profile, select the **Delete** icon next to the entitlement on the Emergency Access Profile Details page. Important If an entitlement is updated, these changes will only apply to future requests. Existing requests must be [retracted](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_view/index.html#retracting-eam-requests) or rejected to reflect the updated entitlements. If you want to include a role that is [blocked](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/block_sap_users_roles.html), first, manually schedule a one-time [Security Extract](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_security_extract.html). Manually scheduled Security Extracts ignore the block list. Once a Security Extract is available that includes all roles, all roles will be available tor use with emergency access management. # Selecting Profile Users For each EAM profile, you can define the users who will serve as the Profile Owners, Requesters, Approvers, and Reviewers for elevated access requests associated with the profile. Note Any Access Risk Management users that have been deleted from your tenant will automatically be removed from the profile since they are no longer valid to be assigned to a profile. You can view these deletions in the profile change logs, along with any other changes that have been made. ## Profile Owners Profile Owners maintain and update profiles by managing entitlements and request participants. Profile Owners can also submit requests for Requestors, perform troubleshooting actions to restart processes, and [export change logs](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/export_log.html) of profiles they own. 1. Select **+ Add Users**. 1. Select the **+** icon next to a user to add the user as an owner. Select **Add All +** to add all users. Notes - You must include at least one Profile Owner for each profile. - While a Profile Owner can submit requests for Requesters, they cannot submit a request for their own User ID. ## Requestors Requestors are users who require temporarily elevated access. Requestors can only submit requests for themselves. If Requestors finish their tasks before their access ends, they can [terminate their access early](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/removing_access.html#terminating-access-early). Note A Requester's Access Risk Management **ERP User ID** field must be populated with their ERP User ID, so the system knows which user should get the access. Refer to [Adding Users](https://documentation.sailpoint.com/access-risk-mgmt/help/users/index.html#adding-users) for more information. 1. Select **+ Add Users**. 1. Select the users who can request elevated access within the application. You can add users individually by selecting the **+** icon or add all users by selecting **Add All +**. Notes - You must include at least one Requestor for each profile. - A Requestor cannot be added to another role *within the same profile*. This prevents users from bypassing the process to obtain elevated access. If you select **Add All +**, you'll receive a list of users who could not be added due to such conflicts . 1. (Optional) Select the **Pre-Approved** checkbox to skip the *approval* stage for giving access to those requesters. The *review* step will still be required to ensure those privileges are not abused. Note If a requestor is added to an EAM profile and an EAM request is created prior to a new security extract being completed, the requestor's utilization report will show all actions as Elevated on the Reviewer report dashboard. This is because the system does not yet know the updated actions available to that user as part of their standard assigned entitlements. You can select **Schedule Jobs > Security Extract > Submit** to trigger a security extract job to populate the user's standard permissions. ## Approvers Approvers approve or reject individual requests by email or within the EAM Dashboard. Approvers can also restart [provisioning](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/provisioning_entitlements.html#resolving-provisioning-errors) or [deprovisioning](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/removing_access.html#resolving-deprovisioning-errors) if the initial attempt fails. 1. Select **+ Add Users**. 1. Select the users who can approve elevated access requests within the application. You can add users individually by selecting the **+** icon or add all users by selecting **Add All +**. Notes - You must select at least one Approver for each profile. - If multiple Approvers are assigned, all approvers will receive an email notification when a request is submitted. However, the decision will be based on the *first* Approver who responds. To prevent inappropriate access, Approvers can reject a request, even after approval and up until the elevated entitlements have been provisioned. They can also immediately revoke a Requestor's access to elevated entitlements. ## Reviewers Reviewers [examine](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html) the appropriateness of an approved Requestor's activity. They will receive an email notification to approve or contest the user's activity using the EAM Reviewer Dashboard. During the review process, Reviewers can leave [comments](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_add_comments.html) asking the Requestor to clarify why they took specific actions while they had elevated access. 1. Select **+ Add Users**. 1. Select users who will review the user's activity. You can add users individually by selecting the **+** icon or add all users by selecting **Add All +**. If multiple Reviewers are assigned, all Reviewers will receive an email notification when an activity report has been generated for an EAM Request. However, the decision will be based on the *first* Reviewer to perform the review. # Setting Attestors You can define which users will serve as *attestors* for each profile. Attestors are generally security administrators or compliance personnel who can attest if access was [deprovisioned correctly](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/removing_access.html#attesting-removed-access) in the event of automated deprovisioning failure, or whether a Requestor used permissions when a utilization extract is [blank](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/resolve_usage.html#attesting-blank-extracts). Under the **Who can attest?** section, select the checkboxes next to Owner, Approver, or Reviewer to enable those roles to attest. You can enable multiple roles to attest, and all users in the assigned roles will become attestors. Note You must select at least one role to become an attestor. You can now select the entitlements for the profile. # Setting Profile Details To configure the available permissions and request participants: 1. Select the **Menu** icon and choose **EAM PROFILES NEW**. 1. Select **+ New** to create a new profile. 1. Enter a meaningful profile name and description to differentiate the profile from others. 1. Select the rulebook associated with this emergency access. You may want to create more granular, profile-specific rulebooks to help reviewers determine which transactions should be considered sensitive. For more information, refer to [Managing Rulebooks](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/index.html). 1. Set the maximum amount of time the Requestor can request emergency access for. You can set the maximum duration for up to 7 days. 1. Select the **Profile is enabled** checkbox to enable the profile. You must enable a profile before it can become available to Requestors. After you've entered the profile's details, you can set the attestors for the new profile. # Submitting Profiles After you've finished selecting the appropriate users for each category, select **Submit** to create the EAM profile. Note You'll receive an error message if a user has conflicting access. For example, a user cannot be set as both a Requestor and Profile Owner *within the same profile*. You must fix any conflicting access before you can create the EAM profile. After you've configured your EAM Profiles, your assigned Requestors, Approvers, Reviewers, Owners, and Attestors will be able to [view the request](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html) as it moves through each stage on their EAM Dashboard. To access your EAM Dashboard, select **EMERGENCY ACCESS NEW** from the navigation menu. # Viewing and Adding Comments All users on the access profile can view, submit, and upload attachments to comments on requests they are assigned to. These allow request participants to communicate about the request and retain evidence for audit and compliance purposes. Note Comments are required when an Approver rejects a request or a Reviewer contests usage. To view comments, select the **Comment** icon next to the request in the EAM Dashboard or in the [Reviewer Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/extract_usage.html). Comments display the state and timestamp of the request when the comment was posted, as well as the Access Risk Management username and email of the author. ## Uploading Attachments Users can upload one attachment per comment. 1. Select the **Comment** icon next to the request in the EAM Dashboard or in the [Reviewer Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/extract_usage.html). 1. Enter your comment. 1. Select **Upload** and choose your file. File requirements - No more than 10 MB - .txt, .csv, .xls, .xlsx, .xlsm, .pdf, .png, .jpg, .jpeg, .bmp, .doc., .docx, .ppt, .pptx, or .zip 1. When you have completed your comment, select **Send**. # Viewing Request Progress Members of an access profile used for a request can view the request in the EAM Dashboard. As Requests move through each stage, the appropriate users on the profile are notified by email and can view the changes in the EAM Dashboard. Each tab displays a core phase of the request process: - Approval - Requests that are waiting for approval - Active - Approved requests that are scheduled to be provisioned, or are actively being provisioned or deprovisioned - Data Collection - Requests that have been deprovisioned and are waiting to extract data of how the Requestor used the entitlements - Review - Requests under review to determine if the permissions were used appropriately - Completed - Requests that have been rejected, retracted, or reviewed The number of requests in each stage is displayed in the parentheses in the tab headers. These numbers will change if you [filter requests](#filtering-requests). Note You may need to select the **Refresh** icon to display changes to emergency requests. ## Generating Reports You can generate and download a set of reports for a single or multiple requests to provide to auditors or enforce compliance. Refer to [Generating EAM Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/generate_reports/index.html) for more information. ## Customizing Your Dashboard Request information is by default displayed in the time zone configured in the user's browser. Users can change the time zone displayed on their personal EAM Dashboard by selecting **Timezone** and choosing a different time zone. You can reorder and resize columns by clicking and dragging the column headers. Column customizations are reset when the EAM Dashboard is refreshed. ## Filtering Requests The EAM Dashboard features multiple filters to help find requests and identify errors. **Filtering within columns** To filter requests within a column, select the **Filter** icon in an available column header and enter your parameters. Select **Filter** to set the filter, or **Clear** to remove filters in the column. **Filtering by metadata** You can select the metadata to filter requests by using the bar above the table. Enter your search term, select the data type from the dropdown list, and select the **Search** icon . Requests can be filtered by: | | | | | | | ----- | --------- | -------- | ------- | ----------- | | ID | Requestor | Reviewer | Reason | Entitlement | | State | Approver | Owner | Profile | Comment | **Filtering by Profile and Reason Code** You can also filter by Profiles and Reason Codes by selecting the fields and choosing the profiles or codes. To remove all filters, select **Clear Filters**. **Filtering by Errors** Select the button in the top right to toggle between displaying all requests, requests with errors, and requests without errors. This makes it easier to identify if a provisioning, deprovisioning, or data collection job needs to be restarted or attested. The text on the button indicates what is displayed in the table below. # Creating Emergency Access Profiles In order for users to request temporary emergency access, Emergency Access Profile Administrators must create and maintain EAM profiles. These profiles define what elevated access users can be granted and assigns users to the EAM request participant roles (Profile Owners, Approvers, Requestors, and Reviewers) that determine who can select the profile when [creating an access request](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_view/index.html#creating-an-eam-request), who will approve requests, and who will review a user's activity after they complete their tasks. EAM profile request participant roles also determine what actions are available to users on their EAM Dashboard as the request progresses. To get started, enter the name and details for your new EAM profile, then complete the following: 1. [Set Profile Details](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/set_profile_details.html) 1. [Set Attestors](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/set_attestors.html) 1. [Select Profile Entitlements](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/select_profile_entitlements.html) 1. [Select Profile Users](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/select_profile_users.html), including Profile Owners, Requestors, Approvers, and Reviewers 1. [Submit Profiles](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/submit_profiles.html) # Managing EAM Requests Before a user can be granted elevated access, a Requestor or Profile Owner must create an [EAM request](#creating-an-eam-request) and select an [EAM profile](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_profile/index.html) that defines the elevated access Requestors are granted if their request is approved. Submitted requests can be [viewed](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/view_request_progress.html) on the EAM Dashboard. You can [retract submitted requests](#retracting-eam-requests) that have not yet been provisioned. ## Creating an EAM Request To create an emergency access request: 1. Select **Emergency Access NEW** from the navigation menu. 1. Select **Create New Request +**. 1. Select an EAM profile you are marked as a Requestor or Owner for in the **Profile Name** dropdown list. The EAM profile defines who can approve requests and who can attest and review usage. 1. Choose a Requestor from the list of available requestors for the profile. Note A Profile Owner can only submit EAM requests on behalf of Requestors. They cannot request access for themselves to the profile they own and manage. 1. Set the length of time the Requestor will have the elevated entitlements. You can set this duration up to the maximum duration defined in the EAM profile. The default is 1 hour. 1. Select a [predefined Reason Code](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/reason_codes.html) that best explains why this access is needed. Tip Name your codes clearly and provide a list of codes to your Requestors to ensure they select the correct one. 1. Select when the access will be granted. The date defaults to the current date and time, but you can change this to submit a request for a future date or time. For example, if a user will need access during a weekend or holiday, they can submit the request in advance while the Approver is available. 1. (Optional) Select a time zone from the **Time Zone** dropdown list to change the time zone for the request to the Requestor's local time. 1. In the **Intention** box, enter additional information explaining why the request should be approved, or how the access will be used. Tip Establish a policy regarding what should be entered here, such as including helpdesk ticket numbers. 1. Select **Submit** to create the request. If the Requestor was [pre-approved](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/select_profile_users.html#preapproved) on the profile, the request will be automatically approved, and provisioning will occur on the selected date and time. This is displayed on the Active tab. The request will display on the Approval tab of the EAM Dashboard and be marked as Awaiting Approval. Approvers will receive an email notification that they have an EAM request to [evaluate](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/approve_reject_requests.html). ## Retracting EAM Requests If the requested entitlements have not yet been provisioned, Requesters, Owners, and Administrators can retract requests: 1. Select **Emergency Access New** to view the EAM Dashboard. 1. On the Approval tab, expand the **Actions** menu next to the request and select **Retract**. Retracted requests are displayed on the Completed tab of the EAM Dashboard. # Evaluating EAM Requests When a request is [created](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/create_view/index.html#creating-an-eam-request), an Approver is notified by email to evaluate whether the request should be [approved](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/approve_reject_requests.html). Approved requests are [provisioned](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/provisioning_entitlements.html) for the duration specified when the request was created, unless it is [terminated early](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/removing_access.html#terminating-access-early). Access is then [deprovisioned](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/removing_access.html) and the usage data is [extracted](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/extract_usage.html) for [review](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html). # Extracting and Reviewing Usage Data Access Risk Management extracts data of the Requestor's actions when they had elevated permissions. This data is used to generate a report Reviewers can use to whether they should [accept](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html#accepting-access-usage) or [contest](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/review_usage.html#contesting-access-usage) the usage. # Generating EAM Reports You can generate and export reports related to [emergency access profiles](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/export_log.html) and [requests](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/generate_reports.html) to manage compliance and provide to auditors. # Mitigating Controls Overview Mitigating controls are actions or business processes taken to reduce the risks introduced by users having conflicting access in a system. Mitigation is generally considered to be less desirable than remediation due to the maintenance, overhead, and traceability requirements of performing and auditing the mitigating control, but are an effective way to manage exceptions. Examples of mitigating controls include using configurable automated system controls, such as three-way match for accounts payable, or manual procedural controls, such as a manager review. Mitigating Controls are created at the customer level and can be applied to users across all your systems governed by Access Risk Management. These controls are then mapped to one or more risks and applied to one or more users through [mapping rules](https://documentation.sailpoint.com/access-risk-mgmt/help/mitigatingcontrols/manage_controls.html#mapping-rules-tab). Controls can be mapped to users at multiple levels: - All users for all systems - All users for a specific system - Specific users within a specific system # Importing or Updating Mitigating Controls Add or update mitigating control data and mappings to risks and users using the UI or by importing a spreadsheet. All changes are tracked in [Mitigating Controls Change Logs](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel/change_logs.html) ## Add or Update Mitigating Controls in the UI Manage mitigating controls in the UI for faster administration of small numbers of changes with ease and consistency, since validations are enforced automatically through a guided process. Notes can be added to mappings and rules to provide additional context for auditors. When you add or update mitigating controls in the UI, the Change Log entries include who made the changes and when. Metadata for controls and mappings shows Created By with the date and Last Modified By and the date. The Risks > Mitigating Controls UI includes three tabs for managing mitigating controls and mapping them to risks: [Mitigating Controls](#mitigating-controls-tab), [Risk Mapping](#risk-mapping-tab), and [Mapping Rules](#mapping-rules-tab). ### Mitigating Controls Tab From the Mitigating Controls tab, you can create new controls and edit existing controls, including all of the relevant text metadata and when the control should take effect or expire. **To create a new control:** 1. Go to **Risks > Mitigating Controls** and select the **Mitigating Controls** tab. 1. Select the **Create Control +** button. 1. Define details about the control: - **Control Code** - Unique identifier for the control. - **Name** - Name of the control. - **Description** - Description of the control. - **Valid From** (optional) - Starting date when the control is valid. - **Valid To** - End date, when the control is no longer valid. - **Last Tested** (optional) - Date when the control was last tested. - **External Link** (optional) - Link to your internal audit application where you have documentation specific to this control. - **Control Objective** (optional) - Business objective that the control serves. - **Test Plan** (optional) - Plan for testing the control. - **Control Type** - Type of control, whether manual or automatic, preventative or detective. - **Frequency** - How often the control should be executed, such as weekly, monthly, or ad hoc. - **Primary and Secondary Owners** - Name of the person or persons who are designated owners of this control. There must be at least one owner assigned to each control. - Select **+ Add Primary Owners** or **+ Secondary Owners**. - In the modal, select **+** to add individuals or **+ Add All** to add all as owners. At the bottom of the window, you can add a comma-separated or line-separated list of usernames and select **+ Add** to add multiple owners at once. - Select **X** to close the modal. 1. Select **Close** (without saving), **Save**, or **Save and Add Risk Mapping**. **To edit or view an existing control:** 1. Locate the control you want to edit by scrolling, searching, or filtering. 1. Select an option from the **Actions** dropdown. - **Enable / Disable Mitigation** - Enable or disable this mitigating control, including any associated user mappings. Note When a mitigating control is disabled, its row is shaded red indicating that no associated risks or users will be identified as mitigated for either What If Simulations or Risk Reports. - **View Risk Mappings** - View risks that this control is currently mapped to. - **View Mapping Rules** - View the mapping rules for this control. - **Add Risk Mapping** - Map a risk to be mitigated. - **Edit Control** - Update fields such as description, objective, and owners. - **Disable Risk Mappings** - Stop allowing this control to be mapped to new risks or users, but without impacting existing risk and user mappings. **To delete an existing control:** 1. Locate the control you want to delete by scrolling, searching, or filtering. 1. In the Actions column, select the **Delete** icon . ### Risk Mapping Tab From the Risk Mapping tab, you can manage how mitigating controls are mapped to the specific rulebook risks that they mitigate. **To start a new mapping of a mitigating control to risks that are associated with a selected rulebook:** 1. Go to **Risks > Mitigating Controls** and select the **Risk Mapping** tab. 1. Select **Create Risk Mapping +**. 1. From the **Mitigating Control** dropdown list, select a control code. 1. Select a Rulebook. Note You can only add risks from one rulebook at a time. 1. Select **+ Add Risks**. 1. In the Risks Selection modal, scroll, search, or filter to locate the risks you want to map to the selected control. 1. Select **+** to add individual risks or **+ Add All** to add all risks in this rulebook. At the bottom of the window, you can add a comma-separated or line-separated list of risks and select **+ Add** to add multiple risks at once. 1. Select **X** to close the modal. 1. Select **Save** to save the control to risk mapping, **Save and Add Mapping** to proceed to add user mappings, or **Cancel**. **To edit or view an existing risk-to-control mapping:** 1. Locate the risk mapping you want to edit by scrolling, searching, or filtering. 1. Select an option from the **Actions** dropdown. - **View Mapping Rules** - View the rules applied to this mapping. - **View Mitigating Control** - View the mitigating control applied to this mapping. - **Add Mapping Rule** - Add a mapping rule to control how this mapping applies to users. - **Edit Risk Mapping** - Modify the notes for a mapping, then select **Save** to save a draft, **Save and Add Mapping**, or **Cancel**. **To delete an existing risk-to-control mapping:** 1. Scroll, search, or filter to locate the risk mapping you want to delete. 1. In the Actions column, select the **Delete** icon . ### Mapping Rules Tab On Mapping Rules tab, you can provide logic for how a control-to-risk mapping applies to users. You can create a logic rule that either mitigates all users for one or more systems, or specific users for one system at a time. **To create a mapping rule:** 1. Go to **Risks > Mitigating Controls** and select the **Risk Mapping** tab. 1. Select **Create Mapping Rule +**. 1. Use the **Control–Risk Mitigation** dropdown to select a control–risk mapping to apply. 1. Select a Mitigation Logic Rule Type: - **All Users** - Applies to all users. Use this option when a risk is not applicable to a given system or globally across all systems. - **Specific Users** - Applies only to selected users. Use this option when a risk should only be mitigated for certain specific users. 1. Select the system(s) that this rule applies to. Note If your rule is for specific users, you can only select one system. 1. If your rule is for Specific Users, select **+ Add Users** and add those users to the User Selection list. 1. Enter notes (optional) to add context and clarity for future audits. 1. Select a Valid To date (optional) to have the mapping logic rule expire after a given date. Note This differs from the Valid To Date at the Control level which expires all mapping rules. **To edit or view a mapping rule:** 1. Locate the mapping rule you want to edit by scrolling, searching, or filtering. 1. Select an option from the **Actions** dropdown. - **View Mitigating Control** - View the mitigating control applied to this mapping. - **View Risk Mappings** - View risks that this control is currently mapped to. - **Edit Mapping Rule** - Modify the notes and valid to date for this mapping rule, then select **Save** or **Close**. ## Import or Update Mitigating Controls via Spreadsheet Manage mitigating controls by importing a spreadsheet when you need to make a large amount of updates at once. 1. Go to **Risks > Mitigating Controls**. 1. If you need to add mitigating controls for the first time, download the Excel template. Select **Import**, then **Download Template**. 1. If you need to update or add to the mitigating controls that are already in your system, download them in a spreadsheet by selecting **Export**. 1. Update the spreadsheet and save your changes. Caution Importing mitigating controls performs a full overwrite of all existing mitigating controls, control owners, and mappings. Make sure that all entries are present in your spreadsheet or they **will be deleted**. - In the provided Excel template, each column has an explanation of what information belongs there. Select a cell to view the explanation. - Any field that requires an enumerated value has data validation. Dropdowns will only allow you to select a permissible value. - For each control, you can specify a Valid From and a Valid To date; this allows you to manage when a control should take effect and when it should expire. Valid To dates are required, but Valid From dates are optional. When there is no Valid From date, the control takes effect the day it is added. Note No users will be mitigated for controls with a Valid From date in the future until that date is reached. No users will be mitigated for controls with a Valid To date in the past. - You can create a control that is not activated by setting the Is Enabled value to FALSE. No users will be mitigated until Is Enabled is set to TRUE. - Control to risk mapping and risk to user mapping is combined on the Mappings sheet. You need to repeat the Control Code, Rulebook Name, and the Risk Code for each mapping rule that you create. - Once you add a single mapping rule for a given control and risk, then the system will automatically create the relationship between the control and the risk when it’s imported. - On the Mappings tab, you can only select a control that has already been entered on the first tab. - The Rulebook Name must be entered exactly as it appears in the Access Risk Management UI. - The Risk Code must exist in the specified rulebook. - The Type column determines whether the mapping rule will be applied to all users or specific users. - The System Name must be entered exactly as it appears in the Access Risk Management UI. - For mapping rules of Type ‘All Users,’ you may either specify a single system in the System Name column to restrict the mapping to only that system, or, if you leave the System Name column blank, the mapping will apply to all of your systems governed by Access Risk Management. - For mapping rules of Type ‘All Users,’ you must leave the Attribute and Value columns blank. - For mapping rules of Type ‘Specific Users,’ you must specify the Attribute value as ‘ERP_SYSTEM_USER_ID’ at this time. Additional Attribute values may be supported in future releases. - The Value column should only be populated for mapping rules of Type ‘Specific Users’ and must exactly match the username of the user to be mitigated from the specified ERP system. - Control Owners is a separate tab in the spreadsheet. You may set more than one user to be the Primary owner, but you must set at least one. Any user specified here must exist in the Access Risk Management application. - Specifying a Valid To value on the Mappings tab causes the mapping rule to expire after the specified date. 1. Select **Risks > Mitigating Controls** to return to the Mitigating Controls - Maintenance page and select **Import**. 1. Use **Select Files** to add your saved .xlsx file. 1. Select **Upload**. Note There may be a gap of up to 30 minutes between the time you upload the spreadsheet and the Mitigations Report being updated with the new data. You can also apply a mitigation when performing a What If Analysis. Refer to [Applying Mitigations](https://documentation.sailpoint.com/access-risk-mgmt/help/review_fiori_whatif.html#applying-mitigations). After uploading a spreadsheet, you are taken to **Activity History > Data Imports**. ### Mitigating Controls Data Validation For tenants where Access Risk Management Validation Service is enabled, your uploaded mitigating controls file is validated against predefined validation rules. On the **Activity History > Data Imports** page, locate the mitigating controls file that you uploaded. Initially, it will have the status Uploaded. Validation may take up to several minutes to complete. As you refresh the screen, the status will move from Uploaded to Validating to either Validation Passed or Validation Failed. Once the validation has passed or failed, the Result column includes the data validation outcome. When there are errors, you can select **View Result** in the Action column to view the data issues that caused the failure. Results include the recommended action for resolving the failure. # Managing Mitigating Controls The Mitigating Controls – Maintenance page is found by selecting **Risks > Mitigating Controls**. Three elements of Mitigating Controls information are available on different tabs: [Mitigating Controls](#mitigating-controls-tab), [Risk Mapping](#risk-mapping-tab), and [Mapping Rules](#mapping-rules-tab). Options in the Actions dropdowns let you trace a control’s risk mapping and mapping rules. To view these for all of your controls, select the Risk Mapping or Mapping Rules tab below the search field. Use the search field at the top of the page for a global search of all fields within the active tab. The column headers offer more advanced filtering options. Select **Import** at the top right to [import or update your controls](https://documentation.sailpoint.com/access-risk-mgmt/help/mitigatingcontrols/add_update_controls.html) and **Mitigations Report** to view the online [Mitigations Report](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_mitigations_reports.html). ## Mitigating Controls Tab The Mitigating Controls tab lists the controls themselves. The dropdown in the Action column has a Disable / Enable Mitigation toggle to disable or enable a specific control. Note that disabling a control does not remove the risk mapping. The mapping still exists, but will not be considered when evaluating mitigations during a risk analysis (e.g., when you generate a report or run a What If simulation) unless or until the control is enabled. The Mitigating Controls tab includes: - **Control Code** – Unique identifier for the control. - **Name** – Name of the control. - **Control Type** – May be automated or manual, preventative or detective. - **Description** – Description of the control. Select to view or copy the full text. - **Valid From / To** – Boundary dates between which the control should be evaluated during a risk analysis. - Valid From may be left blank or may be dated in the past or future. - If you set a Valid From date in the future, the control can be entered and users mapped to it, but it will not take effect until the Valid From date. - A Valid To date is required. It may be set for a year, if that is how often you review your controls, or it may be set longer or shorter as needed. - If you set a Valid To date in the past, the control can be entered and users mapped to it, but it will not take effect. - **Enabled** – Indicates True if it is enabled or False if it is not enabled. Anyone mapped to the control will not be mitigated during a risk analysis until it is enabled, or set to True. - **External Link** (optional) – Link directly to your internal audit application where you have documentation specific to this control. - **Frequency** – How often the control is executed, such as weekly, monthly, or ad hoc. - **Last Tested** (optional) – Date the control was most recently tested. - **Owner(s)** – Name of the person or persons who are designated owners of this control. There must be at least one owner assigned to each control. When there is more than one owner, the names can be selected to view a complete list. - **Created By** – Access Risk Management username of the person who created the control. - **Created Date** – Date the control was created. - **Last Modified By** – Access Risk Management username of the person who last modified the control. - **Last Modified Date** – Date of the most recent changes. ## Risk Mapping Tab On the Risk Mapping tab, you can view how controls are mapped to the specific risks that they mitigate. One control can mitigate numerous risks and multiple controls can be applied to the same risk. Mapping remains in place when a control is disabled; however, the control is not evaluated during a risk analysis unless it is reenabled or the Valid To date is extended. The Risk Mapping tab includes: - **Control Code** – Unique identifier for the control. - **Rulebook Name** – Rulebook that contains the risk to be mitigated. - **Risk Code** – Identifier for the risk mitigated by the control. - **Mitigated Risk Notes** (optional) – Additional information about the mitigated risk. ## Mapping Rules Tab On the Mapping Rules tab, you choose the specific entities that are mitigated. You can mitigate all users for one or all systems (All Users rule type) or specify an individual user that is mitigated (Specific Users rule type). The Mapping Rules tab includes: - **Control Code** – Unique identifier for the control. - **Rulebook Name** – Rulebook that contains the risk to be mitigated. - **Risk Code** – Identifier for the risk mitigated by the control. - **Rule Type** – All Users or Specific Users. - **ERP System Name** – System the mapping rule applies to. This will be blank if the rule applies to all systems. - **Mapping Attribute** – Blank, if applied to all users, or ERP_SYSTEM_USER_ID for specific users. - **Attribute Value** – The specific value for the attribute that the rule applies to. For example, if your mapping attribute is ERP_SYSTEM_USER_ID, then the attribute value would be a system user’s ID, their exact SAP username. This field is blank when you use the All Users mapping rule type. - **Valid To** (optional) – End date for the mapping rule itself for a specific user or for all users. This does not impact any of the other mapping rules or the control. - **Mitigated Entity Notes** (optional) – Additional information about the mitigated entity. # Viewing Mitigations in a Risk Analysis Once Mitigating Controls and Mapping Rules have been created, these will automatically be evaluated as part of any risk analysis, including for SoD / Sensitive Access reporting or What If simulations. 1. Run a [Security Extract](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_security_extract.html) and [Utilization Extract](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_utilization_extract.html) to provide data. 1. Make sure that you have a multi-system [Rulebook](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/index.html) in place, which defines the risks. 1. Upload [Mitigating Controls](https://documentation.sailpoint.com/access-risk-mgmt/help/mitigatingcontrols/add_update_controls.html), which defines exceptions that may be allowed and the circumstances for each. # Using What If Analysis A What If analysis simulates the impact to access risks, including separation of duties (SoD) or sensitive access, that would occur if you give or remove permissions from users, roles, or composite roles. For example, you may use the User What If analysis to determine whether assigning multiple roles would introduce new risks or if removing a role would eliminate them. This provides risk insights for decision makers. Logs of these simulations can serve as audit evidence to demonstrate that the access request process is compliant with applicable control frameworks. Refer to [Using Fiori What If](https://documentation.sailpoint.com/access-risk-mgmt/help/whatif/fiori_whatif/index.html) or [Using What If with SAP ERP Systems](https://documentation.sailpoint.com/access-risk-mgmt/help/whatif/sap_whatif/index.html). # Using Fiori What If You can complete a user, single role, or composite role What If analysis for any SAP ECC or S/4 system with Fiori. A user What If analysis helps you understand the impact of role assignment changes by identifying any access risk changes that would arise from assigning or revoking one or more roles for one or more users. A user What If analysis is automatically generated when creating an Access Request through Identity Security Cloud or IdentityIQ if you have configured the integration with Access Risk Management. A single role or composite role analysis helps you understand the risk implications for user impacts, which consider risks based on all user role assignments, and role impacts, which consider all inherent risks within each single and composite role based on the role composition changes. A single role What If analysis simulates adding one or more new transaction codes and authorizations to a given single role. A composite role What If analysis simulates adding or removing one or more single roles from a given composite role. Refer to [Creating a What If Simulation](https://documentation.sailpoint.com/access-risk-mgmt/help/create_fiori_whatif.html). # Using What if with SAP ERP Systems Caution This document describes the legacy What If Analysis feature. Refer to [Fiori What If Analysis](https://documentation.sailpoint.com/access-risk-mgmt/help/whatif/fiori_whatif/index.html) for details about the latest What If Analysis feature. If you use a SAP ERP system, you can [schedule a What If analysis](https://documentation.sailpoint.com/access-risk-mgmt/help/schedule_whatif.html) by type and then [review analysis results](https://documentation.sailpoint.com/access-risk-mgmt/help/review_whatif_results.html). There are three types of What If analyses: - User - Single role - Composite role ## User What If Analysis A What If analysis for a user identifies any SoD conflicts that may arise from assigning the user one or more roles so you can understand the impact of role assignment changes. A user What If analysis is automatically generated when creating a provisioning request through Identity Security Cloud or IdentityIQ. ## Single Role What If Analysis A What If analysis for a single role simulates the effect of adding or removing transaction codes and authorization objects from a role. This helps with understanding how a change in transaction code assignments to a role can affect SoD conflicts. Many organizations use this as part of their change management processes to gain risk insight early in the role change process. ## Composite Role What If Analysis A What If analysis for a composite role is similar to the What If analysis for a single role except this analysis shows the impact of changing the single roles in an existing composite role. If composite roles are a significant part of your role design, we recommend you include this simulation in your role management and change management processes as well. # Scheduling a What If Analysis To see the results of the simulations of different actions taken on users, single roles, and composite roles, you will need to set up and schedule an analysis. ## Scheduling a User What If Analysis You can schedule a What If analysis for one or more users to simulate the SoD conflicts that could occur based on a specific role assignment. You can select the rulebook(s), users, and roles when you schedule the analysis: 1. Select **WHAT IF ANALYSIS** from the left menu and choose **USER**. 1. Name the analysis. 1. Select the field under **Rulebooks** and choose the rulebook(s) you want included in this analysis. 1. Use the **Security extract** dropdown menu to choose the security tables to use in the analysis, based on the date they were pulled. This defaults to the most recent extract. 1. Use the **Role SAP System** dropdown menu to select the environment to run the analysis in. This defaults to the same system you are currently working in and shows how roles from other connected systems will give access to users. This is commonly used when creating a new role in a non-production system to test the access the user will have in the production environment. 1. Use the **Role Security Extract** dropdown menu to choose the security extract to select roles from based on the date they were pulled from SAP. This defaults to the most recent extract. 1. Under **Users Selection**, you can choose to simulate a new user or add one or more users to the simulation. 1. To simulate a new user without any roles associated, select the checkbox next to **Simulate New User**. 1. To add existing users, select **+ Add Users** to see the Users Selection window. Here you can: - Filter users by username, full name, user group, and user type. - Search for users. - Add all users by selecting **Add All +**. - Specify the user(s) you want to include by selecting the **+** next to each username. - Add users by entering a comma- or line-separated list of UserIDs and selecting **+ Add**. When you have finished your user selection, select **X** to close the window. 1. Use the **Roles Selection** section to specify the role changes to simulate by removing existing roles and/or adding new roles to the users you've selected. - **Remove Existing Roles** - Select what roles to remove from the selected users. - **Add Roles** - Select what roles to give the selected users. Important You must select users before you can assign or remove roles. If you add or remove a user after selecting roles, all roles will be cleared. To remove roles, select **Clear** to remove all selected roles or use the **Delete** icon to remove individual roles. 1. When you're ready to run the analysis, select **Schedule**. The [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-activity-history) page displays the analysis for you to view or download. See how to [review the user results](https://documentation.sailpoint.com/access-risk-mgmt/help/review_whatif_results.html#viewing-user-what-if-analysis). ## Scheduling a Single Role What If Analysis You can schedule a What If analysis for a single role to simulate the SoD conflicts that could occur based on the transaction code and/or authorization object assignments to a role. To generate a report on the impact of adding transaction codes and authorization object assignments: 1. Select **WHAT IF ANALYSIS** and choose **SINGLE ROLE**. 1. Enter a name for your analysis or keep the generated one. 1. Use the **Security extract** dropdown menu to choose the security tables to use in the analysis, based on the date they were pulled. This defaults to the most recent extract. 1. Select the field under **Rulebooks** and choose the rulebook(s) you want included in this analysis. 1. Use the dropdown menu under **SAP Role** to select the SAP role you want to simulate by adding new TCodes and objects. 1. Select **+ Add TCode** and choose a transaction code from the dropdown menu. This will automatically fill in the object, field, and value/range. You can delete the automatically provided objects, fields, and values/ranges by selecting the **Delete** icon . 1. Add additional TCodes, authorization objects, and/or field values to simulate how they will affect the role. 1. When you're ready to run the analysis, select **Schedule**. The [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-activity-history) page displays the analysis for you to view or download. See how to [review the role results](https://documentation.sailpoint.com/access-risk-mgmt/help/review_whatif_results.html#viewing-single-role-what-if-analysis). ## Scheduling a Composite Role What If Analysis You can schedule a What If analysis for a composite role to simulate the SoD conflicts that would occur when you add or remove a single role from that composite role. To generate a report on the impact of deleting existing roles or adding roles to a composite role: 1. Select **WHAT IF ANALYSIS** and choose **COMPOSITE ROLE**. 1. Enter the name for your analysis or keep the generated one. 1. Use the **Security extract** dropdown menu to choose the security tables to use in the analysis, based on the date they were pulled. This defaults to the most recent extract. 1. Select the field under **Rulebooks** and choose the rulebook(s) you want included in this analysis. 1. Use the dropdown menu to select an existing composite role. 1. Use the dropdown menu under **Composite Role** to select the role(s) you are simulating changes to. 1. In the **Roles Changes** section, remove existing roles and/or add roles to simulate what could happen when those roles are removed or added from a composite role. 1. When you're ready to run the analysis, select **Schedule.** The [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-activity-history) page displays the analysis for you to view or download. See how to [review the role results](https://documentation.sailpoint.com/access-risk-mgmt/help/review_whatif_results.html#viewing-composite-role-what-if-analysis). # Reviewing What If Analysis Results To view user, role, and composite role What If results, select **View** next to your analysis in [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html#viewing-activity-history) or go to **WHAT IF ANALYSIS > RESULTS** and select **View**. To download the analysis as an .xlsx file, select **Download**. Analysis results show a high-level summary view and the authorizations that make up the risk or role. You can also see the number of unmitigated risks for pre-existing conflicts and for new conflicts. Select the **Download** icon to download the report as an .xlsx. Select the **Comment** icon to add a comment about a specific item in the report or select the **Book** icon to see more granular information about the permission changes in the analysis. To return to the summary view from the detailed view, select the **Refresh** icon in the upper-right corner. ## Viewing User What If Analysis The User What If analysis identifies the risks that surfaced by changing a user's roles. This analysis shows these key data points: - **Risk rating** - The level of risk associated with the role assignment. - **Conflict Source** - Identifies if the risks are new or pre-existing. The three possible values are: - **Existed Before Changes** - The risk was already present based on the user's previous access. - **Caused By Changes** - This change introduces a new risk. - **Gone After Changes** - The user will no longer have the access that created this risk. - **Business Function Hits** - This shows a total of every single "hit," or authorization object, within the business functions. The different categories for the business function hits are: - **Existed Before Changes** - The user already had access to these authorizations. - **Caused By Changes** - The user will have these new authorizations if the proposed changes are applied. - **Gone After Changes** - The user will no longer have access to these authorizations if the proposed role changes are applied. Select the **Book** icon to see more information about the permissions, including the hit source, function code, object, field, and more. ## Viewing Single Role What If Analysis The single role What If analysis identifies the risks that surfaced by adding transaction codes to a role, including these key data points: - **Risk rating** - The level of risk associated with the transaction code assignment. - **Conflict Source** - Identifies if the risks are new or pre-existing. The two possible values are: - **Existed Before Changes** - The risk was already present based on the role's previous access. - **Caused By Changes** - The change introduces a new risk. - **Business Function Hits** - This shows a total of every single "hit," or authorization object, within the business functions. The different categories for the business function hits are: - **Existed Before Changes** - The role already had access to these authorizations. - **Caused By Changes** - The role will have these new authorizations if the proposed changes are applied. - **Gone After Changes** - The role will no longer have access to these authorizations if the proposed changes are applied. Select the **Role Reporting** tab to see more specific information about the rules and their effect on the roles. Select the **Book** icon on either tab for more information about the hit source, function code, object, field, and more. ## Viewing Composite Role What If Analysis The composite role What If results show changes to the inherent risk within the role and the impact on users when roles are removed or added from the composite. See the [Viewing Single Role What If Analysis](#viewing-single-role-what-if-analysis) for more details. # Creating a What If Simulation Create a What If simulation to simulate the access risk impacts that would occur based on role assignment changes. ## User What If 1. From the left navigation, select **What If Analysis**. 1. At the top right, select **Create New User Simulation +**. 1. On the Create New Simulation page, under **Rulebook**, use the dropdown to select which rulebook to run the analysis against. 1. In the **Users Selection** pane, you can choose to simulate a new user or add one or more existing users. Note The View Real Time Simulation option can be used for one user at a time. If you select more than one user, you can only schedule a technical report. - To simulate a new user without any roles associated, select the checkbox next to **New User**. - To add existing users, select **+ Add Users** to see the Users Selection window. Note The user(s) must exist in the currently selected Access Risk Management system. 1. If you selected + Add Users, use the Users Selection screen to: - Filter users by username, full name, user group, and/or user type. Select the **Filter** icon in the column you want to use, then add filter criteria. - Search for users by entering criteria in the Search field, then selecting the **Search** icon . - Add all currently displayed users with any applied filters by selecting **+ Add All**. - Specify user to include by selecting **+** next to individual username. - Add a mass set of users by entering a comma- or line-separated list of SAP UserIDs in the field at the bottom of the screen and selecting **+ Add**. Note The delimited list feature supports up to 100 items at a time. When you have finished adding users, select **X** to close the window. 1. Use **Roles Selection** to specify the role changes to simulate by removing existing roles and/or adding new roles to the users you've selected. - **Remove Existing Roles** - Select roles to remove from the selected users. - **Add Roles** - Select roles to give to the selected users. Important You must select at least one user before you can assign or remove roles. 1. If you selected Remove Existing Roles, use the Roles Selection window to remove roles by: - Filtering users by role name, username, role location, or description. Select the **Filter** icon in the column you want to use, then enter filter criteria. - Searching for roles by entering criteria in the Search field, then selecting the **Search** icon . - Adding all currently displayed roles with any applicable filters by selecting **Add All**. - Specifying role(s) to remove by selecting **–** next to individual role name(s). Note If you simulate changes to more than one user and a given role is assigned to more than one selected user, you will see a different entry for that role for each user it is assigned to. Be sure to inspect the Username column. When you have finished selecting roles, select **X** to close the window. 1. If you selected + Add Roles, use the Roles Selection window to add roles by: - Filtering users by role name, role location, and/or description. Select the **Filter** icon in the column you want to use, then enter filter criteria. - Searching for roles by entering criteria in the Search field, then selecting the **Search** icon . - Adding all currently displayed roles with any applicable filters by selecting **+ Add All**. - Specifying role(s) to remove by selecting **+** next to individual role name(s). - Add roles by entering a comma- or line-separated list of UserIDs in the field at the bottom of the screen and selecting **+ Add**. Note The delimited list feature supports up to 100 items at a time. When you have finished selecting roles, select **X** to close the window. 1. To remove users or roles from your lists, use the **Delete** icon to remove individual users or roles, or select **Clear** to remove all selected roles. Note The Role Change Type column shows Remove Role or Add Role for each role in your simulation. 1. Optionally, you can view a high-level summary of risks for a single user with a rapid response time by selecting **View Real-Time Summary**. 1. Optionally, schedule a detailed report including exportable results with role- and authorization-level details by selecting **Schedule Technical Report**. ### Running a User What If Analysis After setting parameters, you’re ready to run the analysis. Select **View Real-Time Summary** or **Schedule Technical Report**. View Real-Time Summary is a real-time, high-level risk summary, showing the risk level information, without authorization details, that the user would have after the role changes. From here, you still have the option to Schedule a Technical Report if you would like. Note Real-Time Summary results are not retained and are visible only when you run the simulation. You may screenshot the results or use the **Schedule a Technical Report** button if you need to retain evidence of the simulation for future compliance documentation purposes. Schedule Technical Report allows you to run a full analysis in the background that includes business functions, roles, profiles, and authorization details with an option to export a .csv file of the What If analysis results. This option redirects you to the Activity History dashboard where you can monitor job progress and access the results once the report is ready. You may also view or export the results at a later time by returning to the main grid of What If analysis where you initially scheduled the simulation. Note User What If analysis export is available as a .csv file only. [View](https://documentation.sailpoint.com/access-risk-mgmt/help/review_fiori_whatif.html) or [download](https://documentation.sailpoint.com/access-risk-mgmt/help/export_fiori_whatif.html) your analysis on the What If Analysis page. ## Role What If Create a What If simulation to assess the access risk impacts that would occur based on role composition changes. Single Role What If simulates adding permissions to a role. Composite Role What If simulates adding or removing single roles to or from the composite. 1. From the left navigation, select **What If Analysis**. 1. At the top right, select **Create New Role Simulation +**. 1. Select the type of simulation you want to run, either Single Role or Composite Role. Note A default name is provided, but best practice is to edit this name to include descriptive details so it's easy to reference this simulation at a later date. 1. On the Create New Single or Composite Role Simulation page, select the Analysis Selector **Edit** icon . 1. In the Analysis Selector modal, use **+** to select the analysis you want to run a simulation against and select **Submit**. Note The most recent analysis will be selected by default. If you are using multiple rulebooks, make sure you select the correct analysis. 1. Choose the role you want to simulate changes to. - For a single role analysis, use the **SAP role** dropdown to select a single role. - For a composite role simulation, use the **Composite role** dropdown to select a composite role. 1. In a composite role What If, you can add or remove single roles by selecting **+ Add Roles** or **- Remove Existing Roles** to open the Roles Selection window and browse single roles. Add or remove roles individually using the **+** or **–** buttons in their rows or add / remove all using the **+ Add All** or **– Add All** buttons at the top of the window. Select X to close the window. 1. In a single role What If, you can select **+ Add Action** to specify the role change to simulate by adding new actions (such as SAP Transaction Codes or Fiori oData Services), authorization objects, authorization fields, and field values. Important Single role What If relies on the SAP Authorization Default Values configured using SU24 and stored in SAP table USOBT_C. To populate these values into Access Risk Management, you must import the data. Go to the **Configuration Menu > ERP SYSTEMS** page and select **Refresh Authorization Defaults (SU24)** in the Actions dropdown for each system. - Entering an Action that exists in your SAP Authorization Defaults will automatically populate all default authorization objects, fields, and values according to your configuration in SAP. You may then edit the objects, fields, values, or value ranges as needed prior to submission. Any fields without a value populated will not be evaluated as part of the analysis. Note The Range option for specifying field values works the same way as the SAP From / To ranges. - If you are simulating adding an action that does not exist in your SAP Authorization Defaults, you may manually add each Action, Object, Field, and Value. - If you are relying on SAP Authorization Defaults and you do not populate each of the Fields with a value, you will be prompted with an informational warning that lists each of the fields that are blank. You can use the **Rerun with Changes** action to go back and add values if this was not intentional. 1. Select **Submit**. After setting parameters, the analysis runs. [View](https://documentation.sailpoint.com/access-risk-mgmt/help/review_fiori_whatif.html) or [download](https://documentation.sailpoint.com/access-risk-mgmt/help/export_fiori_whatif.html) your analysis from the What If Analysis page > Role Simulations tab. Note Single role simulations only support Add change types. The simulation examines what happens if we add permissions to a role. Other What If simulations support adding and removing. For example, you might analyze what happens if you add or remove a single role from a composite. # Reviewing Fiori What If Analysis Results To view results, go to the What If Analysis page by selecting **What If Analysis** from the left navigation. Select a tab for the type of review you want to find, either [User Simulations](#user-what-if-results) or [Role Simulations](#role-what-if-results). ## User What If Results User What If analysis results are listed in a table, including: - **Actions** - Options include View, Export, [Rerun with Changes](#rerunning-a-what-if-analysis), [Rerun without Changes](#rerunning-a-what-if-analysis), and View Errors. - **ID** - What If Analysis identification number. - **Status** - Pending, completed, faulted. - **User(s)** - Usernames included in the simulation. For long lists, select to see all usernames. - **% User Risk Mitigated** - Percentage of identified user risks that are currently mitigated, expressed as the number of mitigated risks (green text) out of the total number of risks (red text). “Added by” indicates that the risks were added by the What If simulation. “Existed before” indicates that the risks already existed prior to adding in the What If conditions. - **Rulebook** - Rulebook used to run the simulation. - **Completion Date** - Date the simulation was completed. - **Created Date** - Date the simulation was created. - **Created By** - Email of the user who created the simulation. For columns with a **Filter** icon , select the icon to filter that column. Use **Clear Filters** at the top right to clear all filters from your view. ### Reviewing User Simulation Results at the Risk Level When you locate your analysis in the Risk Analysis tab, select the **View** icon next to it to examine the simulation results on the What If Result – Risk Level page. This shows a listing of the risks produced by the simulation. Each row represents a single risk for a single user. The Risk Level table includes: - **Action** - Select **View** to drill down to SAP role, profile, and authorization details. - **Simulation Impact** - Impact of the proposed changes, rated as Removed Risk, Existing Risk (unchanged by the proposed modifications), Existing Risk with Changes (if the risk was already present, but now there are fewer or more permissions with the proposed modifications), or New Risk (the simulation would introduce this user risk). - **Username** - The username associated with the risk; this field displays New User for a new user simulation. - **Full Name** - The full name associated with the user account. - **Rulebook** - Name of the rulebook applied to the simulation. - **Risk Code** - Risk’s identifying code. - **Risk Name** - Name of the risk. - **Risk Rating** - Severity of the risk to the business. - **Mitigation Status** - Mitigated, if the specified user risk has mitigations that are currently applied, Mitigations Available if mitigations are available that could be applied, or None Available if there are no available mitigating controls. - **Mitigations** - When the mitigation status is Mitigated, this field shows a delimited list of mitigating controls that have been applied to the risk. - **Business Process** - Process impacted by the risk. - **Business Functions** - A delimited list of the business function code(s) that create the risk. - **Permission Hits Count** - Number of permissions impacted by the proposed changes. - **Added By** counts the number of new permissions included in the proposed changes that were identified as contributing to the risk. - **Existed Before** counts the number of permissions that the user already had contributing to the risk before the proposed changes. - **Removed After** counts the number of permissions that would be eliminated by the proposed changes. From the Risk Level page, you can view additional details for any identified risk by selecting the **View** icon in the Action column. ## Role What If Results To view Role What If results, go to the What If Analysis page by selecting **What If Analysis** from the left navigation. Select the **Role Simulations** tab. Role What If analysis results are listed in a table, including: - **Actions** - Options include View, Export, [Rerun with Changes](#rerunning-a-what-if-analysis), [Rerun without Changes](#rerunning-a-what-if-analysis), and View Errors. - **ID** - What If Analysis identification number. - **Status** - Pending, completed, faulted. - **Type** - Type of analysis. Options are Single Role or Composite Role. - **Role Name** - Role selected to simulate changes to. - **% User Risk Mitigated** - Percentage of identified risks that are currently mitigated, expressed as the number of mitigated risks (green text) out of the total number of risks (red text). “Added by” indicates that the risks were added by the What If simulation. “Existed before” indicates that the risks already existed prior to adding in the What If conditions. - **Role Risk Count** - Total number of inherent role risks identified, broken out by risks that existed before the simulated changes and those added by the simulated changes. - **Name** - Name of the What If analysis. - **Rulebook** - Rulebook applied in the simulation. - **Completion Date** - Date the simulation was completed - **Created Date** - Date the simulation was created. - **Created By** - Access Risk Management username of the user who created the simulation. For columns with a **Filter** icon , select the icon to filter that column. Use **Clear Filters** at the top right to clear all filters from your view. ### Reviewing Role What If Simulation Results at the Risk Level When you locate your analysis in the Risk Analysis tab, select the View icon next to it to review the simulation results on the What If Result – Risk Level pages for both User Impacts” identified at the user level based on all assigned roles, and Role Impacts for inherent risks identified within either the single or composite role modified by the simulation, or for any single role changes that are part of one or more composite parent relationships. Select the **Role Impacts** tab to see a listing of the inherent risks identified as part of the simulation. Each row represents one inherent risk for one role. For example, if you have one risk defined in your rulebook, and you simulate changes to a single role that is not part of any composite role, there could be a maximum of one Role Impact row. If you have one risk defined in your rulebook, and you simulate changes to a single role that is part of two composite roles, there could be a maximum of two Role Impact rows. The Risk Level Role Impacts table includes: - **Actions** - View details. - **Simulation Impact** - Existing, Existing risk with changes, or Removed Risk. - **Role Name** - Role selected to simulate changes to. - **Rulebook** - Rulebook applied in the simulation. - **Risk Code** - Code identifying this risk. - **Risk Name** - Name of the risk. - **Risk Rating** - Informational, low, medium, high, or critical. - **Business Process** - Code indicating the business process impacted by this risk. - **Business Functions** - A delimited list of the business function code(s) that create the risk. - **Permission Hits Count** - Number of permissions associated with a newly introduced risk added by the simulated changes, number of permissions associated with risks that existed before the simulated changes, and the number of permissions associated with a risk that would be removed by the simulated changes. - **Role Location Name** - Location of the role, if configured in Access Risk Management. - **Role Description** - Description of the role, either the default SAP description or custom descriptions, if configured in Access Risk Management. From the Risk Level page, you can view additional details for any identified risk by selecting the **View** icon in the Action column. To export a copy of these results, select **Actions > Download**. Find your report on the **Activity History page > Data Exports tab**. Select **Actions > Download** to download your report. The Action button is temporarily disabled while the export is in progress. View details about this What If simulation by selecting **Request Details** above the table. Information includes the simulation’s properties, such as Role Name, What If request ID, What If created date, extract ID, extract created date, analysis ID, rulebook ID, rulebook name, number of new and existing user risks, number of removed user risks, number of new role risks, number of existing role risks, number of removed role risks and the roles that were added or removed in this analysis. Note The Request Details view allows you to quickly screenshot all of the simulation parameters, along with summary counts of the number of risks identified, which is useful for complying with audit evidence requests. ## Applying Mitigations You can apply mitigating controls to a user risk on the What If Result – Risk Level page. The system automatically identifies any mitigating control that has been mapped to the specific risk and will include the status Mitigations Available in the Mitigation Status column. Users with either Mitigating Control Administration or Mitigating Control Mapping permissions can use the Actions dropdown in the risk’s row to apply a control to the SAP user. 1. In the Action column, select **Actions > Apply Mitigation**. 1. In the Mitigations Available window, find a mitigation and select **Actions > View Mitigation Details** or **Actions > Apply Mitigation**. 1. If you selected View Mitigation Details, review the details on the Mitigating Controls – Maintenance page. 1. If you selected Apply Mitigation, add a comment in the Mitigation Note field. Optionally, you can set a date for the mitigation to expire. Select **Submit**. ## Reviewing Risk Permission Details The What If Result - Detail Level page shows entitlement and permission level details specific to the selected risk that either surfaced due to proposed changes, or existed prior to the simulation. This analysis includes the following data: - **Change Type** - Identifies whether permissions are associated with a risk being added, removed, or were preexisting, which is identified as No Change. - **Business Function Code** - Code indicating the impacted business functions. - **Business Function Name** - Name of the impacted business function. - **Permission Group** - This is the logical grouping of permissions. For SAP, these are generally transaction codes. They may also be Fiori apps. Groupings can be customized in your [rulebook](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/index.html). - **Auth Object** - The SAP authorization object. - **Field** - The field of the SAP authorization object. - **SAP Value From** - The authorization FROM field value as assigned in SAP. - **SAP Value To** - The authorization TO field value as assigned in SAP. - **Risk Value From** - The authorization FROM field value as defined in the rulebook. - **Risk Value To** - The authorization TO field value as defined in the rulebook. - **Role Name** - Name of the role responsible for the permission risk line. Note If Parent Role is blank, this role is directly assigned to the user. If Parent Role is not blank, this role is inherited by the user from the composite parent. - **Profile Name** (User What If only) - The SAP profile associated with the single role. Note If role name is blank, this profile is directly assigned to the user, otherwise the profile name is inherited from the role. - **Is Derived** - Boolean indicating whether or not the role is derived from a parent role. - **Parent Role** - The parent for the single role, if applicable. Note Parent role is blank if a single role or profile is directly assigned to the user. Select the **Filter** icon to filter the columns. Select **Clear Filters** at the top right to clear all filters from your view. Select **Request Details** at the upper right to see the details about the request properties and generation. These include: role name, What If request ID, What If created time, extract ID, extract created date, analysis ID, rulebook ID, rulebook name, number of new user risks, number of existing user risks, number of removed user risks, number of new role risks, number of existing role risks, number of removed role risks, role name, and change type. To return to the What If Analysis list from the Risk Level view, select the **Back** button at the upper right. Note Using the **Back** button above the table will retain any filters applied to the prior grid, while using the browser's back button will not. ## Rerunning a What If Analysis In the Actions dropdown for each analysis row on the What If Analysis page, as well as in the Actions dropdown above the What If Result - Risk Level and the What If Result - Detail Level page, there are two options for rerunning a What If analysis without having to reenter the parameters: - **Rerun with changes** – Displays a New Simulation window that is prepopulated with the same parameters as the analysis that was selected. You can adjust your parameters and run a new analysis. - **Rerun without changes** – Runs a new analysis with the same parameters. Note The **Rerun without Changes** option will automatically run the simulation against the same baseline Risk Analysis. If you want to use the most up-to-date analysis data, select **Rerun with Changes** and then select the most recent analysis. For either option, any mitigations you have updated are included when you rerun the simulation. # Exporting What If Analysis Results To download an analysis as a .csv file, locate the analysis you want and select **Actions > Download**. Note What If results downloads are only available in a .csv format. ## Understanding a What If Analysis CSV file A What If Analysis .csv file includes parameters, with metadata about the simulation, and results, with one row per risk, entitlement, or permission that was added, removed, or preexisting. Parameters include: - **Simulation ID** - Identifier for the What If simulation. - **Customer ID** - Access Risk Management Customer identifier. - **Total Users** - Total number of users included in the simulation. - **System ID** - Access Risk Management ERP system identifier. - **Rulebook** - Name of the rulebook(s) used in the What If simulation. - **Extract ID** - Identifier for the security extract used in the What If simulation. - **Extract Date UTC** - UTC timestamp for when the security extract was generated. - **Analysis ID** - Identifier for the analysis used to produce the What If simulation. - **Baseline Analysis Date UTC** - UTC timestamp for when the analysis used to produce the What If simulation was run. - **Created UTC** - UTC timestamp for when the What If simulation was created. - **Requested By** - User who requested the What If simulation. - **Completed UTC** - UTC timestamp for when the What If simulation was completed. Results include: - **Simulation ID** - Identifier for the What If simulation - **User** - SAP User ID - **Full Name** - User’s full name - **Role Added or Removed** - Role that was added or removed in the What If simulation granting the permission. - **Change Type** - Indicates whether the permission was Added, Removed, or part of the simulated user’s pre-existing access, with No Change. - **Impact** - Used in combination with the Change Type column to determine the risk impact: - **Existing Risk with Changes** is a Risk the user already had access to, but has been either worsened or lessened based upon the changes. Examples: - Change type of Added with an impact of Existing Risk with Changes indicates the user had sufficient access prior to the changes, but the permission on this row would grant further conflicting access to the risk. - Change type of Removed with an impact of Existing Risk with Changes indicates the user would lose access to the permission after the changes, but would continue to have sufficient access to execute the functions associated with the risk. - Change type of No Change with an impact of Existing Risk with Changes indicates the user had, and would continue to have, access to the permission after the changes, but there were changes to other permissions associated with the risk. The remaining permissions would need to be removed to fully eliminate the risk. - For remediation projects, filtering on rows with this combination allows you to identify the remaining permissions that would need to be removed to fully eliminate the risk. - **New Risk** is a risk that the user did not have previously, but would be introduced by the proposed changes. - **Removed Risk** is a risk that the user had previously, but would be eliminated by the proposed changes. - **Risk Name** - Full name of the risk. - **Risk Code** - Short code identifying the risk/ - **Rating** - Risk rating, such as informational, low, medium, high, or critical. - **Business Process** - Affected business process that the risk belongs to. - **Function Name** - Full name of the business function. - **Function Code** - Short code identifying the business function. - **Logic Group** - A logical grouping of permissions within a business function that, dependent upon how you set the permission logic for the business function, determine whether you have access to the business function. Traditionally for SAP this would be a transaction code, but now that Access Risk Management supports Fiori, logic groups can also be Fiori applications. - **Auth Object** - Authorization object name. - **Field** - Authorization field name. - **SAP Value From** - Authorization field FROM value, assigned by the SAP authorization. - **SAP Value To** - Authorization field TO value, assigned by the SAP authorization. - **Risk Value From** - Authorization field FROM value, as written in the Access Risk Management rulebook permission. - **Risk Value To** - Authorization field TO value, as written in the Access Risk Management rulebook permission. - **SAP Profile** - The profile granting the permission. - **Derived?** - Boolean column to identify derived child roles. - **Parent Role** - For derived roles, this is the parent role, for single roles inherited from a composite role, this is the composite parent. # Viewing Activity History Some actions, like scheduling an analysis or approving a provisioning request, generate job entries in the Activity History Dashboard. Use the Activity History dashboard to track analyses, change logs, data exports, data imports, reports, security extracts, utilization extracts, provisioning, and validators. You can view or download entries, restart failed jobs, and view additional granular information about the outcome of these actions using the dashboard. On the Activity History page, use the tabs to quickly view job details for each activity category. The columns provide specific details about the selected job activity so that you can find and understand the outcomes of your job requests. Select the **Refresh** icon to update the table. Use the **Filter** icon to create a query for that column. For Security Extracts, the Results column includes the data validation outcome. When there are errors, you can select **View Result** in the Action column to view the data issues that caused the failure. Note Messages that exceed four lines of text, such as detailed error messages in the Result column, will show links that, when selected, show the full text that you can copy to your clipboard. ## Viewing Utilization Extracts To track newly-created utilization extract jobs or to download completed extracts, go to **Activity History > Utilization Extracts**. The Utilization Extract Activity History table includes the following information for each extract: - **Action** - When extracts successfully complete, the **Download** button is available to download and review the extracted data for validation. - **ID** - Unique identifier of the utilization extract. - **Type** - Type of extract. - **Status** - Completed jobs show a status of Completed or, if the job failed, LoadFailure. - **Name** - Name of the utilization extract. Legacy extracts are named STAD and SM20 extracts are named Security Audit Log. - **Description** - Description of the extract. Includes the period covered by the extract in the format MMMM DD YYYY to MMMM DD YYYY. - **File Size** - Size of the extract file expressed in bytes. - **Result** - The results of the Utilization Extract action, including a reference ID that SailPoint customer support can use to quickly identify all logs associated with the job for efficient troubleshooting. - **Created Date** - Date the extract was created. - **Completion Date** - Date the extract was completed. - **Created By** - For extracts that run from a scheduled recurrence, this field will say System. For one-time or ad hoc extracts, the username of the person who ran the report. ## Viewing Security Analyses To validate that online reports are based on the latest security analysis, go to **Activity History** and select the **Analyses** tab. Both ad hoc and scheduled analyses are listed on this page. Locate the most recent successful Security Analysis. You can review details in the Description and Result columns. A timestamp in the Completion Date column indicates the date and time that the Security Analysis was completed. # Viewing the Dashboard The Risk Snapshot Dashboard shows a summary view of the risk in your environment. To populate and update the dashboard, select **Schedule Jobs** and choose **Risk Snapshot**. The dashboard information is broken down by Risk Rating, Business Process, Users, and Roles. ## Editing the Dashboard Select **Edit Dashboard** at the upper right to arrange your view. Choose which widgets to include by selecting the checkbox next to each one listed in the Edit Dashboard pane. Select the arrows at the right of the widget’s name and drag up or down reorder them. When you are finished editing, select **Cancel** or **Save**. ## Using Dashboard Filters Select **Filters** to filter your dashboard content. In the Filters panel, select the checkboxes for the information you want to include, such as risk level, mitigation status, and types of TCode executions. Select **Cancel** or **Apply** when you are finished. ## Viewing Your Current Risk Status The dashboard provides insight into the overall risks in your environment. You can view the risk graphs for a high-level view or select areas within the graphs to see more granular reports - giving you the information you need to assess and remedy risks. Information includes: - User Risks by Rating - User Risks by Business Process - Users by Highest Unmitigated Risk - Roles by Highest Executed Risk - User Risks History Access Risk Management risk ratings map to numeric ordering: - 0 - Informational - 1 - Low - 2 - Medium - 3 - High - 4 - Critical Risk ratings are also visible in some reports. For an example, refer to [User Risk Summary by Rating](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_user_reports.html#user-risk-summary-by-rating). ### User Risks by Rating The User Risks by Rating report shows all the risks in the environment broken down by the risk rating defined in the rulebook. These are separated by the utilization of the users with access to those risks. The graph shows four types of utilization and their associated risk levels: - **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** - A sensitive access risk that requires access to only one function and the user has executed transaction codes associated with that function. To see more details, you can select a section of the graph and navigate to the User Risk Level Details screen with the appropriate filters applied to match the selection. **Use Case** This summary-level report is often used by business owners or managers to see users who pose the most risk to the business. You can view and filter by the different levels of risk and see which users have that access. This can help determine if the users have access to the expected risks and if remediation is needed. If the reported users are not ones expected to have the risk, further remediation should occur. If remediation is not possible, mitigating controls can be assigned. ### User Risks by Business Process The User Risks by Business Process report contains similar information to the User Risks by Rating report, with the added dimension of the Process Area defined in the rulebook. The breakdown of risk and drill-down reporting acts the same as the User Risks by Rating and the total risk numbers will be the same. **Use Case** This summary-level report is often used by business process owners or owners of specific functional areas to review users who pose the most risk within their respective area. You can view and filter by the different business process areas and see which users have that access. This can identify if the expected users have access to the risks that might be expected of them so you can use that information to determine if risk remediation or mitigating controls are needed. ### Users by Highest Unmitigated Risk The User by Highest Unmitigated Risk report identifies how many unique users have executed both sides of an SoD or Sensitive Access Risk without having any mitigating controls assigned. Since a user can execute multiple risks, the report will display them based on the highest level of risk they have executed. Selecting a section of the graph will show the User Summary report with the correct filter applied on the Highest Level of Fully Executed Unmitigated Risk column. **Use Case** This report can help identify users who are the cause of the most issues. Most remediation projects will start with remediating roles to ensure that they are free of inherent risk and then analyze the users after. From there, you can determine if you should remediate by modifying business processes or job responsibilities or if you should apply a mitigating or manual control for that user / risk that can't be remediated otherwise. ### Roles by Highest Executed Risk The Roles by Highest Executed Risk report identifies how many unique roles have an inherent SoD or sensitive access risk built in and indicates if that risk has been fully executed by the assigned users. Selecting this report will navigate to the Role Summary report and apply filters based on the Highest Level of Fully Executed Risk column. **Use Case** This report is often used to identify those roles that cause the most risk in your environment, which might be a place to focus initial remediation efforts. It can show roles that have execution on both sides. Since it can be different users executing both sides, the role can be split, resulting in two roles that are inherently free of SoDs. For more information, refer to the [Role Conflicts Matrix report](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel_role_reports.html#role-conflicts-matrix-report). ### User Risks History The User Risks History graph shows the historical trends of the organization's risks over time to indicate if something has changed in your environment. If your additional controls are effective, the line will stay flat. If something has changed in your security that is causing risk, the line will rise. **Use Case** The graph is also frequently used to report risks over a period. This can be helpful in determining when to review your risks again. If there is fluctuation in the risk history, you may want to reevaluate your controls using the other available dashboard reports. # Reports Overview Access Risk Management shows risks in your environment in multiple forms - from high-level summaries to granular reports. You can see these different levels of risk reporting using the Dashboard, online and Excel reports, and the activity history. - [Dashboard](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/dashboard/index.html) - The Dashboard uses graphs to show high-level summaries of risks and utilization. Select a section of a graph to view a detailed report of those risks or utilizations. - [Online](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online/index.html) and [Excel](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel/index.html) reports - Access Risk Management generates more than 25 types of reports to give you the insight you need to protect your organization. - [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) - Some actions, like scheduling an analysis or approving a provisioning request, generate job entries in the Activity History Dashboard. - [Data Export](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/data_export.html) - For offline reporting or compliance, export the complete data from an Access Risk Management Risk Analysis into a portable SQLite database. This export includes both user-based risk analysis hit details and role-based analysis hit details down to the authorization field value level. # Business Process Conflicts Matrix Report The Business Process (BP) 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** - Defaults to the report type and date/time but can be customized. - **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** - Includes 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](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/dashboard/index.html#user-risks-by-rating) 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. # Exporting Risk Analysis Data Use Data Export to extract a complete copy of all reporting data from any completed Risk Analysis that is available via Online Reports into a portable, GZIP-compressed SQLite database. This gives you offline access to all details needed for compliance audit evidence when you need to provide immutable analysis results with metadata; validated, full-result details of your implementation; and the ability to complete deep-dive analyses using external reporting tools. ## Downloading an Export To download a data export from Access Risk Management: 1. Go to **Activity History > Analyses**. 1. Select **Export Risk Analysis** at the upper right. 1. The Analysis Selector modal lists all available Risk Analyses. Locate the analysis you want and select **Export** from the left column of that row. 1. You will be redirected to **Activity History > Data Exports**. The status of your export updates to Success when the job is complete. 1. Select **Download** to download the data. ## Export File Contents The downloaded data export file is a GZIP-compressed SQLite database, containing four tables: [Analysis Properties](#analysis-properties), [Properties](#properties), [Role Based Hit Details](#role-based-hit-details), and [User Based Hit Details](#user-based-hit-details). ### Analysis Properties The Analysis Properties table stores high-level metadata about the exported Risk Analysis. This table is critical for understanding the context of the results. Properties include: - **Total User Analysis Detail Records** - Count of all user-based hit rows at the authorization object field value level. - **Total Role Analysis Detail Records** - Count of all role-based hit rows at the authorization object field value level. - **Analysis Date** - Timestamp when the analysis was executed. - **Total Unique User-Risks** - Number of distinct user risks identified. For example, 1 user with 10 risks = 10 user-risks, or 10 users with 1 risk each = 10 user-risks. - **Number of Rules Analyzed** - How many risks from the rulebook were analyzed as part of the Risk Analysis. - **System Name** - SAP system analyzed (e.g., S4H_GOLD). - **Role Utilization From/To Date** - Date range used to calculate the Action Execution Count and Action Last Executed Date columns. - **Rulebook Name** - Version of the rulebook used (e.g., MSRB_BASELINE.xlsx). - **Number of Users Analyzed** - Total users included in the Risk Analysis. - **Number of Roles Analyzed** - Total roles included in the Risk Analysis. - **Analysis Name** - Name specified when scheduling the Risk Analysis. - **Analysis ID** - Unique ID of the Risk Analysis. ### Properties The Properties table is a mapping of each exported table to its row counts and export timestamp. You can use this information to validate how many rows were exported and when the export was performed. ### Role Based Hit Details The Role Based Hit Details table contains reportable details for inherent role risks in SAP single and composite roles. Columns include role type, analyzed role, child role, business function, action, authorization object and field, and execution details inferred from any users assigned to the role. ### User Based Hit Details The User Based Hit Details table contains reportable details for user-specific risks. Columns include user information (username, full name, group, active or locked status), role assignments, business function, action, authorization object and field values, execution data, and mitigating controls. ## Using a Data Export with SQLite To start using your data export with SQLite: 1. Uncompress the .gz file using any available file compression utility. 1. Install a free tool such as the open source [DB Browser for SQLite](https://sqlitebrowser.org/dl/). 1. Open the downloaded SQLite .db file using the SQLite DB browser. 1. Use the **Browse Data** tab to explore the table details. 1. Use the **Execute SQL** tab to run SQL queries. 1. Optionally, you can export the results into CSV format by going to **File > Export > Table(s) as CSV files**. Note Any dataset over a million rows can’t open in Excel until you filter the results to be under the million-row limit. # 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](#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](#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. # 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](#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](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/bp_conflicts_report.html) 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** - Defaults to the report type and date/time but can be customized. - **User Types and Statuses** - 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** - Includes 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** - 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** - 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. # Execution Reports The execution reports shows the transactions codes and who executed them. ## Execution Summary **Purpose** The Execution Summary report is used to show all transaction codes that users have executed along with the total number of executions. This is a good way to see a high-level view of what access in SAP is being used. *Use Case* This report is generally used for reference to understand transaction code usage. ## Execution Summary Monthly **Purpose** The Execution Summary Monthly report is used to show all transaction codes that users have executed, the total number of executions, and in which month transactions were executed. This is a good way to see a high-level view of what access in SAP is being used with the addition of the time it was executed. *Use Case* This report is generally used for reference to understand transaction code usage. # Online Mitigations Report There are two ways to get to the Mitigations Report. Either select the **Mitigations Report** button on the Risks > Mitigating Controls page or go to **Online Reports > Mitigations Report**. Once you create and enable mitigations with a Valid From date (optional) and Valid To date (required), they are applied when you do Separation of Duties (SoD) reporting. View a report with all available metadata of your organization’s mitigating controls. 1. Select the tab you would like to report on, such as Mitigating Controls, Risk Mapping, Mapping Rules, etc. 1. Below the tabs, text shows which analysis is currently displayed. 1. Filter your view to find the information you need. - The most common filters are found above the dashboard. Use the dropdowns to select your criteria and your reports will update accordingly. - Advanced filtering is available for some of the options in the filter pane on the right. 1. The **crosshatch arrows** icon at the top of the screen moves you to full-screen mode, showing only the dashboard widgets. Select **ESC** to exit full-screen mode. Refer to [Managing Mitigating Controls](https://documentation.sailpoint.com/access-risk-mgmt/help/mitigatingcontrols/manage_controls.html). # Property Reports Use the property reports to keep track of the data used to generate the reports. ## Snapshot Properties **Purpose** The Snapshot Properties shows the information that was used to create the risk snapshot or dashboard reports. This includes the account information, user who scheduled the snapshot, the rulebook(s) used, along with the dates and times of the security and utilization extracts. ## Risk Descriptions **Purpose** The Risk Descriptions report is a reference table to show the risks, risk rating, and descriptions of any risks that generate at least one result (i.e., at least one user or role has access to the risk) based on the definitions from the rulebook(s) used to create the risk snapshot. ## Business Function Descriptions **Purpose** The Business Function Descriptions is a reference table to show the business functions, function names, and the description for functions associated with risks that generate at least one result (i.e., at least one user or role has access to the risk) based on the definitions from the rulebook(s). ## Mitigating Controls **Purpose** The Mitigating Controls table in the Properties section is a reference table to show the different mitigating controls in the system, along with the objective and description defined for those mitigating controls associated with risks that generate at least one result (i.e., at least one user or role has access to the risk) based on the definitions from the rulebook(s). This table is used as a reference to give more information about the mitigating control in place for a risk or user since most reports only indicate the mitigating control code. # Role Reports The role reports give insight into role components and risks. Use the Role Summary report to get a total view of the roles in the system, then use the other reports to drill down into how those components show risk in that role. ## Role Summary **Purpose** The Role Summary report provides a breakdown of all the roles in the system along with key data points around the associated risks. Some key details are related to how many users are assigned that role, how many sensitive transaction codes exist, inherent risks in the role, and whether those risks have been executed on. Users can drill down for specific roles to see more details on the Role TCode Level Risk Details report or see potential remediation actions on the Role Remediations report. *Use Case* The Role Summary report is used to identify which roles to target when initiating a remediation project. The first step during remediation is generally to remediate inherent risks in the roles and this report is used to select which roles to look at first if you want to make that decision based on risk. This can be done by filtering on the Number of Critical and High Risks or Fully Executed Critical or High Risks Count columns. ## Role Ranked by Risk **Purpose** The Role Ranked by Risk report is a summary report, similar to the Role Summary, with additional information around the risks. This report focuses specifically on the roles that carry the most risk to help with remediation projects and deciding prioritization. Users can drill down to the Role TCode Level Risk Details report for specific risks to see the explicit transaction codes that are associated with the different functions in the risk. *Use Case* The Role Ranked by Risk report helps identify what roles to focus on first when performing a remediation project. A common approach is to identify the roles that have the most risk, or most executed risk, and then drill down to see the transaction code details to understand what access the role has associated with risk. You can then use this information and leverage other reports to see what transaction codes are being used and who is using them. In conjunction with the Role Ranked by Risk report, the Role TCode Level Risk Details report can be used to identify any transaction codes in the role that are associated with risk but not being used. The Role Member TCode Executions report can show who is executing transaction codes that are being used in the role. Once you know who is using the access, you can work with the business to see if processes can be adjusted, or you may determine that remediation isn't possible and mitigation is the appropriate course of action. ## Role TCode Level Risk Details **Purpose** The Role TCode Level Risk Details report gives a granular view into the cause of risk in a role. The report shows the role, the risk(s) the role has access to, the transaction codes that provide access to each side of that risk, and the total number of times users with that role have executed each transaction code. This report allows you to drill down further to the Role Authorization Object Level Hit Details and Role Member TCode Executions. *Use Case* This Role TCode Level Risk Details report is usually one of the first used reports when you are initiating a remediation project since best practice is to remediate roles with inherent risk before assigning them to users. Some common remediation steps include: - Remove unused transaction codes from the roles. This is identified in the All TCode Execution Count column where the value equals one. Since the transaction code is not being used by anyone who has that role assigned, there should not be an impact to anyone's ability to perform their job functions if the TCode is removed. If all transactions associated with one of the business functions are removed, there is no longer an inherent risk in that role. - If there is utilization for a transaction code, you can identify who is using that transaction code when you drill into the Role Member TCode Executions report. If you are able to identify that different users are executing transaction codes from each side of the SoD risk, you can then split the role up into multiple roles so that users keep what they are using while eliminating an inherent risk in the role. - If there is utilization for a transaction code and the same user(s) is executing transaction codes from both sides of the risk, you can potentially remediate by changing business processes so the same users are no longer using both sides. If that isn't a possibility due to department size or headcount, you can choose to mitigate that risk. You can edit your [rulebook](https://documentation.sailpoint.com/access-risk-mgmt/help/rulebooks/index.html) to apply mitigating, or manual, controls to a risk or user. - If you believe a risk is showing in a role, and for at least one of the business functions it should be display-only access, you can drill down into the Role Authorization Object Level Hit Details report to identify the specific authorization objects in the role. If there is create or change access where you believe there should only be display access, you can change the authorization objects in the role to remediate the risk. ## Role Authorization Object Level Hit Details **Purpose** The Role Authorization Object Level Hit Details report allows you to drill down to the most granular layer of data when it comes to the security and role design in SAP. This report shows every authorization object the role grants access to in the columns starting with SAP, compared to the access searched for in the rulebook in the columns starting with Rule. *Use Case* This report is used to understand all the reasons why a role is being flagged as having an inherent risk. The two most common examples of inherent risks in roles that need further investigation are: 1. A role with a display naming convention showing up as having inherent risk built-in - This means that the role also has additional authorizations that are identified in the rulebook. You can see this because the columns starting with Rule Authorization show what we were testing for and the columns starting with Role identify what access is in the role. 1. A role granting access to a business function that was believed to be display-only - This is referenced in the use case section of the Role TCode Level Risk Details report. This information is reviewed similarly to example 1. ## Role Member TCode Executions The Role Member TCode Executions report shows all the roles, who has access to that role, and whether or not they have executed the transaction codes in the role. ## Role Remediations **Purpose** The Role Remediations report is used to reduce risk in the system by identifying what transaction codes within the roles are not being executed. This report also shows what level of risk is associated with the unused transaction codes so you know the potential impact of removing the access. The Role Remediation report provides best practice suggestions for managing risk associated with the transactions in the role being used. For example, the Recommendation column may suggest splitting single roles into multiple roles or breaking a composite role. *Use Case* Organizations use this report when doing initial cleanup or periodic reviews to ensure roles are not providing more access than is being used. Since Access Risk Management only pulls the utilization already stored in SAP when the initial implementation is done, generally three months, organizations should allow additional months to collect utilization data and then remove the transaction codes that are not being used. If the end goal is reaching a state of least privilege access, this is a common next step to reducing the unneeded access in SAP. # Online User Reports User-based reports provide summary and detailed views of the risks associated with user privileges and actions. ## User Summary **Purpose** The User Summary report provides a breakdown of all the active users in the system and key data points for the risks associated with the users. These include the number of roles that are assigned, the number of risks users have access to, and how many of those risks have been executed. Report viewers can also drill down for specific users to review the User Risk Level Details and User TCode Level Risk Details reports and User Remediation. *Use Case* The User Summary report is generally used to identify which users to target during remediation projects. Many organizations prioritize the most impactful changes first, which can include users that have access to high-risk conflicts and/or are executing those risks on both sides so there is a potential of inappropriate activity having occurred. ## User Risk Summary by Rating **Purpose** The User Risk Summary by Rating report focuses on the risks in the environment. This summary shows all the risks in the system, information on how many users have access to that risk, and whether there have been executed transaction codes associated with the risk. Report viewers can drill down to the User Risk Level Details or User TCode Level Risk Details to see the users who have access to these risks. *Use Case* The User Risk Summary by Rating report is used by organizations to help identify what risks they want to focus on first with remediation efforts. A common approach is to go after high-risk conflicts first, and then within the high risks, they might choose to look at those that are being executed at the highest rate since that will likely be a more complex remediation effort. ## User Risk Level Details **Purpose** The User Risk Level Details report shows all of the risks within the system and the users who have access to those risks. Additional information included is related to the risk, such as Risk Name, Risk Rating, and Risk Description, along with utilization information. You can see summary-level details on the total transaction codes executed by the user for each of the business functions associated with the risk. Since each business function can contain multiple transaction codes, you will want to access other reports to see the specific transaction codes that are being executed. The drill-down options from this report are the User TCode Level Risk Details, User Authorization Object Level Hit Details, User Remediations, and Execution Summary for that particular risk and user. *Use Case* This report is often used as a starting point when reviewing the specifics of a risk that a user has access to. The utilization bucket contains key data points used to pick what risk and user to examine. A common scenario is to review a risk that is being executed on both sides and the summarized utilization. The summary-level utilization data can pinpoint if there are scenarios in which a user is using one function significantly more, so maybe you want them to keep that access but find someone else to take over responsibilities for the other function. In other situations it may be evident that someone is using both functions evenly, in which case you might want to look at applying mitigating controls if there is no way to remediate the risk. Once you identify the specific user and risk you want to review, you can drill down into the more granular reports to view the transaction codes and authorization objects to which user has access to help make decisions on risk. ## User TCode Level Risk Details **Purpose** The User TCode Level Risk Details report provides a granular view into what is causing a user to have access to a risk. Some things you will be able to identify on this report are the user, what risk they have access to, what transaction codes they have access to from each side of that risk, how many times they have executed each transaction code, and what role(s) gave them access to that transaction code. This report allows you to drill down further to the User Authorization Object Level Hit Details, Role Member TCode Executions, and User Remediations. *Use Case* Once you identify a specific risk to review for a user, this report shows details around that risk to assist decisions. Understanding what transaction codes a user has actually executed and where that access is coming from provides insight into how to deal with the risk either through remediation or mitigating controls assignment(s). Another possible use case is for organizations to review their Display Only roles. If a transaction code appears in a role marked as display-only, additional investigation is recommended. In this scenario, you will use the User Authorization Object Level Hit Details report to identify if the role is giving additional authorizations or if that user is getting them from other roles or transaction codes. Since SAP has more transaction codes than authorization objects, this cross-pollination of authorizations is not uncommon. ## User Authorization Object Level Hit Details **Purpose** The User Authorization Object Level Hit Details report drills down to the most granular layer of security role data. This report shows every authorization object to which the user has been assigned (shown in the columns starting with SAP) compared to the access searched for in the rulebook (shown in the columns starting with Rule). *Use Case* This report is heavily used to understand why a user has access to a risk. A common findings is that a transaction code associated with a risk is coming from a Display Only role on the User TCode Level Risk Details report. This may look like a false positive, however, there are two possible explanations that this report can help identify: 1. The Display Only role is giving more than display access. This will be clearly indicated when you go to this report since the same role will appear throughout the Role Name column. 1. The transaction code is coming from the display role and the create or change authorizations are coming from a different role the user has assigned. Since there are more transaction codes in SAP than there are authorization objects, this cross-pollination or sharing of authorizations is common. This is identified because you will see the different roles giving access in the Role Name column. ## User Remediations **Purpose** The User Remediations report is used to reduce risk in the system by identifying what roles users have assigned but are not utilizing. The report indicates if any of the transaction codes associated with the access has been executed. This report also identifies how many risks are associated with that role and how many of those risks fall into the High or Critical risk rating. Important If a risk is on this report, it simply means that a transaction code in the role is associated with a business function. It does not mean that there is an inherent risk in that role, so this report is a good first step to removing unnecessary access in the system that has the potential for that risk. *Use Case* Organizations use this report when doing an initial cleanup or periodic review to ensure users do not have unnecessary roles that they are not using. Since only the utilization stored in SAP is initially imported to Access Risk Management, which is generally three months, organizations should allow some additional months to collect utilization data and then remove the roles that are not being used. If the end goal is reaching a state of least privilege, this is a common first step to reducing the unneeded access in SAP. # Downloading 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](https://documentation.sailpoint.com/access-risk-mgmt/help/eam/generate_reports/index.html). Report types include: - [Excel User Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel_user_reports.html) - [Excel Role Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/excel_role_reports.html) - [Business Process Conflicts Summary Matrix](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/bp_conflicts_report.html) # Mitigating Controls Change Logs The Mitigating Controls Change Logs report provides an auditable record of creation, deletion, and update events made to the [mitigating controls](https://documentation.sailpoint.com/access-risk-mgmt/help/mitigatingcontrols/index.html) entities and related user mappings for documented exceptions granted to users that have, or may have, sensitive or separation of duties risks within a system. ## Downloading a Mitigating Controls Change Log Report Download a Mitigating Controls Change Log report from the Mitigating Controls – Maintenance page. 1. From the left navigation, select **Risks > Mitigating Controls**. 1. Above the table, select **Change Logs**. 1. The date range defaults to one year, midnight to midnight. If you want different dates, adjust the start and end date for your change log. 1. The time zone defaults to your local browser time zone. If you want to use a different time zone, adjust the value in that field. 1. Select **Submit**. 1. After submitting a change log request, you are directed to the Activity History page. 1. On the Change Logs tab, your change log request is running at the top of the table. You can refresh using the Refresh icon/button above the table to refresh the view while retaining any filters you have applied. 1. When your report has finished running, the status updates to Success and the Actions column allows you to select **Download**. ## Viewing a Mitigating Controls Change Log After downloading a Mitigating Controls Change Log, go to your Downloads folder to open the report. The zip file’s name includes a date and time stamp for the audit period covered by the report, for example from 2024-01-01 040000(UTC) to 2024-12-31 235959(UTC) includes all changes for 2024. Within the zip file, the report consists of: - **Change Logs.csv** - Details of all creations, deletions, and updates - **Properties.csv** - Options selected when running the report, including the number of log entries exported. - **Manifest** - A folder with digital signatures that can be used to verify the files have not been tampered with when performing completeness and accuracy audit procedures. - **Change Logs.csv.sig** - The digital signature file for the change logs themselves. - **Properties.csv.sig** - The digital signature file for the properties file. For each creation, deletion, or update to a mitigating control, a control to risk mapping, a mapping rule to mitigate a user, or a control owner, the change log file includes the following filterable columns: - **Timestamp** - When the change was made. - **Mitigating Control** - Events for the parent Mitigating Control and all metadata. - **Risk Mapping** - Events for mapping a Mitigating Control to a Risk in a specific rulebook. - **Mapping Rule** - Events for mapping Controls to Users. - **Owner** - Events for specifying who owns a Mitigating Control. - **Changed Table** - The entity that was impacted. - **Changed Object** - Which control was updated for which risk. Entries use [control] > [risk] > [attribute] formatting as a primary key to make clear which entry has been updated. Note For each Changed Table, the format of the Changed Object column will vary, depending on the level of detail, to appropriately identify the record impacted. - **Event Type** - Created, updated, or deleted. - **Property Name** - Specific property that was updated. - **Changed By** - User who made the change. - **Old Value** - Value prior to the change. For a record that was newly created, this value is null. - **New Value** - Value after the change. For a record that was deleted, the value is null. Note For deleted entitles where optional columns were not populated, both the old and new values would be null for those unused optional columns. # Viewing Online Reports Note This page contains information about the former Online Reports functionality, which we now refer to as "legacy." It is still supported as we move to the newer version. For latest Online Reports functionality, refer to [Viewing Online Reports - New](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_new/index.html). Access Risk Management generates over 25 online reports for user activity, role usage and risks, executions, and properties. These reports can help you determine where risk lies within your organization so you can take remediation or mitigating actions. Report types include: - [Online User Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_user_reports.html) - [Online Role Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_role_reports.html) - [Online Execution Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_execution_reports.html) - [Online Property Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_property_reports.html) ## Customizing Your View For the User Based, Role Based, and Execution reports, select **EDIT GRID** at the top to choose which columns are displayed. ## Filtering Your View You can filter your reports view in two ways. Depending on the type of report, you can use the top filter buttons to add specific users, risks, roles, or TCodes. You can also select the **Filter** icon on a column to create a query. ### Filtering by Users, Risks, Roles, or TCodes Select the Filter button to see the selection screen for the item you are filtering on. The example above shows how to filter on TCodes in the Execution Summary Monthly report. Select the TCodes filter button to see the selection window. Select **+ Add TCodes** and add the TCodes you want to filter on. Select **Apply**. The report will change to the new filtered view. If the report supports more than one filter, you can combine them. The example above allows you to add filters for both Users and TCodes. Including Users and TCodes will update the report to show you if those users have those TCodes. ### Filtering by Queries Select the **Filter** icon on a column to create a query. ## Scheduling Report Snapshots All online reports are part of the Risk Snapshot job. To schedule this, select **SCHEDULE JOBS** and choose **RISK SNAPSHOT**. Refer to [Risk Snapshot](https://documentation.sailpoint.com/access-risk-mgmt/help/schedulejobs/index.html#risk-snapshot). # Viewing Online Reports - New Note This page contains information for the latest Online Reports functionality. The former Online Reports functionality is also still supported. Refer to [Viewing Online Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online/index.html). Access Risk Management generates many online reports for user activity, role usage and risks, executions, and properties. These reports can help you determine where risk lies within your organization so you can take remediation or mitigating actions. Report types include: - [Online Mitigations Reports](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/online_mitigations_reports.html) ## Navigating the Report UI View online reports by selecting **Online Reports** from the left navigation. Select the tabs at the top of the page to go to different report pages. The **crosshatch arrows** icon at the top of the screen moves you to full-screen mode, showing only the reporting data. Select **ESC** to exit full-screen mode. For any item in the data tables and report visuals, you can hover over or right click, select **Drill Through**, and choose an option to trace additional data specific to that item. Hovering over data tables or visuals brings up a set of icons at the upper right. They are: - **Filters** – List every filter that is currently applied in your view. - **Personalize this Visual** (available for visuals only) – Personalize the appearance of a dashboard widget, including visualization type, y-axis, x-axis, legend, etc. - **Focus Mode** – Remove the tabs and filtering options above the table to view only the report data. - **More Options** – Select an option, such as Export Data, Show as a table, Spotlight, Get insights, and sorting options. Export Data lets you export your filtered report data, with or without formatting. Note While data is loading, a spinning disk icon appears in the top left corner of each dashboard widget. ## Filtering Your View Use filters to include only the data you’re interested in. The most common reporting filters are found at the top of each page. Select the dropdown arrow in a field to view and select options. Press and hold **Ctrl** to select multiple dropdown options. Adjust date ranges by entering dates, using the sliders under the date fields, or selecting the calendar icons. Note Filter options differ depending on which report is selected. Your view may include different options than are shown in the screenshot below. Advanced filters are on the right side of the page. Use the small double arrows at the top to show or hide the Filters panel. Once you’ve applied a filter, its filter card is highlighted to let you know that it has been applied. You can select the eraser icon at the right side of the card to remove that filter from your report. Filter cards include basic filtering, and some offer advanced filtering as well. Advanced logic includes options such as contains, does not contain, starts with, is, is not, etc. Note There may be an Analysis ID error in the advanced filtering window; it does not impact your reporting. In the data table’s column headers, a small arrow indicates the column(s) being used to sort. The direction of the arrow indicates whether it’s sorting in ascending or descending order, and you can select it to change directions. Select multiple sorting columns by holding down Shift while selecting column headers. To cross-filter the visuals, hold **Ctrl** while you select the visuals and/or filters that you want to include. Use the **clear all filters** icon to remove all filters currently applied. Note The Analysis Selector button does not impact the data used in online EAM or Mitigations metadata reporting. It is used for reports that rely on a specific SoD Risk Analysis. # Viewing Online Reports Access Risk Management generates online reports for analysis of separation of duties (SOD) and sensitive access risks at the authorization level for user conflicts as well as inherent role conflicts. Reports are also available for action execution summaries for risk remediation and long-term risk tracking across all governed systems. These reports can help you determine where risk lies within your organization so you can stay in compliance and remediate or mitigate risks as needed. Available reports include: - **Analysis Properties** - Enables auditing the inputs into a Risk Analysis including Rulebook details, User metadata, Role metadata, and User Role assignments. - **Role Risk Details** - Comprehensive diagnostic view of role-based inherent SOD risks, offering full visibility into authorization-level granularity, user impacts, utilization, and corresponding mitigation coverage. - **User Risk Details** - Comprehensive diagnostic view of user-based separation of duties risks due to combined role assignments, offering full visibility into authorization-level granularity, utilization, and corresponding mitigation coverage. - **User-Risk History** - Global view of every user-risk instance across all of your governed SAP systems over time, including when the risk was first identified, and whether it has been mitigated or remediated. - **Execution Summary** - Analyze all action executions at the User or Role level to understand utilization of the available actions, including those that are defined in the rulebook and carry some risk, and those that are not in the rulebook and involve no risk, such as display actions. - **Block List Exclusions** - Unified overview at the tenant level of all [block list](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/block_sap_users_roles.html) rules and the resulting excluded entities across all SAP systems governed by Access Risk Management. - **Analysis Dashboard** - Executive-level overview of the current risk posture to understand where open risks are concentrated, how exposure has changed over time, and enables analysts to determine where to focus remediation efforts. Important To enable the Analysis Dashboard in your tenant, you need to explicitly grant the **Analysis Dashboard** reporting group and either directly assign it to users on the **Settings > Manage Users** page or create an inheritance for all users assigned to an Access Risk Management permission role on the **Settings > Manage ARM Roles** page. Note Reports can handle a maximum of 250,000,000 materialized permission records, meaning the total combined number of users, risks, business functions, roles, authorization objects, and authorization field values. ## Navigating the Online Reports UI View reports online by going to **Online Reports**, then selecting a report type. Report sheets have filters or summary cards at the top, widgets in the middle, and full details on the lower portion of the screen. Tooltips for various cards and widgets include a description and sample data from your tenant’s data set. You can navigate reports using the following options: Note Not all options are available on every page. - Navigate between report sheets by selecting the sheet name button at the top of each report. - The **Application Help** sheet provides detailed information about the current report. - Hover over visuals to bring up options at their upper right. Expand the size of the visual by selecting **Full Screen**. - Export to Excel by hovering over data tables or containers, then right-click and select the **Download** option. ### Filtering Online Reports You can filter the data sets according to your preferences. Some ways to filter include: - Select any individual text value within a table or chart, then use the filtering context menu that appears in the upper right corner of the visual. Select the **check mark** icon to apply the filter. - Use the filter panes across the top of each report, such as **Risk Code**, to perform advanced filtering functions on that field. By default, your cursor will appear between two asterisks, like this: * | \*. Start typing to create a Contains filter, move your cursor to the left of the asterisk wildcards for a Starts With query, or move your cursor to the right of the asterisk wildcards for an Ends With query. Examples: ```text - *Payables* would find any value that contains “Payables” - Payables* would find any value that starts with “Payables” - *Payables would find any value that ends with “Payables” ``` Selecting the **More** icon on a filter pane displays additional advanced options, such as **Select Alternative**, which is useful when you want to exclude a defined list of values. Search for and select the values you want to exclude. - **Selections Tool** icon at the upper right opens a page where you can select which data to include on your report sheet from the various filter panes. The top part of the page shows active selections, and the lower part of the page shows available fields that can be used to filter the report data. Select the icon a second time to close this view. - **Smart search** icon lets you search this report for specific data. For example, you can paste a delimited list of usernames, role names, or risk codes. - **Step back** and **step forward** icons undo or reapply your filter selections. Use them to quickly navigate between filtered states. - **Clear all filters** icon clears all applied filters at once. If you select this option accidentally, use the step back icon to reapply your filters. - **Bulk Filter** - [Download](#exporting-online-reports) a chart, open the downloaded file, then highlight and copy the data you want to include in your filter. Return to your Access Risk Management online report and select the filter pane for the data you copied. For example, if you copied risk codes, select the filter pane titled Risk Codes. In the search field, delete the asterisks, paste your copied data, and press **Enter**. Important Remember to press **Enter** after pasting your data. If you select the checkmark, the filter will not be applied. Applied filters appear as blue boxes at the top of the page and can be cleared by selecting the **X** on the right side of each applied filter. ### Customizing Table Layout Table visuals in the Online Reports can be customized. Default columns may be hidden, resized, or reordered, and optional columns may be enabled. - To customize a table visual, select the Full screen icon in the context menu that appears in the upper right corner of a table visual when you hover over the table. Then right click anywhere on the table and select the **Chart exploration** icon to open the available table configuration options. - Use this to customize the table to show only the columns relevant to your analysis. Default columns may be hidden or reordered, and optional columns can be enabled and reordered. - Select the checkbox to the left of any column name to enable or disable the column. - Select and drag a column name to reorder the columns. - Resize any column width using the column drag handles. ## Exporting Online Reports You can download results from any of the tables on the reports to an .xlsx file. To export up to 1 million rows of data, right click on any table visual and select the **Download** icon from the available chart options. Caution If you hover over a table and then select the **Download** icon at the upper right, you will only be able to download an image of the container report. To download the data in an .xlsx file, select somewhere on the table, then outside click to see the chart options. Select from that menu. To export more than 1 million rows of data, go to the **Activity History** page and select **Analyses**. Refer to [Exporting Risk Analysis Data](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/data_export.html). ## Bookmarking Layout Preferences and Filter Selections Use the **Bookmarks** option to create and manage stored views for you preferred layouts and filter sets. You can save filters only, or both filters and layouts. 1. Select the **Bookmarks** icon in the upper left corner of any report to open the Bookmarks pane. 1. Select **+ Create new bookmark** to create a bookmark or you can choose from a list of available bookmarks to switch to that view. Important Select **Save Layout** to retain any layout changes you made while using the chart exploration options, otherwise the bookmark will only save the applied filters. Tip Use naming conventions for your bookmarks that make it easier to return to them. ## Verifying the Security Analysis Used in Online Reports Below the filters, you can find the security analysis, system, and date that are the current source of your analysis and reporting data. Select the expand arrows to see a larger view of this information. To view a security analysis, go to **Activity History > Analyses**. Refer to [Exporting Risk Analysis Data](https://documentation.sailpoint.com/access-risk-mgmt/help/reports/data_export.html). # Scheduling Jobs Use Schedule Jobs to schedule reporting jobs to run either one time or on a cadence that you define. This option is available in the left navigation for the following jobs: - [Security Extract](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_security_extract.html) - [Utilization Extract](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_utilization_extract.html) - [Risk Analysis - NEW](#risk-analysis-new) - [Risk Snapshot](#risk-snapshot) - [User Analysis](#user-analysis) - [Role Analysis](#role-analysis) ## Security Extract Refer to [Scheduling Security Extracts](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_security_extract.html). ## Utilization Extract Refer to [Scheduling Utilization Extracts](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_utilization_extract.html). ## Risk Analysis NEW If you are taking advantage of the Fiori-enabled capabilities within Access Risk Management, the risk analysis is generated slightly differently and it includes SOD and Sensitive Access analyses. You can use the risk analysis for reporting as well as What If functionality. To run a risk analysis: 1. Go to **Schedule Jobs > Risk Analysis**. 1. Use the **Repeat** dropdown to indicate whether this is a one-time job or scheduled to reoccur. Options are Do not repeat, Monthly, Weekly, or Daily. - When you select **Do not repeat**, use the calendar selector to indicate the specific date range to include in the risk analysis. Use the Security Extract selector to choose which extract to apply. Tip When you select **Do not repeat**, you will get an option to **Disable block list for this Risk Analysis**. Select this checkbox to run a Risk Analysis that does not include any Block List rules. - When you select a recurring option, such as **daily**, **weekly**, or **monthly**, the utilization period is determined by your selection and a live security extract is used. Tip [Schedule Utilization Extracts](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_utilization_extract.html) to run on the same schedule, ideally 30-60 minutes before the Risk Analysis. 1. Use the **Rulebook** dropdown to select a rulebook to apply to your risk analysis. Note Risk Analysis only works with one of the new rulebooks, available under **Risks > Rulebooks > Multi-System Rulebooks**. 1. In the Extract field, use the **Edit** icon to choose an extract. If you want to remove it, select **Clear**. 1. Utilization Data Range defaults to one year. Select the calendar icons to customize your date range. Note Utilization data is pulled from the SAP Security Audit Log (SM20). If the data does not exist in SAP, it cannot be extracted. Make sure to use an Access Risk Management agent released in July 2024 or newer. Existing customers prior to July 2024 need to schedule utilization extracts in order to import data from the SAP Security Audit Log, since that is the new source for all utilization data. Here’s how: Once you’ve [configured your agent](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/sap/connect/index.html), [schedule utilization extracts](https://documentation.sailpoint.com/access-risk-mgmt/help/erp/schedule_utilization_extract.html) for each of the prior months. After running those jobs and extracting the data you need from the new data source, your new risk analyses will include the appropriate data. If you need assistance, contact support. 1. Under Generate Reports, select the **Include Reports** checkbox to use new Risk Analysis data to refresh all of your online reports. Note When **Include Reports** is unselected, the Risk Analysis job will only refresh data used for performing What If analyses. 1. Select **Submit**. ## Risk Snapshot All online reports are part of the Risk Snapshot. To schedule this job, select **Schedule Jobs > Risk Snapshot**. The following information needs to be populated to schedule a risk snapshot: - **Repeat** - Used to determine if this is a one-time job or scheduled to reoccur. The options are to not have it repeat and just run once, or schedule it to run monthly, weekly, or daily. SailPoint recommends running the risk snapshot at least monthly to ensure you are capturing the historical information around user access and monthly utilization data since SAP only retains it for three months. Many organizations choose to run the snapshot more frequently, such as weekly if weekly transports to production are done or even daily if a project is taking place that has constant updates being made in SAP. Note If you schedule a job to run on a recurring basis, the Security Extract and Utilization Extract can only be set to use live data. You can review all recurring jobs by selecting **Recurring Tasks** from the left navigation. - **Report Name** – Enter a name or review and accept the default report name. The default includes the date/time, user who scheduled the job, and the rulebook included. - **Email when done** - Email to receive notification of completion of the risk snapshot job. This defaults to the user who is scheduling the snapshot. - **Security Extract** - Select if you want to use live data, which will run a new security extract to base the snapshot on, or a previously completed security extract. Note The Use Live Extract option schedules a new security extract to be run as part of this job. It must complete before the scheduled job can continue, so it can take a bit longer than using an existing extract. - **Rulebooks** - Select which rulebook(s) to use for the analysis. - **Months of Utilization** - Select how many months of utilization to include on the snapshot. This defaults to the maximum, which is 12 months, or you can select a shorter time. - **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 older than three. - **Include Types and Statuses** - Select the checkboxes next to the types and statuses you want to include After you select **Submit**, you can view the status of your snapshot report on the [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) page. ## User Analysis A User Analysis creates a downloadable archive that includes .db and .json files with security analysis information for the users selected. To schedule this job, select **Scheduled Jobs > User Analysis**. The following information needs to be populated to schedule the user analysis: - **Repeat** - Used to determine if this is a one-time job or scheduled to reoccur. You can choose to run the job once or schedule it to run monthly. Note If you schedule a job to run on a recurring basis, the Security Extract and Utilization Extract can only be set to use live data. You can review all recurring jobs by selecting **Recurring Tasks** from the left navigation. - **Analysis Name** - Enter a name or review and accept the default analysis name. The default includes the type of analysis, email of the user who scheduled the job, environment, and the date/time. - **Security Extract** - Select whether you want to use live data, which will run a new security extract to base the snapshot on, or a previously completed security extract. Note The Use Live Extract option schedules a new security extract to run as part of this job. It must complete before the scheduled job can continue, so it can take a bit longer than using an existing extract. - **Rulebooks** - Select which rulebook(s) to use for the analysis. - **Include Types and Statuses** - Select the checkboxes next to the types and statuses you want to include. - **Users Selection** - Use the **Include**, **Exclude**, and **+Add Users** buttons to select who to include. After you select **Submit**, you can view the status of your job on the [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) page. ## Role Analysis A Role Analysis creates a downloadable archive that includes .db and .json files with security analysis information for the roles selected. To schedule this job, select **Scheduled Jobs > Role Analysis**. The following information needs to be populated to schedule the role analysis: - **Repeat** - Used to determine if this is a one-time job or scheduled to reoccur. You can choose to run the job once or schedule it to run monthly. Note If you schedule a job to run on a recurring basis, the Security Extract and Utilization Extract can only be set to use live data. You can review all recurring jobs by selecting Recurring Tasks from the left navigation. - **Analysis Name** - Enter a name or review and accept the default analysis name. The default includes the type of analysis, email of the user who scheduled the job, environment, and the date/time. - **Include Types and Statuses** - To include unassigned roles in the analysis, select the Unassigned Roles checkbox. - **Security Extract** - Select if you want to use live data, which will run a new security extract to base the snapshot on, or a previously completed security extract. Note The Use Live Extract option schedules a new security extract to run as part of this job. It must complete before the scheduled job can continue, so it can take a bit longer than using an existing extract. - **Rulebooks** - Select which rulebook(s) to use for the analysis. - **Roles Selection** - Use the **Include**, **Exclude**, and **+Add Roles** buttons to select who to include. After you select **Submit**, you can view the status of your job on the [Activity History](https://documentation.sailpoint.com/access-risk-mgmt/help/activity/index.html) page. # Using Access Risk Management with Identity Security Cloud The integration between Identity Security Cloud and Access Risk Management gives you the ability to perform fine-grained separation of duties (SoD) analysis of SAP permissions at the authorization object level as part of your access request process in Identity Security Cloud. Using the Access Risk Management [What-If analysis](https://documentation.sailpoint.com/access-risk-mgmt/help/whatif/index.html) simulation engine, this integration flags SoD risks so that approvers can make informed decisions and maintain compliance with company policies. Refer to [Reviewing Access Requests](https://documentation.sailpoint.com/saas/user-help/approvals/reviewing_access.html). Note Using Access Risk Management with Identity Security Cloud requires that your implementation has SAP set up as a source. Contact SailPoint Professional Services for assistance. Identity Security Cloud and Access Risk Management work together as follows: Refer to [Requesting Access](https://documentation.sailpoint.com/saas/user-help/requests/request_center.html#requesting-access) for details about requesting access to SAP in Identity Security Cloud. Important - You cannot simulate risks for entitlements across multiple SAP systems. - While ISC currently aggregates SAP profiles as entitlements, the ability to run SOD simulations on SAP profiles has not yet been implemented. Therefore, if an access request includes entitlements that are SAP profiles, the What If simulation does not include the permissions from these entitlements, only the permissions from the SAP roles.