ARA: Need your suggestion for mitigation of risks???

[former_member184114]

i All,

We are implementing GRC AC 10.0. First I implemented ARA with customized risks copied from SAP standard risks. Business has signed-off all the custom risks and those risks are activated in ARA. Of course, there are lots of violations and due to slow business reponse, these risks were not addressed, meaning that "GET CLEAN" is not successfully done.

Now, we are planning for ARQ and most of the work is done and in fact ready for go-live. The problem is that, as per customer's business requirements, all requests containing violations should be routed to the highest authority of the organization. What is happening is that, almost all the requests are having violations and they are likely to reach that highest authority for his address. This seems to be not correct and very disturbing.

My questions/concerns are:

1. If all roles are violations-free and a single role is added in a

   request, then probably this kind of requests will not go to that

   authority. This is ok

2. If two or more violations-free roles are added in a request and risk

   analysis results in a violations, then how this should be handled?

Please share your valuable inputs to deal with this situation.

Regards,

Faisal

[alessandr0 · Accepted solution]

Dear Faisal,

in our enterprise we do not differenciate between having requests with one or more conflicting roles. In the end the "highest authority" has to do a mitigation before the request can be approved. Hence we do not handle such requests differently.

Basically it is important that, following the motto "stay clean", all requests with risks must be handled by the responsbile (remediation or mitigation) before final approval.

Does this answer the question?

Regards,

Alessandro

[former_member184114 · Accepted solution]

Alessandro,

Thanks for your reply.

Yes, I agree. If a request has one or more conflicting roles, finally the designated person has to mitigate it before approving. This has answered partially- thanks again for this.

My concern is that, the "GET CLEAN" process was not done successfully roles having violations. The clean-up is going on and will be done shortly. The actual question is that, what should I do if a request has violations as this is getting routed to the designated person. He belongs to top most management and do not expect him to create mitigation control by himself and mitigate the risk - correct me, if need be.

May you please help me formulate a process for this? One option I think  could be is,

before actually that designated person mitigates a risk, somebody proactively creates a control and keep it ready for getting it assigned for mitigation by that person.

Please help me have clarity on this.

Regards,

Faisal

[alessandr0 · Accepted solution]

Dear Faisal,

I am using the mitigation maintenance workflow for creation of mitigating controls. The responsible person can create and will be reviewed and finally approved by the GRC team.

In my enterprise I have created mitigating controls for each region, but only controls which are required. If we do have a new upcoming risk, which wasn't present earlier, the control must be created first. Creation of a mitigating controls means more than just creating a control in GRC. In the end each mitigation needs to have a defined compensating control which really mitigates the risk. This process must be monitored by a second person to ensure that the controls are defined properly.

I assume that creation of controls are seldom and therefore I do not see the reason of having controls for each risks available in GRC. As global responsible for internal controls and GRC my first target is to reduce the number of risks which are mitigated. Hence I like to have an additional step for creation.

Looking forward to hear from you.

Best regards,

Alessandro

[former_member184114 · Accepted solution]

Alessandro,

Thanks for your reply.

 I am using the mitigation maintenance workflow for creation of mitigating controls. The responsible person can create and will be reviewed and finally approved by the GRC team

May I know who is that "responsible" person to create these mitigation controls in your organization? Do you have a designated one person to do it or how you get a mitigation control information. Of course, in GRC we simply create and upload that given information by the business in the form of mitigation sign-off document- correct me, if need be.

In my enterprise I have created mitigating controls for each region, but only controls which are required. If we do have a new upcoming risk, which wasn't present earlier, the control must be created first. 

You mean that for each risk, we need to have its compensating control ready, proactively? If that is so, suppose I have 100 risks, I need to have 100 controls for it, right? Please accept my apologies for such questions, but really need clarifications.

. Creation of a mitigating controls means more than just creating a control in GRC. 

Can you please elaborate it?

I assume that creation of controls are seldom and therefore I do not see the reason of having controls for each risks available in GRC. 

We have copied most of the standard risks to custom and most of them are throwing violations. Therefore, in this case in spite of remediation, risks are available. Business wants to mitigate it. Therefore, this is the reason these controls are to be created. Please advise.

As global responsible for internal controls and GRC my first target is to reduce the number of risks which are mitigated. Hence I like to have an additional step for creation.

Can you please this further?

Regards,

Faisal

[alessandr0 · Accepted solution]

Hi Faisal,

