SOX Compliance
The Sarbanes–Oxley Act (SOX) requires management to certify and maintain the effectiveness of internal controls over financial reporting. For companies...
Why Access Controls Must Be Tested for All In-Scope Systems
Sarbanes-Oxley and control design best practices require access controls be tested for every in-scope ERP system within an organization’s Risk and Control Matrix (RACM). While this may not be the standard for external auditors, let me attempt to make a case.
Access Controls should be tested for all in-scope systems for two main reasons. The first reason is auditors need to confirm that the control performer does not have access to the activities they oversee. One could argue this test of independence should be an entity level control (ELC) but is often not included in ELCs as this is assumed to be a part of the design within every control.
Second, auditors need to test Segregation of Duties conflicts and Sensitive Access risks that stem from defined IT General Controls and IT Application Controls for each in-scope system in the Risk and Controls Matrix (RACM).
Evaluating the Independence of the Control Performer
The person performing each control must have independence from the activities they are monitoring; this is control design 101. Yet organizations do not always have certainty as to whether this is the case or not, regardless of the adoption of Sarbanes-Oxley over a decade ago. To confirm this independence, the auditor should understand how the control is performed and should understand the data related to the control. This requires the auditor to confirm the control performer does not have access to maintain the data they are overseeing in the control design. Examples include:
| Control Summary | Activities to which the Control Performer should not be able to maintain |
| Bank reconciliation review |
|
| Authorization of credit memos |
|
| Lookback procedures over Change Management activities |
|
Occasionally, we see some ‘basic’ testing to try to verify independence. This is done by running a listing of users and assigned roles, then looking to make sure that the control performer does not have access to roles known to have such access. However, testing is not normally performed to identify if the abilities they oversee are contained in other roles. Complete testing of independence by the control performer requires all roles are tested for sensitive access risks. A full assessment is needed to confirm that no ‘other’ roles have access to these abilities.
For example, a control performer overseeing the issuance of credit memos may not have access to the Receivables Manager role where access to credit memos is expected. However, if a different role, the Receivables Clerk role, also has that access and that role is assigned to the control performer, the control performer’s independence is compromised, and the control must be considered ineffective.
In cases such as this, there may be a way to cure the deficiency through lookback procedures by requiring someone other than the control performer to review the full population of transactions. This individual would identify if the control performer has entered or maintained any transactions related to the control. This is what is referred to as lookback procedures.
If there are records that have been entered or maintained by the control performer, another person must re-perform the control against those records.
Consideration Given to ITGCs and ITACs, typical Segregation of Duties Conflicts and Sensitive Access Risks
Let us now turn to a second scenario which also demands for access controls be tested within every in- scope system.
Some IT Application Controls (ITACs) drive the need to test SoD conflicts and Sensitive Access risks. ITACs are also referred to as IT Dependent Controls or IT Dependent Manual Controls. ITACs have system dependencies on one of these three elements:
- A report is being used to execute a manual control. For example, a control performer needs a population of manual invoices and credit memos to confirm the authorization of the They would be executing the control to validate the risk that no person is manipulating the financial statements by impacting revenue recognition. In this case, the external auditor’s obligation is to validate that the control performer does not have the ability to enter or maintain an invoice or a credit memo.
- A configuration is used to design the ITAC. Auditors should test to make sure the process owner does not have access to any of the configurations which impact the ITAC design. Many modern ERP systems use a workflow-based process; it is rare to find a control performer having the ability to configure a workflow. However, there are other types of configurations a control performer may have access to such as Journal Sources or Descriptive Flexfields (DFFs). DFFs are used to store data in ERP Cloud and E-Business Suite. The control performer may have access to this configuration as Oracle has included this configuration in many seeded end user roles in ERP Another example, profile option values, can contribute to ITAC design; these are found in many end user roles as well. We have logged Enhancement Requests (Ideas) with Oracle to remove both DFFs and profile option values from all end user roles.
- Access controls – Segregation of duties conflicts and sensitive access risks are the final category of risks related to ITGCs and ITACs. Both ITGCs and ITACs could specify certain abilities be segregated or access to a particular transaction or master data element should be tested. There are common SoD conflicts tested in most organizations such as Enter and Maintain Suppliers being segregated from the ability to Enter and Maintain AP invoices. The ability to Enter and Maintain Suppliers is also a risk in and of itself. Supplier master data has two elements containing risk. The first is check payments relies on the name and address. The second, EFT / ACH payments rely on the bank account data contained in the vendor master. Unauthorized access to enter and maintain the supplier master is a significant fraud risk. This is what we refer to as a Sensitive Access Risk.
Where the control is defined, certain procedures should be segregated, and the auditor must test to confirm the proper segregation of duties is in place. Following are two examples:
| Example | Comments |
| Entry and approval of a journal | This could be segregated through role design or through workflow design. If there is no workflow in place to prevent this, then role design must be tested. If there is a workflow that has been designed to prevent someone from approving their own workflow, then the workflow design must be tested and testing access controls for this scenario would not be needed |
| Entry of a purchase order and the receipt of the good(s) or service(s) related to the purchase order | This could be segregated by role design and role design would need to be tested to verify that no single role has both of these and that no users have access to a combination of roles that allow them to have both abilities |
Summary and Conclusions
We often find that auditors do not consistently test access controls for the in-scope ERP systems identified in the organization’s Risk and Control Matrix. There are two main reasons auditors should test access controls in all in-scope systems:
- The control performer must maintain independence from the activities they are overseeing and the only way to confirm this is to confirm they do not have access to these activities.
- ITGCs and ITACs cause a need to test specific segregation of duties conflicts and sensitive access
Auditors currently not testing access controls for all in-scope ERP systems should consider expanding their testing scope to fully consider the risks and requirements outlined above.
