Oracle ERP control evidence gaps are widening under audit scrutiny

At a glance

What this is: This is a SafePaaS analysis of Oracle ERP audit evidence gaps, arguing that control design alone is no longer enough when auditors want independent proof of access and SoD operation.

Why it matters: It matters because IAM, IGA, and SOX teams must now show that ERP controls can be evidenced across systems, timelines, and reviewers, not only inside the application under test.

Context

Oracle ERP evidence is becoming a governance problem, not just a control-design problem. As finance systems absorb more business activity, auditors increasingly want proof that access, segregation-of-duties, and review controls operated throughout the year, not just at the moment a report was pulled.

In this context, the issue is whether Oracle can be treated as its own evidence source. The article argues that runtime-native reporting may be operationally useful, but independent evidence is what makes the control story durable under ITGC, SOX, and regulator scrutiny.

Key questions

Q: What breaks when Oracle ERP evidence comes only from the system under test?

A: The evidence story becomes easier to challenge because the same platform that executes the transaction is also certifying the control. That creates independence concerns for Internal Audit and SOX, especially when access, SoD, or mitigating controls need to be proven over time rather than at a single review point.

Q: Why do Oracle EBS configuration changes create audit and SoD risk?

A: Because access in Oracle EBS is often inherited through Menus, Functions, Request Groups, profile options, and organizational scope. A small edit can broaden effective access for many users without a new Responsibility assignment, which means SoD conflicts and control impacts can appear even when the ticket looks routine.

Q: What are the signs that Oracle ERP evidence is too manual to scale?

A: Repeated spreadsheet reconciliations, heavy dependence on a few subject-matter experts, and long explanations about where evidence came from usually indicate an assurance process that will not scale. Those symptoms also signal that the organisation is carrying too much hidden effort into every audit cycle.

Q: How should teams prove segregation of duties across Oracle and connected apps?

A: They should correlate access, approvals, and transaction outcomes across the full process, not just within Oracle. If a purchase, journal, or vendor workflow crosses multiple systems, the SoD test has to follow that path end to end or the control conclusion will be incomplete.

Technical breakdown

Why Oracle-native evidence is not the same as independent evidence

Oracle-native reports show what the system recorded, but that is not always the same as evidence that satisfies audit testing. In SOX and ITGC reviews, the harder question is whether the artifact can be trusted without the audited system effectively testifying about itself. That matters most when access changes, SoD exceptions, and mitigating controls need to be demonstrated over time. The architecture problem is not visibility alone. It is whether the evidence trail is independent enough to survive challenge from Internal Audit, external auditors, and regulators.

Practical implication: Separate operational control execution from the evidence store so audit testing does not rely only on the runtime under review.

How cross-system access and SoD evidence gets diluted

Oracle is rarely the only system in the process chain. When approvals, vendor setup, payments, journal posting, or integrations span Oracle and adjacent tools, the control question becomes cross-system by definition. Evidence collected in silos can make each application look fine while hiding toxic combinations across the end-to-end process. That is why unified governance layers matter: they reconcile access, approvals, and transactions across applications without forcing every team to rebuild its workflow. The technical issue is correlation, not just collection.

Practical implication: Correlate identity, approval, and transaction data across connected systems before concluding that SoD is effective.

Why continuous monitoring beats audit-calendar evidence collection

Calendar-driven review cycles create blind spots whenever roles change mid-year, new entities appear, or service accounts are added outside the normal testing window. The article points to the growing role of non-human identities in Oracle environments, which makes point-in-time review even less representative of real operating conditions. Continuous monitoring changes the evidence model from episodic snapshots to ongoing policy evaluation. That does not eliminate testing, but it does reduce the gap between control operation and control proof.

Practical implication: Use continuous monitoring for access and SoD exceptions so evidence reflects the full operating period, not just audit checkpoints.

NHI Mgmt Group analysis

