Thinking Through Oracle ERP Cloud Change Management for Audit and Compliance

One of the primary benefits of moving to a cloud application is the likely reduction of infrastructure maintenance and costs on IT teams. With cloud vendors managing the back end, this enables companies to focus on enhancing the governance of their business processes, including change management. The goal of an organization’s change management structure is to ensure that methods and best practices are followed to mitigate the risk of introducing inappropriate changes or security vulnerabilities. Unfortunately, due to the lack of control within the back end of most systems, the ability to produce system changes via scripts from the database becomes obsolete — introducing challenges when capturing a complete and accurate change management population for compliance purposes.

Each year, external auditors are increasing the requirements and scrutiny for Sarbanes-Oxley (SOX) procedures, including the expectation that financially relevant changes are documented and approved to mitigate the risk of fraudulent or inappropriate changes. Oracle ERP Cloud is a primary example of a cloud application making strides to improve the audit trail functionality to help capture these requirements; however, there have been challenges with this functionality. So, what is the right approach for identifying an appropriate change population in Oracle ERP Cloud? Like with most things, “it depends,” and likely will require close collaboration with your external auditor.

Change populations can be comprised of many things: configuration updates, patches, upgrades, security updates, report changes and more. It is critical to first understand what types of changes are in-scope for compliance requirements. Then, work to determine if these changes can be automatically logged by the system for future reference. In Oracle ERP Cloud, the primary change history feature is maintained through Manage Audit Policies. Let’s step through Oracle ERP Cloud’s Audit History and Audit Reports features, with an eye on both the benefits and drawbacks.

Configuring Audit Policies

• What are Audit Policies? Audit Policies is a feature that enables users to select specific available business objects for change monitoring. Details of who, what and when a change was made for the object is then logged by Oracle, with the ability to be displayed in an Audit Report thereafter.
• What can be tracked through Audit Policies? Oracle pre-defines the areas and objects available for monitoring. The table below provides a high-level description of what is available. Prioritization of higher risk objects should be considered as teams work through identifying monitoring scope.

• How to enable Audit Policies?
  • Go to Navigator > Setup and Maintenance (User must have a role that includes the “FND_MANAGE_AUDIT_POLICIES_PRIV” privilege)
  • Search for the task name Manage Audit Policies – user will be presented with the below screen
  • By default, auditing is disabled for all applications. Under “Oracle Fusion Applications,” users will be required to both set up “Configure Business Object Attributes” for auditing, as well as update the “Audit Level” from None to Auditing (red box). If only the “Audit Level” is enabled with no objects selected, auditing remains inactive for the “Oracle Fusion Application” area.
    • Oracle Fusion Applications is the only policy area that allows for end-user object selection. All other areas can only be set to either low, medium and high. Based on the level selected, Oracle will monitor a pre-defined grouping of activities (blue box).

• • • Select the “Configure Business Objects Attribute” button (red box, above). This screen will allow users the ability to toggle between various products to determine which objects are available for tracking. Select the desired product and enable an object under the “Audit” field via the check mark.

• • • Upon selection of an object, details of the specific attributes to be added-on will be displayed in a right-hand pane. After confirming which objects are to be audited, select “Save and Close.”
    • Verify the “Audit Level” is set to Auditing in the Oracle Fusion Applications policy area and Save. You are now enabled for audit trail functionality. Repeat these steps, should any monitoring changes be required.

• How can the audit history be viewed? Go to Navigator > Tools > Audit Reports (users will require roles with the privilege FND_VIEW_AUDIT_HISTORY_PRIV to view Audit Reports.)
• How does this feature help with change management testing? The ability to produce veritable change history reports will allow for system generated evidence to be leveraged as part of an organization’s change population. Audit teams will be able to select a known system change to verify if appropriate documentation, testing and approval exists for change management. Organizations can also choose to supplement Audit Reports with point-in-time snapshots (i.e., version number) of key configurations for baseline comparison purposes.
• What are the drawbacks of using Audit Policies and Audit Reports?
  • Not all desirable business objects are available for tracking, limiting what can be included in the Audit Reports. This may inhibit organizations from capturing key in-scope changes.
  • Audit reports can contain large volumes of data, making it difficult to inspect and interpret collected information for further analysis.

Oracle’s ERP Cloud Audit Policies are by no means a silver bullet. However, it offers clients the ability to gain change history straight from the system – a key aspect for any change management evaluation.  Consider working with your internal and external audit teams to determine if Audit Policies can help with enabling change management evidence.

To learn more about Protiviti’s Oracle solutions, contact us.