GRC - Good practises for SOD functions design

[madhusap]

Hi All,

When defining risks in any project first step is to identify all the processes in the company and group similar processes as functions and then validate these functions against each other in a SOD role matrix to come out with different types of risks [High, Medium, Low] and Mitigation controls.

From my first project i always have the same doubt. On what basis are these functions defined.

As per standard definition function will include a group of transactions which can perform a similar task.

For example creating security deposits and posting payments might be two different functions but when according to business they are done by the same person, in that case i can define both in a single function or i create separate functions for posting, separate functions for release activities, separate functions for maintenance activities. Will this be a good approach to go ahead with?

I just want to know good practices followed/suggested by experts who have been with the product from quiet a long time, so that it will be very helpful in my approach.

Thanks & Regards,

Madhu.

[former_member184114 · Accepted solution]

Madhu,

How these risks are defined mean:

1. Identify different business process (for example MM).

2. Group the business activities of similar kind (represented by TCODES in SAP). For example, Create Vendor.

3. Group another business activities of similar kind (represented by TCODES in SAP). For example, Vendor Payment.

Now assuming that in an organization, only MM business process is there and in that process only 2 sub functions are there. These grouping of similar business activities are based upon auditing rules and those are termed as conflicting activities.

Note that, same tcodes are used across different module. Therefore, do not forget to include them in functions.

Regards,

Faisal

[Colleen]

Hi Madhu

I see it as group like transactions together as a Function. E.g. Enter Invoice -which could be some F-xx* transactions and FB transactions. Then if another Function is Process Payments it would contain all the steps that allow you to process a payment.

The risk would then be the two functions.

The rule violations would then be an action in the Enter Invoices with an Action in Process Payments

A function is not about grouping a heap of transaction the user has in their job. Ask yourself when you form the risk Id will each combination constitute a valid rule violation

The other thing to consider with Functions is also integration with BRM. You can add a Function to the Role you build it when you maintain authorizations (launches PFCG) it will import the transctions from the Function to the role Menu.

Regards

Colleen

[madhusap]

Hi Faisal and Colleen,

Thanks for your inputs. I am also going in the same way as suggested by you. Today we had a review with business and apart from few changes it went well.

Thanks for your explanation with example which gave bit more clarity for me on this SOD part.

Regards,

Madhu.