Nov 26

This document elaborates the usage of Emergency Access Management (EAM) and its dangers of inappropriate usage. To get more information about EAM in general please refer to the excellent collection document from Leo:EAM - For the new kid on the block.

Before you start using EAM you have to think why you are using it and what you are going to analyze in log review. SAP's official GRC300 course (GRC300 - SAP Access Control 10.0 - Implementation | SAP Training and Certification Shop) says that EAM is used as a form of remediation/mitigation for SOD (Segregation of Duties). This document focuses more on firefighting in emergency situations rather than on mitigating critical access.

In the section "Inapproriate Usage" I have mentioned that daily business tasks should not be performed with a firefighter. In case you define EAM as mitigation/remediation of critical access, as mention in GRC300 course, then this isn't an inappropriate action as it covers an end user's business function for supporting user. Also you might have support users have daily activities that they use Firefighter for (from security point of view it's recommended as a way to capture service call numbers for audit trail).

Short Overview

EAM in general offers a number of advantages for the management of emergency access, including

  • Mitigates the most common open audit issue faced by virtually every company (e.g. with profile SAP_ALL and SAP_NEW)
  • Eliminates emergency phone calls to approve access outside the business hours
  • Tracks and logs transaction code usage and changes made within the firefighting session
  • Allows to provide defined authorizations and validity dates
  • Sends email notification of emergency access logon immediately to defined controllers
  • Generates auditable reporting logs

Appropriate Usage

Appropriate usage of emergency management includes:

  • Emergency changes required in productive environment
  • Sensitive transactions not available via end user security roles
  • SOX sensitive and restricted transactions
  • Infrequent and sensitive tasks (e.g. opening and closing of posting periods)
  • Cutover activites

Inappropriate Usage

Inappropriate usage of emergency management includes:

  • Daily business tasks by support users (e.g. creating purchase orders, etc.)
  • Non-sensitive tasks available via security roles (e.g. display access)
  • Displaying sensitive reports
  • Using EAM as a crutch to support a bad security design

Dangers of Inappropriate Usage

Excessive usage represents one of the largest EAM issues.

  • Frequently, EAM is used as a crutch for a poor security role concept. End users tend to rely on their Firefighter ID instead of using their regular access given to their personal user ID. Simple table display (e.g. SE16) or daily activities for supporting business tasks are both examples of inappropriate usage seen in several companies.
  • The high volume of use generates longer logs, requiring more system resources, and more time to review.
  • As a result logs are not reviewed in detail and EAM cannot be relied on as a security control.

It is important that the concept of firefighting is defined properly as excessive usage might cause real danger to your organization as fraudulent actions might remain undetected due to the high volume of logs. Inappropriate usage could be eliminated with a proper provisioning strategy (see also EAM - Provisioning Strategies), the proper type of firefighting (see also ID-Based Firefighting vs. Role-Based Firefighting), as well as a proper authorization concept defined by your basis/security team.

Furthermore it is required to correctly assess the role design of the FF roles as role design has an impact on the size of the logs. Firefighter Logs (see also Emergency Access Management Reporting) do not differentiate between display and change and hence EAM collects all information that is logged. This means the file can become overwhelming for the Controller to review.

Instead of using Firefighter, if you are on 7.40 release, you could configure RAL (Read Access Logging (RAL)) that allows you to monitor and log read access to sensitive data.

Hope this document helps for the general understanding of how EAM should and shouldn't be used. Your feedback is always highly appreciated to improve the quality.

Best regards,


Document on SCN:

Posted by Alessandro Banzer

Twitter Facebook
Nov 19

The motivation to write this document comes with the Community Collaboration for GRC Blogs and Documents project that we have started recently in the GRC space. Leo has requested a document that elaborates which tools and transactions are used by a GRC consultant. I have extended the request to also name some programs and tables I regularly use to complete my job. The following listing will give you an overview of transactions, tools, programs and tables used by a GRC consultant.


Transaction Description Key Area Why is this useful? Further details, links, etc.
NWBC Launch Netweaver Business Client All launch NWBC HTML. You will need to have work centre roles assigned or build you own.
SPRO Customizing All Self explanatory - configuration entry point for both GRC and plug-in systems
GRAC_UPLOAD_MIT_ASGN Upload Mitigation Assignments ARA Upload a huge number of mitigation (user, role, profile) in one shot. You can either append your current mitigations or overwrite. Mass change of Mitigation Assignments
GRAC_DWLOAD_MIT_ASGN Download Mitigation Assignments ARA Download a huge number of mitigation (user, role, profile) in one shot.  Mass change of Mitigation Assignments
GRFNMW_CONFIGURE_WD MSMP Workflow Configuration WF MSMP Workflow Configuration - standard view (web dynpro will launch)
GRFNMW_CONFIGURE MSMP Workflow Config Expert WF SAP GUI expert mode to configuration workflow configuration. Do not use this transaction if you not familiar or strong with MSMP configuration as you will risk corrupting your build. This is useful if you need to retransport or transport all of the MSMP in one go as you can select it like an IMG table.
GRFNMW_DBGMONITOR_WD MSMP Instance Runtime Monitor WF Comprehensive view of the workflow execution for MSMP evaluation including Stage/Path calculation, provisioning notes, notifications and agents. This is useful for an Administrator to track issues with an MSMP after a request has been submitted.
SWDD Workflow Builder WF Unlikely you will need to go into this transaction as the Worfklows for SAP are out of the box and MSMP is used. You can identify the MSMP integration from here.
SWIA WF SAP standard workflow. This will allow you to check the current Workflow and Task numbers. If the MSMP Instance Runtime shows the workflow is completed but SWIA is not completed then there is an issue with the workflow configuration. Check Marketplace incase there is a correction.
GRAC_ROLE_MASS_IMPRT Mass Role Import from Backend System BRM
GRAC_SPM_CLEANUP Cleanup EAM Application Data EAM Program to clean up EAM tables.
GRAC_EAM/GRAC_SPM and /GRCPI/GRIA_EAM EAM Logon Pad EAM For centralized firefighting, you use GRAC_EAM to open the EAM Launchpad on the GRC system. For decentralized firefighting, you use /GRCPI/GRIA_EAM to open the EAM Launchpad on the plug-in systems. The launchpad for centralized firefighting displays all the plug-in systems to which you have access. The launchpad for decentralized firefighting does not display any systems because it allows you to access only the current plug-in system.
GRAC_UPLOAD_RULES Upload Access Control Rules ARA This is available in the IMG navigation and allows you to import the rule set. Note, if you have workflow activated for you ruleset it will not trigger workflow.
GRAC_COPY_RULES Copy Access Control Rules ARA Utility for copying SOD rules from one system to another of same type.
GRAC_RULE_DELETE Delete Access Control Rules ARA This is available in the IMG navigation and allows you to delete the rule set. Note, if you have workflow activated for you ruleset it will not trigger workflow.
GRAC_DOWNLOAD_RULES Download Access Control Rules ARA This is available in the IMG navigation and allows you to download the rule set. Recommend you save a selection variant with the file name and paths so you do not have to continually maintain them.
GRAC_GENERATE_RULES Generate Access Control Rules ARA This is available in the IMG navigation and allows you to mass generate the rules. You can also execute this via NWBC, however, this program would allow you to schedule in background via SM36/37
GRAC_RULE_TRANSPORT Transport Access Controls Rules ARA This is available via IMG navigation and allows to mass transport the rule set.
GRAC_EXPORT_RA Export Risk Analysis Data (e.g. when the file is too big for the web) ARA Program to download the results of the risk analysis to a local file.
GRAC_BATCH_RA Risk Analysis in Batch Mode ARA This is available in the IMG navigation and triggers the program for you to schedule batch risk analysis. Ensure your configuration parameters are set
GRAC_GENERATE_RULES WF Build MSMP rules (usually BRF+). Refer to comment below for creating application first.
GRAC_GEN_ERM_BRFRULE WF/BRM Build the BRF+ Rules for BRM role methodology and approval conditions groups. Note, before running to to BRF+ and create a shell application that has been assigned to a transport and activated. Use this application in your definition. If not, it gets created in $TMP
BRFPLUS BRFplus Workbench WF Alternative transactions: BRF+ and FDT_Workbench. You can maintain the BRF+ rules here and transport through to Production.
STZAD Customizing Time Zones BC Discuss with Basis before making any changes to timezone as it can impact EAM log collections, etc.
SLG1 Display Application Logs BC Application log display. It is useful to track error messages. Most GRC authorisations errors will show in the application log
SE61 SAP Documentation (Email templates, etc.) All Document maintenance.
SE63 Translations All This transaction enables you to directly translate individual objects.
SCPR20 Activate BC Sets Basis Activation of BC Sets. Activate BC Sets - Business Configuration Sets (BC-CUS) - SAP Library
PPOM Maintain Organizational Plan Basis Maintain Organizational Plan
SOST/SOSB SAPconncet Send Requests Check if there has been an issue with sending on email notifications or reprocess requests. Transaction SOSB can be restricted to limited functionality. Tcode SOST
SCOT SAPconnect Administration Basis Configuration of SAPConnect. Discuss with your Basis team. Take care in enabling in Non-Production environment so you do not accidentally send emails to users and add confusion. If enabled for Non-Prod, recommend you put dummy email addresses on the user accounts.
ST01/STAUTHTRACE/ST05 System Trace Trace for an application server. ST01 is useful for authorisation checks and include database calls, kernel and RFC. STAUTHTRACE is new version for security tracing with ALV functionality and drill down (heaps easier to intepret than ST01). ST05 comes in handy to trace SQL calls to find the table where information has been stored.
SM12 Enqueue Locks Basis You can access this in display mode only. It can be a quick way to find which tables your data is stored in. Go into the NWBC screen in change mode so it puts a lock on the tables. Open a new session and go to SM12 to find the tables.
STAD Display Statistics for all systems Basis EAM FF logs import STAD information
SCC4 Client Administration Ability to change client setting to enable cross-client changes. Do not make changes to these settings without discussing with Basis. Depending on your landscape strategy you may need to maintain some IMG settings directly in the client (such as integration framework)
SNOTE Note Assistant BC Import and apply SAP Notes. You will need to check with your company's policy for note application responsible. If you have not applied and OSS note before, it is strongly recommended your talk to your developer or Basis to learn about pre-requisite and post-processing activities. In some cases, a developer key will be necessary.
SE01/SE09 Transport Organizer BC Manage your transports
SE16 / SE16N Data Browser Transaction to easily browse thru data tables.
SM01 Lock Transactions SEC Lock transaction to prevent users (even if authorised) from executing the transaction. Usually security is responsible for this activity.
SM36 Schedule Background Jobs BC GRC Access Controls uses a job scheduler via NWBC. SM36 jobs for connector sync,etc can be set up via SM36
SM37 Overview of Background Jobs BC Allow you to view background jobs. All jobs runtimes will show here, even if scheduled via NWBC.
SA38 ABAP Reporting ABAP Execute SAP ABAP programs.
SE38 ABAP Editor ABAP Program Editor
SE80 Object Navigation ABAP SAP Development workbench, most development functionality is available from this transaction.
SE37 ABAP Function ABAP MSMP SAP standard rules are usually function modules. You can look at the code if you want to better understand what is being evaluated. Also comes in handy for break point if you need to debug.
SE24 ABAP Class ABAP useful if you need to check the code and add a breakpoint to a method
OOCU Task Customizing
BD54 Logical Systems Basis RFC connections have to be defined as a logical system (usually same name) to then reference in the integration framework configuration
SM59 RFC Destinations Basis RFC Configuration
SM66/SM50 Workprocess Basis View the number of background work process available to define as part of the integration framework for background job processing
SUIM SEC User Information Reporting system
S_BCE_68001426 Transactions for User SEC Report shows a list of all transactions assigned to a user. This is a very helpful report to identify critical transactions as user has access to.
S_BCE_68001418 Roles by Role Name SEC Report to find roles by complex selection criterias. This report can be used to find roles by description, etc.
S_BCE_68001419 Roles by User Assignment SEC Report shows a list of all roles assigned to a user. This is very helpful to have an overview of all authorized roles a user have.
S_BCE_68001420 Roles by Transaction Assignment SEC Reports shows a list of all roles that includes a specific transaction. This is very helpful to easily find possible roles to assign a transaction.
SICF HTTP Services BC Discuss with Basis and Security before activating these as it poses a security risk. If you receive a 403 Forbidden error in NWBC it means a service needs to be activated for the webdynpro. You can also test the services here. For PSS/End User Login screens, the SICF services need to be configured with the Service Account Username and Password stored
GRAC_REP_OBJ_SYNC Object Rep Sync All User + Role + Profile Synchronization Job
GRAC_USER_SYNC User Sync All User Synchronization Job
GRAC_ROLE_SYNC Role Sync All Role Synchronization Job
GRAC_ROLE_USAGE_SYNC Role Usage Sync All Role Usage Synchronization Job
GRAC_ACT_USAGE_SYNC Action Usage Sync EAM/ARA Action Usage Synchronization Job
GRAC_PROFILE_SYNC Profile Sync All Profile Synchronization Job
GRAC_AUTH_SYNC Auth Sync All Authorization data Synchronization Job
GRAC_SPM_SYNC EAM Sync EAM Emergency Access Management Master Data Synchronization Job
GRAC_SPM_WF_SYNC EAM Workflow Synchronization EAM Emergency Access Managmement Workflow Synchronization Job
GRAC_SPM_LOG_SYNC EAM Log Sync EAM Emergency Access Management Log Synchronization Job
GRFN_STR_DISPLAY / GRFN_STR_CHANGE Org Structure Expert Change All These transactions show all the relationships between objects in the structure considering the timeframe of each object and the timeframe of the relationship.

Both are considered super transactions which are really sensitive. They are exclusive GRC transactions to check Objects Hierarchy. The point of GRFN_STR_CHANGE is that within this transaction you can change master data that you could not using UI. It means that the structure change transaction is not recommended as you can cause severe data inconsistency in the system if you use it without knowing it.
PFCG Role Maintenance Basis Role maintenance to create and edit roles. 5 Role Maintenance in PFCG - SAP NetWeaver Business Client - SAP Library
SU01 User Maintenance Basis User maintenance
SE16 Data Browser Basis Data browser to view/add table data
SM30/SM31/SM34 View Maintenance Basis SE16 and SM30 essentially give direct access to tables information. SM30 is restricted in a way that you cannot use the SM30 interface to view all the tables. Only tables with a maintaince dialog defined can be accessed through SM30. But there is no restriction on the access to tables in SE16 as long as u have access to the authorization group pertaining to the table you will be able to access the information through SE16.
GRFNMW_CN_VERA MSMP Process Active Version Maint. WF
GRFNMW_DEBUG MSMP Process Debug Settings WF
GRFNMW_DEBUG_MSG MSMP Process Debug Messages Settings WF
GRFNMW_DEV_CONFIG MSMP Development Configuration WF
GRFNMW_DEV_RULES MSMP Rule Generation / Testing WF
GRFNMW_GEN_VERSION Generate Versions for MSMP Config WF Generate version is useful to run after you import a transport (post processing activity) instead of going into MSMP screen to activate.
GRFNMW_MONITOR MSMP Workflow Monitoring WF Monitoring of the MSMP Workflow statistics.
GRAC_ENDUSRFORM_SICF End user form SICF service
GRAC_FFOBJ_DSC_MAINT Maintain EAM FF Object Description
GRAC_FFOBJ_DSC_MNT1 Firefighter Object Maintenance
GRAC_DATA_MIGRATION AC10 Data Migration Program to migrate data from an earlier version.
GRAC_DELETE_REPORT_S Delete Report Spool data
GRACRABATCH_MONITOR Batch Risk Analysis Monitor This program is used to monitor the execution status of a running batch risk analysis.
GRAC_ALERT_GENERATE Alert Generation Program that generates alerts. SAP GRC AC 10.0 Alerting
GRAC_BATCH_RA Risk Analysis In Batch Mode Offline analysis is not real-time data but is dependent on the date of the last Batch Risk Analysis. The Batch Risk Analysis is run as background job in GRC by using transaction GRAC_BATCH_RA. Online vs. Offline Risk Analysis


Program Description Why is this useful? Further details, links, etc.
PRGN_COMPRESS_TIMES Program to merge the assignments of identical users and roles, provided the validity periods overlap with one another or immediately follow each other. Also you can delete expired assignments. Very helpful to easily delete expired assignments or to clean up the assignments after a system copy.
Please note that this program should not be run if you have ARQ in place for business roles provisioning.
Before Initial Load
TZCUSTHELP Troubleshooting Support for Time Zone Settings Timezone changes best practices - Basis Corner - SCN Wiki
TZONECHECK Check Time Zone Data for Consistency Timezone changes best practices - Basis Corner - SCN Wiki
RSLDAPSYNC_USER Synchronization of SAP User Administration with an LDAP-Compatible Directory Service Synchronization of SAP User Administration with an LDAP-Compatib - Identity Management - SAP Library
GRFNMW_BATCH_EMAIL_REMINDER Job User to send Email reminders to approvers based on number of days and frequency
GRFNMW_BATCH_STALE_REQUEST This program was useful for deleting non-actionable old requests from the system as housekeeping activity
RSCONN01 This job used for sending email (and other types of communication items)
/GRCPI/GRIA_DNLDROLES Download roles data for mass import


Table Description Why is this useful? Further details, links, etc.
GRACREJREASONT UAR Rejected Reasons Texts
USR02 User Logon Data
GRACOWNER Master Table for Central Owner Administration

I am really looking forward to your input to extend the listing.

Best regards,

SAP SCN document:

Posted by Alessandro Banzer

Twitter Facebook
Sep 5

This document elaborates the SoD Management Process that is a key part to reduce Segregation of Duty (SoD) conflicts in a company. In fact SoD is a key contributor for fraud activities within an organization and hence to achieve seamless compliance (e.g. SOX) it is absolutely necessary to follow a straight process.


The SoD Management Process has six single steps that need to be completed one after one. Each step has its own outcome that you have to achieve before proceeding with the next.


Steps Description

Gather a list of applicable SOD conflicts that allow fraud or generate significant errors. The outcome of this step is that your business has determined what is an unacceptable risk that they want to report on and manage via remediation or mitigation.


Helpful documents:

Risk Lifecycle


Build the rule set based on the recognized risks from step 1. The outcome of this step is the technical rule set to analyze the user and/or role assignments.


Helpful documents:

Business Risks / Rule Set

Rule set - Rules & Rule Types


Analyze the SoD output. This can be performed with the help of SAP GRC Access Control. In case of manual analysis, for each user, analyze if he/she has the access to perform any of the conflicting functions defined in step 1. The outcome is basically to provide the business insight to alternatives for correcting or eliminating discovered risks.


Helpful documents:

Online vs. Offline Risk Analysis


In this step, evaluate if the conflicting tasks can be performed by an alternate person. If so, role changes and/or user reassignments can be performed to segregate duties properly. The outcome must be a very low number of remaining risks that need mitigation.


Helpful documents:

Remediating Access Control SoD Risks


If it would not be possible to remediate the existing conflicts, consider formulating an appropriate control to mitigate the risk. This would typically entail working with the business to setup additional monitoring procedures that ensure to compensate the risk. The outcome must be no remaining risks.


Helpful documents:

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

Creation of Mitigation Controls in GRC 10.0

Mitigating Control Lifecycle


Finally, establish a new continuous process wherein every access request is reviewed against the SoD conflict matrix prior to provisioning on the system. Also make sure that all role changes must be analyzed and remediated before implementing. The outcome, and also final result, your system remains clean.

Helpful documents:

Approve/Reject Own Requests

Risk Terminator - GRC 10

Best regards,

Posted by Alessandro Banzer

Twitter Facebook
Aug 25

GRC's Access Risk Analysis is a tool within Access Controls to enable you to define user access risk (via way of a rule set); execute risk analysis to identify access risk (or simulate for potential risk); and then provide you with system functionality to remediate the risk or mitigate via assignment of a control. As this is an approach, it can apply to any version of GRC (of course the system screen shots are in 10.x version).

Like any other risk process the reviewer is has four options: accept; transfer; mitigate or remediate. This document details our strategy and approach to risk remediation. Our position is that you should always attempt to remediate a risk before your mitigate. Remediation removes the risk (or the residual level is acceptable) from the system and does not rely on the use of compensating control (typically manual control that requires a person to take regular action and can be subjected to human error). Accepting and transferring of risk are last resorts. Of-course the your decision would involve a cost-benefit analysis. It makes not sense to spend more on the control than the true cost of the risk (financial, reputation, legal and compliance, etc).

When a risk has been identified (violation, issue, etc.) someone has to take action to resolve it. Depending on your master data setup, GRC automatically displays the risk definition, including who is responsible (risk owner); the respective business process; as well as mitigation owners/monitors. This information is important to enable your to know who to contact to discuss the risk and receive advise (and some of this interaction will occur off system).

Risk Violation Count is Massive (Why?)

Be aware that the first time you run a risk analysis it is likely that the number of violations will be very high. Users may have access creep due to change in job function and retained old access. Roles may have been built with too much access. At the time, the business did not have adequate tools to identify these risks. Many organisations undergo a security redesign project once they have implemented GRC due to the number of inherent conflicts in their roles. In the end they find it easier to completely rebuild security (get it right and clean first time) than try to unpick the issues and clean the existing roles. In some cases, companies are aware of the issues but mistakenly believe implementing GRC will fix it: all GRC will do is give you the number of violations and will not help you if you do not go down the path of remediation and mitigation.

For example, in the screen shot below there are over 200,000 conflicts (more if we scrolled down). This number is large - huge - and probably daunting when it comes to fixing it. After all where would you start? Remember a risk violation is one rule in the risk definition being met. Therefore, if a risk has two functions and both functions have two actions you then have 4 rule violations. If a user happens to have all four actions they too have 4 violations. If there are 50 derived roles, you will see the violation count increase to 200 (4 x 200). In the screen shot below, on further analysis (not visible in this screen shot) the bulk of the issues are caused by derived roles. By cleaning the imparting roles the number of violations will reduce substantially (also, you cannot clean a derived role without using PFCG incorrectly or actually fixing the imparting role).


Where to start for Remediation (Still overwhelmed by so many violations)?

Your security role design as well as access provisioning strategies will impact how you approach remediation. This diagram below assumed position-based security is used in your organisation. Depending on the authorisation concept and access management in your system, the number of circles will vary. For example, you may not user business roles or composite roles.

object sequence for remediation pbs.jpg

When approaching risk remediation, use the diagram below as a reference and work your way from the inside out.

    1. Single Roles: focus on remediating conflict in your imparting roles and other non-derived single roles. You will fix the derived roles when you distribute the change from the imparting (assuming you have followed SAP standard security rules and not added additional authorisations to your derived). Single role clean up will involved removal of transactions and other authorisations.
    2. Composite Roles: by this stage you expect that none of the single roles have inherent conflict. You cannot remediate risk in a composite role if the single role has conflict. Your choice to remediate at this point is to remove roles assigned to the composite (possible replace with a different version). Another option is to remove access from the single (it may not cause an inherent conflict in the single) if the access is not required and it is contributing to the violation.
    3. Business Roles: this assumes you have built business roles via GRC Business Role Management for provisioning. Same principal applies as composite.
    4. Positions: if you are using position based security then you can consider removing roles (single, derived, composite, etc) from the position.
    5. Users: finally you have removed all inherited risk. The only unmitigated risk violations against the user is due to the combination of access. At this stage you can then remove roles.

Note: Remediating inherent role conflict will take time. You will need to work with the business process owners (the business) to determine the appropriate solution. Once you identify the permissions to removal from a role you will then need to follow your companies change management process to schedule the change and arrange a transport to Production. As an interim measure, you may need to implement a mitigating control.

Who should I engage with? What should I say?

This will depend on your company's organisational model and approach to risk management. However, regardless of approach it is still a business decision. You will need to consider meeting with the business process owners, line managers, etc.

In starting the conversation with these stakeholders you need to outline and explain what the risk is and why it needs to be remediated. In some cases the conversation may be as simple as 'Is this access really required'. You may discover over time that access creep has cause the conflict and requires clean-up. Where a user is concerned, the question may be 'Does this user really need both access'. The stakeholders identify non-compliance in a job duties or that there is an alternative person to take on part of the function. Again, it will all depend on the business so get out there and talk to the stakeholders!

For some more ideas refer to Reviewing of Risks in the: Risk Lifecycle

How can I decide remediation approach?

The diagram below has been devised to visually represent the process to deciding how to remediate the access. You may devise a similar approach and change the sequence of options depending on your organisation's policy.

decision flow.jpg

Is it a Risk?: Before investing work effort into remediation you need to verify that violation is actually a risk and not a false positive.You may have executed the report at Action level only but if you re-ran at permission the violation is not longer there. Alternatively, you may look at the violation and question why it is a risk in the first place. If you realise the risk definition is incorrect then you need to change it. The rule-set is not static and must be reviewed regularly.

Does the object need both functions?

The violation is a risk and you need to take action. Does the object (role, position, etc) require both actions? To assist in this decision you could look at action usage reports in GRC. If it appears one of the functions is not used, then remove it. For roles this will be a change request and users/positions it will be an Access Request. Approval from the business will be required regardless.

Is there Alternative Access?

You determined the both functions were used but could you assign a different transaction or authorisation combination to restrict. For example, the user might have XK01/02 transactions for Vendors but does not need all views - such as payments details. Instead they only need FK01/02 which does not include the payment details.  By changing the transaction over the user can still perform their job function via a different transaction.

Is there a System Control - Can system controls via IMG configuration, workflow and ABAP development be implemented to remove the risk? Alternatively, can the business process be changed to include a new step. For example, add vendor confirmation via FK08/FL09 for sensitive fields to force a second pair of eyes to review the change.

Unable to Remediate -  By this stage you have exhausted all possibilities to remediate the access and must investigate mitigation as an option.As already mentioned many times on SCN, always try to find a way to remediate a risk instead of defining compensating controls. Mitigation, whether it be with the help of spot checks, reviewing postings, etc. is always a reactive way and fraudulent actions might be done in the mean time. Still there needs to be a balance between managing risk and allowing the business to function. If you cannot remediate, refer to the document for further details on defining mitigating controls: Defining Mitigating Controls / Compensating Controls

Analyse Again (or verify your Remediation via Simulation)

Once you have remediated your risk we recommend you re-execute your risks analysis. You need to ensure that by remediating the list violations you did not introduce a new one. The good news with GRC is the ability to simulate access risk. Before going to the effort of role change or access change you can execute a risk simulation to test removing of the conflicting function and replacing with the alternative. This will provide you with confidence to remediate and avoid introduction of new risk. Using simulation will also reduce rework through continual rebuild or access change.

Finally I'm Finished - the system is clean...

Sorry to break it to you bust risk identification and analysis is continual. You must regularly plan to review your rule set to ensure the risks are valid (support packs, enhancement packs, custom development, changes to configuration, changes to the business, etc) as the system and business is in a constant state of change. In addition, when security role changes are migrated to production then user may now have risks.

Keep on top of the review so you only ever have a small number of violations to respond to. Scheduling Role Re-certification in BRM, SoD and UAR Review workflow will help manage this regular review.

Does your organisation approach remediation in GRC differently? We would love to hear your feedback in the comments below.

Best regards,

Alessandro Banzer & Colleen Lee

See the original version of the document:

Posted by Alessandro Banzer

Twitter Facebook
Aug 19

This document describes the provisioning strategies of Emergency Access Management. Basically SAP GRC Access Control offers two different strategies how EAM can be utilized.


Some users are pre-approved for specific Firefighter IDs and have pre-assigned access in GRC. When a Firefighter ID is checked out, the application sends notification to the controller whenever the firefighter logs onto a system (Parameter 4008). Additionally the controller gets informed when the log report is available (Parameter 4007) and it is his responsibility to confirm that the actions taken were appropriate. The application sends the notification either as email or workflow item to the controller (Notification settings in the Firefighter ID Assignment).

Approval Required

On the contrary, a user must request access to EAM before the Firefighter ID can be used. Access can be requested in Access Request Management. Super User Access Request Type is available to automate provisioning access to Firefighter IDs via workflow in ARM.

Both strategies have as well advantages as also disadvantages. Having pre-approved firefighters have the advantage that the IDs are available at any time and emergency activities can be provided immediately (e.g. during weekends), whereas it might be critical that fraudulent activities can be executed and are reviewed afterwards. If a user must request access to EAM, emergency access is delayed due to the fact that the approval from the controller is required before usage. In case of an emergency e.g. during weekends the controller might not be available and the work can't be done.

I would like to know which strategy you prefer and do you have other concerns than mine?

Looking forward to your feedback and contribution.

Refer also to SAP SCN GRC Community:

Posted by Alessandro Banzer

Twitter Facebook
Aug 15

An der ersten Clubmeisterschaft des BC Schaan in diesem Jahrtausend konnten sich die etablierten Spieler durchsetzen. So gingen die erstmals vergebenen Bergkristalle an Alessandro Banzer (Clubmeister), Marco Cristoforetti (2. Rang) und Michael Biedermann (3. Rang), allesamt Spieler der diesjährigen Vizemeistermannschaft in der 1. Vorarlberger Landesliga.

Im Kampf um den Finaleinzug duellierten sich Biedermann und Cristoforetti auf hohem Niveau - mit besserem Ende für den letztgenannten (6:3). Im Finale konnte sich dann der formstarke Banzer mit einem 7:4 gegen Cristoforetti durchsetzen und sich so den ersten Clubmeistertitel in der neuzeitlichen Vereinsgeschichte des BC Schaan sichern. Der Vorstand bedankt sich bei allen Mitgliedern für die rege Teilnahme.


Posted by Alessandro Banzer

Twitter Facebook
Jul 16

This document describes the difference between Online and Offline Risk Analysis in SAP GRC Access Control based on several SAP Notes.

In order to be able to run offline analysis at all, the configuration option "Enable Offline Risk Analysis" must be set to YES (Parameter 1027) in Access Control configuration settings in SPRO. 

This configuration option is now selectable in the Risk Analysis > Additional Criteria. 

Offline analysis is not real-time data but is dependent on the date of the last Batch Risk Analysis. The Batch Risk Analysis is run as background job in GRC by using program GRAC_BATCH_RA. This is the same batch risk analysis that is run to update the management reports and companies should be running this on a frequent basis to ensure their management reports are accurate. Running the Offline analysis is the same as drilling down via the Management View.

The benefits using offline analysis is mostly in response time. By using offline analysis, Risk Analysis and Remediation does not have to make as many calls into the connected systems so the analysis will return much faster than using online analysis. However, please keep in mind that offline analysis is not real-time and will not take into account any changes made since the last Batch Risk Analysis.

Also, it's important to understand that even when you run offline analysis it will have to make a call to the back-end system to obtain composite role names. Therefore, if the back-end system is down, offline analysis will not work.

Using offline analysis, you can obtain both summary and detail reports. The one exception is that if you run Report types Critical Action or Critical Permission, you will not be able to see the detail report, only the summary report. Please note that this is only for Critical Action and Critical Permission. Report types of Permission level and Action level can go down to the detail level in offline mode.

Please keep in mind that how you have the Batch Risk Analysis set up for defaults will impact the data you have to run offline analysis on. For example, in Configuration under Risk Analysis  you have the option "Exclude Locked Users". If this is set to YES, when running the batch risk analysis, it will not evaluate locked users which means the tables holding the conflicts will not include any data for locked users.

When you run Risk Analysis, you have the option to change Ignored Users field to something other than what is set up in the Configuration. However, if you change this to NOT ignore locked users and run in offline mode, you will not receive any conflicts because no locked users were evaluated during the batch risk analysis. Running this report in online mode may turn up conflicts with locked users.

Impacts on Workflows

The following listing shows the impact on each workflow which uses date from the risk analysis.

Segregation of Duty (SoD) Review

The system uses Offline Risk Analysis data to update management graphics and to generate SoD Review workflow requests. When the system detects SoD violations, it automatically sends reports to managers so that they can take actions to either remove user access or to mitigate the SoD risks.

User Access Review

The system uses Offline Risk Analysis data to update and generate UAR Review workflow requests.

Access Request Submission

The application automatically performs an online risk analysis when the requestor submits the request. This behaviour can be configured in parameter 1071 (Enable risk analysis on form submission). Note: The risk analysis results are intended for the approver. Therefore, the risk analysis results appear on the approver’s screens but not on the requestor’s screens. SoD violations for access requestes are stored in table GRACSODREPDATA.

Role Approval Workflow

In Business Role Management (BRM), some customers may have a business requirement that once a role is sent for approval to Role Approval workflow, the role owner(s) must re-run the risk analysis and mitigate a risk before approval. The risk analysis has to be performed during Analyze Access Risk methodology step and is always performed as Online Risk Analysis.

Impact on Reports

The following listing shows the impact on Reports which uses data from the risk analysis.

Risk Analyisis in Access Management

The risk analysis results in Access Management, like User Level, Role Level, Profile Level or HR Objects, are based on real-time risk analysis. Also simulation uses real-time risk analysis data.

Risk Analysis in Reports and Analytics

The risk analysis in Reports and Analytics tab is always offline analysis and hence you should have run the Batch Risk Analysis to populate the violations data.


See the document also in SAP GRC Community:

Posted by Alessandro Banzer

Twitter Facebook
Jul 15

In this article I take a look at the importance of good internal controls and how automating those controls can streamline your business and help you catch the exceptions to the rule. Please also see my other document regarding Defining Mitigating Controls / Compensating Controls.

Almost every problem that a company confronts can be traced back to a lack of good internal controls. Good internal controls mean that you know what is going on in your business. The definitions of the key business processes are different from each company and therefore it is necessary to understand how these processes run. Strong internal controls can also help you monitor and reduce risks. Internal controls are really the essence of good governance, taking a policy and translation it into details of day-to-day business practice.

First of all it is important to understand internal controls in general. Internal controls may mean different things to different people. Let me give you an idea what internal controls mean to me and how such controls can be defined. Controls encompass all the actions, processes or physical barriers that direct or guide a resource to achieve a desired result. Often they prevent, detect or correct risks from becoming barriers to success. Here are some different types of controls:

  • Preventative controls - these controls prevent a bad event from happening.
  • Detective controls - these controls determine whether a bad event has already happened.
  • Corrective controls - these controls come into play once a problem is discovered.

The adoption of good internal controls in order to become SOX (or regulation) compliant is a top-down process that starts with management. Management recognizes that the regulations exist and cannot be ignored. They select a team to define how the regulations will be implemented as controls in the company. Control owners and business process owners work out how to incorporate these regulations into the business through automated controls.

After the controls were implemented they help close off avenues of risks. Companies may then enjoy such happy side-effects as preventing unintentional errors, improving efficiency and keeping auditors smiling.

As mentioned internal controls deliver a happy side-effect as they offer some benefits to companies. Each company has their own processes to handle different business scenarios. These processes contain risks which are barriers to success and avenues for fraud and negligence.  Hence companies must have strong internal controls to avoid their occurrence. Nowadays, with the compliance requirements of regulations such as SOX (Sarbanes-Oxley Act), companies are trying to be more proactive about their controls. Being more proactive about controls requires effort and input, but also has many benefits.

From my point of view a company has four main benefits with the implementation of strong internal controls. Let me shortly give you an overview of these four:

Business process improvement - as a nice side effect of implementing strong internal controls is the improvement of business processes. While taking a close look at the business processes, companies often find potential to make them more efficient and streamlined. It gives companies a chance to examine their processes closely and to recap how other companies or how best practise works.

Management by exception - By establishing a norm companies learn to manage by exception. e.g. a dedicated process works this way and when it doesn’t, a control will alert us. Controls start to function as a barometer of how things are operating in the company and give an early warning of how things could go awry, or an indication of trends. Controls can also flag how companies need to change or improve their processes. If companies don't continue to assess their controls and respond to the changes that controls indicate are necessary, they could be considered negligent.

Real time monitoring - automated internal controls are like traffic cops. They prevent accidents (by directing the flow of traffic), detect accidents (by listening to the radio) and clean up after accidents (removing damaged cards and calling an ambulance to take the injured to hospital). Like traffic cops, automated internal controls can be on duty 24 hours a day, seven days a week, monitoring both past activity and activity taking place in real time.

Mindset changes - Implementing automated controls requires more than changes to software. Doing so also requires a mindset change. Management commits to a code of ethics and to a new control consciousness, but they also have to ensure that this filters down throughout the company.

I hope this article helps you to understand why strong internal controls are highly recommended and necessary for all companies. I am looking forward to your feedback and input.


Article in the SAP GRC Community on SCN:

Posted by Alessandro Banzer

Twitter Facebook
Jul 6

In regard to my document about Rule Set / Business Risks I would like to give some detailed information about rules and rule types. As we learned rules (or risk rules) are possible combinations of transactions and permissions for a business risk.

Rules must be generated when ever risk contents change. This can be done in SPRO (GRC > Access Control > Access Risk Analysis > SOD Rules > Generate SoD Rules). Generally rules are combinations of actions and aren't maintained manually (done automatically by the program).

The number of rules defined from a risk is determined by 

  • the number of action combinations, and
  • permission/field value combinations contained in each function of the risk.

The following graphic shows the rule structure in more detail:

Now let me give you a short overview of the different types of rules considered by GRC.

Transaction Rules

Rule components are as follows:
  • System
  • Conflicting Actions
  • Rule ID
  • Risk Level
  • Status
Example (from the graphic above):

F001001: Maintain fictitious GL account & hide activitiy via postings
F001001 - Risk ID
F001001 - Action code combination number (represents Conflicting Actions)

Permission Rules

Rule components are as follows:
  • System
  • Object
  • Field
  • Rule ID
  • Risk Level
  • Status
Example (from the grapic above):

F00100101: Maintain fictitious GL account & hide activity via postings
F00100101 - Risk ID
F00100101 - Action code combination number
F00100101 - Object combination number

Critical Action

List of actions considered critical. Option to run at both Action and/or Permission level. Critical Actions are created same way as Segregation of Duty risks, exept Risk Type = Critical Action, and can contain only 1 function (as shown above with SCC4).

Critical Permission

List of objects/permission considered critical. Created same way as Segregation of Duty Risks, exept Risk Type = Critical Permission, can contain only 1 function, and function cannot contain actions.

Critical Roles and Profiles

Roles and profiles considered critical. Critical roles and profiles will be excluded from analysis if the configuration parameter 1031 (Ignore Critical Roles & Profiles) is set to YES.


Used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organziational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies are controlling what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.


Additional security parameters other than authorizations a user must have to enable access. First checks to see if the user exists in the supplementary table, then checks if conditions are met. Based on exclusion setting, it will include or exclude the user in the risk analysis.

Please share and contribute in this document to make it better. See also my document on SAP SCN GRC community:

Regards, Alessandro

Posted by Alessandro Banzer

Twitter Facebook
Jun 19

With respect to my document Rule set - Rules & Rule Types and as I've got some requests to discuss the org rules in more detail I would like to share some more information about organizational rules.

Organizational rules in GRC Access Control are used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organizational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies control what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.

Basically organizational rules allow you to filter false positives from the risks analysis. What does that mean? If you have a role concept where you derive roles from master roles, for example the leading organizational level is the company code, the risk analysis might show a risk which is due to the limitation of the authorization based on the organizational level no risk. Let me give you an example:

Role A: Z_ROLE_A_1000 for company code 1000 with action FB60

Role B: Z_ROLE_B_2000 for company code 2000 with action FK02

Role A contains transaction FB60 (posting of vendor invoices) for company code 1000, whereas Role B contains transaction FK02 (changing vendor master data) for company code 2000.

The combination of FK02 and FB60 is a SOD risk, as posting of vendor invoices and changing of vendor master data shouldn’t be performed by the same person. A user who gets the two roles would have both transactions assigned hence the risk analysis shows a risk. Actually this isn’t a risk, but as the organizational values are not considered it shows as a risk. This behavior is false positive as the user cannot execute FB60 and FK02 for the same company code. To filter these false positives you can utilize organizational rules.

While running a regular risk analysis, the user would show up with a SOD conflict, as he has both conflicting transactions assigned.  To find out if the risk exists for the same company code you can use the organizational rule. Therefore create an organizational rule hat filters the company code 1000 and apply this org rule to the risk analysis. After adding the org rule to the analysis the user won’t show up with the risk. Please be aware that after creating org rules the SOD rules must be regenerated (GRAC_GENERATE_RULES).

In most of the cases org rules are created for designated risks. Alternatively it is also possible to define org rules for all possible false positives by using wildcards (e.g. XGPR*).

Looking forward to your input.

Best regards,

See also on SAP SCN:

Posted by Alessandro Banzer

Twitter Facebook
May 27

To ensure seamless GRC processes it is highly recommended to guarantee that a single user is not allowed to initiated and approve his/her own requests. The principle which stipulates how many users must be involved in approving access requests must be defined by each company and can be slightly different from one to another. This may be a 2, 4 or even 6-Eyes-Principle as given from your management.

In this document I would like to share how we can technically guarantee that a user who initiates the request is not allowed to approve, so that at least the 4-eyes-principle is given.

The following example describes a common set up with four steps.
  • Step 1: Request Initiation – Requestor
  • Step 2: Manager Approval – Manager
  • Step 3: Role Owner Approval – Role Owner
  • Step 4: Security Stage – Security Personnel

Basically I recommend that the Requestor is not allowed to approve his own requests (neither for his own user nor for requests submitted by him) as Manager at the Manager Stage. As Role Owner he should be allowed to approve requests for his user account and also for requests submitted by him. In case you have different requirements this document gives you a basic idea how this can be handled.

How does the configuration look like?

Go to the IMG Configuration (SPRO) > GRC > Access Control > User Provisioning > Maintain End User Personalization.

I suggest having separate EUP configurations for each stage. Therefore create a new EUP for each stage (Manager, Role Owner and Security). Preferred way is to copy from an existing (e.g. DEFAULT) as most of the settings are available and can be modified easily.

The EUP has to be assigned in MSMP configuration for each stage. Below is an example for the Manager Stage with reference to the EUP configuration 920 (Manager View). All others are similar.

The EUP configuration can be defined in different ways:

  • If maintained as USER or Blank, the user will not be able to approve his own request 
  • If maintained as USER AND REQUESTOR, neither user nor requestor can approve the request

Define the field as not editable and not visible as it isn’t required to be seen by the approver.

In the Access Request approval screen you will see the error message “You are not allowed to approve your own requests”.

As mentioned it is possible to define who can approve/reject own requests at each stage. In my example I have maintained only for Manager Stage as I assume a 4-eyes-principle is sufficient for most of the companies.

Let me know if you need further ideas and do not hesitate to contribute.

See also my document on the SAP SCN GRC Community:

Posted by Alessandro Banzer

Twitter Facebook
May 14

This document describes how to perform mass change of mitigation assignments. I would like to give you an overview how the down-/upload program for mitigations can be used and in which business scenarios it might be helpful.

Problems which can be handled:

  • Change monitor of mitigating controls (e.g. replacements)
  • Change validity date
  • Change system
  • Add / Remove a huge number of mitigations
  • Activate / Deactivate a huge numbers of mitigations

The most complex scenario is to change a monitor of mitigating controls and this best practice process I would like to share in this document. All other scenarios are similar and can be handled analog to this.

Removing an existing monitor, who still monitors mitigations, must be changed before he can be removed from a control. The following error message will appear if you try to remove the monitor.

First we have to define the new monitor by adding a new row and define with assignment type = Monitor. Please be aware that the new monitor must be assigned to the organization unit and must be an owner (pre-requirements).

The following picture shows that BANZER_A is still monitoring an active mitigation for the user T-BANZER as we could see above. It is also possible that the user monitors more than one mitigation.

Updating all mitigations in NWBC would take some time and therefore you can use the following programs.

GRAC_DOWNLOAD_MIT_ASSIGNMENTS To download all mitigations to a local file
GRAC_UPLOAD_MIT_ASSIGNMENTS To upload all mitigations from a local file

Start the program via transaction SA38.

Beside user mitigations it is also possible to download profile, roles and role/user organizational mitigations. In this example we are going to change user mitigations and therefore we choose USER.

Personally I always download all mitigations as XLS file as it is easy to change the content with Excel (filter, search, etc.).

After downloading the file you will see all mitigations in the Excel. In my example I have only one mitigation for the user T-BANZER.

The structure of the file, as the titles are missing, is given below.

It is possible to update each column (system, validity, etc.) and also to add an additional lines for new user mitigations. Please be aware that the values are checked while uploading and wrong data will abort the upload.

As we can see in the following picture I have updated the monitor in column H to LIJA (user name of the new monitor).

After I am done with editing the file I save and upload via the upload program. Therefore I use again SA38.

Here it is also possible to upload user, role, profiles and organizational mitigations. Uploading mitigations can be done in two different modes. Append means the uploaded mitigations will be added to the existing, whereas overwrite will overwrite all existing mitigations. Please be aware if you have for example 1000 mitigations and you upload a single record and choose overwrite, all others will be deleted and the single mitigation is the only one existing in the system.

To avoid such scenarios I always download all mitigations to a file, copy the file, modify the copied and upload the modified file. In case if something goes wrong I can upload the old file.

If the file is uploaded successfully you will see the following message. Errors will also be reported.

In NWBC we had the following mitigation before uploading.

After uploading we can see the new monitor.

Now the old monitor can be removed and the mitigating control is successfully updated.

As mentioned above it is also possible to change other values in the local file such as validity date, systems, etc. which offers great functionalities to easily change a huge number of mitigations.

Let me know if you have other inputs to extend this document. Please also see my document on SAP SCN:

Best regards,

Posted by Alessandro Banzer

Twitter Facebook
May 7

SAP GRC Access Control delivers a comprehensive, cross-enterprise set of Access Control that enables all corporate compliance stakeholders, including business managers, auditors, and IT security managers, to collaboratively define and oversee proper SoD enforcement, standardized role management, compliant provisioning and superuser privilege management.

SAP GRC Access Control in its latest version includes four modules which offer the above mentioned functionalities. The modules are Access Risk Analysis (ARA), Access Request Management (ARM), Emergency Access Management (EAM) and Business Role Management (BRM). When deployed together, they provide an end-to-end access control solution that addresses the following areas:

- Access Risk detection: the ARA applications detect even the most obscure access and authorization risks across SAP and non-SAP applications, providing protection against every potential source of risk, including segregation of duties and transaction monitoring.

- Risk remediation and mitigation: these applications for access and authorization control enable fast and efficient remediation and mitigation of access and authorization risks by automating workflows and enabling collaboration among business and technical users.

- Reporting: the applications deliver the comprehensive reports and role-based dashboards businesses need to monitor the performance of compliance initiatives and to take action as needed.

- Risk prevention: once access and authorization risks have been remediated, SAP GRC Access Control can prevent new risks from entering a production system. By empowering business users to check for risks in real time and automating user administration, the applications make risk prevention a continuous and proactive process.

Also see in the following overview graphic how each module ensures that an enterprise stays clean after getting clean.

Posted by Alessandro Banzer

Twitter Facebook
Apr 23

Das diesjährige Osterturnier - und die Trophäe in Form eines 2,5kg-Schokohasen - wurden eine Beute von Alessandro Banzer. Nachdem er sich in der Gruppe souverän durchsetzte, konnte er im Halbfinal Michael Biedermann und im Final Sascha Ludwig, der sich in der anderen Hälfete mit einem 6:5 gegen Marco Cristoforetti fürs Finale qualifizieren konnte, in eindrücklicher Manier bezwingen.

Das Trostturnier konnte Martin Heeb für sich entscheiden und damit seine ebenfalls starke Form unter Beweis stellen. Überaus erfreulich ist die Leistung unseres jüngsten Mitgliedes Sandra Winkler, die 2 Siege feiern über arrivierte Spieler feiern und sich den 3. Platz im Trosttableau sichern konnte.

Der BC Schaan bedankt sich für die rege Teilnahme (22 Anmeldungen) und gratuliert den Genannten recht herzlich!!!


Posted by Alessandro Banzer

Twitter Facebook
Apr 22

To get a better understanding how a business risk occur, we have to understand the process how GRC identifies a risk and its key terms which are used. One or more business risks can be covered in a rule set which is also shown below. Let’s start with the key terms which are used by specialist to talk about GRC.

Business Process – used to classify risk, rules and rule sets by business functions. E.g. Order to Cash, Purchase to Pay, etc. are all types of Business Processes. All risks and functions are assigned to business processes.

Business Risk – identify potential problems your enterprise may encounter, which could cause error or irregularities within the system.

Business Function – identifies the tasks an employee performs to accomplish a specific portion of their job responsibilities. This can be analogous to a role, but more often a role comprises multiple functions.

Actions – known as transactions in SAP. To perform a function, more than one transaction may be required to be performed.

Permissions – authorization object in SAP, which form as part of transactions.

Risk Rule - possible combinations of transactions and permissions for a business risk.

Rule set – categorize and aggregate the rules generated from a risk. When you define a risk, you attribute one or more rule sets to that risk. Similar to business processes.

Belows graphic shows the architecture of a Business Risk. Basically two business functions, for example accounts payable payments and vendor master maintenance, are defined as a business risk. The business risk is called “SOD required between accounts payable payments and vendor master maintenance” and says that this two functions should be segregated properly. The business risk, technically named XGPR0005 in my example, is assigned to a rule set. While analyzing the user, GRC compares the rule set with the actual authorization in SAP. Technically GRC compares the given authorization by the rule set and the actual authorization in SAP on permission level and reports if there is a match which should be segregated.

To make it more clear another graphic specifically designed for the above mentioned SOD conflict „SOD required between accounts payable payments and vendor master data maintenance“.

As seen above business risks are a combination of two business functions which shouldn't be performed by one single person. One or more business risks can be categorized in a rule set which is required to run the risk analysis. Another example, based on the architecture shown above, shows a typicall example of a rule set.

This example also shows that a business function (here Business Function 2) can conflict with one or more other business functions. Let's say Business Function 2 is "Accounts payable payments" which is conflicting with "Vendor masterdata maintenance" (shown as Business Function 1) and as well with "Bank Reconciliation" (shown as Business Function 3). Hence it might be possible to have a business function assigned in two or more business risks.

I hope this document helps to understand the concept of a rule set and how a rule set works from its architectural point of view.

This article is also online on the SAP SCN GRC community:

Please do not hesitate to collaborate and share your knowledge.

Regards, Alessandro 

Posted by Alessandro Banzer

Twitter Facebook

(Page 1 of 19, totaling 277 entries)