Oracle ERP evidence independence is now a governance requirement, not a reporting preference. When the system under test is also the primary source of proof, the control story becomes fragile under scrutiny. That assumption was tolerable when evidence demands were lighter, but it breaks when auditors need defensible, externalised proof across the full year. The practical conclusion is that evidence architecture now sits alongside access architecture as a core control design choice.

Calendar-bound review models no longer match Oracle operating reality. Oracle environments change continuously through role updates, reorganisations, new integrations, and service-account additions. A control programme that waits for the audit calendar to gather proof will always lag the business. The implication is that evidence collection has to move closer to continuous assurance if teams want to stay ahead of review friction.

Independent evidence turns SoD from a design assertion into an audit-ready control story. The issue is not whether Oracle-native SoD can be configured correctly. The issue is whether the organisation can demonstrate, without prolonged explanation, that the right access existed at the right time and did not produce toxic transactions. That distinction is what separates operational confidence from defensible governance.

Cross-system governance is now part of Oracle ERP assurance. Once critical processes span Oracle and adjacent platforms, isolated control reports stop being sufficient. The real challenge is proving transaction integrity end to end, which means identity, approvals, and posting activity must be interpreted as one control surface. Practitioners should treat Oracle evidence as one input to a broader assurance model, not the entire model.

Long-lived evidence debt is the hidden cost of spreadsheet heroics. Manual reconciliation can make an audit pass, but it also creates dependency on a small number of people and opaque workarounds. That pattern does not scale as Oracle footprints grow or as regulators expect stronger independence. The conclusion is straightforward: control maturity is increasingly measured by how repeatable the evidence path is, not how heroic the last audit was.

What this signals

Independent evidence now matters more than elegant control design. Oracle teams can have strong native roles, access monitoring, and SoD rules, yet still fail to satisfy audit expectations if the proof lives only inside the application. The programme lesson is to treat evidence architecture as part of control architecture, not as a reporting afterthought.

Control proof has to follow the business process, not the system boundary. As Oracle footprints extend into payments, procurement, journal activity, and connected applications, the assurance model has to follow the transaction path. Teams that keep evidence at the app level will keep running into the same question: what happened across the workflow, not just inside Oracle?

Year-round assurance is becoming the new baseline for Oracle governance. Point-in-time testing may still be necessary, but it is no longer sufficient on its own when roles, integrations, and non-human accounts change continuously. Practitioners should expect more pressure to evidence continuous operation, not just clean audit snapshots.

For practitioners

• Establish an independent evidence store Keep Oracle control proof outside the runtime so auditors can validate access and SoD operation without relying on the system under test as the only evidence source.
• Correlate cross-system control activity Join Oracle, approvals, and adjacent application data so toxic access combinations can be evaluated across the full business process rather than app by app.
• Shift from audit-calendar reviews to continuous assurance Track access changes, integrations, and service-account additions as they happen so evidence reflects the operating period instead of a point-in-time sample.
• Document SoD and mitigating controls in a shared timeline Build one year-round narrative for access, exceptions, and remediation so Internal Audit, SOX, and ERP teams work from the same control record.

Key takeaways

• Oracle ERP control design is no longer enough on its own when auditors want independent evidence of operation across the year.
• The real pressure point is not only access or SoD configuration, but whether evidence can be trusted outside the system being tested.
• Practitioners should move toward independent, cross-system, and year-round assurance if they want their control story to hold under scrutiny.

Key terms

• Independent Evidence: Independent evidence is information that confirms a claim without relying only on the vendor’s self-attestation. It includes external scans, telemetry, shared control validations, and observable security signals that help reviewers close blind spots and challenge inconsistent questionnaire responses.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Continuous Assurance: A control model that checks identity and security conditions continuously instead of only during scheduled audits. It improves readiness in dynamic environments, but it requires clear thresholds, exception handling, and human accountability so automation does not outpace governance.
• Evidence Store: An evidence store is a separate repository for control artefacts, review outputs, and transactional proof. In identity governance and ERP assurance, it matters because it gives auditors a durable record that is not dependent on the availability or interpretation of the production system itself.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.