Governance, Risk and Compliance (SAP GRC)

Use

In this Customizing activity, you can configure the LaunchPad settings for Governance, Risk, and Compliance (GRC) application menu items. The GRC application uses one repository and seven LaunchPads, one for each work center, as listed below:

Repository

Role = GRCIAREPOS
Instance = GRC_AC_PC_RM_IA_REPOSITORY
Operation = GRC AC PC RM IA Repository

Work Centers

My Home
Role = GRCHOME
Instance = GRC_SUITE_HOME
Operation = GRC Suite Home Workset
Master Data
Role = GRCMASDAT
Instance = GRC_SUITE_MASTER_DATA
Operation = GRC Suite Master Data IA
Rule Setup
Role = GRCRULESET
Instance = GRC_SUITE_RULE_SETUP
Operation = GRC Suite Rule Setup Workset
Assessment
Role = GRCASSESSM
Instance = GRC_SUITE_ASSESSMENTS
Operation = GRC Suite Assessment Workset
Access Management
Role = GRCACCMGMT
Instance = GRC_SUITE_ACCESS_MANAGEMENT
Operation = GRC Suite Access Management Workset
Reports and Analytics
Role = GRCREPORTS
Instance = GRC_SUITE_REPORTS
Operation = GRC Suite Reports Workset
Application Administration
Role = GRCAPPADMI
Instance = GRC_SUITE_APP_ADMINISTRATION
Operation = GRC Suite App Administration

Note If SAP provides updates to the content, then such changes update the standard SAP delivered repository and LaunchPads; the changes do not directly update any customized versions. To view the changes to the SAP delivered versions and to update your customized version go to Extra->Show SAP Version.

Requirements

You have created the new menu item using the Customizing activity Maintain Authorizations for Application Links.

Activities

To create new menu items, do the following:

1. Choose a component for the menu items.

2. Choose New Application.

3. In the field Link Text , enter the menu item name.

4. Select Application Categoryand choose WDA Webdynpro ABAP.

5. In the field Namespace, enter the required SAP namespace.

6. Enter the applications. (This can possibly result in the need for development of the new applications.)

7. Enter the System Alias based on the component of the menu item. You can use the following aliases:

SAP-GRC for items applicable to both Process Control and Risk Management, and for all (Access Control, Process Control, Risk Management)

SAP-GRC-AC for Access Control only

SAP-GRC-PC for Process Control only

SAP-GRC-RM for Risk Management only

8. Enter the required Application Parameters.

9. In the field Add Information, enter MENUITEMID=<The MENUITEMID,as maintained using the Customizing activity Maintain Authorizations for Application Links.

10. Save your entries.

To link the menu items to a particular LaunchPad, do the following:

1. Double-click the LaunchPad you want to link, for example Master Data.

2. Navigate to the folder to locate the new menu item.

3. Choose Link to a Repository Application.

4. Choose the repository GRC AC PC RM IA Repository, and drag the menu items to the folder.

5. Save your entries.

To create new menu folders, do the following:

1. Double-click the LaunchPad of the work centers in which you want to locate the menu folders.

2. Choose the New Folder pushbutton.

3. Enter the folder name and folder description.

4. Change the icon of the folder. (This step is optional)

Hi,

In GRC10 – ARM Access Request approver have the choice to do Risk analysis at “Action Level”, “Permission Level”, “Critical Action”, “Critical Permission” and “Critical Role/Profile”. But In 5.3, Approver didn't have choice to decide while using from CUP.

When approver open access request in AC10 under Risk Violation tab Permission Level is always selected .Selection is fine as this is configured this way (Parameter in SPRO 1023 -Default Report Type for Risk Analysis). But the approver also has an option to deselect "Permission Level".

If you want to ensure that approver always keep "Permission Level" as an option, in other words option should be grayed out with permanent tick mark. This is to make sure that CUP enforce "Permission Level" check, otherwise if approver deselect then they can always skip the risk analysis by clicking different report types. Also possibility at times all the approver doesn't understand the meaning of each option. Both accidental / intentional ways skipping Risk Analysis is possible.

As you can see Permission level is always selected but editable. Approver can deselect and submit the request with no violation. This way unmitigated risks can be submitted.

