Tommie W. Singleton, Ph.D., CISA, CGEIT, CITP, CPA
The first part of the maze, and the source of confusion for some of those involved, is to be clear about the specific nature of Service Organization Control (SOC) reports. A SOC 1 report (SSAE No. 16 engagement) is the only report associated with internal controls over financial reporting (ICFR). It is, therefore, the only report that is applicable to the financial audit where a service organization (SO) is relevant (i.e., the service provided has the potential to materially affect the financial report of the user). A SOC 2 report is related to security-type audit objectives. A SOC 3 report is basically a “skinny” SOC 2 report, and the only SOC report that has unlimited distribution. Therefore, the ideal situation for a financial audit that includes a relevant SO is for the SO to provide a SOC 1 Type II report, which still may not be sufficient to gain an adequate level of assurance over the SO transaction processing and resulting data.
The second part of the maze is dealing with a relevant SO where no SOC 1 report exists, but some other report, such as a SOC 2 or an ISO report, does. When a report on controls at the SO exists that might provide useful information to the user auditor, then the user auditor should just step back and remember the process in general.
That process is to gain an understanding of the holistic flow of transactions at the user entity, including initiation, authorization, export function to SO, SO functions, import from SO, recording, journal entries, and financial reports. This understanding is critical to being able to parse any report and gain some assurance over the controls along this process chain.
The IT auditor should read the report and see if it identifies controls associated with the transaction flow as the IT auditor understands it. It is possible that a report other than a SOC 1 Type II may provide some level of assurance about ICFR at the SO. It is imperative that the IT auditor not have blinders about the nature of controls. They do not have to be automated; they could be manual and still be effective. Therefore, be sure to review any manual controls described in controls reports from the SO.
It is possible that the SO has no report on its controls. This situation leads the user entity’s IT auditor to the last part of the maze.
The last part of the maze is perhaps the most important. All SO controls should be designed to work as complementary to the user’s controls. In fact, the user auditor is required by Public Company Accounting Oversight Board (PCAOB) standards to map those complementary user controls to the assertions and SO controls. Thus the IT auditor would need to make sure he/she understands the user’s automated and manual controls that do, or could, serve as complementary controls. It is possible that a complementary control will mitigate the absence (such as no controls report) or weakness of controls (such as a report that can only provide limited assurance about SO controls) at the SO. For instance, if the controller of the user entity reviews a list of transactions (or some report) coming back from the SO in the import step and reconciles the information, that manual control may compensate for any missing controls at the SO. A similar situation is probably more likely to exist at the user entity.