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.

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

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

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

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.

Access Controls is used as a documental tool for Mitigating Controls, rather than a implementing tool, i.e. you apply
the control against the role/user, but the actual application of the control is performed outside of Access Control. This
may be realized by running a custom SAP report to monitor the usage of the risky functions within the ECC system
etc.
Action is for the t-code of the SAP Report. A brief explanation below will help in understanding
If you have a mitigation control that Mr. Z will run X report using Y t-code on a frequent basis of monthly or quarterly
and reviews the report.
Then you need to give that Report name- X, in Action - Y T-code and frequency as Monthly/Quarterly. This helps for
the system to check if the t-code has been executed or not in that frequency by the Monitor and generates an Alert
[based on alert generation configuration]. If the monitor doesn't execute the action in backend in the set frequency,
we will find an alert in Alert monitor- control monitoring, but if the monitor executes the action we will NOT get alert.
The role of Monitor is to see whether everything that was risky from the access being mitigated is fine or not. That is,
he/she would see to it that the user who has been given extra excess or conflicting access has not mis-used it. Every
Mitigation control, for this purpose has a Monitor attached to it who does this job.
Action - This is some tcode a monitor has to execute in backend to see that reports.
 A. E.g. if someone is doing check payment entry(risk), and mitigation is done for a user/role, there must be a
tcode where we can check what payments are made( sorry I am not well versed in FI Tcodes) , this tcode
will be put in action tab and monitor will have to check it via that particular tcode.

Frequency is simply what the period you want to set within which a monitor must perform this activity - say one week
or one month.
If a monitor doesnt execute that action/tcode within that time, an alert will be generated and mail will be triggered to
mitigation approver (indicating that supposed task is not being performed).

Example:

We have a mitigation control defined for Risk " To check if a user has created a fictituous GL account and generated
Journal activity via positing entries".

So, we are giving this access to some of the users by defining a control on top of it.

The role of Monitor is to see whether everything that was risky from the access being mitigated is fine or not. That is,
he/she would see to it that the user who has been given extra excess or conflicting access has not mis-used it. Every
Mitigation control, for this purpose has a Monitor attached to it who does this job.

So, our monitor will run the report everyday using the report for G/L accounts change log Tcode as mentioned in the
control.

So, the Tcodes which we mention under ACTION field under reports tab actually depends on what are you trying to
monitor if that access risk access is given to any user. This action which we mention can be standard ones or
Customized reports.