We have achieved this by deploying SAP NOTE 1796838 - UAM Risk analysis at permission level set to non editable and following below steps.

1. Go to transaction se80.

Select Package as ‘GRAC_ACCESS_REQUEST’.

Click on Web Dynpro -> Web Dynpro Application

2 .Drill down to application ‘GRAC_OIF_REQUEST_APPROVAL’. Right click on it and click Test.

3. Now, the following screen will appear.

Go to the URL of the above screen and add the following parameters to it.

&SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/984BE163CDB81ED2ADCBAA0BE167D546&WORKITEM_ID=000000213104&MODE=E&ADMIN_MODE=X.

Observe that the dump will now get removed and an access request will be opened.

4. Go to the Risk Violation Tab and right click on the Type check boxes and choose ‘Settings for Current Configuration’

5. Now, the following pop up window will appear.

In this, you can go to each of the type of result options and click on ‘read only access’ check box.

6 For example, If you click on Permission Level and set Read-Only Access as ‘Yes’, permission level will appear as non editable on approval screens for all requests.

Click on ‘Save and Close’.

Please see that the Permission level check box is now disabled.

Hope this will help you if you meet such a kind of requirement.

Regards

Dilip Jaiswal

Purpose and functionality

EAM allow users to take responsibility for task outside of their normal job function.
Allow temporary access for users when assigned with solving problem, giving them provisionally broad, but regulated access.
This temporary access will monitored and reviewed by the application.
EAM provides the ability to manage and utilize firefighting activities centrally from the access control application
The log files can be distributed to controller and owner via workflow for additional approval

Defining Users

The owner of the ID
The controller
The users who will log on through EAM.

Important Roles and Terms

Firefighter: a business users requiring emergency access.
Firefighter ID:
A user id with elevated priviledges.
Access T-code GRAC_SPM
Firefighting: the act of using a firefighter id.
Controller: review and approves (if necessary) the log file generated by the firefighter.
Owner: a user responsible for the firefighter id and assignment the controller of the firefighter.

Firefighter Application type:

There are two deferent applications that can be used that can be used:

ID based firefighter Application
Role Based firefighter Application.

Configure in the IMG using parameter 4000 (Application type)
Only once application can be configured at a given time.

GRC Server package

The main application runs in the GRC server.
It is possible to assignment user for all system using NWBC or portal.
Provisioning of the emergency access can also be done via access request(Workflow)

Process

Firefighter access is done centrally using the GRC system.
Firefighter logon to the GUI back and execute t-code GRAC_SPM
Click on the login.

Emergency Access Architecture

Plug-in

Once component called plug-in that is installed in remote system.
Emergency Access Management access the plug-in using RFC.

Prerequisite

Create users and roles as needed
Execute program GRAC_ROLEREP_USER_SYNC

Centralized firefighter overview and prerequisites

Centralized firefighter overview

EAM provides a centralized console through which firefighter can logon to deferent system for firefighting.
In id based scenarios, firefighter do not have to logon to individual client system to do firefighting.

Centralized firefighter prerequisites

Application type is 1 for id based firefighting
Set parameter group 6 super users management
Set parameter id 4000
Firefighter user must exists in the central access control system and the role SAP_GRAC_SPM_FIREFIGHTER

Centralized Logon Pad

● Access Control provides centralized logon pad for accessing the firefighter IDs in all connected back end systems

The centralized logon pad allows:

Displaying all firefighter IDs assigned to the user
Logging on to all connected back end systems
Sending messages to other firefighters who are using a specific firefighter ID
Unlocking a firefighter session not closed properly

While a Firefighter Session is running

The status of the firefighter ID will display in red
The firefighter can take the following actions:

● Click Additional Activity to enter more information

● If the firefighter ID is in use by another firefighter, choose Message to send notification to the other firefighter

● Choose Unlock to unlock the firefighter ID if it is locked

EAM Configuration

Parameter setting

4000-Application type

4001-Default Firefighter Validity Period (Days)

4002-Send Email Immediately

4003-Retrieve Change Log

4004-Retrieve System log

4005-Retrieve Audit log

