01 May Managing SOX in the age of SOA
Service-Oriented Architecture (SOA), the core of such major product suites as Microsoft’s .NET, and BEA’s AquaLogic, is a potential boon to business productivity. However, the very openness of SOA can disrupt the internal controls over financial reporting required by Section 404 of Sarbanes Oxley Act (SOX), the 2002 federal law that was enacted in the wake of the Enron scandal.
A typical internal control over financial reporting for the company depicted in Figure 1 might look like the pairing of control objective, risk, and control practice shown in Table 1:
Though some internal controls are manual, most are rooted in IT. Gartner reports that 97 percent of material weaknesses in internal controls can be mitigated through IT. In our 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 upon to document and test these technological factors that support this internal control.
If the control is not effective, the company faces a risk that the control objective to “accurately record invoices from all authorized shipments” will not be met. Disclosure of deficient controls can result in potentially serious problems for public companies. For example, there is the risk of “channel stuffing,” where 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 might seem obvious, but it happens all the time and it can be quite hard to detect or prevent in a large, complex organization.
Internal controls in a transition to SOA
Figure 2 shows the company with an SOA. With SOA, they can now exchange data and operating instructions using the open standard of Web services. And they have taken advantage of the universal “machine-to- machine” interoperational capability of SOA and enabled customers to have direct, programmatic access to their ordering systems. However, while SOA may be great for business owing to its flexibility, it can fracture internal controls.
A new level of openness
Because SOAs are based on open standards, they have the potential to expose critical data and application functionality to a vast new array of users. Any internal controls that touch an SOA must consider this new level of openness. In the example shown in Figure 2, the internal controls must consider the risks inherent in exposing the data within the Warehouse system, General Ledger, and customer hub to unauthorized access. For example, a SOX auditor may want to test the controls over the integrity of inventory documents that support the inventory asset figures stated in the company’s balance sheet. To certify that the control is effective, the auditor will probably want to see documented evidence that access to the software that generates these inventory reports is restricted only to authorized personnel. The open nature of SOA creates an added challenge to establishing and testing this kind of internal control.
Web services, the fundamental building blocks of most SOAs, are based on machine-to-machine interactions. This creates another internal control hurdle for SOX compliance because most internal controls are based on the assumption that the user of a given application is a person, not a machine. Many of the standard internal controls in place today involve the authorization and authentication of specific individuals and their privileges to access financial applications and modify data contained within those applications.
Before, specific individuals could transact business over the Customer Portal. Internal controls relating to revenue recognition, as depicted in Table 1, were based on a process of authenticating and authorizing those individual users against an identity store that was under the control of the company. In the new SOA, the “users” of the customer hub are actually the ERP systems of its customers. There are people using those ERP systems, of course, but there needs to be a way for the company to authenticate and authorize those users before granting access to financial applications that have been exposed as Web services.
Segregation of roles
Segregation of roles is a core technique of internal controls over financial reporting. With the machine-to-machine authorization, it may be impossible to establish clear role segregation in an SOA. If the “user” of a Web service-based financial application is actually another application, but the internal controls use role-based authorization of a human user, then the control will be deficient.
For example, in Figure 2, a sales representative should not be able to access the General Ledger and create a sale that will result in a bonus for him or access the Warehouse system and move inventory around. The potential results of such role-based control lapses include error and fraud. If the sales representative can access those systems using a Web service consuming application on the SOA that does not authorize him directly, there can be trouble.
The move to SOA places a greater emphasis on application level controls than may have been required for compliance in a conventional IT architecture. For this reason, SOA requires some rethinking of internal controls over financial reporting. The good news is that SOA represents an incremental shift in the IT aspects of internal controls, not a categorical revolution. However, one thing should be clear: A poorly governed SOA could easily result in deficient internal controls and problems with Sarbanes Oxley compliance.