Knowledge Article

Access Risk Management Milestone

Author

ryan_cutter
SailPoint

Access Risk Management (ARM) milestone automates the monitoring and management of access risks within organizations, helping to minimize potential breaches, reduce fraud, expedite remediation, and detect insider-led security threats. IT & Security teams can utilize ARM to assess separation of duty (SoD) risks before granting user access, streamline access reviews and manage emergency access workflows with auditable controls. Compliance & Audit teams can benefit by accelerating compliance processes, thereby reducing costs through automation and audit-ready reports to enhance their overall security and efficiency.

1 Setup Infrastructure

Resources:

Agent Setup for VM

Tenant Setup

Advice:

Ensure that the tenant is provisioned in the correct Data Center:
- US East: For customers in America and Latin America geos.
- North Europe: For customers in Europe and APJ geos.
Provide an email address of the user who will have default administrator rights for the tenant.

Note: The SailPoint Support team is responsible for the above operations and will share details on next steps.

Pitfalls:

Incorrect data center selection can cause delays.
Not providing the default administrator’s email address can slow down the process.

Prerequisites for ARM Agent VM Setup

Advice:

The ARM agent acts as middleware, sitting between the SAP systems and the ARM cloud server. It is crucial to configure the ARM agent properly for optimal performance.

ARM agent must be set up on Windows Server 2012 or a later version.
Microsoft .NET Framework 4.8 or higher is installed on the VM
Visual Studio 2010 (VC++ 10.0) and Microsoft Visual C++ 2010 Redistributable Pack (x86) are installed on the VM
Ensure the hosting machine is on the same network as the target SAP system and is restarted every month
Port 443 on the VM side and port range 3200-3400 are opened on the SAP side

Pitfalls:

ARM agent can only be installed on Windows machines.
Incorrect VM specifications or missing prerequisites can lead to installation failures.

Whitelist URLs

Advice:

Ensure the following URLs are whitelisted for US and EU-based tenants before ARM agent installation.

For US-based tenants:

For EU-based tenants:

Pitfalls:

Failing to whitelist the required URLs may cause connection issues. and unknown errors
If Cloudflare is used, ensure IPs are allowed.
If a proxy is configured on the Windows machine, additional settings are required during the agent installation. Please contact the SailPoint team for assistance with setting up the agent using a proxy.

SAP Source Configuration prerequisites

Advice:

Install the SailPoint Add-on in your SAP system as instructed by the SailPoint team. The Add-on replaces the RFC_READ_TABLE standard function module with a secure version.
Upload all SAP roles provided by the ARM team to your SAP system.
Create a dedicated service/system user for RFC communication and assign all required SailPoint roles in your SAP system.
Enable Security Audit Logs in the SAP system.
For CUA setups: (This step is required only if the SAP source system provisioning is routed via a CUA system)
- Add the CUA parent system details in the ARM agent configuration for the child system.
- Create the RFC service/system user in both the CUA parent and child systems.
- Assign the ARM agent roles in both systems.
- Use the same password for the RFC user in both systems.

Note: While RISE with SAP isn’t officially supported, connecting to ARM through the SAP S/4HANA infrastructure is possible.

Full compatibility and support for RISE-specific components are not guaranteed.

Pitfalls:

Not installing the SailPoint Add-on correctly may cause data extraction failures.
Missing or outdated SAP roles can cause access and sync issues.
Incorrect or missing roles for the RFC user block communication with SAP.
Audit logs being disabled or incomplete may cause monitoring gaps.

Configure Security Audit Logs

Advice:

When setting up RSAU_CONFIG / SM19, keep the following points in mind:

Log Storage: Store audit logs in the file system only. ARM cannot read logs stored in the database.
Log Frequency: Ensure there is only one log file per day for security audit logs.
Active Audit Classes: ARM collects only audit classes for transactions with message IDs AU3 and CUI. Make sure these audit classes are active in both dynamic and static configurations.

Pitfalls:

Storing logs in the database prevents ARM from reading or processing audit data.
Having multiple log files per day can cause confusion and data inconsistencies.
Leaving audit classes AU3 and CUI inactive will prevent ARM from capturing essential security audit data.

Configure ARM Agent Settings

Advice:

Install the ARM agent and enter SAP system credentials accurately.
Match the SAP system time zone with the ARM agent configuration.
Enter the service/system user credentials in the username and password fields.
Check “Use SailPoint table extraction” if the SailPoint Add-on is already installed.
If CUA is enabled, check “Is CUA enabled” and enter the CUA parent and child system details correctly.
In Utilization Options:
- Keep SAPWL_WORKDLOAD_GET_STATISTIC selected (default).
- Select USE_RSAU_READ_LOG for SAP BASIS 750 or higher.
- Use SM20 variable data column or Transaction code column for BASIS below 750.
- To verify RSAU_READ_LOG availability:
  - Log in to SAP → Run SE37 → Search for RSAU_READ_LOG.
  - If it exists, it can be enabled in ARM.
Leave Opt out of STAD logs for SM20 unchecked (opt-out).
Under “Application server collection”, add additional app servers (but not the central instance).
Contact the SailPoint ARM team for configuring job hooks to filter unwanted data.

Pitfalls:

Time zone mismatches can lead to sync and log timestamp issues.
Not selecting SailPoint table extraction when the Add-on is installed may cause extraction errors.
Selecting the incorrect utilization option for your BASIS version may cause log collection failures.
Forgetting to add additional SAP application servers results in incomplete data collection.

Job Hooks for Data Filtering (Optional)

Advice:

ARM allows you to filter out unwanted data before sending it for analysis.
You can configure an SQL script under the Job Hooks section in the agent UI.
Contact the SailPoint ARM team for assistance with job hook configuration.

Pitfalls:

Not setting up filters may allow irrelevant or excessive data into the system.
This can result in longer report load times and longer risk analysis job durations.

2 ARM User Management

Resources:

Manage ARM users and assign ARM Roles

Advice:

In Manage Users, use Export to download the template and Import to upload the .xlsx file with user data.
Bulk user creation and updates can be done through file import; individual user management is handled through the UI.
When performing bulk updates, append new user details to the exported file and leave existing users intact to avoid accidental soft-deletion.
To suppress welcome emails (especially with SSO enabled), set SendWelcomeEmail = False in the import file.
Add the SSO Name if ARM is configured for single sign-on.
Provide the ERP User ID (SAP ID) if the user will perform access reviews or require temporary elevated access.
Ensure each new user is Active and assigned at least the Default Standard and Reporting roles.
Assign ARM roles by selecting the user in User Management and choosing + Add User Roles.
Assign Reporting Groups to users to grant access to specific reports, such as EAM Profile, Fiori Reporting, and User Risk History reports.
Email addresses cannot be modified by ARM administrators.
- Note: Please contact the SailPoint Support team to change user's email address.
Managing users across multiple ARM tenants (e.g., Sandbox and Production) is not currently supported through the front-end.
- Note: Please contact the SailPoint Support team to grant users access to multiple tenants.
Users once deleted cannot be restored from the UI
- Note: Please contact the SailPoint Support team to restore accidentally deleted users.
As a best practice, set the username to match the user’s company email address.
ARM enforces global uniqueness for usernames, so using the email address helps ensure the username is unique across all tenants and companies.

Pitfalls:

Removing users from the bulk import file will soft-delete them from ARM.
Incorrect bulk file handling during mass updates may unintentionally remove or disable users.
Forgetting to set users as Active or failing to assign required roles may block their access.

Change Logs

Advice:

ARM provides change logs for Users, Mitigating Controls, Rulebooks, and EAM Profiles.
User Change Logs:
- Navigate to Manage Users → Dashboard.
- Select a date range and click Submit to view changes, including timestamps.
- Last login details are not included; request via a support ticket if needed.
Rulebook Change Logs:
- Go to the Rulebooks Dashboard, select the rulebook, choose a date range, and click Submit.
- Multi-system rulebook changes follow the same steps.
EAM Profile Change Logs:
- Access via EAM Profiles Dashboard, select All Systems or a specific system, set a date range, and submit.
Mitigating Control Change Logs:
- Access via Mitigating Controls Dashboard, select a date range, and submit.
Monitoring & Downloading:
- Track all change log jobs in Activity History → Change Logs tab.
- Reports can be downloaded in Excel/CSV format from the same tab.

Pitfalls:

Last login information is not included in user change logs; assuming otherwise may cause confusion.
Not selecting the correct system in EAM Profiles or Rulebooks dashboards may result in incomplete or irrelevant logs.

Schedule Automatic Logouts (Optional)

Advice:

Automatically logout idle users sessions after a specified period of inactivity.

Select My Settings.
Choose the desired logout times (days, hours, minutes, seconds).
Select Schedule.

Single Sign-on Integration (Optional)

Advice:

ARM supports SSO with Azure AD or SAML 2.0 Identity Providers (IdP).
Ensure all required information from the IdP team is collected before contacting SailPoint Support.
To enable SSO:
1. Obtain the metadata URL of SailPoint ARM if needed for your IdP configuration.
2. Create an application in your IdP for ARM.
3. Share the application’s metadata URL with SailPoint.
4. Provide SailPoint Support with your vanity URL and your application’s metadata URL.
If you have two ARM instances, create one IdP application; SailPoint will create two vanity URLs pointing to the same application.
Open a support ticket when you are ready to enable SSO.

Pitfalls:

Attempting to configure SSO without collecting all IdP information may cause delays.
Creating multiple applications in the IdP for multiple ARM instances is not needed and may cause configuration issues.
Not opening a support ticket may delay SSO enablement.

3 Scheduling Background jobs

Resources:

Schedule SAP User Synchronization Jobs (Security Extracts)

Scheduling Jobs in ARM

Advice:

Scheduling jobs allows you to automate and manage reporting tasks for security, utilization, and risk analysis. You can schedule these jobs to run at a specific frequency—either as one-time jobs or on a recurring cadence such as daily, weekly, or monthly. The jobs available for scheduling include:

Security Extract
Utilization Extract
Risk Analysis
Risk Snapshot
User Analysis
Role Analysis

Each of these jobs plays a vital role in aggregating, analyzing, and reporting security data, helping organizations stay proactive in identifying and managing access risks.

Pitfalls:

Scheduling jobs without considering system data dependencies (like live vs. existing extracts) may cause delays or incomplete reports.
Over-scheduling jobs too frequently may create unnecessary system load, especially with large data extractions.

Schedule SAP User Synchronization Jobs (Security Extracts)

