Despite having been in the Oracle applications space for over 20 years it is still a mystery to me what external auditors do or don’t do in their audit.  Recently on vacation I ran into an IT auditor from a big four firm who specializes in SAP.   I took the opportunity to help me better understand if there were differences in how they audited various ERP systems.  In most ERP systems there are security objects (T-Codes for SAP, privileges for ERP Cloud, Functions for E-Business Suite) that allow a user to bypass workflow approval processes.   If an organization is relying on workflow processes, yet someone can enter a transaction or maintain master data that bypasses the workflow, the IT application control (ITAC) design may not be deemed to be reliable.  For example, if the system has been configured to have all purchase orders (PO) go through a workflow approval process, yet an IT user or end user could upload an approved PO (that isn’t subject to the workflow approval process), then that user would have the ability to bypass the design of the ITAC – effectively undermining the ITAC design.  The same can be true for journal entries, requisitions, suppliers, supplier bank accounts, orders, invoices, etc.

Back to my big 4 auditor friend who supports external audits… I asked him if their IT audits always tests for the T codes that can override / bypass the workflow.  He said yes… which is what I expected him to say

What is interesting about this interaction is that is NOT normally the case in the Oracle ERP space.  Specifically, this is not the case for auditors in the ERP / HCM Cloud space.  We do know of one client in the ERP Cloud space that received a Material Weakness, but that was because I was the SME for the auditor and we DID test for the ability to bypass workflow processes.  They had several users with access to the Application Implementation Consultant role (AIC) (some were external consultants) on a permanent basis long after hyper care was over.  I could make the argument that anyone with the AIC role should be flagged as a control deficiency for SOX.  There are many other implementation roles with similar risks.  There are also many end users roles that have such privileges.

What we recommend:

After go-live no users should have the ability to override / bypass the workflow approval processes.  There are several categories of privileges that provide this ability including interface processes, conversion processes, web services, REST API privileges, and HCM Dataloader abilities.  Unfortunately, just about all Oracle seeded roles have one or more of these abilities.   In every assessment we have done related to these risks we have found many of these abilities in seeded and custom roles; leaving the organization vulnerable to at least a Significant Deficiency, if not a Material Weakness.  One example is the ability to override a supplier’s bank account through the Employee role (and 38 other seeded roles).  Another example is the ability to upload a journal entry via FBDI.

See these Customer Connect ideas for more on these topics:

Employee Role: Remove two critical privileges and one toxic Duty Role from the seeded Employee role. – https://cloudcustomerconnect.oracle.com/posts/16e90b9d56

FBDI Journal Entry Upload: Add new privileges to separate importing FBDI journals, uploading ADFDI journals, and creating accounting. https://cloudcustomerconnect.oracle.com/posts/a67fd9f77d

Eventually, external auditors will have these types of risks as part of their audit program.  Don’t get caught flat-footed and unaware of these risks.  It could be very costly for your organization at the time of your audit.

If you would like to have a call with us on this topic, please contact us here: https://www.erpra.net/contact-us/.