Important factors to consider when using Reporting Tools to produce audit evidence

“What can be asserted without evidence can be dismissed without evidence.” – Christopher Hitchens

It is no secret that good data provides invaluable information about your organization that helps establish baselines, benchmarks, and goals. It is generally wise for organizations to invest in reporting tools as it can cut down time and costs by half. But is the data accurate? Is the source reliable? What controls are in place to ensure its integrity? These are some questions that an auditor may ask. Introducing any type of new tools to your system will require careful considerations towards security risks and therefore may be subject to ITGC controls.

Below are some points you may want to consider taking a closer look at.

Where Does the Data Come from?

A data source is the location to which the data that is being used in your reports originates from. The first step is to determine and document what is the data source and how that process is controlled. The key to defining whether your system is in-scope for SOX is to determine if there is an impact to financial reporting.

Here are a few questions to ask of your data source:

• Is it sourced from an in-scope SOX system?
• Is the data from an out-of-scope system?
• Or is the source data from a combination?

Almost all reporting tools allow you to join and blend data from multiple sources into one output. It is therefore important to document the installation as it relates to source data for the specific install of the reporting tool in your organization.

Who Has Access to the Report Tool?

Just like access to your ERP system is subjected to various logical access controls, the same is applicable for your reporting tool.  Most reporting tools can connect and utilize the security from your existing system, however almost all tools come with additional security that can only be applied within the reporting tool itself.  The ability to design reports, publish reports to other users and even the rate of data being refreshed are all permissions that need to be reviewed and approved prior to being granted.

Perform a user access review for all users who have access to your reporting tool. The report should include:

• User Information
• Role
• License information
• Permissions
• Reports.

What Is the Password Policy?

Certain reporting tools inherit the password settings from the ERP system they are associated / connected to; others require you to manually set the password parameters.  For any password settings within your reporting tool, ensure that:

• A review is conducted against your organizations password policy to confirm if alignment to the policy is available within the reporting tool
• Align the password policy if the tool allows
• If you cannot align the password policy due to limitations of the reporting tool, determine if the reporting tool offers advanced features which will reduce risk and are accepted by your organization
• Document the password policy if different from the organization policy.

What Is the Change Management Process?

It is important to outline a change management process for creations and updates to reports. Work with the business and IT to design a process that verifies when changes to reports must occur.  The change management process should consider:

• Documentation of the request for creation / change (ticketing system)
• Review of requirements
• Designer of reports (should be different from requestor)
• Testing of reports (should be different from designer)
• Test process and associated documentation (test scripts)
• Additional documentation required if report is being used as audit evidence
• Approvals (should be different from requestor, designer, and tester).

You must ensure that creation / changes are done in a controlled manner, perhaps not for all reports but at minimum for key SOX reports.

Not all reports (or items within a report) are key for SOX, so it is important to begin by identifying the key SOX components of a report and understand if there is potential to limit the changes.  Not every report needs to follow a formalized change management procedure. By targeting those associated with key SOX components, it may reduce the overall burden of having every report subject to this process.

Consider creating a reporting repository to identify key SOX related components / reports including:

• Data source (system, table, columns)
• Scope of report
• SOX elements / items within the report
• Relation to control
• Relation to business requirement.

How Do you Plan to Back Up & Restoration Reports?

Back up / restoration planning as it relates to individual reports is another essential item for consideration.  Is there a plan in place if changes are made to reports and the original report is overwritten?

It’s advisable to create and implement a process for report design and / or changes, whereby the designer saves a back up of the original report prior to the changes, implements the change and then executes testing.  In the event the report does not meet requirements when deployed / published to production, a restoration process exists that will allow the original report to be restored for use.

Is There a Disaster Recovery Plan in Place?

Just like a disaster recovery plan for your ERP system, one should be in place for reports / reporting tools that contain key SOX reports.  In the event the report tool is compromised, you need to ensure that you have a disaster recovery plan in place, including elements such as:

• Back up / restoration of key SOX reports each quarter
• Report tech specs / documents saved that can be available for rebuilding reports manually or via another reporting tool method
• Testing is conducted for the disaster recovery process on a regular basis to ensure it is effective.

What Is the System Uptime & Its Availability?

When your reporting tool houses key SOX reports, it is necessary to determine the tool up-time to ensure it meets the availability requirements of both the business, for operational needs, and the auditors during critical testing periods.

Consider availability requirements for each user group such as:

• Month end
• Quarter / year end
• Deployment of new report / report changes mid-month / two weeks ahead of month-end
• Patches / upgrades occur once per quarter unless determined urgent (security breaches).

Having a plan in place with your IT department on when upgrades / patches / fixes are implemented is key to ensuring the reports are available to all stakeholders when required.

How Will You Keep Your Reporting Tool Up to Date?

With third-party reporting tools you will need to consider the possibility of updates and patches provided by the vendor for bug fixes and enhancements. It is important to have a plan for:

• Notification of updates
• Review to determine impact
• Deployment path
• Testing process
• Approval.

Business Benefit vs Auditability – Getting the Balance Right

Reporting tools offer a long list of benefits, so it’s crucial to give users the flexibility to use them, while instituting processes that will ensure the business remains compliant with associated SOX controls.

Consider the control objectives, principals and criteria covered by each key SOX report and determine if any complementary IT controls are needed to fully address associated risks.

As with any recommendations it is important to review and discuss the requirements with the business, IT support teams, and internal audit departments to design effective controls / control objectives and then test against those controls ahead of an external audit to ensure they are operating effectively.

If you would like more advice and guidance on creating audit-ready reporting, please contact us or find more information about audit reporting solutions for JD Edwards, Oracle E-Business Suite or Oracle ERP Cloud here.