Advice:

Security Extract job helps extract user and role data from SAP systems into ARM for security analysis, reporting, access reviews, and What-If analysis.

Navigate to Schedule Jobs --> Security Extract in the ARM interface.
In the Repeat dropdown, select the desired frequency (Daily, Weekly, Monthly) or Do Not Repeat for a one-time extract.
If scheduling a recurring extract, specify the details (time, day, etc.).
Enter a descriptive name in the Recurrence Name field.
Click Submit.
Monitor the job status on the Activity History page under the Security Extracts tab.
SailPoint ARM uses RFC_READ_TABLE by default for data extraction.

Note: Due to potential performance issues with RFC_READ_TABLE, especially with large datasets, consider using the SailPoint Add-on. This add-on replaces the standard function module with a more efficient alternative.

Pitfalls:

The security extract job may fail due to data inconsistencies in SAP (e.g., duplicate users, table overflows in USR* tables). ARM performs validation checks post-extraction to ensure data accuracy.

Note: If the job fails, please contact the SailPoint Support team for investigation. Do not proceed without addressing the underlying data issues in SAP.

Schedule Utilization Extracts

Advice:

For analysis alongside security extracts, extract the utilization metadata from SAP systems, which helps provide data for online reports, Excel reports, and access reviews.

Verify that the correct settings are selected at the ARM agent level within the ARM Agent Settings.
Ensure the time zone selected on the ARM agent matches the SAP system time zone for time-zone consistency.

Navigate to Schedule Jobs --> Utilization Extract in the ARM interface.
In the Repeat dropdown, select the desired frequency (Daily, Weekly, Monthly) or Do Not Repeat for a one-time extract.
If scheduling a recurring extract, specify the details (time, day, etc.).
Enter a descriptive name in the Recurrence Name field.
Ensure the source of the utilization data is correctly selected (SAL from SM20/RSAU_READ_LOG or STAD) within the ARM Agent UI.

Pitfalls:

The utilization extract may fail or return blank data if the Security Audit Log (SAL) Configuration is not properly configured in the SAP system.
Data Availability: Utilization data is pulled directly from SAP’s Security Audit Log. If transaction data is not available in the system, the extract will not retrieve any data.
Legacy Systems: Customers with systems before July 2024 need to schedule utilization extracts to import data from the SAP Security Audit Log. Ensure your system is updated to take advantage of newer features.

Note: Ensure the SAL is configured according to SailPoint's recommendations.

Risk Analysis

Advice:

Risk Analysis is used for generating Separation of Duties (SOD) and Sensitive Access analysis reports, which are crucial for monitoring access risks. This feature is available in Fiori-enabled environments and uses new rulebooks.

Scheduling Tips:

Regularly schedule Risk Analysis to track and mitigate access risks. Align it with your extract schedules to ensure data consistency.

Pitfalls:

Rulebook Compatibility: Risk Analysis only works with new rulebooks available under Risks → Rulebooks → Multi-System Rulebooks. Ensure you have the correct rulebook before running the analysis.
Data Source Limitation: If the data is not updated or security logs are incomplete, the risk analysis may produce inaccurate results.

Risk Snapshot

Advice:

The Risk Snapshot job gathers data for all legacy online reports related to user access and risk. It helps capture historical access data and provides a snapshot of current risks.

Scheduling Tips:

Monthly or Weekly Scheduling: Run the Risk Snapshot at least monthly to capture user access data, especially since SAP only retains access data for three months.
If your organization performs frequent updates (e.g., weekly transports or project-based changes), consider running it weekly or daily.

Pitfalls:

Frequency: Risk Snapshots should be scheduled based on your organization’s needs. Running them too frequently can create excessive system load, while infrequent snapshots may miss critical updates.
SAP Retention Policy: SAP retains historical access usage data for only three months. Therefore, it's essential to run the snapshot at least once a month to avoid losing important historical data.

User Analysis

Advice:

The User Analysis job generates downloadable archives (.db and .json) containing security analysis information for selected users. This report is useful for auditing and understanding user-level risks.

Scheduling Tips:

Schedule User Analysis jobs to run on a monthly cadence to regularly capture user-specific access information.

Role Analysis

Advice:

The Role Analysis job generates a downloadable archive (.db and .json) that provides detailed security analysis for selected roles. This analysis is helpful in assessing role-based risks across your organization.

Scheduling Tips:

Schedule Role Analysis monthly to ensure you have up-to-date data on role-based access risks.
Align it with the Security Extract to ensure that role data is synchronized and accurate.

General Scheduling Tips

Advice:

Review Recurring Jobs: You can monitor all scheduled recurring jobs by selecting Recurring Tasks from the left navigation. Ensure these jobs are running as expected without conflict or delays.

Pitfalls:

Over-Scheduling: Too many jobs scheduled to run frequently may strain system resources, leading to delays or failures.
Outdated Agents: Ensure you are using an Access Risk Management agent from July 2024 or newer to avoid compatibility issues with newer job types like Utilization Extract.

4 Access Rule Maintenance

Resources:

Managing Rulebooks

Managing Rulebooks

Managing Rulebooks

Advice:

