The basic principle underlying the Segregation of Duties (SoD) concept is that no employee or group of employees should be able to create fraudulent or erroneous transactions in the normal course of their duties. Said differently, the American Institute of Certified Public Accountants (AICPA) defines Segregation of Duties as ”the principle of sharing responsibilities of a key process that disperses the critical functions of that process to more than one person or department.” It is important to note that this concept impacts the entire organization, not just the IT group. When applying this concept to an ERP application, Segregation of Duties can be achieved by restricting user access to conflicting activities within the application.
To establish processes and procedures around preventing, or at a minimum monitoring, user access that results in Segregation of Duties risks, organizations must first determine which specific risks are relevant to their organization.
What is an SoD ruleset?
When referring to user access, an SoD “ruleset” is a comprehensive list of access combinations that would be considered risks to an organization if carried out by a single individual. Each unique access combination is known as an SoD “rule.” An SoD rule typically consists of several attributes, including rule name, risk ranking, risk description, business process area, and in some more mature cases, references to control numbers or descriptions of controls that can serve as mitigating controls if the conflict is identified.
If organizations leverage multiple applications to enable financially relevant processes, they may have a ruleset relevant to each application, or one comprehensive SoD ruleset that may also consider “cross-application” SoD risks.
The table above shows a sample excerpt from a SoD ruleset with cross-application SoD risks.
Establishing risk ranking definitions
Building out a comprehensive SoD ruleset typically involves input from business process owners across the organization. Before meeting with various groups to establish SoD rules, it is important to align all involved parties on risk ranking definitions (e.g., critical, high, medium and low) used to quantify the risks. This helps ensure a common, consistent approach is applied to the risks across the organization, and alignment on how to approach these risks in the environment. For example, the risk of a high ranking should mean the same for the AP-related SoD risks as it does for the AR-related SoD risks.)
If risk ranking definitions are isolated to individual processes or teams, their rankings tend to be considered more relative to their process – and the overall ruleset may not give an accurate picture of where the highest risks reside. For example, an AP risk that is low compared to other AP risks may still be a higher risk to the organization than an AR risk that is relatively high.
One recommended way to align on risk ranking definitions is to establish required actions or outcomes if the risk is identified. For example, a critical risk might be defined as one that should never be allowed and should always be remediated in the environment, whereas high risk might be defined as a risk where remediation is preferred, but if it cannot be remediated, an operating mitigating control must be identified or implemented…and so on.
Developing SoD rules
Establishing SoD rules is typically achieved by conducting workshops with business process owners and application administrators who have a detailed understanding of their processes, controls and potential risks. It is also usually a good idea to involve audit in the discussion to provide an independent and enterprise risk view.
As business process owners and application administrators think through risks that may be relevant to their processes/applications, they should consider the following types of SoD risks:
- Master data and transactions: A user may create or update master data elements and then transact against those updates (e.g., update a supplier’s bank account and then process a payment for that supplier).
- Configurations and transactions: A user may update key configurations and then transact against the changed configurations (e.g., change receipt tolerances and then inappropriately receive goods)
- Transactions within the same process: A user may be able to inappropriately push a transaction through a process (e.g., create an inappropriate invoice and then process the payment for that invoice).
- Transactions and transactions approvals: A user may create an inappropriate transaction and approve that transaction (e.g., enter a purchase order and approve that purchase order). This is particularly important if automated workflows are not available or configured in the application.
- Transactions and audit log updates: A user may create an erroneous or fraudulent transaction and then conceal it through audit log updates. This is particularly important in applications where the act of turning the audit log off and on is not logged or captured.
- Transactions and reconciliations: A user may create an erroneous or fraudulent transaction and then conceal it during a reconciliation process.
If building a SoD ruleset from the ground up seems too daunting, many auditors, consulting firms and GRC applications offer standard or out-of-the-box SoD rulesets that an organization may use as a baseline. If leveraging one of these rulesets, it is critical to invest the time in reviewing and tailoring the rules and risk rankings to be specific to applicable processes and controls. This ensures the ruleset captures the true risk profile of the organization and provides more assurance to external audit that the ruleset adequately represents the organization’s risks. In this case, it is also important to remember to account for customizations that may be unique to the organization’s environment.
Developing technical mapping
Once the SoD rules are established, the final step is to associate each distinct task or business activity making up those rules to technical security objects within the ERP environment. In other words – what specifically do we need to look for within the realm of user access to determine whether a user violates any SoD rules? If we are trying to determine whether a user has access to maintain suppliers, should we look at the user’s access to certain roles, functions, privileges, t-codes, security objects, tables, etc.?
Typically, task-to-security element mapping is one-to-many. The approach for developing technical mapping is heavily dependent on the security model of the ERP application but the best practice recommendation is to associate the tasks to un-customizable security elements within the ERP environment. (Usually, these are the smallest or most granular security elements – but not always). If the tasks are mapped to security elements that can be modified, a stringent SoD management process must be followed during the change management process or the mapping can quickly become inaccurate or incomplete.
In the above example for Oracle Cloud, if a user has access to any one or more of the “Maintain Suppliers” privileges plus access to any one or more of the “Enter Payments” privileges, then he or she violates the “Maintain Suppliers & Enter Payments” SoD rule.
An SoD ruleset is in place – now what?
Ideally, organizations will establish their SoD ruleset as part of their overall ERP implementation or transformation effort. This allows for business processes (and associated user access) to be designed according to both business requirements and identified organizational risks. However, if a ruleset is being established for the first time for an existing ERP environment, the first step for many organizations would be to leverage the SoD ruleset to assess application security in its current state. This can be achieved through a manual security analysis or more likely by leveraging a GRC tool. Depending on the results of the initial assessment, an organization may choose to perform targeted remediations to eliminate identified risks, or in some cases, a complete security redesign to clean up the security environment. If an application is currently being implemented, the SoD ruleset should serve as a foundational element of the security design for the new application.
In the longer term, the SoD ruleset should be appropriately incorporated in the relevant application security processes. Similar to the initial assessment, organizations may choose to manually review user access assignments for SoD risks or implement a GRC application to automate preventative provisioning and/or SoD monitoring and reporting.
Conclusion
An SoD ruleset is required for assessing, monitoring or preventing Segregation of Duties risks within or across applications. Moreover, tailoring the SoD ruleset to an organization’s processes and controls helps ensure that identified risks are appropriately prioritized.
It’s critical to define a process and follow it, even if it seems simple. Not properly following the process can lead to a nefarious situation and unintended consequences. While there are many types of application security risks, understanding SoD risks helps provide a more complete picture of an organization’s application security environment.
To learn more about how Protiviti can help with application security, please visit our Technology Consulting site or contact us.
