Auditors Are Talking about Segregation of Duties Too Much!
in Blog Article by Jeff HareHaving been in the Security and Controls space for far too long, I have witnessed and am still witnessing a phenomenon that needs to be addressed. Auditors talk WAY too much about Segregation of Duties.
Hear me out…
In testing access controls, auditors spend way too much time assessing risks related to SoD and far too little time considering sensitive access risks. Most auditors only look at sensitive access risks in the context of administrative access such as those that can provision users and create or modify custom roles.
We routinely find that auditors fail to identify risks in key business processes that could have a financially significant impact (ICFR) such as:
- Supplier Master Maintenance
- Item Master Maintenance
- Price Lists
- Price changes on orders
- Orders without shipments
- Invoices without Orders
- Cost adjustments
- Customer Master Maintenance
- Journal entries not subject to workflow approvals
- Conversion abilities allowing data importation, while requiring workflow approval
- APIs and Web Services
- Etc…
What is Segregation of Duties, Anyways?
Before we provide more details, let us first look at a few common definitions. My simple definitions are:
| Types of Risks | Definition |
| Segregation of Duties | A user having two or more abilities that create a risk in aggregate |
| Sensitive Access Risks | A user having access to a security object that creates a risk in and of itself (without having to consider another security object) |
In researching standards-based organizations, I don’t see a common definition of Segregation of Duties. Here are a few examples:
- NIST: the principle that no user should be given enough privileges to misuse the system on their own
- IIA: Sadly, a search for Segregation of Duties on the Institute of Internal Auditors website yielded over 2,500 results and no clear definition. In the official glossary of the IIA, there was no definition. [i]
- ISACA: 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
- Verification[ii]
- 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:
Clearly, misunderstanding of SoD in the audit community.
Why Focusing on Segregation of Duties is Missing the Mark
Yet I digress… the intent of this article is to convince you to (mostly) STOP talking about Segregation of Duties (SoD). Instead let’s talk about risk. SoD is a form of risk that auditors DO need to consider. However, there is much more to risk than just SoD conflicts.
In fact, in modern ERP systems, I would say SoD conflicts should be the least of your concerns. Here is why…
Effective Workflow Design Negates the Need to Test for SoD.
Did you know workflow design processes cover most of the traditional SoD risks? In modern ERP systems such as ERP/HCM Cloud, Workday, NetSuite, and Salesforce, the design of workflow is easy to configure. The intent of the configuration of workflow, 99% of the time, is to segregate entry of a transaction from the approval of a transaction. Do you need to test workflow design – Yes of course. However, the validation of the design of workflow to confirm that the person entering the transaction cannot be the person approving the activity is not testing Segregation of Duties. Effective walkthrough of workflow design negates the need to test for SoD.
Taking a Closer Look: The SoD-Focused Route
The following are common SoD conflicts and how modern systems mitigate risks via workflow:
| SoD Conflict | Common workflow mitigations |
| Enter Suppliers vs Enter Purchase Orders | Workflows are often in place for both entry and maintenance of suppliers and entry and maintenance of purchase orders. If either were in place, this SoD conflict doesn’t need to be tested |
| Enter Journal Entries vs Post Journal Entries | The most common workflow in all ERP systems is the SoD between Entry and Posting of JE’s. Workflows are extremely common. Having said this, some systems allow some ‘sources’ of JE’s NOT be to subject to the JE approval workflow. Here is an article that covers this in more detail. |
| Enter Customers vs Enter Orders | Orders are frequently subject to approval workflows, whereas customer master data workflows are less common, except in dedicated CRM systems like Salesforce. |
| Enter Purchase Orders vs Enter Goods Receipt | Purchase Order workflows are very commonly implemented. |
From the table above, it is understandable how some SoD conflicts do not need to testing IF the workflow design is valid. (This typically means no one can approve their own transaction).
Hitting The True Bullseye: Sensitive Access Rules
Although there is a lot of dysfunctions in the audit community related to scoping and testing of Segregation of Duties, I would like to next discuss the importance of Sensitive Access rules and why the audit community is dramatically underestimating the importance of risks posed by these activities ‘in and of themselves’.
Why Is the SoD Conflict Really an SA Risk?
Let’s look at each of these risks above.
| SoD Conflict | Common workflow mitigations |
| Enter Suppliers vs Enter Purchase Orders | Workflows are often in place for both entry and maintenance of suppliers and entry and maintenance of purchase orders. If either were in place, this SoD conflict doesn’t need to be tested |
Analysis:
In the procurement to pay cycle, focus is often on the combination of risk – someone having the ability to enter and maintain suppliers AND the ability to enter or maintain purchase orders. Most organizations have workflows in place that govern Purchase Orders and Suppliers. Therefore, workflow can often mitigate this SoD conflict.
Taking a Closer Look: How the Fraud Risk Emerges
However, unauthorized changes to supplier master data in and of itself could allow for material / financially significant fraud. Here is a list of risks that often are not in the risk library and, therefore, controls are not normally implemented in an organization’s RACM:
- Unauthorized change to supplier bank information
- Unauthorized changes to a supplier’s name
- Unauthorized changes to a supplier’s bank account
- Unauthorized changes to a supplier’s contact information
The design of controls must include all four of these risks depending on whether supplier payments are via check or electronically.
All four of these risks are what we refer to as “Sensitive Access Risks”. Anyone making unauthorized changes to one of more of these data classifications could cause fraud as follows:
| Data | Fraud Risk |
| Supplier Bank Information | Re-directing electronic payment to a fraudulent bank account |
| Supplier Name | Meant to change the name on the check to make the cashing of the check easier |
| Supplier Address | Meant to re-direct the check, when mailed, to gain physical custody of the check so it can be cashed |
| Supplier Contact | A common fraud scheme to send an email or letter requesting a change in bank account information. Typically, organizations have a process in place to call the ‘Supplier Contact’ to confirm the legitimacy of the change request |
More Common SoD Conflicts This Situation Applies to
The following are common SoD Conflicts for the Quote to Cash cycle:
- Enter Customers vs Enter Orders
- Enter Customers vs Enter Price Lists
- Enter Orders vs Ship Orders
- Enter Orders vs Create AR invoice
Looking At SA Risks “In and Of Themselves”
One cannot properly assess controls without an understanding of these risks ‘in and of themselves’. Let us look at several other Sensitive Access risks that are not commonly considered in the design of controls because of the ‘overemphasis’ on SoD conflicts.
| Sensitive Access Risks: | Risks: |
| Enter Customers | Unauthorized increases to credit limits could lead to unwanted credit exposure. Flag to check credit could be unchecked leading to lack of credit checking on orders. Send statements / Send invoices / Send dunning flags could be unchecked. |
| Enter Orders | Orders can be entered that do not require a shipment; often referred to as miscellaneous orders. One can enter orders in which the workflow approval requirement is off. |
| Enter / Update Pricing on Orders | Unauthorized price changes for certain lines. Revenue recognition could be changes causing the wrong timing. |
| Enter / Update Price Lists | Unauthorized changes to price list could cause an overstatement or understatement of revenue |
| Create AR invoice | Unauthorized creation of a miscellaneous invoice (not generated from an order) could cause an overstatement or understatement of revenue |
Sensitive Access Risks First, SoD Conflicts Second!
When we look at application access controls for a client, we don’t look at SoD conflicts until we have looked at Sensitive Access risks first. We take a Sensitive Access approach first, then an SoD conflict approach second.
We have two courses that go into much more depth on this topic:
- “Auditing IT Dependent Risks in ERP Systems: A Foundation for Financial and IT Auditors”. This course takes you through common control design deficiencies and helps provide a foundation for financial and IT auditors for their work. The article also addresses how to build a system flow diagram to make sure you have a complete understanding of data flow and risks.
- “Why Access Controls Must Be Tested for All In-Scope Systems” This course helps you understand how to scope SoD conflicts and Sensitive Access risks. You will learn to test them for the ‘in scope’ entities. It also reiterates that testing for the independence of the control performer per this article, is part of that testing.
In conclusion, auditors spend way too much time focusing on SoD Conflicts and way too little time understanding and auditing Sensitive Access risks. Auditors must update their audit programs and ensure they address ALL risks in control design and access control testing, not just SoD conflicts.
