New E-Book on Segregation of Duties: A Review
I congratulate Larry Carter for his new e-book, published by Compliance Week, on the topic “Segregation of Duties and Sensitive Access: Leveraging System-Enforced Controls”.
This is a timely discussion and explanation of a difficult topic and it includes useful information on the differences between manual and automated controls, preventive and detective controls, and more.
I believe it will be a useful read for internal auditors and application developers who are relatively new to the area, and a reminder to more experienced individuals of some of the key points to consider when designing automated controls to prevent individuals from having more access than they need – which can lead not only to fraud, but disruption, errors, and accidents.
For example, when I was leading the internal audit and SOX programs at Maxtor Corporation, the external auditor asked for access so he could examine some of the SAP configurations as part of his control testing. IT inadvertently provided him not only with the access he requested, read-access to the tables involved, but the ability to change the accounting period. Without realizing what he was doing, the auditor closed the accounting period while our financial team was still posting quarter-end journal entries!
Larry makes the excellent point that we need to consider not only inappropriate combinations of access privileges (i.e., Segregation of Duties, or “SOD”) but inappropriate access to a single capability. He calls this latter Sensitive Access, although the more common term is Restricted Access (“RA”).
As he points out, it is good business practice to limit everybody to the access they need to perform their job. Although it may be easier to establish the same access ‘profile’ (a set of access privileges) for several people, care has to be taken to ensure that nobody has more access than they need. If they do, that creates a risk that they may deliberately or inadvertently use that access and create a problem.
Some years ago, my internal auditors found that an individual in Procurement had the ability to create a vendor in the system and approve payment, as well as approve a purchase order. This creates a risk of fraud. The IT manager said there was a control: “We don’t tell people what access they have”. As you might imagine, we didn’t accept that argument.
This brings me to the critical topic of risk.
Larry makes the excellent and key point that you need to design your controls to address risk. You don’t design and operate controls for any other reason. With SOD, the primary reason for limiting inappropriate combinations of access is to prevent fraud. As he says, it is important to perform a fraud risk analysis and use that to identify the SOD controls you need.
When it comes to controls relating to sensitive or restricted access, the controls you need should also be determined by risk. For example, you will probably want to ensure that only a limited number of people have the ability to approve a journal entry, not only because of the risk of fraud but because you want an appropriate review and approval process to occur before they are posted. Similarly, you will want expenditures over a certain value to be approved by a more senior manager, and that is enforced through a restricted access control.
While Larry makes it clear that risk should drive the determination of what controls you need, I wish that had been how he designed his process for identifying necessary SOD and RA controls. Instead he identifies the total population of potential controls and only then considers (although it is less clear than it should be) whether the risk justifies having a control.
In fact, sometimes there are other controls (other than automated SOD or RA controls) that mitigate or even eliminate the risk. When the design of internal controls is based on a risk assessment that considers all the available controls, you are more likely to be able to design a more efficient combination of controls to address important risks. For example, let’s say you have a risk that individuals with inappropriate access to the spare parts inventory might use that to steal materials critical to manufacturing. At first blush, a control to ensure only authorized people have access might seem mandatory – and it would certainly be good practice. But, if the manager of the warehouse had an inventory taken of that area of the warehouse twice each day, the personnel working there could be relied upon to challenge anybody entering the space, and cameras detected any access, the value of an automated RA control is significantly diminished.
A related issue that Larry unfortunately doesn’t mention is the need to limit the access capabilities of the IT staff – not only to functions within applications, but to functions within IT business processes. For example, you need to limit who can change application code or bypass all your controls using “superuser” capabilities.
Another area that is often overlooked is the need to limit ‘read-only’ access to confidential information. Access privileges that allow unauthorized individuals to view customer or employee’s personal information, or confidential corporate information, may be required to comply with laws and regulations as well as to address the risk of theft or misuse of that information.
Overall, this is an e-book with a lot of useful information and it is an easy read.
Norman Marks is a semi-retired internal audit executive, author of World-Class Internal Audit and How Good is your GRC? (both are available on Amazon), and a frequent blogger on the topics of governance, risk management, internal audit, and the effective use of technology in running the business. He can be reached at firstname.lastname@example.org.