4006-Retrieve OS Command log

4007-Send Log Report Execution Notification Immediately

4008-Send FirefightId Login Notification

4009-Log Report Execution Notification

4010-Firefighter ID role name

Monitoring Emergency Access

Firefighter Report types and purpose

Using firefighter reports

Resulting change log is stored in CDHDR and CDPOS tables
Log data is retrieved from the client system and stored in GRC for report generation

In this article, I will provide an overview of the Emergency Access Management reports and which information can be seen. GRC provides six reports specifically for EAM, e.g. the consolidate log report shows firefighting activities which have been executed while using firefighter. The consolidate log report is far the best and used for management review from the firefighter controller (if workflow is in place). The consolidated log report has all the captured information from the backend system in a consolidated view. Following a short overview of the captured information and where it comes from.

Transaction Log

Captures transaction executions from transaction STAD. System, Firefighter, Firefighter ID, Reason Code, Transaction, Date and Owner are read.

System Log

Captures debug and replace information from transaction SM21.

Change Log

Captures change log from change document objects which are stored in table CDPOS and CDHDR.

Security Audit Log

Captures security audit log from transaction SM20.

OS Command Log

Captures changes to OS commands from transaction SM49. For further investigation or to get more information about the activities performed in the backend system these transactions might be helpful.

Other reports are:

Invalid Superuser Report - shows expired, locked and deleted firefighter IDs.

Firefighter Log Summary - shows firefighter ID session details (only available for ID-Based firefighter, see also my blog post about Types of Firefighter).

Reason Code and Activity Report - shows reason and activity details.

SOD Conflict Report for Firefighter IDs - shows SoD conflicts (risk analysis) for firefighting sessions.

Please contribute in this blog post and share your experience and know-how about firefighter reporting.

The purpose of this post is to demonstrate how to create Template Based Requests and make them available for provisioning in SAP. This document will demonstrate how to customize and associate End User Personalization forms for use with Access Request: Template Based Requests.

Template Based Requests are an effective way to provision access in SAP environments. Security administrators can create pre-defined templates with specified roles for each back-end environment to simply provision requests for end users. In addition, templates can leverage the Business Role Concept from Business Role Management in GRC 10.0/10.1 to provision bundled composites and singles roles across multiple back-end environments. The following steps outline the process to follow when implementing template based requests:

Step 1: Customize EUP personalization

Access the GRC IMG via t_code SPRO followed by menu path:

Governance, Risk and Compliance> Access Control> User Provisioning> Maintain End User Personalization

Step 2: Create copy of the default EUP personalization form

Within the IMG activity, select the default EUP personalization form.

With the default EUP personalization form selected press F6 or click the “copy as” icon.

Enter a new EUP ID #, EUP Config Name, and Description.

Execute or hit enter and copy all dependent entries in the following pop-up.

Click through the confirmation pop-up and save.

Step 3: Customize the EUP Copy

Select the new EUP personalization form and double click the maintain EUP fields folder.

Select fields to include or exclude in the Template Based Request and save.

List of available options for each field.

Step 4: Create an Access Request: Template Based Request and how to associate EUP Personalization forms.

Navigate to the Access Management Work center in NWBC and select the Template Management under Access Request Administration.

Select create, input name of Template, EUP form, and Request Type.

Select Access Details, and click the add button, choose role.

Choose single, composite, or business role, move role down and select OK.

Role will now appear in the Template, select save.

Access Request: Template Based Request is now available for provisioning.

Access Request: Template Based Request end user view.

Template Based Access Requests can take some time to configure, but the benefits gained simplifying access requests for end users often makes this an easy enhancement to justify for your GRC environment.

SAP is introducing a new product for Governance, Risk and Compliance: SAP Assurance and Compliance Software (ACS). SAP ACS is released to customers as of Monday, February 10, 2014.

SAP Assurance and Compliance Software is composed of two solutions that share infrastructure and are installed and upgraded together. These solutions are:

SAP Fraud Management, enhanced with this release and in General Availability as of September, 2013
SAP Audit Management, a new solution, also in General Availability as of February 10, 2014 .