Rulebooks define the rules for separation of duties (SoD) and sensitive access (SEN) that will be tested within the application. A rulebook comprises rules, business functions, and the associated permissions that constitute their risk.
Access Risk Management provides baseline rulebooks containing over 240 SoD risks and 8 sensitive access risks. While the default rulebooks cover most organizations' needs, you can customize them. Customizations include creating or adding new rules, excluding rules from analysis, changing risk ratings, and adding custom transaction codes.

Note: Most implementations define between 50 and 500 rules in a rulebook. If you need to define more than 500 rules, engage an SAP advisory partner to help clearly define your security needs and create a rulebook that meets those needs.

Rulebook Types

SailPoint provides two types of rulebooks: Legacy and Multi-System.

Legacy rulebooks: These are used for legacy reporting and will be deprecated soon.
Multi-system rulebooks: These are used for Firefighter report generation, New Access Reviews, and new Fiori-based reporting.
- Note:
  - If using legacy reporting and the Firefighter module, maintain both Legacy and Fiori rulebooks. If using Fiori reporting and not legacy reporting, only the multi-system rulebook is needed.
  - Also, if the customer's ISC tenant is integrated with ARM, the multi-system rulebook is used for that integration.
The rulebook provided by SailPoint is a baseline rulebook. We provide rulebooks for ECC, S/4HANA, and Fiori systems.
We use ServiceIDs for Fiori apps in the rulebook.
A basic understanding of SAP SoD risks is important before customizing the rulebook. Engage an SAP advisory partner to review the rulebook periodically.

Managing Rules

Advice:

The Rule Dashboard displays the rules within a selected rulebook. Each rule can be expanded to show its business functions, permissions, authorization objects, and their values.

To edit rule details: Select the Info icon in the rule row, make your changes, and select Save.
To add an existing rule: Select + ADD and then the Add icon on the desired rule row. Use the search field to find specific rules.
To add a new rule: Select + New, enter the rule details, and select Save.
To remove a rule: Select the Remove icon.
Ensure the rule type is set correctly.
When a rulebook is active, all its rules are considered during risk analysis for report generation. Remove any obsolete rules from the rulebook.

Managing Business Functions

Advice:

To display a rule's business functions, select the Expand icon next to a rule name. Sensitive access rules contain one business function, while SoD rules contain more than one.

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.

Pitfalls:

Ensure the business function is mapped to the rules correctly.
Verify that the object logic and transaction code logic are set correctly. In the ARM baseline rulebook, the object logic and transaction code logic are set to "OR" by default, but you can change this.

Managing Permissions

Advice:

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.

Pitfalls:

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.

Editing Rulebooks Offline

Advice:

Rulebooks can be edited or created offline by exporting/importing .xlsx files.
To edit an existing rulebook:
1. Export your rulebooks and select Export All.
2. Use the tabs in the exported file to view components like rules, business functions, permissions, etc.
3. Make edits directly in the .xlsx file.
4. Import the updated file back into ARM.
Ensure the rulebook and all rules are set as active so they are considered in risk analysis jobs.

Pitfalls:

Failing to select Export All may result in missing data or overwritten content during import.
Importing a new rulebook will overwrite existing rulebooks—exercise caution.
Inactive rulebooks or rules will cause risk analysis jobs to return blank results or reports.
When editing a rulebook offline, ensure that you do not remove any existing rulebook entries. Instead, append new items below the existing ones. If you remove any rows from the rulebook file, ARM interprets it as a deletion request and will remove the corresponding entry from the rulebook. Therefore, when adding new permissions, business functions, or other permissions, add the new entries below the existing ones and avoid deleting existing items from the rulebook.

How Permissions Are Defined and Work in ARM Rulebooks

Advice:

Permissions in the ARM rulebook consist of three primary components: Transaction Codes (TCODEs), Objects, and Field Values.
TCODE Logic
- Logical Operators:
  - AND: A hit is generated only if the user or role has access to all specified transactions.
  - OR: A hit occurs if the user has access to at least one of the specified transactions.
  - Default Condition: Transactions are generally treated with "OR" logic for both sensitive access and Segregation of Duties (SoD) risks.
Object Logic
- Authorization Objects: This logic operates at the level of authorization objects. The key consideration is whether the user needs access to:
  - All Objects (AND): All specified objects must be accessible for a hit.
  - At Least One Object (OR): Access to any one of the specified objects is sufficient for a hit.
Field Level Logic
- Field Value Level: If multiple values are defined for the same field, they are always treated as "OR."
  - Example:

S_USER_PRO ACTVT 01S_USER_PRO ACTVT 02

This configuration will check for '01' OR '02'.

The logic for different fields within an authorization object is always "AND." Therefore, if an authorization object contains two fields in the rulebook, the user must have access to both fields to trigger a hit.
Example:

S_USER_PRO ACTVT 01S_USER_PRO ACTVT 02S_USER_PRO PROFILE "SUPER"S_USER_PRO PROFILE "TEST"

This configuration will check for these combinations:
"01" + "SUPER"
"02" + "SUPER"
"01" + "TEST"
"02" + "TEST"

Configuring Rulesets for Any Value vs. Wildcard '*' Value

Advice:

When a business function code is configured with a literal '*' (asterisks in single quotes) value in the rulebook, the application checks only for the specific * value of the SAP role.
When a business function code is configured with an unquoted * (asterisk) value in the rulebook, the application checks for any value, including * of the SAP role.

