Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How To Perform Segregation of Duties(SoD)?

Former Member
0 Kudos
2,087

We are implementing ECC6 and currently I already have a list of transactions that will be used for creating roles.

As the company is following SOX regulations, how do we do the SoD? How do you create the SoD Matrix?

Thanks in advance!

9 REPLIES 9

jurjen_heeck
Active Contributor
0 Kudos
377

This depends on what your role in the organization is.

At least it cannot be a one man job to list transactions, decide which should not be used together and build the roles.

1- Business (together with functional consultants) lists required transactions for the designed processses and procedures

2- Auditors and the business draw up segregation of duties based on corporate risk analysis and SOX

3- The above information is put together in a functional design, complete with test requirements

4- From this, a technical design is made and implemented in the system

5,6,7..... testing/rework/testing/rework............

So, somewhere in this your task(s) will lie....

Former Member
0 Kudos
377

Hi JB L.

Do some searches on google & SDN for RSUSR008_009_NEW

There is standard functionality within SAP to allow creation and reporting on SoD's.

It's not pretty, it's difficult (for me anyway) to set up but it is free! and beats doing the analyses manually.

0 Kudos
377

SoD is always company specific.

I agree that it is not a one-man job and can be difficult, but it is not up to us to decide on that.

Normally in a company there is someone called controller as a assistant to the CFO and SoD is their responsibility. So whatever you do on SoD you should NOT do it without their written agreement.

Most companies i worked with already had things sorted out for Finance, but we had to do it for all functional areas in SAP. No SoD matrix i have seen was applicable for all.

Even in international implementations we had to redo this for certain countries, sometimes because of different local laws but mostly because of different organizational aspects.

One of the things around SoD is that there are different stages in risks:

1 absolutely forbidden

2 preferably not, but can be allowed with additional controls like reports

3 not if it can be solved elsewhere.

So a number 1 in a specific situation can be changed to a 2 or 3 in other countries and vice versa.

The SoD is a process not a list. And if you read SOX on this they also do not provide you with a list, just tell you that the company should have a SoD list created and adhere to that list.

Of course there are a number of SoD's that apply everywhere and those can be found on the internet, but are far from complete!

0 Kudos
377

can you provide help in explaining how to use it. it will be highly appreciated.

0 Kudos
377

>

> can you provide help in explaining how to use it. it will be highly appreciated.

Hi Novice,

A good place to start is here:

http://help.sap.com/saphelp_nw04s/helpdata/en/f9/558f40f3b19920e10000000a1550b0/content.htm

Personally I find it complex at the best of times - too much so to put in a post at this point in time.

0 Kudos
377

If "it" is report RSUSR008_009_NEW, then I recommend getting up do date with SP levels and a reasonably high supported release level before you start. Also read the SAP notes on the report, in addition to the documentation....

As Alex mentioned, it is not only tricky, but there are a number of patches and changes to the logic. However, once you have it working, it does the trick to quite easily cover 80% or more of meaningfull analysis with 20% or less of the effort and costs of going "the full Monty".

SAP security is tricky as well for a novice (no offense!) and you could be "tricked" into buying a lot of nonsense..., so the fact that report RSUSR008_009_NEW is tricky as well is, in my humble opinion, a perfect, for free and SAP supported fit

Cheers,

Julius

0 Kudos
377

>

> it does the trick to quite easily cover 80% or more of meaningfull analysis with 20% or less of the effort and costs of going "the full Monty".

>

> SAP security is tricky as well for a novice (no offense!) and you could be "tricked" into buying a lot of nonsense..., so the fact that report RSUSR008_009_NEW is tricky as well is, in my humble opinion, a perfect, for free and SAP supported fit

I couldn't agree more, it is a very useful tool which is overlooked all the time. All it takes is time, patience and a good understanding of the authorisation concept - all things which you need to properly implement far more expensive add on solutions. That is not to say that they don't have a place, but configuring RSUSR008_009_NEW to do the mechanics of your SoD's can be a very cost effective alternative to an external tool, although there are some less expensive options which are very good too.

0 Kudos
377

Hi Alex,

I was expecting some "please email me the "the_full_monty.exe" responses...

Anybody who has been around for a while, will have battled with the SAP reports (and often resorted to "download the tables"). I can understand that and have done so myself. But ultimately, much like RSUSR008_009_NEW, we are all the guilty ones ourself for not having used them... until it is too late (and some ppt takes control of exe (combined with a release upgrade).

One thing about SDN which I realy like, is that we as customers, consultants, business partners, even end users... can provide feedback to SAP and engage in improving the systems we use.

Surely, it is a rediculous investment for paying customers to not use the standard tools (if used...)...

I find it absurd to pay additional licenses for external tools to comply with legal requirements for already licensed products / platforms.

Cheers,

Julius

Former Member
0 Kudos
377

Hi JB,

As you are concerned with the Security and Authorizations i will assume you are a BASIS/Security consultant/administrator.

Basically you should be 'provided with' a list of SoD conflicts which would normally entail a list of transactions and corresponding authorization objects which when together cause a conflict.

This list comes from different places/people depending upon the structure and responsibilities in your organisation.

If i were you i would ask the Person(s) who are responsible for the technical assurance of SoD in your particular organisation to provide you with at absolute minimum the list i mentioned above. However there are many tools out in the market which will do SoD scans of your system and locate the exact role/profile/user and what objects are causing this. I wont mention any names but SAP do have such a tool, as well as many other third parties which are SAP approved.

SoD is a complex issue, so don't forget be patient, Good Luck!

Regards

Ashley