A Step-by-Step SoD Implementation Guide (2024)

Segregation of duties (SoD) is a central issue for security and governance. It helps to minimize risk such as fraud and misappropriation of assets; in fact, SoD is central to achieving compliance with laws and regulations and assuring shareholders (and other stakeholders) that proper governance is applied,1, 2 and it is included as an activity in COBIT.

Although SoD principles may be clear, implementation is not always as straightforward. An article about segregation of duties (SoD) states:

There is an easy test for SoD. First, ask if any one person can alter or destroy your financial data without being detected. Second, ask if any one person can steal or exfiltrate sensitive information. Third, ask if any one person has influence over controls design, implementation and reporting of the effectiveness of the controls. The answers to all these questions should be “no.” If the answer to any of them is “yes,” then you need to rethink the organization chart to align with proper SoD.3

This is somewhat true. In a complex enterprise the easy test might not be so easy to undertake, and the answers to these questions might be difficult to determine, although they would be interesting.

Applications of SoD are not limited to financial processes. For example, DevOps software development should adhere to SoD principles.4 In an interesting case study, blockchains were also used to enforce SoD within a DevOps software development model.5 With a simple step-by-step method, SoD can be analyzed across different processes and functions.

The Basics of SoD

In relation to the US Sarbanes-Oxley Act of 2002 (SOX) compliance, the following definition by ISACA applies:

Segregation of duties (SoD) is a key internal control and regulates which users have access to what areas of applications and IT infrastructure. The purpose of segregating responsibilities is to prevent occupational fraud in the form of asset misappropriation and intentional financial misstatement. The core concept that underlies SoD is that no employee or group of employees should be in a position to perpetrate and to conceal errors or fraud in the normal course of their duties. In general, duties to be segregated are:

• Custody of assets
• Authorization or approval of related transactions affecting those assets
• Recording or reporting of related transactions
• Verification6

Thus, the basic rule is that a single actor performs only a single duty. For example, if an employee is recording transactions, that employee should not authorize related transactions, nor should that employee perform any duty related to the custody of assets or verify that transactions have been carried out correctly. The term asset has many different nuances in finance, economics and IT. In this case, asset refers to any resource, document or deliverable that has an economic value or information content within a business process. Applying the definition to a real-life scenario leads to complex, large matrices that are error-prone and difficult to maintain. For this reason, simplified models have also been proposed and adopted.7, 8 The aim of such models is to provide the same information about possible conflicts among duties but with easier implementation.

There are two common examples that can be used to illustrate a step-by-step approach for analyzing incompatible duties that should be segregated using proper SoD implementation: a procurement process and a software development process.

Step 1: Identify the Actors

Actors can be identified using a process description, which can be a simple table or a process flow diagram drawn in a standard format such as Business Process Model and Notation (BPMN), possibly with the support of enterprise architecture tools. Actors play specific roles within the process, and they can be either individuals or organizational functions. In this example, they are:

• Requestor
• Board of directors (BoD)
• Purchasing department
• Chief executive officer (CEO)
• Accounts payable department

Step 2: Identify Subprocesses and Activities

To complete this step, the SoD analyst should draft a high-level process description. This can be done by creating a table of all the activities performed and the processes or subprocesses to which they belong. A more detailed description or notes can be useful as well. Ideally, the level of detail in this table should be tailored to meet the needs of step 3, which classifies all activities with an SoD perspective.

Step 3: Classify Activities as Duties

In this step, duties are linked to activities. The duties and their codes include:

• Authorization (AUT)—This includes any activity leading to authorization or approval of transactions affecting assets.
• Recording (REC)—Before an asset exists, it is often present in an organization’s records. The actor that creates the records performs a recording duty.
• Custody (CUS)—the custody duty implies responsibility for the integrity of the asset itself. Examples might include picking and sending (physical) goods, receiving payments from a customer and setting a price for a sales order.
• Verification (VER)—Examples include checking that transactions are authorized and records correspond to what has effectively been received (or sent). In some cases, verification duties are called reconciliation or control duties.

Step 3 requires the processes be described in greater detail. For example, the manage purchasing plans subprocess might be described by a diagram using BPMN notation, similar to the one in figure 1.

