Mitigation versus RuleSet Change

[Former Member]

Hi,

We are going live with GRC 10 in January and are currently building and testing roles in our TST environment.

We are encountering resistance from process team owners in relation to certain risks. For example, we have a risk called ZS007 (copy of SAP Std S007) which is an OTC risk that covers Create Sales Order versus Create Billing Document.

The process owner above does not see this as a risk for our business. She would need to split her team into two in order to accommodate this risk and the team is too small to split up. She does not want to put any mitigating monitors in place as she says that 1. she does not have time to do them and 2. it will only involve her reading reports about what transaction her staff have been running and she knows that already.

Therefore, the process team owner has asked us to delete this risk from the Rule-Set. We are reluctant to do this as it could open the flood-gates and we may start getting many more requests to delete risks. We also do not know the effect this would have as we roll-out the product to other areas of the business in the future.

How do other companies deal with these issues? Is it OK to delete Risks from the Rule-Set if they are deemed irrelevant? What level of Mitigation is acceptable? We have been told a figure of 5%.

All advice greatly appreciated.,

Regards,

Colin

[Former Member]

Is the Z risks not custom?

Is there no risk management team?  If we let our process owners deterrmine risk then nothing would be a risk

For our team we have many players involved in establishing the risks and the maintenance.  We value the process owners input but from a compliance standpoint it is a group effort on compliance.  Keep in mind that no two rule sets will look the same.  Internal processes and external compliance guidelines will help establish your rule set.

Security Team - Technical Expertise

Business Controls - Ensures compliance at the business level

IT Controls - Ensures technical compliance

Internal Audit - Overall compliance team

[Former Member]

SAP's standard rule set has a comprehensive list of violations and would need to be tailored to the company's need. As rightly pointed out by Chris it is a collective effort by Compliance teams and Security with a buyin from Audit. In this case, we can make the risk Inactive instead of deletion if all 3 teams agree that ZS007 is not a risk. If the size of the company is small to medium we have observed that SAP's ruleset is very exhaustive and manual mitigations are a must to work around them.

Good luck with the convincing process

Regards,

Sri

[kevin_tucholke1]

Colin:

As a general rule, I am very seldom in favor of 'deletion' from a rule set.  I ususally recommend that you 'disable' after disucssion with the compliance personnel involved.  In most companie, I ususally see that there is either a compliance office or commitee that will take a look at requests such as this and make a determination if such a request is appropriate. 

The delivered rule set is just a launch pad to start with and EVERY company will modify this to fit their compliance situation.  If your company does not feel that the risk is justified in your environment, then you can make the adjustment as you see necessary. 

In regards to the level of mitigation, this again differs by company.  Some companies state a limited mitigation assignment policy and choose to change the business process instead. 

I have seen the situation also where people in a certain User Group (i.e. Sales Support) are expempt from a particular risk, but everyone else is still subject to the rule.  This can be accomplished by using the Supplementary Rules.

Just a couple of questions:

1.  Is there a particular reason that you have a ZS007 if it is a copy of the delivered Risk?  The delivered rule set, as I said above, is really meant to give SAP Customers a launch pad to start from and to maintain as they see fit.

2. Has your rule set been productively used previously?  If so, then I would reiterate that 'deletion' is truly not the way to go as you probably need to document that you had the risk previoulsy, but have gone through the process and discussions to 'remove' (disable) this risk from the risk anlaysis.

While the BPO is the person who truly understands the functional and business processes around the business flow, I usually don't see that they have the ultimate authority to say that a particular risk just should be turned off. 

Hope this helps.

Kevin Tucholke