The purpose of SAP Assurance and Compliance Software is to offer customers an integrated suite of applications that let customers use the speed and power of SAP HANA to address a broad spectrum of risk management and corporate and partner compliance issues.

The modern applications that make up ACS offer advanced HTML5 user interfaces that have been designed with users for efficiency and user-friendliness. The lightweight infrastructure shared by the applications makes it possible to extend the applications, for example, to address customer-specific fraud scenarios with SAP Fraud Management. The ability of SAP HANA to offer instant analysis of big data revolutionizes the approach to assurance and compliance issues.

SAP Fraud Management offers a generic platform for analyzing data for signs of potential fraud. The application signals suspicious occurrences with a limited set of alerts. Alerts, in turn, provide the workflow for fraud investigators. SAP Fraud Management also supports investigators in managing and documenting investigations and reporting results. SAP Fraud Management also can be integrated into all kinds of business processes, for real-time online evaluation of claims before payment, disbursals for purchases, and so on.

SAP Audit Management offers a complete solution for managing auditing. The application supports all phases of audit planning, execution, and reporting, beginning with a flexible audit universe repository for auditable items. In the planning phase, the audit department can create an audit plan, to manage audit activity over time, and can set up individual audits, assigning auditable items and audit staff to the audits. The application helps auditors during the execution phase with powerful management functions for working papers and for findings. The application also integrates reporting and follow-up, with management of audit report review and issuance and tracking of open findings.

SAP Fraud Management and SAP Audit Management are fully mobile-enabled. The same user interface can be accessed from the desktop, tablets, and smartphones.

The solutions can be deployed on-premise as well as in the cloud.

SAP Fraud Management is released with new and enhanced features as of Monday, February 10, 2014. SAP Fraud Management is generally available since September, 2013.

SAP Fraud Management offers a generic platform for analyzing data for signs of potential fraud. The application signals a suspicious occurrence with an alert. Alerts, in turn, provide the workflow for fraud investigators. SAP Fraud Management also supports investigators in managing and documenting investigations and reporting results. SAP Fraud Management also can be integrated into all kinds of business processes, for real-time online evaluation of claims before payment, disbursals for purchases, and so on.

SAP Fraud Management uses advanced HTML5 user interfaces that have been developed with user input for efficiency and user-friendliness. The lightweight, generic infrastructure that SAP Fraud Management offers makes it possible to extend the application, for example, to address newly discovered
fraud scenarios quickly and easily.

New and enhanced features in SAP Fraud Management include the following:

Alert dispatching: Alerts that are not assigned to any investigator can be managed with a new dispatcher work list, accessible by way of the Unassigned Alerts tile in the user interface. Unassigned Alerts offers a special dispatcher workflow, so that a dispatcher can pre-investigate an alert, dispatch it, or close it without investigation. There are new sorting, search, and filtering tools to make it easy to manage alerts produced by SAP Fraud Management.
Enhancements to existing features include:
- Navigation to external targets to view original documents from nodes displayed in the graphical Network Analysis investigation tool
- Touch and mouse zooming of the Network Analysis graph
- Enhancements to generic searching
- Customizable alert and search messages.
The existing anti-corruption content , delivered without support or warranty via SCN, remains fully compatible with SAP Fraud Management. Further anti-corruption content will not be released via SCN. Here is a link to the anti-corruption content in SCN.

See also the SAP Fraud Management Release Note.

SAP Fraud Management is mobile enabled and available on desktops, tablets, and smartphones. The solution can be deployed on-premise or in the cloud.

SAP Fraud Management has been integrated into the new SAP offering, SAP Assurance and Compliance Software. SAP Assurance and Compliance Software integrates SAP HANA-based solutions that let you address a broad spectrum of risk and compliance issues in corporate governance.

As of Monday, February 10, 2014, SAP Audit Management is generally available to customers.

SAP Audit Management, powered by SAP HANA, offers an end-to-end solution for managing audits. In the preparation and planning phases of auditing, an auditing department can use SAP Audit Management to collect auditable items in a flexible audit universe repository, prepare audits and assign auditors to them, and build audit plans to manage audit activity over time. During audit execution, the application supports auditors with easy-to-use features for managing working papers and findings. The application also integrates reporting and follow up, with management of audit report review and issuance and tracking of open findings.

