Book Image

Governance, Risk, and Compliance Handbook for Oracle Applications

Book Image

Governance, Risk, and Compliance Handbook for Oracle Applications

Overview of this book

It seems that every year since the Enron collapse there has been a fresh debacle that refuses to lower the spotlight from corporate Governance, Risk, and Compliance management.Before Sarbanes Oxely forced company managers to become risk conscious, if you asked a chief executive whether he thought he had adequate internal controls, the most likely answer would have been "What is an internal control?" This is clearly no longer the case. Every week some story breaks detailing a lack of good governance, a failure to plan for a foreseeable catastrophe or a failure to comply with an important law or regulation. These stories bring GRC themes into public view, and public scrutiny, and make management and directors keen to show they have put their best efforts forward to govern their companies well, manage risks to the enterprise, and to comply with all applicable laws.Perhaps only Oracle and SAP are in a position to really address all three aspects. The mission of GRC applications is to ensure that the managers and directors of Enterprises that run such applications have a strong defensible position. Written by industry experts with more than 30 years combined experience, this book covers the Governance, Risk Management and Compliance Management of a large modern enterprise and how the IT Infrastructure, in particular the Oracle IT Infrastructure, can assist in that governance. This book is not an implementation guide for GRC products rather it shows you how those products participate in the governance process, how they introduce or mitigate risk, and how they can be brought into compliance with best practice, as well as applicable laws and regulations.The book is divided into three major sections:Governance ñ where we discuss the strategic management of the enterprise, setting plans for managers, making disclosures to investors, and ensuring that the board knows that the enterprise is meeting its goals and staying within its policies.Risk Management ñ where we discuss audit disciplines. This is where we work out what can go wrong, document what we have to do to prevent it from going wrong and check that what we think prevents it going wrong - actually works! We move through the various sub-disciplines within the audit profession and show what tools are best suited from within the Oracle family to assist.Compliance Management ñ where we map the tools and facilities that we have discovered in the first two sections to frameworks and legislations. We give this from an industry and geography agnostic viewpoint, and then drill into some specific industries and countries.We neither stay in the narrow definition of GRC applications, nor limit ourselves to the Business Applications but take you to the most appropriate places in the full Oracle footprint. The book is written from the perspective of big GRC. It is not an implementation manual for the GRC products, although we hope you can get the best out of the GRC products after reading this book. We discuss many applications and technology products that are not in the GRC product family.
Table of Contents (22 chapters)
Governance, Risk, and Compliance Handbook for Oracle Applications
Credits
Foreword
About the Authors
Acknowledgement
About the Authors
Acknowledgement
About the Reviewers
www.PacktPub.com
Preface

The Audit and Compliance process


The following figure explains the Audit and Compliance process starting with the establishment of the program office and ending with certified financial statements:

While there are many processes that support and feed into the audit processes process, it is important to realize who the players are at the end of top level process. The process has to make evident to investors and regulators that risks are managed. Once an Audit and Compliance process is established, it goes through a risk assessment, audit planning, documentation phase, a testing phase, and a reporting phase, before the results are combined with the financial disclosures and signed by the management.

Risk Assessment phase

In the Risk Assessment phase, you will be cataloging the risks to the objectives of the business and asking questions such as "What can go wrong?". There are many methodologies, tools, and focuses for this. One methodology is to review the financial statements by subsidiary and highlight the lines that are material and then start to investigate the risks to which that line is exposed. For example, if a subsidiary constitutes less than five percent of the revenue of the enterprise, its revenue line may not be material. For one of the subsidiaries, the revenue line may be subject to risks of mistatement. For example, if revenue is claimed when customers have vouchers outstanding. Other methodologies include facilitated workshop methods and survey methods.

Audit Planning phase

In the Audit Planning phase, you will create a set of audit engagements, each with a defined scope and projected timeframe. Scope may be defined in terms of process, business units, and subsidiaries. The scope sets a boundary around the set of risks and controls that will be tested. An engagement itself is a project that has an engagement manager and a set of auditors assigned. The audit and its scope is generally authorized through an engagement letter addressed to the management and authorized from the Chief Audit Executive or audit committee. It may well include a records request for access to records that are within the scope of the audit.

Documentation phase

As you kick off the program, you will probably establish a program office. The controls will need to be cataloged, but they are generally organized by processes, and the processes and procedures themselves may be controls in and of themselves. The testing phase will be performed within the legal entities and business units of the enterprise, so the enterprise structure needs to be documented.

Testing phase

The testing phase will include a risk assessment to prompt the management to think about the risks to the mission of the enterprise. When the risks have been cataloged, the scope of the audit and the audit plan can be set. The scope may be set in terms of the processes, business units, or individual controls. The audit plan is broken down into individual engagement projects that have their own scope, where controls are tested and the results reported back to the Chief Audit Executive. Management may also be testing controls themselves and providing self assessments of the effectiveness of those controls.

Reporting phase

The reporting phase brings together management testing and the results of audit operations to be able to arm management and the directors with the information they need to certify the financial statements.

The Chief Audit Executive will need to keep the audit committee apprised of the findings in the audit engagements.

Relationships between entities, accounts, process, risk controls, and tests

We should always remember that the end goal is that we can prove to the investors that management and directors have worked with due diligence to govern the company, assess risks to the enterprise and its mission, and comply with applicable laws and regulations.

We should look at an example of a process, a risk, a control, and a test:

In this example, a subsidiary of Infission runs the U.S. Operations. Part of the results for the subsidiary is the revenue line. The receivables management process has a material impact on what is reported as revenue. There is an inherent risk that we may apply improper revenue recognition policies. For example, we may recognize revenue, even though we have written into the contract that the customer has right of return if the product does not perform as specified, within 90 days. The control may be that every contract with revenue over 100,000 dollars is reviewed by the Revenue Recognition Team. That control may be tested by generating a report of all contracts over 100,000 and testing for revenue recognition approval.