How ARM Works When Multiple Business Functions Are Mapped to a Single Sensitive Risk

Advice:

When configuring ARM Rulebook, it's important to understand how the system interprets sensitive risks that are mapped to multiple business functions. Incorrect configuration can lead to risks not being triggered as expected, resulting in false negatives during risk analysis.

System Behavior

When multiple business functions are mapped to a single sensitive risk, ARM requires at least one hit from each mapped business function simultaneously in order to trigger that sensitive risk. In other words, the system treats the mapping as a logical AND condition rather than an OR condition.

Example Scenario:

Sensitive Risk A is mapped to Business Functions X, Y, and Z.

For ARM to flag Sensitive Risk A, there must be at least one hit in each of the functions X, Y, and Z at the same time.

If only Business Functions X and Y are triggered, but Z is not, the risk will not be flagged.

Pitfalls:

To avoid unintended behavior and improve accuracy in risk detection, we recommend the following:

Do not map multiple business functions to a single sensitive risk. Instead, create separate sensitive risks for each business function. This allows each risk to be triggered independently, based on its specific business function activity. This approach ensures better risk visibility, simplifies analysis, and aligns more closely with how ARM evaluates access data.

Adding Custom Transaction Codes to a Rulebook

Advice:

To add a custom transaction code (T-code) to a rulebook:

Use an existing Business Function or create a custom one with:
- Business Function Code
- Business Function Name
- Business Function Description
  - Populate these values in the Business Functions tab.
In the Permissions tab:
- Scroll to the last row and add a new row below.
- Fill in: Business Function Code, Custom Transaction Code (T-code), Authorization Object, Authorization Field, and Value.
If a new business function is created, ensure it is mapped to at least one SOD or sensitive risk.
Save the file and import it into ARM.

Pitfalls:

Not mapping a new business function to at least one SOD or sensitive risk may result in file import failure

5 Mitigations

Resources:

Mitigations Overview

Advice:

Mitigating Controls reduce risks from conflicting user access.
Use automated system controls (e.g., three-way match) or manual controls (e.g., manager review) to enforce security.
Regularly review mappings using the Risk Mapping Tab to track which risks are mitigated.
Use spreadsheets for bulk import/updates, ensuring all fields and mappings are accurate.

Pitfalls:

Incomplete Data on Imports: If the spreadsheet is missing data (like control codes or rulebook names), existing mappings will be overwritten or deleted.
Incorrect Rulebook or Risk Codes: Mismatched rulebook names or risk codes can result in failed mappings, leaving some risks unmitigated.
Inconsistent User Mapping: Using “All Users” or “Specific Users” mapping rules incorrectly can either apply controls too broadly or not at all.

Managing Mitigating Controls

Advice:

Maintenance Page: Go to Risks --> Mitigating Controls to view and manage controls.
Key Tabs:
- Mitigating Controls Tab: Lists all controls with details.
- Risk Mapping Tab: Displays how controls are linked to risks.
- Mapping Rules Tab: Shows specific users or systems mitigated by the controls.
Control Actions:
- Use the Actions dropdown to enable/disable controls.
- Use Search and filters to find specific controls quickly.

Pitfalls:

Disabled Controls: Disabling a control does not remove its mappings. It won’t be evaluated unless re-enabled.
Outdated Mappings: Inactive or expired controls may distort risk assessments.
Mitigation: Regularly update Valid From/To dates and ensure controls are enabled.

Mitigating Controls Tab

Advice:

Control Details:

Control Code: Unique identifier.
Control Type: Automated/manual, preventative/detective.
Valid From/To: Defines when the control is active.
Enabled: Must be True for the control to be evaluated in risk analysis.
Owner(s): At least one owner should be assigned.

Pitfalls:

Inactive Controls: Controls not enabled won’t be evaluated during risk analysis.
Mitigation: Always verify and enable controls to ensure they’re active.
Missing Data: Incomplete data (e.g., dates, owner details) can leave controls improperly monitored.
Mitigation: Ensure all required fields, especially dates and owners, are filled..

Risk Mapping Tab

Advice:

Linking Controls to Risks: One control can mitigate multiple risks.
Control Disabled: If a control is disabled, its mapping remains but won’t be evaluated in the analysis.

Pitfalls:

Unmapped Risks: Unlinked controls may not be included in the analysis.
Mitigation: Double-check mappings to ensure alignment with the rulebook.
Mitigation: Periodically review mappings to remove redundancies.

Mapping Rules Tab

Advice:

Rule Types: Map controls to All Users or Specific Users based on your needs.
Mitigated Entity Notes: Use this field to add context on mitigated users.

Pitfalls:

Incorrect User Mapping: Mismatched ERP_SYSTEM_USER_ID could prevent controls from applying correctly.
Mitigation: Ensure accurate usernames and IDs, especially for Specific User mappings.

Importing Mitigating Controls

Advice:

Importing controls via spreadsheet can save time, but make sure all necessary data is included in the template to prevent accidental overwrites.
Validate data in Excel templates before uploading, ensuring all control and user mappings are correct.
Set activation dates using the Valid From and Valid To fields to manage control validity over time.

Pitfalls:

Full Overwrite Risk: Importing controls without full data can lead to unintended deletions. Always check for completeness..
Activation Delays: If the Is Enabled value is set to FALSE, controls will not be activated, leaving some risks unmanaged