The key features of SAP Audit Management include:

Full mobile-enablement and easy access from
multiple devices and platforms: desktops, tablets, and smartphones.
Full coverage of the audit roadmap; including
planning, preparation, execution, report, and follow-up
Flexible Audit Universe that serves as a single
source for audits and monitors audit requests globally
Powerful working paper management that allows
you to create audit documents via drag-and-drop, single-click access to the
documents, and management review
Global monitoring of findings and following up
on the progress of actions
Powerful search function that helps you find the
target information with one click
Clear and intuitive HTML5 user interface design
that improves the user experience and boosts efficiency
Deployable on-premise and in the cloud.

SAP Audit Management, powered by SAP HANA, is one of the solutions of the new SAP offering, SAP Assurance and Compliance Software. SAP Assurance and Compliance Software integrates SAP HANA-based solutions that let you address a broad spectrum of risk and compliance issues in corporate governance.

SAP GRC Access Control supports real-time compliance around the clock and prevents security and control violations before they occur. After implementation and deployment of the risk analysis and remediation software, businesses can analyze real-time data, find hidden issues and help ensure the effectiveness of access and authorization controls across the enterprise.

Some considerations regarding alert functionality:

Alerts could be used as soon as a user executes a specific conflict within the system:

to check if a user executes an SoD conflict or a critical transaction
to check if the reports defined in the mitigating controls were executed on time

Points to consider when using alerts:

no detailed authority check, only on transaction level
no time-dependend aspects considered (e.g. order goods on day 1 and create goods received on day 2 for a separate order will create an alert as well)

My suggestion is to use the alert functionality wisely.

How to use Alerting within SAP GRC?

Run the program GRAC_ALERT_GENERATION to create alerts. Make sure that the action usage sync job run before (GRAC_ACT_USAGE_SYNC) so that all executed actions are captured from the backend system.

There is the possibility to send email notifications to risk owner to be informed when a SOD violation occurs.

NWBC Report

Alert reports can be displayed or cleared in the frontend. Go to NBCW workcenter "Access Management" and open "Conflicting and Critial Access Alerts" in section "Alerts".

You have the possibility to clear an alert or delete an action.

Clear Alert– removes all parts of an alert. User has to execute all sides for the alert to reappear. This tasks requires a comment to be entered.
Delete Action– removes 1 action of an alert. User has to execute the deleted action for the alert to reappear.

If you need more information about the possibilities of alerting with SAP GRC do not hesitate to contact me directly by leaving a comment or sending an email.

A high amount of time during a SAP GRC project will be spent on defining processes and responsibilities. My suggestion is to think in lifecycles for getting a better understanding of the processes and who is taking over the responsibilty.

In this post I would like to clarify the lifecycle of Mitigating Controls. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

Creation of Mitigating Controls

Tasks

Define the control including:

Control description
Control execution
Control approver and control monitor
Documentation of control execution
Templates used to monitor the risk

Involved functions

Control Owner
ICS responsible
SAP GRC responsible

Changing of Mitigating Controls

Tasks

Change the control for example:

Control description
Control execution
Control approver and control monitor
Documentation of control execution
Templates used to monitor the risk

Involved functions

Control owner
ICS responsible
SAP GRC responsible

Deletion of Mitigation Controls

Tasks

Delete the mitigating control within SAP GRC AC
Document the decision of deletion of the mitigating control

Involved functions

Control Owner
ICS responsible
SAP GRC responsible

Reviewing of Mitigating Controls

Tasks

Analyse if maintained controls within SAP GRC are still valid
Analyse if the mitigating controls are covering the risk fully
Test the effectiveness of the mitigating controls

Involved functions

Control owner
ICS responsible
SAP GRC responsible

If you want to have further information or contribute in this blog post do not hesitate to contact me or reply to this post directly.

In this post I would like to clarify the lifecycle of Risks. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

Creation of Risks

Tasks

Define the SoD risk on business level (e.g. with internal auditors)
Evaluate the necessary transactions to execute the SoD conflict (transaction and authorization)
Implement the risk within SAP GRC AC
Validate the risk analysis results

