Oracle SOX Compliance Consulting

Oracle Fusion Cloud ERP is built on a role-based access control (RBAC) model that separates duty roles, job roles, and data roles. A duty role bundles a set of granular privileges tied to specific functions — creating a supplier, approving a payment, posting a journal entry. Job roles aggregate duty roles into something resembling an actual position, and data roles constrain what data (business unit, ledger, cost center) a job role can act on. For SOX purposes, this is the layer where segregation of duties is either enforced or quietly broken: a job role that inherits both the duty role for supplier creation and the duty role for payment approval is a textbook SoD conflict, and Oracle will apply it exactly as configured, conflict included, unless someone has explicitly analyzed and ruled it out.

E-Business Suite uses an older but structurally similar concept — responsibilities built from menus, functions, and request groups, assigned to users directly or through role-based access control (RBAC) introduced in later EBS releases. The complication in both Fusion and EBS is the same: access is additive. A user can inherit conflicting capability from two role assignments that were each individually reasonable, built by different teams for different reasons, with nobody explicitly aware the combination creates a conflict. This is precisely the gap Oracle Advanced Access Controls exists to close in Fusion Cloud, and why an EBS environment without a comparable SoD tool relies heavily on manual, periodic access reviews that are easy to let slip.

Advanced Access Controls (AAC) is Oracle's native SoD engine for Fusion Cloud ERP. It ships with a library of predefined access-risk and SoD rule sets mapped to Oracle's own role and privilege model, continuously analyzes role assignments against those rules, and flags conflicts before they reach production when integrated into the security-provisioning workflow — not just after the fact during a quarterly review. Because AAC understands Oracle's native role hierarchy directly, it avoids the translation gap that shows up when a third-party GRC tool has to reverse-engineer Oracle's privilege model from the outside.

Advanced Financial Controls (AFC) is the complementary continuous-monitoring layer — it runs automated tests against live transactional data for things like duplicate payments, unusual journal entries, or transactions that bypass an expected approval threshold, converting sample-based quarterly testing into something closer to full-population monitoring for the controls it covers. The realistic scope for AFC in most Oracle SOX programmes is a focused set of high-risk, high-volume controls rather than every control in the ICFR matrix; a control library that is configured once and never revalidated against changing business processes becomes a false-negative risk in its own right.

Oracle Fusion Cloud ERP is a SaaS platform with quarterly Oracle-managed updates, which shifts a meaningful share of infrastructure-level change management to Oracle itself — but does not eliminate the customer's ITGC obligation. Configuration changes the customer controls (approval hierarchies, tax rules, flexfield structures, security role definitions) still need a documented change-control process, and Oracle's audit trail — accessible through the Application Audit Trail feature and the Setup and Maintenance change history — needs to actually be enabled for the objects auditors will sample, since audit trail configuration in Fusion is opt-in at the object and attribute level rather than universal by default.

E-Business Suite change management runs through a more traditional patching and customization lifecycle — DBA-applied patches, custom PL/SQL or Forms personalizations, and configuration changes migrated between instances (development, test, production) using Oracle's standard multi-instance promotion practices. The control gap that shows up repeatedly in EBS 404 testing is not the absence of a promotion path but the absence of an enforced second approver before a change lands in production, and incomplete documentation connecting a specific patch or customization to a change ticket. Auditors specifically test whether the person who applied a production change is distinct from whoever approved it, and whether emergency changes were retroactively reviewed rather than left undocumented.