Viewing Mitigations in Risk Analysis

Advice:

Once mitigations are mapped, they will be automatically evaluated during risk analysis (e.g., SoD, Sensitive Access, What-If Simulations).
Ensure a multi-system rulebook defines risks and that controls are correctly uploaded and mapped.

Pitfalls:

Unaccounted Controls: Controls not properly mapped won’t be evaluated in the analysis.
Mitigation: Always check mappings before running reports.
Inaccurate Risk Evaluation: Incorrect user or rule data can skew analysis results.
Mitigation: Review data for accuracy before running risk assessments.

6 Access Risk Analysis

Resources:

User What If Analysis

Advice:

ARM supports two types of What If analysis: User Level and Role Level.

User-level simulates the impact of assigning roles to a new user. Use this to assess whether the user’s role assignments would introduce any new access risks.

User level What-IF:

Go to What-If Analysis > User-level
Select “New User” to simulate a new user with no roles.
For existing users, click + Add Users to open the Users Selection window.
Filter Users using criteria like username, full name, user group, and user type.
Search Users by entering keywords and selecting the Search icon.
Add Users:
1. Use + Add All to select all filtered users.
2. Select individual users using the + next to their username.
3. Add users via comma- or line-separated SAP UserIDs at the bottom of the screen.
After adding users, select X to close the window.

Role Selection and Changes - Remove Existing Roles

Advice:

To assess the impact of removing roles from users, select roles to remove and simulate potential risk reductions.

Process:

Filter Roles by role name, username, or other criteria.
Search for roles to remove.
Select Roles by clicking – next to the role name.
Add All to remove all filtered roles.

Click X to close the window after making your selections.

Role Selection and Changes - Add Roles

Advice:

To simulate the impact of adding roles to users, select roles and assess if new risks emerge.

Process:

Filter Roles by role name, location, or description.
Search for roles to add.
Select Roles by clicking + next to the role name.
Add All to include all filtered roles.
Add roles via a comma- or line-separated list of UserIDs.

Click X to finalize your selections.

Pitfalls:

Adding multiple roles simultaneously can increase complexity and overlook potential conflicts.
Role-level What-If Analysis

Role What If Analysis

Advice:

Role What If Analysis simulates how changes to role compositions—either adding or removing permissions, or actions—impact access risks. It helps assess potential separation of duties (SoD) or sensitive access violations before changes are implemented. The analysis provides decision-makers with data-driven insights to ensure compliance and proper risk mitigation.

Pitfalls:

Skipping risk review or mitigation steps may lead to residual or unaddressed risks.
Outdated rulebooks or extracts may cause inaccurate simulations.

Simulating Single Role Changes

Advice:

Use this simulation to test the effect of adding new actions, transactions, or authorization objects.

Steps:

Select + Add Action to define the role changes.
Existing actions in SAP Authorization Defaults auto-populate fields; others must be entered manually.
Review and adjust authorization fields and values as needed.

Pitfalls:

Incomplete authorization data may prevent accurate evaluation.
Unpopulated field values will not be included in the analysis.

Composite Role Simulation

Advice:

Simulate adding or removing single roles within a composite to assess changes to cumulative risk exposure.

Steps:

Use + Add Roles or – Remove Existing Roles to modify composite role structure.
Add or remove individually using + / – or in bulk with Add All / Remove All.
Close the selection window with X when done.

Pitfalls:

Adding or removing roles without assessing dependencies may introduce hidden conflicts.

Reviewing Role What If Results

Advice:

Access the Role Simulations tab to view high-level results of all simulations.

Results Table Includes:

Actions: View, Export, Rerun with Changes, Rerun without Changes.
Status: Pending, Completed, or Faulted.
Type: Single Role or Composite Role.
Role Name / Name: Role and simulation name.
% User Risk Mitigated: Percentage of risks currently mitigated.
Role Risk Count: Total existing and newly added risks.
Rulebook / Completion / Created Dates / Created By: Metadata for traceability.

Reviewing Risk-Level Details

Advice:

Drill into the Risk Analysis view to review role and user-level risk impacts.

Role Impacts

Displays inherent risks introduced, removed, or changed by the simulation. Includes:

Simulation Impact (Existing, Changed, or Removed).
Role Name, Risk Code, Risk Name, Risk Rating.
Business Process / Function details.
Permission Hits Count, Role Location, and Description.

Exporting:

Select Actions → Download to export results. Files appear under Activity History → Data Exports.

Request Details

Advice:

Use Request Details to verify simulation context and outcome metrics.

Information Displayed:

Role Name, Request ID, Creation and Extract Details.
Analysis ID, Rulebook ID/Name.
Counts of new, existing, and removed risks.
Roles added or removed during the simulation.

Applying Mitigations

Advice:

Mitigations can be applied directly within the Risk Level view to address identified risks proactively.

Steps:

Select Actions → Apply Mitigation for a specific risk.
In the Mitigations Available window, choose View Details or Apply Mitigation.
Add a comment in the Mitigation Note field and optionally set an expiration date.
Click Submit to confirm.

Note: Only users with Mitigating Control Administration or Mapping permissions can apply controls.

Reviewing Risk Permission Details

Advice:

The Detail Level page provides granular entitlement and authorization information to validate simulation results.

Details Include:

Change Type: Added, Removed, or No Change.
Business Function Code / Name, Permission Group.
Auth Object / Field, SAP Value From–To, Risk Value From–To.
Role Name / SAP Profile / Derived / Parent Role.
- Use the Filter icon to refine results and Request Details for metadata. Select Back (top right) to return to the main view while preserving filters.

Pitfalls:

Ignoring field-level values can hide critical permission conflicts.

Rerunning a What-If Analysis

Advice:

Quickly re-execute simulations with or without parameter modifications to validate change
Options:
- Rerun with Changes: Opens pre-filled simulation allowing parameter updates.
- Rerun without Changes: Executes immediately with the same parameters.
  - Updated mitigations are automatically included in both rerun options.

Note: “Rerun without Changes” uses the same baseline and may not reflect current system data.

Understanding the What-If Analysis

Exported CSV files serve as detailed audit evidence containing parameters and results for every risk analyzed.

Parameters Section Includes:

Simulation ID, Customer ID, System ID.
Rulebook, Extract ID/Date, Analysis ID.
Baseline Analysis Date, Creation/Completion Times, Requested By.

Results Section Includes:

Simulation ID, User, Full Name.
Role Added/Removed, Change Type (Added/Removed/No Change).
Impact (New, Existing with Changes, or Removed Risk).
Risk Name, Code, Rating, Business Process, Function Details.
Auth Object, Field, SAP and Risk Values.
SAP Profile, Derived?, Parent Role.
- Filter Existing Risk with Changes to identify residual permissions requiring remediation.

Pitfalls:

Misreading “Existing Risk with Changes” can cause incorrect conclusions about residual risk.

Common Pitfalls Summary

Simulation Setup	Selecting wrong analysis type	Confirm Single vs. Composite before proceeding.
Data Completeness	Missing role actions or field values	Review SAP Authorization Defaults.
Analysis Accuracy	Using outdated rulebooks or extracts	Always verify extract and rulebook timestamps.
Review Process	Ignoring Role Impacts view	Review both user- and role-level results.
Mitigation	Not applying available mitigations	Apply controls promptly post-analysis.
Reporting	Misinterpreting CSV results	Validate impact and change types carefully.

7 User Access Reviews Management

Resources:

Managing Access Reviews

Advice:

Access Reviewer automates coordination between review administrators and reviewers, simplifying user-to-role access reviews.
ARM supports user-to-role access reviews for on-premise SAP systems.
Role Owner Maintenance:
- Download the SAP roles list from ARM.
- Add ARM user IDs of role owners in the file.
- Upload the updated file to ARM.
Manager-to-SAP User Mapping:
- For manager-led reviews, download SAP users from Manage HR Info.
- Add ARM user IDs of managers against SAP users and upload.
Reviewers receive detailed reports including SAP user ID, assigned/child roles, associated risks, and role usage history.
Administrators can add extra SAP user attribute columns, adjust due dates, and exclude roles from review.
ARM uses the rulebook to determine risks associated with user access.
ARM supports delegation during access reviews.
ARM provides email notifications for initial reviews, final submission, and reminders. Email body and reminder duration are customizable.
Administrators can monitor the status and percent complete of each access review.
Automated role removal: Once all reviewers complete 100% and submit their reviews, administrators can trigger role removal, and ARM will automatically deprovision rejected SAP roles.

Pitfalls:

Failing to maintain role owners or manager-to-SAP user mappings will prevent proper assignment of reviewers.
Reviews are triggered only for roles with role owner mapping and users with manager mapping; missing mappings prevent reviews from being triggered.

How to Use Role Locations While Creating Access Reviews (Optional)

Advice:

Create Role Locations first via Settings > SAP Role Location.
Provide clear naming and descriptions for locations (e.g., Plant Code, Company Code, Geographical Location).
Once locations are created, map them to roles either individually or in bulk using Excel imports.
Use these locations when setting up access reviews to target specific role groups for inclusion/exclusion

Pitfalls:

Inconsistent location names: Ambiguous or unclear location names can lead to confusion and misclassification of roles.
Bulk updates: When using Excel to update locations, errors in file formatting can cause import issues. Always double-check the file before importing.

How to Add Role Owners to SAP Roles

Advice:

Assigning a role owner is mandatory for each role to be included in an access review.
For manual assignment, filter the role by name and use the Edit option to assign a role owner directly.
Always confirm the role owner is the appropriate individual (e.g., business unit head or manager) for that role.
For bulk assignment, consider uploading role owners through a file to save time.

Pitfalls:

Skipping the refresh step: Failing to click Refresh may result in outdated role lists, missing newly created or updated roles.
Assigning the wrong user: Ensure that the role owner is accurately assigned — assigning the wrong user can cause delays or errors in the review process.
Bulk upload errors: When using file uploads, ensure the file format and user data are accurate. Any mismatch can result in incomplete or failed uploads.

How to Exclude Roles While Creating an Access Review

Advice:

Use "User to Role" as the Review Type.
In the Role Selection section, add roles that must be excluded.
Ensure the toggle remains on Exclude Roles (default setting).
Review all details before submission to avoid incorrect role inclusion.

Pitfalls:

Changing the Exclude toggle: Accidentally switching to "Include" can lead to reviewing roles that should be excluded.

Setting Email Reminders for Access Reviews

Advice:

Utilize Reminder Emails to encourage reviewers to complete the review, with up to three reminder emails allowed. Ensure these do not overlap with the Initial or Final emails.
The Final Email should be sent one day before the review is due, nudging any remaining reviewers to complete the process.
Customize the email content using variables such as %firstname%, %lastname%, %sapsystemname%, and %duedate% for personalized and clear communication.

Pitfalls:

Overlapping email dates: Ensure reminder emails aren’t set for the same day as the initial or final email. This can cause confusion and clutter in reviewers’ inboxes.
Neglecting final reminders: Not sending a final reminder email the day before the review deadline can result in incomplete reviews, especially for busy or absent reviewers.
Unclear or missing variables: If the placeholders (e.g., %firstname%) are not correctly configured or left out, reviewers may receive impersonal or unclear emails. Always preview email templates before sending.

Reviewing Rejected Roles

Advice:

To view rejected roles, navigate to the far-right column of the Administrator Dashboard and select Remove Roles.

Pitfalls:

Not validating role rejections: Ensure that the roles being rejected are correctly identified before approving their removal. Mistakenly removing roles could lead to access disruptions.
Missing user impact: When removing rejected roles, verify if the affected users need alternate roles or permissions to maintain their work functions.

Generating Access Review Reports

Advice:

Use the Latest Report to get a comprehensive view of all review line items and their current status. This consolidates all reviewer responses into one easily accessible Excel file.
For a more detailed view, especially if you're looking for specifics like delegation actions or role changes, use the Reviewer Action Log. This log captures every action taken, not just the final review decisions.

8 Emergency Access Management

Resources:

EAM Setup & Operations Guide

Advice:

EAM automates elevated permission requests for sensitive tasks.
Only users mapped to roles in the profile can request or approve access.
Ensure requestors and role owners. reviewer and approvers are correctly mapped for access review workflows.

Pitfalls:

Requests may fail if profiles or role mappings are incomplete.

EAM Profiles & Role Mappings

Advice:

Create new profiles via EAM Profiles → New. Use a descriptive name and a clear description.
Define role mappings for each profile: Profile Owners, Approvers, Requestors, Reviewers.
Add the relevant SAP role/entitlement to the profile.
Assign attestors to each profile to confirm proper access removal after requests end.
Set maximum access duration up to 7 days.
Ensure rulebooks are correctly defined to include only sensitive transactions.

Pitfalls:

Misconfigured or missing user mappings can prevent requests or approvals.

Agent Setup & Logging

Advice:

Ensure time zone consistency between SAP system and ARM agent.
Select utilization options according to SAP version:
SM20 for versions below 750
RSAU_READ_LOG for versions 750 or later
If multiple SAP application servers exist, add all servers to agent configuration.
Enable security audit logs via SM19 or RSAU_CONFIG, with kernel parameters configured.
Maintain daily audit files with a max size of 1000 MB.

Pitfalls:

Missing or incorrect audit configuration can prevent logging of critical events.
Incorrect file size or log creation settings may result in incomplete logs.
Ignoring audit classes (AU3, CUI) can prevent capturing key sensitive activity.
Not including all app servers may cause missing data and incomplete monitoring

9 ISC to ARM Integration

Resources:

Using ARM with ISC

Advice:

The integration between Identity Security Cloud (ISC) and Access Risk Management allows for a detailed Separation of Duties (SoD) analysis at the authorization object level for SAP permissions. This analysis is integrated into the access request process within ISC, ensuring that SoD risks are identified and flagged. Approvers can then make informed decisions based on the results, helping organizations maintain compliance with internal access policies.

Using the Access Risk Management What-If simulation engine, this integration allows users to simulate and analyze potential risks in SAP permissions and entitlements before access is granted.

Pitfalls:

Integration Setup: Proper configuration is required to ensure successful integration. If the SAP system is not correctly set up as a source in your implementation, the integration will not work.
Limited Scope for Entitlements: The integration does not support risk simulations for entitlements across multiple SAP systems or SAP profiles.
Note: Please contact SailPoint Professional Services for assistance if you are unsure about your setup.

Integration Setup

Advice:

To leverage the integration, SAP must be set up as a source within your Identity Security Cloud environment. This integration enables fine-grained SoD analysis and allows the use of the What-If simulation engine to assess risks for SAP roles.

Pitfalls:

Implementation Assistance: If your SAP system is not set up as a source, the integration won’t work as expected.
Note: Please contact SailPoint Professional Services for assistance if you are unsure about your setup.

Simulation Limitations

Advice:

The What-If simulation engine allows for detailed risk analysis for SAP roles, making it easier to assess and mitigate Separation of Duties risks within the access request process. For each access request, approvers can evaluate whether granting access will introduce conflicts or violate SoD policies.

Scheduling Tips:

If access requests involve SAP profiles, ensure that role-based permissions are included in the request for risk analysis, as the simulation will only flag role-based permissions, not profile-based ones.

Pitfalls:

Multi-System Limitations: You cannot simulate risks for entitlements across multiple SAP systems. This means that if your environment spans multiple systems, the integration will only work within a single SAP system at a time.
SAP Profile Entitlements: The integration currently does not support SoD simulations on SAP profiles as entitlements. If an access request includes SAP profile entitlements, the simulation will not include the permissions associated with these profiles. It will only include permissions derived from SAP roles.