Involved functions

Risk owner
Process owner
ICS responsible
SAP GRC responsible

Changing of Risks

Tasks

Define the changes within the SoD risk on business level (e.g. with internal auditors)
Evaluate the necessary transactions to execute the SoD conflict (transaction and authorization)
Change the risk within SAP GRC AC
Validate the risk analysis results

Involved functions

Risk owner
Process owner
ICS responsible
SAP GRC responsible

Deletion of Mitigation Controls

Tasks

Delete risks within SAP GRC AC which are not valid anylonger
Document the deletion of the risk and especially the decision to delete the risk

Involved functions

Risk owner
ICS responsible
SAP GRC responsible

Reviewing of Risks

Tasks

Analyse if maintained risks within SAP GRC are still valid
Define actions to take because of:
- New business processes
- Changes in the IT system
- Changes in the Internal Control System

Involved functions

Risk owner
Process owner
ICS responsible
SAP GRC responsible

If you want to have further information or contribute in this blog post do not hesitate to contact me directly.

SAP Fraud Management Release 1.1 SP02, powered by SAP HANA, has been released together with a new solution, SAP Audit Management, powered by SAP HANA, as of February 10, 2014.

SAP Fraud Management, in General Availability as of September, 2013, and SAP Audit Management, in General Availability as of February 10, 2014, share infrastructure and can use each other's features. The solutions offer advanced HTML5 user interfaces that have been designed together with users for efficiency and user-friendliness. The lightweight infrastructure shared by the applications makes it possible to extend the applications, for example, to address customer-specific fraud scenarios with SAP Fraud Management. The ability of SAP HANA to offer real-time analysis of big data allows new approaches to assurance and compliance issues.

The two solutions belong for technical reasons to a new product, SAP Assurance and Compliance Software. In a previous version of this blog, this product was incorrectly accorded a higher status than it actually has. The product provides only a technical wrapper for the SAP Fraud Management and SAP Audit Management solutions. Installation and upgrade guides and installation components in the Service Marketplace and SAP Update Manager appear under the name SAP Assurance and Compliance Software. But the two solutions are usable separately or together and are searchable in SAP web sites under their own names as well as under the new product name.

The solutions of SAP Assurance and Compliance are integrated with the SAP Governance, Risk and Compliance Suite. SAP Fraud Management, for example, can create a corresponding ad-hoc issue in SAP GRC Process Control (GRC-PC) when an SAP Fraud Management alert is closed with the finding 'Proven Alert'.

The solutions can be deployed on-premise as well as in the cloud.

SAP Fraud Management Release 1.1 SP02, powered by SAP HANA, has been released as of February 10, 2014 together with a new solution, SAP Audit Management, powered by SAP HANA.

SAP Fraud Management, in General Availability since September 2013, and SAP Audit Management, in General Availability as of February 10, 2014, share infrastructure and can use one another's features. The solutions offer advanced HTML5 user interfaces that have been designed together with users for efficiency and user-friendliness. The modular infrastructure shared by the applications makes it possible to extend them. For example, SAP Fraud Management can be extended to address customer-specific fraud scenarios. The ability of SAP HANA to offer real-time analysis of large volumes of data allows new approaches to assurance and compliance issues.

The two solutions belong for technical reasons to a new product, SAP Assurance and Compliance Software. In a previous version of this blog, this product was incorrectly accorded a higher status than it actually has. The product provides an organizational wrapper for the SAP Fraud Management and SAP Audit Management solutions. Installation and upgrade guides and installation components in the Service Marketplace and SAP Maintenance Optimizer appear under the product name SAP Assurance and Compliance Software. Actually licensable and directly usable are the two solutions, SAP Fraud Management and SAP Audit Management. The two solutions can be used together or separately.

The solutions of SAP Assurance and Compliance are integrated with SAP Governance, Risk and Compliance. SAP Fraud Management, for example, can create a corresponding ad-hoc issue in SAP GRC Process Control (GRC-SPC) when a fraud alert is closed with the finding 'Proven Fraud'.

The solutions can be deployed on-premise as well as in the cloud.

SAP Fraud Management uses a modular architecture so that partners and customers can extend the solution with new detection and investigation technology. You can quickly adapt SAP Fraud Management to address new customer-specific fraud scenarios.

SAP has now released the SAP Fraud Management Enablement Sessions, a set of videos that explain how to extend SAP Fraud Management with new detection and investigation technology. With these videos, you can get up to speed on SAP Fraud Management extension concepts and implementation quickly, so that you can get a fast start on enhancement projects.

The following videos in the series SAP Fraud Management Enablement Sessions are on offer:

SAP Fraud Management Enablement Sessions: Introduction - Here, you'll get an overview of the Enablement Sessions and a quick introducton to SAP Fraud Management.
Data Modeling for Detection - This session explains how detection is modeled in SAP Fraud Management, how to create your own detection data model, and how to set up the data model in Customizing.
Implementing Detection Methods - Here, you'll learn how to implement a detection method in SAP Fraud Management. The solution uses detection methods to find specific irregularities, using SQLscript procedures to harness the speed and power of SAP HANA.
Creating and Calibrating Detection Strategies - A detection strategy groups related detection methods to search for signatures of business irregularities and potential fraud. This video explains how to set up and optimize detection strategies using SAP Fraud Management Calibration. You'll also learn about alerts in SAP Fraud Management.
Extending the Social Network Analyzer - In this video, you'll learn how to set up the Social Network Analyzer provided by SAP Fraud Management to analyze your own detection data model. The Network Analyzer is a powerful investigation tool for graphically displaying relationships in the data, such as relationships between suspicious purchase orders and potentially fraudulent vendors.

You can also turn to the Extensibility Guide for SAP Fraud Management for support in your enhancement projects.

Process Control is totally dependent on the standard frequencies and timeframes provided by SAP in General Settings -> Key Attributes -> Maintain Timeframe frequencies/Maintain Timeframes. When creating custom timeframes, customers need to keep frequencies always active and timeframes always available if any task was previously created with a specific custom timeframe.

When a plan is created, it is dependant of the timeframe chosen. Everytime users open planner, all the tasks are validated according to the timeframe chosen on their creation.

Sometimes, An ASSERTION_FAILED dump is raised by the system highlighting class CL_GRFN_API_TIMEFRAME and method GET_FREQ when accessing planner.

If you face the symptom described above, you can check the following SAP note:

SAP Note: 1970216: ABAP Dump when accessing Planner

If it was not possible to find the missing or inactive timeframe, there is a wiki page which explains how to find it:

http://wiki.scn.sap.com/wiki/x/kIeoFQ

In this post I would like to clarify the lifecycle of Firefighter IDs. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

I have additionally added the RACI matrix to see who is Responsible, Accountable, Consulted and Informed for each step. Please be aware that this is very much depending on the point of view and can be different in your organization. My considerations are commonsense and pretty much of thinking in smooth processes throughout a global enterprise.

Creation of Firefighter ID

Tasks

Define the necessary access rights of the FFID
Define the responsibilities (Ownership, Controller)
Create Firefighter ID

Involved functions

Firefighter owner
SAP authorization team
SAP GRC responsible
Business role owner

Changing of Firefighter ID

Tasks

Define the necessary changes in access rights
Define changes in resonsibilities (Ownership, Controller)
Define changes of Firefighter ID (e.g. validity)

Involved functions

Firefighter owner
SAP authorization team
SAP GRC responsible
Business role owner

Deletion of Firefighter ID

Tasks

Delete the Firefighter ID
Document the decision of the deletion
Archive belonging firefighter logfiles

Involved functions

Firefighter owner
SAP authorization team
SAP GRC responsible

Reviewing of Firefighter ID

Tasks

Review validity
Review firefighter ownership and controller
Check proper access rights

Involved functions

Firefighter owner
SAP authorization team
SAP GRC responsible
Business role owner

If you want to have further information or contribute in this blog post do not hesitate to contact me or reply to this post directly.

Knowledge, Skill & Performance Assessments and Tests are more critical than ever, especially within such industries as Utilities, Financial Services, Public Sector, and High Tech where knowledge needs to be assessed through testing and certifications on a regular basis.

Regulatory bodies and their requirements on such testing and assessment vary by Industry and country - please see here some examples: FDA Compliance (21 CFR Part 11), SOX (Sarbanes-Oxley), OSHA (Occupational Safety and Health Administration), AGG (Allgemeines Gleichgestellunggesetz) or GMP (Good Manufacturing Practice).

SAP Education added recently the assessment technologies powerhouse Questionmark to its portfolio under the brand: SAP Assessment Manager - so I thought this might also be of interest for the GRC Space on SCN.

Please find here a selection of Infosources on the general background as well as on the SAP Assessment Manager

Intro Blog to SAP Assessment Manager with press-release, video etc. by Stewart Davis
Blogpost on "Making a business case for “testing out” of training/ Online assessments in compliance #1" by John Kleeman
If you want to see customer case studies, demos and further details please register to one of our webinars. The first one is german speaking - taking place this friday 14.00 and accessible here. Further englishspeaking webinars will follow.

Hope this info was useful. Please use the comments section to share your feedback and questions.

In this post I would like to clarify the lifecycle of user assignments to firefighter IDs. I have grouped them into four steps Assign, Usage, Delete and Review. Please see for each step expected Tasks and who is involved. Please see also my blog post about Firefighter ID lifecycle if you are interested to get more information in this regard.

The RACI matrix shows who is Responsible, Accountable, Consulted and Informed for each step. Please be aware that this is very much depending on the point of view and can be different in your organization. My considerations are commonsense and pretty much of thinking in smooth processes throughout a global enterprise.

Assignment of User to Firefighter ID

Tasks

Request FF ID assignment
Define validity of assignment
Assign user to FF ID
Define FF controller and method of notification

Involved functions

Firefighter owner
SAP authorization team
SAP GRC responsible

Usage of Firefighter ID

Tasks

Usage of Firefighter
Check Firefighter logfiles

Involved functions

Firefighter ID user
Firefighter controller

Deletion of Firefighter ID assignment

Tasks

Delete Firefighter ID assignment

Involved functions

Firefighter owner
SAP GRC responsible

Review of Firefighter ID assignment

Tasks

Review if Firefighter ID assigment is still correct
Define actions if necessary

Involved functions

Firefighter owner
Firefighter controller
SAP authorization team
SAP GRC responsible

Please contribute and share your opinion as comment to improve the quality of this document.

Thanks and regards,

Alessandro

Recently, I came across with an unique issue where I was not able to transport the SoD rule set across the clients.

While creating the Transport Request as Customized, the system was throwing an error and so asking to create the Transport Request as Workbench Request (I understand, you all would be amazed the same way as I got). It doesn't really require creating WB-TR to transport SoD across clients but just to give it a try, I created the same (WB-TR), then the system started behaving in strange way, It didn't even allow me to enter the WB-TR.

After a couple of try over the same and struggling for it and in absence of any supportive solutions over SDN/SCN/Google, decided to reach-out to SAP.

They provided the SAP Note: , but this was applicable to the system version; GRCFND_A - SP14 and SAPNW 740 with version11 and as I was on version10, so couldn't apply the same and then requested SAP to provide the compatible note which I got today and in fact, released as of toady. The SAP Note: 1991730 - Not able to create transport for SoD Rules after upgrading to NW 740 SP04 AC 10.0 (https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361…). So, now fianlly able to rectify the original issue with the Transport SoD rule-sets.

Thinking of this could be new/helpful to others, I am sharing this to you.

Cheers,

Ameet Kumar

GRC 10.0 - GRC Request with both System and Role Line Items

Most common question I have come across in this forum is how to handle the GRC requests with both System and Role LineItems. As system will not have any owner associated with it, SYSTEM lineitem should be moved to NO STAGE path and remaining roles should follow regular path.

End user logs on to GRC and will add both System and Role LineItems to the request.

1. Create an BRF+ Initiator decision table as shown below to separate System LineItem to NO STAGE path once the request is raised.

2. MSMP configuration should look as shown below.

Once above configuration is done. If a request has both system and role line items, System line item will go to a NO_ROLEOWNER_PATH and roles will go to regular path.