Organization Rules

Organizational rule functionality has been created to eliminate false positives based on organizational level restrictions. It is important to understand that organizational rules should only be used in those specific situations where a customer has made a conscious decision to segregate via organizational levels.

For example, a customer may have a shared service center where they allow a team member to both process vendor invoices and create AP payments. Normally, this would be a high risk level conflict.

However, the shared services center has specifically segregated their team members so that they cannot do these two functions for the same organizational levels.

In our examples below, the shared service center has segregated so that the user who can enter vendor invoices for plants BR01 or BR03 cannot process payment for company code 1000 (since plants BR01 and BR03 are part of company code 1000). In this example, a conscious decision was made to deal with the conflict via segregating org levels so for this risk, organization level rules are applicable.

This functionality should not be used to try to group users into reports by organizational levels in order to distribute SoD reports to various management levels. Organization level rules should only be used for exception based reporting in order to remove false positive conflicts that result from organization level segregation.

Because of the sizable performance impact that organization level rules can have, they should be used minimally for only those situations where the company has made a conscious decision to segregate via org levels.

Organizational Level reporting is what can be used in order to consolidate reports of conflicts for a specific organizational unit to assist in distributing reports to the risk owners of each area.