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
Because so much of business today is done using computers and software, IT plays a prominent role in internal controls. Underscoring that point, Gartner reports that 97% of the material weaknesses in internal controls can be mitigated through IT. In practice, there are two essential ways that IT finds a 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
There are numerous IT General Controls. To stay focused, we'll only look at one example - "Control Objective: Controls provide reasonable assurance that financial reporting systems and sub-systems are appropriately secured to prevent unauthorized use, disclosure, modification, damage, or loss of data."

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
Many internal controls over financial reporting are not technological in nature. For instance, subjective valuation of some balance sheet assets usually involves manual processes. However, many of them rely on IT for their effectiveness. Using the COSO framework, an internal control for the company depicted in Figure 1 might look like the pairing of control objective, risk, and control practice shown in Table 1.

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.

Problem Scenarios
If the control isn't effective, the company faces a risk that the control objective, "Accurately record invoices from all authorized shipments" won't be met. If this control is deficient to the point that it could cause a material misstatement of financial results - a "material weakness" in internal controls - then the company could be in real trouble. If a public company discloses a material weakness in internal controls under SOX and fails to remedy it, consequences can include SEC investigations, sanctions, and even delisting from exchanges.

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
If the company described in Figure 1 transitioned to a Service Oriented Architecture (SOA), its IT architecture would resemble the one shown in Figure 2. What's different? Well, where before the company relied on a proprietary interface to connect its systems with one another, they can now exchange data and operating instructions using the open standard of Web Services. The company has also taken advantage of the universal "machine to machine" interoperation capability of SOA and enabled its customers to have direct programmatic access to its ordering systems. Instead of a portal, the company now has a Customer Web Service hub to which customers can connect directly using their ERP systems.

SOA's Impact on Internal Controls
While SOA may be a boon to business executives owing to its inherently flexible nature, this new architectural paradigm can cause difficulties for the IT side of SOX-mandated internal controls. There are several major areas of concern outlined below.