It is not necessary to describe all the activities and loops in the subprocess as long as no new duty is highlighted. For example, in figure 1, both “Draft, share and update purchasing plans” and “Submit plans to board” are REC duties performed by the same actor, on the same asset. There is no need to include both steps in the analysis of the potentially incompatible duties.

In fact, from a SoD point of view, both activities detect a REC-type activity performed by the requestor, on the same asset (i.e., the plan). If there is any incompatibility with any other activity (e.g., an authorization for the same plan), a single REC activity is enough for detecting it. Adding another one does not provide any additional information on incompatible duties.

This observation can lead to a significant reduction in the size of the tables.

Similar BPMN diagrams can be drafted for the remaining subprocesses: Request purchase, select vendor and manage purchase order.

With the addition of duties, a table listing all the activities would look like figure 2.

Not every activity of the process needs to be included to evaluate SoD. If two or more activities are performed by the same actor on the same assets with the same duties, those steps can be collapsed into a single evaluation (in a single row of the matrix in step 4).

Step 4: Assess Incompatible Duties

Incompatible duties are duties that should not be performed by the same actor on the same asset. For example, with inadequate SoD, the purchasing department and the CEO might be assigned conflicting duties, such as being responsible for both generating a request (REC) and authorizing it (AUT).

To assess incompatible duties, it is useful to set up a matrix highlighting possible conflicts (figure 3). Activities should be listed in the rows and columns of a spreadsheet (along with the related classifications), thus creating an n x n matrix, where n is the number of activities. Then, using a simple formula, every cell is checked to determine whether the duties are compatible.

View Large Graphic

The cells with an X indicate where the duty linked with the activity listed in the row is different from the duty linked with the activity listed in the column, revealing incompatibilities. Reading the matrix row by row (because it is symmetrical, it can be read either row by row or column by column), the following incompatibilities are present:

• Requestor—Incompatible with the BoD, the CEO and the purchasing department. Although the incompatibility with the board and the CEO is straightforward, the incompatibility with the purchasing department is more complex because it also has authorization duties. However, this incompatibility can be mitigated.
• CEO—Incompatible with the requestor and the purchasing department, but not with the BoD. The CEO has an AUT duty (as does the BoD), while the requestors and purchasing department have an REC duty. The CEO could in theory request a purchase and authorize it with no further control, leading to the potential risk of embezzlement. The CEO should be able to request a purchase to be made, but a separate process should be in place to manage the request.
• BoD—Incompatible with the requestor and the purchasing department, but not with the CEO. The BoD has the same duties that the CEO has.
• Accounts payable—Incompatible with the BoD, the CEO and the purchasing department.
• Purchasing department—Incompatible with all other actors and with itself. The main incompatibility with the other actors arises from the CUS duty, but most interesting is the fact that the purchasing department has a possible conflict with itself, as it has both authorization (AUT) and recording (REC) duties. However, duties are not incompatible if they are applied to different assets.9

In the AUT activity, the department checks the PRF submitted by the requestor; in the REC and CUS duties, they send the PO to the supplier. In the first case, there are two different assets (PRFs and POs), so SoD is maintained. In the second case, the purchasing department is solely responsible for sending orders to suppliers. This creates a potential risk, and mitigation steps should be implemented. For example, the requestor could review and sign off on the PO before it is sent to the supplier (thus exercising an AUT duty). Alternatively, an independent audit could be run on POs, providing independent verification (a VER duty). Furthermore, a separate process should be set up to manage situations in which the requestor is the purchasing department itself.

Step 5: Plan and Implement Remediation Actions

The purchasing department is the most critical unit in the whole process. This is no surprise, as the process itself is about procurement, and the purchasing department plays a crucial role.

There are cases when, in the table, an actor has assigned two duties (e.g., an AUT and an REC duty) that, according to the rules, should be incompatible. However, the incompatibility may not pose any risk because different duties are performed by the same organizational unit, but on different assets. No action is needed in these cases.

However, there is a potential risk that should be addressed and managed if the purchasing department can perform different duties without any other actor overseeing or authorizing them.

Dedicated process flows or procedures are needed to manage specific cases (e.g., a purchase request made by the purchasing department or the CEO).

A Software Development Example

