Skip to Content

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.

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

  1. Colleen Hebbert

    Hi Alessandro

    Great to see someone like you starting up blogs around process and governance of using GRC. It helps to better understand why GRC has been built the way it has and how to go about designing your processes.

    Would it be possible to expand this out to capture your acronyms (e.g. ICS) and a high level summary of why they should be involved in the decision making (possibly a RACI model); what sort of activities and impacts they should consider in determining the control.

    Regards

    Colleen

    (0) 
    1. Alessandro Banzer Post author

      Dear Colleen,

      thank you very much for your input which is much appreciated.

      For sure I will update my blog to get a clear understanding for everyone. For someone like me, who is working with such terms daily, everything is naturally and I do not realize that I am writing in technical jargon.

      Best regards,

      Alessandro

      (0) 
  2. Ameet kumar

    Hi Alessandro,

    This is really quite a ahelpful document.

    Could you please elaborate on “templates used to monitor the risk” and do you mean ICS by some Audit-controls?

    (0) 
    1. Alessandro Banzer Post author

      Hi Ameet,

      thanks for your feedback.

      This was a mistake and I corrected already in the latest version. Templates used are the reports which can be defined for monitoring the risk.

      ICS is an internal jargon we are using for “Internal Control System”. I’ve changed as well to “Internal Control responsible” and hope this makes it more clear.

      Thanks and regards,

      Alessandro

      (0) 
  3. Patrick Beyer

    Hi Alessandra,

    That’s a good overview!

    Could you share who is generally playing each function you mentioned.

    For intance, who is the control owner, the internal control responsible, the SAP GRC responsible ?

    In our company, we are using SAP GRC 10 and the control owners we put for each mitigating control (MC) are our internal auditors. They are also mentioned as monitor.

    However, the controls that are linked to the MCs are supposed to be executed on a regular basis (monthly mosto f the time) by the manager or designed person for the respective users assigned to the MC.
    Therefore, when our internal auditor are doing their audit they are asking for evidence that the control was processed as expected.

    We, as GRC admin, are doing MC assignment removal when a user doesn’t have any risk anymore due to roles assingment change or role content change. We are also proposing roles removal options to remove a MC from a user when that user didn’t execute the set of Tcodes generating the risk. We are also maintaining and supporting the whole Access Control application (workflows, risks, functions, …). Is the SAP GRC responsible related to our GRC Admin as described above ?

    Thanks in advance for your feedback.

    Feedback from anyone else is also welcomed.

    Patrick.

    (0) 
    1. Alessandro Banzer Post author

      Hi Patrick,

      thanks for your feedback. I try to clarfiy all your questions and hope it helps for a better understanding.

      Regarding the ownership:

      – Mitigation Control Owner is in our enterprise the ICS (Internal Control System) responsible from each entity. As we have different Internal Controls in different entities each entity has its own owner. To generalize this is definitely a business person in my point of view.

      – Internal Control responsible we have separated into two levels. We have a global responsible who is also taking care of the GRC. Secondly, we have in each entity a local responsible who is taking care of the internal control system. When it comes to mitigation and defining compensating controls this is part of the local responsible. Mostly in close collaboration with the global counterpart.

      – SAP GRC responsibilities we have splitted into two main areas. Business perspective and technical perspective where the business responsible for GRC is actually maintaining GRC (e.g. Create/Update/Delete mitigating controls, run risk analysis, etc. etc.). The technical counterpart is doing technical settings in the background (e.g. SPRO, rule set upload, MSMP workflows, etc. etc.).

      From our current set up the Control Monitors are business functions which we have defined in the Internal Control System. Each function then gets a name from business (mostly process owners) and that is the one who is maintained as Monitor.

      Our internal and also external auditors are reviewing and asking for evidence directly by the Control Monitor as it is his responsibility for his particular organization.

      Mitigation Control removal, as you mentioned, are done by our business GRC responsible (from business itself) via the Invalid User Mitigation report.

      Generally I am saying that the complete ownership of GRC must be in business and definitely not in IT. IT or a SAP Competence Center is only supporting business when it comes to technical aspects of GRC like updates, bug fixing, etc.

      Hope to get also your opinion and thoughts on this.

      Looking forward to hear from you.

      Regards,

      Alessandro

      (0) 
  4. Scott Erickson

    Once I have a mitigating control set up and it’s being used to mitigate risks, how can I change the assigned mitigating control monitor (e.g., a new person assumes a job)?  When I attempt to change the name in the control set-up, it’s states the control is being used to mitigate risks and cannot be changed.  GRC will allow me to add the desired name and save (I just cannot delete the old name).  The only way I can figure to change the assigned monitor is run a report of mitigated risks, sort by the control in question, and then change each instance of mitigation one-by-one using the control and monitor drop-down menu. This takes forever.   There must be an easier way to simply re-assign control monitors.  Please advise.  Thanks.

    (0) 
  5. Denis Ontiveros

    Great Content. Are you aware of any standard GRC workflow we can use to periodically review mitigating controls and mitigating control assignments?

    If not, how would you propose this could be done in a more efficient manner than manually!

    Thx

    Denis

    (0) 

Leave a Reply