What is Segregation of Duties Matrix?
The term Segregation of Duties (SoD) refers to a control used to reduce fraudulent activities and errors in financial reporting. While SoD may seem like a simple concept, it can be complex to properly implement. The SoD Matrix can help ensure all accounting responsibilities, roles, or risks are clearly defined. Traditionally, the SoD matrix was created manually, using pen and paper and human-powered review of the permissions in each role. Today, there are advanced software solutions that automate the process.
SoD matrices can help keep track of a large number of different transactional duties. The figure below depicts a small piece of an SoD matrix, which shows four main purchasing roles. Each role is matched with a unique user group or role. The duty is listed twice—on the X axis and on the Y axis. This layout can help you easily find an overlap of duties that might create risks.
In modern organizations relying on enterprise resource planning (ERP) software, SoD matrices are generated automatically, based on user roles and tasks defined in the ERP. Each task must match a procedure in the transaction workflow, and it is then possible to group roles and tasks, ensuring that no one user has permission to perform more than one stage in the transaction workflow.
|Create requisition||Approve requisition||Create PO||Approve PO|
|Process||COSO||Procedure/Function||User Group (Role)||1||2||3||4|
|Purchasing||Record||Create requisition||1||Elevated Risk||Low Risk|
|Purchasing||Approve||Approve requisition||2||Elevated Risk|
|Purchasing||Record||Create PO||3||Low Risk||Elevated Risk|
|Purchasing||Approve||Approve PO||4||Elevated Risk|
The above matrix example is computer-generated, based on functions and user roles that are usually implemented in financial systems like SAP. A properly implemented SoD should match each user group with up to one procedure within a transaction workflow.
ISACA’s Two Approaches to the SoD Matrix
In an enterprise, process activities are usually represented by diagrams or flowcharts, with a level of detail that does not directly match tasks performed by employees. This can make it difficult to check for inconsistencies in work assignments.
ISACA, the global organization supporting professionals in the fields of governance, risk, and information security, recommends creating a more accurate visual description of enterprise processes. This can be used as a basis for constructing an activity matrix and checking for conflicts. When creating this high-detail process chart, there are two options:
- Group or delete activities and change the process description to hide details not relevant to the SoD—this can reduce the size of the matrix, but the downside is that it requires some prior work, and can introduce errors or oversimplifications.
- Keep all activities, but clearly label any SoD conflicts. This creates a huge matrix, but remains consistent with the actual implementation of existing processes.
ISACA tested both methods and found the first to be more effective, because it creates matrices that are easier to deal with. Because it reduces the number of activities, this approach allows you to more effectively focus on potential SoD conflicts when working with process owners. However, this approach does not eliminate “false positive” conflicts—the appearance of an SoD conflict in the matrix, whereas the conflict is purely formal and does not create a real risk.
Building a SoD Matrix for ERP Applications
Enterprise resource planning (ERP) software helps organizations manage core business processes, using a large number of specialized modules built for specific processes. SAP is a popular choice for ERP systems, as is Oracle. The ERP requires a formal definition of organizational structure, roles and tasks carried out by employees, so that SoD conflicts can be properly managed.
How to create an organizational structure
To create a structure, organizations need to define and organize the roles of all employees. For example, account manager, administrator, support engineer, and marketing manager are all business roles within the organizational structure.
Each business role should consist of specific functions, or entitlements, such as user deletion, vendor creation, and approval of payment orders. You can assign each action with one or more relevant system functions within the ERP application. In SAP, typically the functions relevant for SoD are defined as transactions, which can be services, web pages, screens, or other types of interfaces, depending on the application used to carry out the transaction.
For example, a table defining organizational structure can have four columns defining:
- An ID number of the assignment
- The business role
- A specific action associated with the business role, like “change customer”
- A transaction code associated with each action
How to create a SoD matrix
After setting up your organizational structure in the ERP system, you need to create an SoD matrix. To do this, you need to determine which business roles need to be combined into one user account. Create a spreadsheet with IDs of assignments in the X axis, and the same IDs along the Y axis. Then mark each cell in the table with “Low”, “Medium” or “High”, indicating the risk if the same employee can perform both assignments.
How to apply the matrix in an ERP system
You can implement the SoD matrix in the ERP by creating roles that group together relevant functions, which should be assigned to one employee to prevent conflicts. Then, correctly map real users to ERP roles. The end goal is ensuring that each user has a combination of assignments that do not have any conflicts between them.
Automating SoD Matrix Creation with Pathlock
Pathlock provides a robust, cross-application solution to managing SoD conflicts and violations. Finance, internal controls, audit, and application teams can rest assured that Pathlock is providing complete protection across their enterprise application landscape.
With Pathlock, customers can enjoy a complete solution to SoD management, that can monitor conflicts as well as violations to prevent risk before it happens:
- Integration to 140+ applications, with a “rosetta stone” that can map SoD conflicts and violations across systems
- Intelligent access-based SoD conflict reporting, showing users’ overlapping conflicts across all of their business systems
- Transactional control monitoring, to focus time and attention on SoD violations specifically, applying effort towards the largest concentrations of risk
- Automated, compliant provisioning into business applications, to monitor for SoD conflicts when adding or changing user access
- Streamlined, intelligent User Access Reviews that highlight unnecessary or unused privileges for removal or inspection
- Compliant workflows to drive risk mitigation and contain suspicious users before they inflict harm
Interested to find out more about how Pathlock is changing the future of SoD? Request a demo to explore the leading solution for enforcing compliance and reducing risk.