Another interesting example is software development (from coding to deployment in a production environment). Some regulations impose SoD requirements on software development and operation (e.g., application maintenance) teams.10 These requirements can be analyzed with the tools provided by SoD models.

According to the proposed step-by-step guidance, a simplified model of software development activities following a classic waterfall approach can be used, as shown in the matrix in figure 4.

View Large Graphic

Again, incompatibilities are apparent:

• Requestor—Incompatible with the duties of the change advisory board (CAB) because the requestor would authorize their request if acting on behalf of the CAB. More interestingly, the requestor has an AUT duty in many steps of the process because they are required to authorize all the specifications produced by the technical teams based on the requestor’s requirements. This is an example of duties that should be incompatible but are allowable because they involve different assets. The decision that such duties do not conflict can be determined by examining the risk scenarios that could arise from overlapping duties. In this case, the requestor checks whether the documents produced by the technical teams are aligned with the original requirements. In a sense, the authorization given by the requestor is not the sole determining factor; it is just one step in implementing the authorization given by the CAB (which is, in fact, the only real authorization in this process).
• Developers—Incompatible with the CAB, the requestor and IT operations. Regulators are right when they require SoD between developers and IT operations. The latter function is performing a CUS duty on the production environment. Security, malpractice and fraud risk can be mitigated by keeping the development and IT operations teams separate.
• CAB—Incompatible with any other duty
• Project and portfolio managers/IT project managers—These actors have the same REC duty as developers and are similar to them. In most enterprises, they are part of the same organizational function.

Conclusion

These examples of a step-by-step implementation of SoD controls within a procurement process and a software development process can help process owners and governance teams identify which actions must be taken to plan and implement proper SoD to minimize risk such as fraud or embezzlement and ensure compliance. Subsequent steps involve matching activities, actors and permissions on applications (role mining) to enforce SoD directly with systems, applications and data. In this case, enterprises can leverage identity governance systems.11

Endnotes

1 Singleton, T.; “What Every IT Auditor Should Know About Proper Segregation of Incompatible IT Activities,” ISACA^® Journal, 1 November 2012, https://www.isaca.org/archives
2 American Institute of Certified Public Accountants (AICPA), “Segregation of Duties,” https://us.aicpa.org/interestareas/informationtechnology/resources/value-strategy-through-segregation-of-duties
3 Behr, A.; “Separation of Duties and IT Security,” CSO Online, 3 August 2017, https://www.csoonline.com/article/2123120/separation-of-duties-and-it-security.html
4 Aiello, B.; “DevOps and Segregation of Duties,” Agile ALM DevOps, 1 November 2016, https://agilealmdevops.com/2016/11/01/devops-segregation-duties/
5 Ernst & Young, Blockchain in DevOps, 2017, https://assets.ey.com/content/dam/ey-sites/ey-com/en_ca/topics/blockchain/ey-blockchain-in-devops.pdf?download
6 ISACA^®, IT Control Objectives for Sarbanes-Oxley, 4th Edition, USA, 2021
7 Kobelsky, W. K.; “A Conceptual Model for Segregation of Duties: Integrating Theory and Practice for Manual and IT-Supported Processes,” International Journal of Accounting Information Systems, vol. 15, iss. 4, 2014, p. 304–322
8 Ferroni, S.; "Implementing Segregation of Duties: A Practical Experience Based on Best Practices," ISACA® Journal, vol. 3, 2016, https://www.isaca.org/archives
9 Ibid.
10 Bank of Italy, Circular no. 285 of 17 December 2013, Supervisory Provisions for Banks, Update no. 38, 22 February 2022, https://www.bancaditalia.it/compiti/vigilanza/normativa/archivio-norme/circolari/c285/index.html
11 CoreSecurity, “Why Identity Governance Is Essential for Segregation of Duties (SoD),” https://www.coresecurity.com/blog/why-identity-governance-is-essential-for-segregation-of-duties

STEFANO FERRONI | CISM, ISO 27001 LA, ITIL EXPERT

Is a senior consultant and trainer in the information and communications technology services and solutions business unit at Beta 80 Group. He concentrates on the telecommunications and finance industries, and his areas of expertise include business continuity, IT governance and compliance, information security and service management. He has contributed to and guided many ISACA^® white papers. He can be reached at stefano.ferroni@beta80group.it.