in my organization we have several roles. Let me explain:

- Global GRC Responsible

- Global Internal Control Responsible

- Local (per entity) Internal Control Responsibles

Mitigations are done per entity by the local IC responsible. Mitigating controls can be requested by the local responsibles but must be approved by the global GRC responsible. The global GRC responsible, who is the same person as the global IC responsible, has to make sure that all documents are filled properly.

Yes - I have created a mitigating control for each risk, as each risk needs to have its compensating control defined. The mitigation must be reviewed and also monitored by a second person (four eyes principle). Mitigations must be created proactively before approving an access request as we do not want to have uncontrolled risks in the system.

As mentioned each mitigation is a compensation of a risk. Means you have to define controls and steps how risks are mitigated. This can be reports which need to be run, analyzing lists, second signature, etc. etc. Such controls must be defined before implementing a control in the system as otherwise it is not possible to guarantee the evidence of the control.

My last point regarding the reduction of risks: if you have 100 risks currently in your productive system, your target has to be reducing such amount to a lower level. In the end the target must be having all duties properly segregated, as otherwise you can never guarantee that fraud cannot happen.

During my last projects we could eliminate more than 90% of SOD conflicts by changing processes and the organization of an enitiy. In some entities I have 6-8 risks remaining, which is a very low level. All other risks which we initially had, could be remediated and solve effectively. For the remaining 6-8 risks we have defined compensating controls which fully cover the risks.

Hope this helps 🙂

Regards,

Alessandro

[alessandr0 · Accepted solution]

see more about mitigating controls and compensating controls in one of my documents:

[former_member184114 · Accepted solution]

Dear Alessandro,

Forgot to tell you that I am unable to recognize you in this new picture

Earlier I had some other image of yours and now it is different!

I am assuming GRC in general term and not related to "GRC System"

- Global GRC Responsible
- Global Internal Control Responsible
- Local (per entity) Internal Control Responsibles

Will it be ok if I map below:

Global GRC Responsible=External Auditor

Global Internal Control Responsible=Internal Auditor

Local (per entity) Internal Control Responsible=Department Head (or any one responsible from dept)

 The global GRC responsible, who is the same person as the global IC responsible, has to make sure that all documents are filled properly.

Can you please elaborate it?

Yes - I have created a mitigating control for each risk, as each risk needs to have its compensating control defined. The mitigation must be reviewed and also monitored by a second person (four eyes principle). Mitigations must be created proactively before approving an access request as we do not want to have uncontrolled risks in the system. 

This means, I need to create mitigation controls for all risks. Earlier, what was happening was, after performing risk analysis for roles/users, if we get risk violations, then only those risks were getting mitigated. I think this should be changed now and need to create mitigation controls for all the risks available -  please request you to confirm it.

This can be reports which need to be run, analyzing lists, second signature, etc. etc. 

Can you please help me understand this?

I appreciate your patience 🙂

Regards,

Faisal

[alessandr0 · Accepted solution]

Dear Faisal,

sorry for my late reply.. couldn't find the time to get back to you earlier.

I see... I've just updated my picture to a newer one 🙂

I am assuming GRC in general term and not related to "GRC System"


- Global GRC Responsible
- Global Internal Control Responsible
- Local (per entity) Internal Control Responsibles



Will it be ok if I map below:

Global GRC Responsible=External Auditor
Global Internal Control Responsible=Internal Auditor
Local (per entity) Internal Control Responsible=Department Head (or any one responsible from dept)

Such discussions depend on your organization and can be slightly different from mine. Generally I say the Global GRC Responsible shouldn't be an external person, as this responsibility should be internal (my meaning). Global IC Resp can be an internal auditor. Responsibilities from local entities must be handled from each entity independently as in the end each of them is responsible for the internal controls. In our organization it's most of the time the entitiy controller or head of finance departement as those people are close to topics related to internal controls.

 The global GRC responsible, who is the same person as the global IC responsible, has to make sure that all documents are filled properly.

Can you please elaborate it?

All defined controls (compensating controls, is a control effective, evidence, etc. etc.) must be documented and are checked by the global responsible if they are effective and properly documented. Also he checks if all the defined (required) controls for a risks were performed and documented (e.g. spotchecks, etc.).

Yes - I have created a mitigating control for each risk, as each risk needs to have its compensating control defined. The mitigation must be reviewed and also monitored by a second person (four eyes principle). Mitigations must be created proactively before approving an access request as we do not want to have uncontrolled risks in the system.




