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

 

  • SoD transport issues with GRC AC10.0 SP14

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.

Transport issues.png

 

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 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 (http://service.sap.com/sap/support/notes/1991730) So, now fianlly able to rectify the original issue with the Transport SoD rule-sets.

 

 

  • SoD Transport issues with GRC AC 10.1 SP04/05

For those who are on AC 10.1 with SP04, I am sure they would encounter with the similar issues whilst transporting the SOD rule sets across clients/systems, as I did

With getting no solution from anywhere had decided to reach out to SAP seeking for the solution and it was so quick  and perfect solution. They recommended to implment http://service.sap.com/sap/support/notes/1968082

 

This note is applicable to GRC AC 10.1 with SP04 so is for SP04

 

I had almost forgotten to update this information until now when I saw a thread claiming to have encountered with the same issue.

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

 

Cheers,

Ameet Kumar

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 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

RACI_FFID_User_Assign.png

 

 

Usage of Firefighter ID

 

Tasks

  • Usage of Firefighter
  • Check Firefighter logfiles

 

Involved functions

  • Firefighter ID user
  • Firefighter controller

RACI_FFID_User_Usage.png

 

 

Deletion of Firefighter ID assignment

 

Tasks

  • Delete Firefighter ID assignment

 

Involved functions

  • Firefighter owner
  • SAP GRC responsible

RACI_FFID_User_Delete.png

 

 

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

RACI_FFID_User_Review.png

 

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

 

Thanks and regards,

Alessandro

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.

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 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.

Lifecycle_Mitigating_Control.png

 

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

RACI_FFID_Create.png

 

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

RACI_FFID_Change.png

 

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

RACI_FFID_Delete.png

 

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

RACI_FFID_Review.png

 

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.

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

SAP Fraud Management uses a modular architecture so that partners and customers can extend the solution with new detection rules and investigation features. 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 rules and investigation features. 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 (it takes a couple of seconds to start the video player - don't be alarmed if you have to wait a short while). The Enablement Sessions build on one another. View the entire series if you are newbie to SAP Fraud Management, or skip to the video that helps you with your current task.

 

The SAP Fraud Management Enablement Sessions are as follows:

 

  • 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 Network Analyzer - In this video, you'll learn how to set up the 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. Here is the Wiki version of this posting.

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 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.

Alessandro Banzer

Risk Lifecycle

Posted by Alessandro Banzer Feb 23, 2014

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 Risks. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

 

On request 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 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

RACI_Risks_Create.png

 

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

RACI_Risks_Change.png

 

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

RACI_Risks_Delete.png

 

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

RACI_Risks_Review.png

 

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

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.

 

On request from Colleen 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.

 

Lifecycle_Mitigating_Control.png

 

 

Creation of Mitigating Controls

 

Tasks

Define the control including:

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

 

Involved functions

  • Control Owner
  • Internal Control responsible
  • SAP GRC responsible

RACI_Mitigation_Create.png

 

Changing of Mitigating Controls

 

Tasks

Change the control for example:

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

 

Involved functions

  • Control owner
  • Internal Control responsible
  • SAP GRC responsible

RACI_Mitigation_Change.png

 

 

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
  • Internal Control responsible
  • SAP GRC responsible

RACI_Mitigation_Delete.png

 

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
  • Internal Control responsible
  • SAP GRC responsible

RACI_Mitigation_Review.png

 

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.

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.

Alerting_Program.png

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.

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 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.

    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


1.jpg


2.jpg


Step 2: Create copy of the default EUP personalization form

 

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

3.jpg

 

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

 

4.jpg

 

 

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

 

5.jpg

 

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

6.jpg

7.jpg

 

 

Click through the confirmation pop-up and save.

 

8.jpg

 

 

Step 3: Customize the EUP Copy

 

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

 

9.jpg

 

10.jpg

 

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

8.jpg

11.jpg

 

List of available options for each field.

 

      12.jpg13.jpg14.jpg15.jpg

 

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.

 

16.jpg

 

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

 

17.jpg

 

18.jpg

 

19.jpg

 

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

 

20.jpg

 

 

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

 

21.jpg

 

22.jpg

 

Role will now appear in the Template, select save.

 

23.jpg

 

24.jpg

 

 

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

 

25.jpg

 

 

Access Request: Template Based Request end user view.

 

26.jpg

 

 

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.

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.

Actions

Filter Blog

By author:
By date:
By tag: