Managing SOX in the Age of SOA
Rethinking internal controls
By: Hugh Taylor
Jul. 28, 2006 09:45 AM
Service Oriented Architecture (SOA) is at the heart of many major IT initiatives and vendor offerings. However, while SOA has the potential to deliver business value through streamlined application integration, as well as integration with partners and suppliers, the open nature of SOA has the potential to cause problems with Sarbanes-Oxley compliance. This article will look at compliance issues inherent in developing an SOA. Using a practical example, we'll examine COSO Control Objectives, Risks, and their supporting IT systems from the perspective of Sarbanes-Oxley compliance.
This article is meant to help IT professionals, corporate managers, and auditors understand two complex and interconnected sets of activity in the world of corporate computing: Sarbanes-Oxley (SOX) and SOA. Both SOX and SOA are emerging as major areas of focus - some might say distraction - for a growing number of people involved in information technology, management, and audit.
Familiarity with the origins and intent of the law will help you understand why the Sarbanes-Oxley Act is relevant to IT professionals at a public company. Congress passed SOX in 2002 to calm the financial markets after Enron, Adelphia, and Worldcom. To assure investors that the financial statements that public companies make are accurate, SOX expanded the reporting and disclosure requirements concerning their internal financial controls, the process, practice, or structure designed to provide a reasonable assurance of the reliability of financial reports.
Internal controls can be either preventive or detective. A preventive control prevents fraud or errors that can result in a misstatement of financial results. A locked cash register is a simple example of a preventive control. A detective control enables an accounting staffer or auditor to check to see if a financial statement, or a supporting piece of data for a financial statement, is correct. Bank statement reconciliation is an example of a detective control.
SOX Sections 302 and 404 mandate that a public company documents and tests its internal controls. Management must then certify that the company's internal controls are effective. Then, an external auditor must also test and certify them.
The Public Company Accounting Oversight Board (PCAOB) has directed public companies to adhere to the internal control framework known as COSO in their SOX 404 compliance. The COSO framework pairs risks with control objectives and control practices to provide a level of confidence in a company's internal controls. If they are not effective, the company must disclose the deficiency, which can cause problems with the SEC and others.
If you're involved in IT and SOX then you should understand that you're working on showing that IT supports the COSO control objectives intended to mitigate the risk of financial misstatement. The purpose of your work is to help the company comply with SOX 404 and 302 by establishing, documenting, and testing the effectiveness of IT systems that support COSO Control Objectives.
IT's Place in Internal Controls
1) The IT General Controls as recommended by COSO
2) IT as a component of a non-technological internal control over financial reporting (often an application-level control)
Now we'll look at each of these categories using the example found in Figure 1, which depicts the IT architecture used by a public company. It shows the systems and software applications necessary to process inbound, revenue-producing transactions. While the corporate general ledger system is responsible for financial reporting, much of the supporting data regarding the transactions and inventory comes from two connected systems: A mainframe-based warehouse management application and a customer portal.
IT General Controls
With regard to this control objective, in the context of the architecture shown in Figure 1, the internal auditor would have to document and test the effectiveness of the internal controls that secured that architecture. Specifically, the internal controls would have to prevent unauthorized access to the General Ledger system, the Warehouse system, and the Customer Portal. The internal control would have to establish rigorous password protections, firewalls, hardening guidelines, and so on to assure the auditor that the systems in question were "appropriately secured." We'll return to this point later when we introduce the idea of Service Oriented Architecture.
IT Supporting Non-Technological Controls
Following the COSO framework virtually all internal controls are expressed in the format shown in Table 1. Of course, in reality the details might be different or more specific in any given situation, but the principles apply. Internal controls over financial reporting set out a control objective intended to mitigate a risk using a control practice.
Although the internal control described in Table 1 is procedural in nature, and may in fact be entirely manual, it's likely rooted in IT. In our Figure 1 example, there must be a reasonable level of certainty that the general ledger system is receiving accurate, timely data from the warehouse system and the customer portal. The IT department may be called on to document and test these technological factors that support this procedural control.
Let's look at an example of what could go wrong. Material weaknesses usually manifest themselves in fraud. Consider the practice known as "channel stuffing." Channel stuffing involves creating bogus revenue by colluding with customers. To earn a high bonus, an executive might ask a customer to place a large order on December 28. The revenue is booked for the year, but on January 2, the goods are returned. This device might seem obvious, but it happens all the time and it can be quite hard to detect or prevent in a large, complex organization.
If the company doesn't have effective internal controls over invoicing and inventory and the IT systems that support those controls then it's more vulnerable to the risk of channel stuffing than it would be if it had robust controls. The channel-stuffing example also highlights one of the key principles of internal controls over financial reporting, which is the segregation of roles. It's usually required that one individual, such as a salesperson, can't be able to book a sale, take possession of the merchandise, request shipping, and book the revenue into the general ledger. A fraud such as channel stuffing is much harder to prevent or detect if role segregation isn't practiced as one of the internal controls.
Consider then, what happens, when the architecture is opened up as an SOA.
Internal Controls in a Transition to SOA
SOA's Impact on Internal Controls
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week