This means, I need to create mitigation controls for all risks. Earlier, what was happening was, after performing risk analysis for roles/users, if we get risk violations, then only those risks were getting mitigated. I think this should be changed now and need to create mitigation controls for all the risks available -  please request you to confirm it.

Depends on your process. If I come back to my understanding first I try to remediate all risks if possible. Means I really try to remove risks by changing processes, organizations, duties, etc. so that the risk is not applicable anymore. Whatever is left over must be mitigated. Means you have to define compensating control to monitor the risk. Such compensations are documented in my post () and must be defined for each risk. As mentioned above possible mitigations are implementing a 4-eyes-principle, define spotchecks, check reports, etc.

In the end each risks must either be completeley removed from your system or mitigated with a valid compensating control. How such compensating controls look like can be different in each organization.

Once again I want to highlight that this concept and way of thinking is based on best practice and how I see the concept/process of GRC. At the end of the day the management and the internal control responsible have to make sure that all risks are monitored and properly documented.

Looking forward to further discussions 🙂

Best regards,

Alessandro

[former_member184114 · Accepted solution]

Dear Alessandro,

Thanks a lot for explaining these concepts in detail! 🙂

Actually certain things are subjective and need to be handled locally based upon the environment nature. However, I got an opportunity to understand overall concept from you and again I thank you for that

Regards,

Faisal

[alessandr0 · Accepted solution]

Welcome! Let us discuss if you have further requirements always looking forward to get more details.

Regards,

Alessandro

[former_member184114 · Accepted solution]

Surely I may need your help going forward too!

[Former Member · Accepted solution]

Hi Alessandro,

firstly, many thanks for all your contributions to the community.

i would like to know more on the process of changing the process to eliminate risks but wasn't sure where to start. i have the below queries based on your statement -

"During my last projects we could eliminate more than 90% of SOD conflicts by changing processes and the organization of an entity"

Can you please elaborate on the above around changing process as in role redesign or business process in general with an example if possible?

2. say i have 20 risks of which around 12 dont reflect in my violation reports as of now..do controls need to be defined for these 12 - to plan for future access changes and the likelihood of some of these showing and so have a control ready?

Also, if i define a control that mitigates a risk that is not currently reflecting for any of my users, how is that documented as the control may have to be redesigned in the future owing to several factors (especially with four eyes concept).

hope i am clear enough..

[former_member184114 · Accepted solution]

Vamsi,

Below is my understanding about "Changing Processes"

Vamsi V wrote:


"During my last projects we could eliminate more than 90% of SOD conflicts by changing processes and the organization of an entity" 

Usually, it is noticed that businesses follow their own processes to achieve the business goals. During this, they do not consult with any "Authority" to check if they are doing it correctly. Their objective is to just achieve the business goal. This may result in 'corrupted' business process, thereby giving more SOD violations.

Now, if this is thoroughly investigated and 'flaws' are removed (Changed)  from existing processes by following standard processes or 'clean' processes (in consultation with Auditors or otherwise), the SOD violations are reduced to maximum!

This is very normal and a part of Get and Stay clean process. This is more related to business processes, not the role design.

2. say i have 20 risks of which around 12 dont reflect in my violation reports as of now..do controls need to be defined for these 12 - to plan for future access changes and the likelihood of some of these showing and so have a control ready?
Also, if i define a control that mitigates a risk that is not currently reflecting for any of my users, how is that documented as the control may have to be redesigned in the future owing to several factors (especially with four eyes concept).

First of all, the question arises that 'how that 20 risks have come?'. Meaning, you must have not discussed these 20 risks with business, therefore you do not know if business "REALLY" needs them.

Had these risks been discussed with business, you would have filtered the required risks and unwanted risks would not be available.

I would explain about the 20 risks situation now - As soon as we have risks, their mitigation controls have to be coupled with them. This was my initial question and Alessandro answered it.

Meaning, 20 Risks are coupled with 20 mitigation controls = 20 Risks <-> 20 MC.

It is not mandatory to reflect all risks in your reports. It depends upon the authorization design in back end system. If any Role/User has conflicting authorizations defined in Rule Set, it will report, otherwise not.

You have 2 posts here from Alessandro for Life Cycle of Risks and Mitigation Controls. Please visit them and hopefully you will get an idea about the last piece of your question.

Regards,

Faisal