A New Level of Openness
Because an SOA is built on open standards, it can expose critical data and application functionality to a vast new array of users. Any effective set of internal controls over financial reporting that relate to applications in an SOA must take this new level of openness into account. In the example shown in Figure 2, the internal controls must consider the risks inherent in exposing the data in 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 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 to authorized personnel. The open nature of SOA creates the added challenge of establishing and testing this kind of internal control.

Machine-to-Machine Security
The fact that Web Services, the fundamental building blocks of most SOAs, are based on machine-to-machine interactions creates another internal control hurdle for IT professionals involved in SOX compliance. While not a revolutionary shift, the machine-to-machine nature of SOA changes the nature of many existing internal controls that assume that the user of a given application is a person.

Many standard internal controls in place today involve the authorization and authentication of specific individuals and their right to access financial applications and modify the data in those applications. In the age of SOA, the focus has to change to accommodate the reality that many of the new "users" of financial applications are in fact other applications that can't be authenticated or authorized using a traditional identity store or access management system.

In the example shown in Figure 2, the shift to SOA has changed the nature of the customer's interactions with the company. Before, specific individuals could log onto the customer portal and transact business with the company. Internal controls related 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 company's control. In the new SOA, the "users" of the customer hub are actually the customers' ERP systems. There are people using those ERP systems, of course, but there has 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. If there is no such authentication or authorization going on, then the open access to financial systems by unknown persons working through an ERP system at another company would probably result in an internal control deficiency.

Segregation of Roles
Segregation of roles is a core technique of internal controls over financial reporting. Continuing with the machine-to-machine authorization issue described in the previous section, note that it may be impossible to establish clear role segregation in an SOA. Why? If the "user" of a Web Service-exposed financial application is actually another application, but the internal controls use role-based authorization for a human user, then the control will be deficient.

For example, in Figure 2 a sales rep shouldn't be able to access the general ledger and create a sale that would give him a bonus or access the warehouse system and move inventory around. The potential results of such role-based control lapses are error and fraud. If the sales rep can access those systems using a Web Service-consuming application on the SOA that doesn't authorize him directly, then there can be trouble. In the transition to SOA, those responsible for internal controls involving financial systems need to evaluate whether or not they are addressing the potential for deficient control over authorization and role segregation.

No Perimeter Emphasizes Application Controls
Overall, the move to SOA puts greater emphasis on application level controls than may have been required in a conventional IT architecture. While many of the IT general controls focus on the perimeter - firewalls, network access, passwords, baseline standards, and so on - the SOA renders much of perimeter security irrelevant. If access to critical financial applications is open to direct use by virtually any application in the world, then the perimeter is necessarily less significant as a component of an internal control practice.

Conclusion
Service Oriented Architecture requires some rethinking of internal controls over financial reporting. In terms of IT general controls, SOA changes some of the underlying assumptions that exist today, including the importance of the perimeter and the role of individual users versus machine users of critical applications. For IT systems that support non-technological internal controls, the transition to SOA should stimulate analysis regarding access rights, segregation of roles, and integrity of data.

The good news is that SOA represents an incremental shift in the IT aspects of internal controls and Sarbanes-Oxley compliance. SOA is not a categorical revolution in technology that shatters previously understood notions of internal controls.

However, one thing should be clear: A poorly governed SOA could easily result in deficient internal controls and problems with Sarbanes-Oxley compliance.