Rationale for rules in standard ruleset

[Former Member]

I'm reviewing the violations reported against out R/3 production system, and I'm struggling to understand why some of them, particularly in the "Basis" business process, are SoD violations. Is there a list or document somewhere that explains the thinking behind the standard rules and what issues they are trying to highlight. There are some rules I'm tempted to disable, but there's a nagging doubt in my mind that I might have missed something and disabling the rules would be a really bad idea! Obviously somebody, somewhere, thought all of these standard rules were right for them...

For example, we have some users that have transaction SE16 (display only) and transaction SM50. This trips over risk B009, but why? What am I missing?

Thanks,

Steve.

[Former Member · Accepted solution]

Hi Steve, unfortunately there is no documentation except of the "long text" available.

Best thing is asking your auditor / internal revisor. They should help you by creating a customized matrix. In my mind, a lot of these risks can be switched off.

[Former Member · Accepted solution]

Thanks guys. That's what I thought. My problem is that I am the Basis guy here and I don't understand why some of these rules are there, but that makes me think I'm missing something because the rule must be there for a reason, right? I just thought it would be helpful to know why the rules are there in the first place.

Steve.

[Former Member]

From what I understand the default ruleset is created from many years and many customers suggestions and input. The default ruleset is just a suggestion and should be taken as such. You are correct in your analysis and its a great idea to compare what is in the default ruleset and apply to your own practices. I think you are approaching this the correct way. Load the default ruleset, disable what does not apply to you and add your own SOD's. I think you'll find you've covered yourself quite well this way.

Dave wood

[Former Member]

Thanks. Yes, I'm quite happy with the approach we're taking. Some of the default rules obviously don't apply to us and have been disabled. Some have needed fairly obvious changes before they are appropriate for us. Those rules have been copied, and the copies changed and the originals disabled - doing the same to affected functions where necessary. This gives us an easy audit trail. All of this has been done with the help of our internal auditors.

What we're left with now are rules that our users are triggering, but we don't understand well enough to know why. I like to think I have quite a devious mind, and so if there's a possible exploit somewhere I can figure it out. But some of the standard rules I just don't understand at all. Somebody, somewhere, must have thought all these rules worth including in the standard ruleset, so there must be an exploit hiding in there somewhere. That's what makes me nervous about disabling the ones I don't understand. It would have been really nice if the people compiling the standard ruleset had kept, and published, notes about why each rule was there and what it was intended to detect, rather than letting each customer figure it out for themselves. Yes, we're all different and need a different customised ruleset, but that doesn't mean we don't need to know what the standard rules are there for. We need to understand the starting point before we can be sure about what we get when we customise it.

Sorry. Rant over...!

Steve.

[Former Member]

Hi Steve,

Christian is right. The rules should be reviewed by either the internal audit team, SOX officer or even the business analysts per area (example Basis business analyst)...after careful review of the ruleset, the non-applicable rules can then be disabled provided there is signifcant reasons from the business. Please document these reasons as the external auditors would probably query why the certain rules were disabled.

There is no proper documentation explaining the rationale behind the ruleset, but it caters for all industries and is not specific to your enviroment. Ruleset customisation is definitely required as the standard ruleset is more of a "starting point" to get you started.

Hope this helps.

Rgds,

Prevo.