I was chatting with the soon-to-be-retired information systems director of a major Richmond insurance company several nights ago at the gym. Our friendship goes back many years to when we were both audit directors for the Virginia State Auditor of Public Accounts. My friend was commenting, among other things, on the confusing flood of regulatory changes that’s swept over his industry in recent years relating to Service Organization Controls (SOC) reports. Since SOC reports can be important tools for fraud examiners, I thought they might be an interesting topic for a post.
Briefly, SOC reports are a group of internal control assurance reports, performed by independent reviewers, of IT organizations providing a range of computer based operational services, usually to multiple client corporations. The core idea of a SOC report is to have one or a series of reviews conducted of the internal controls related to financial reporting of the service organization and to then make versions of these reports available to the independent auditors of all the service organization’s user clients; in this way the service organization doesn’t have to be separately and repeatedly audited by the auditors of each of its separate clients, thereby avoiding much duplication of effort and expense on all sides.
In 2009 the International Auditing and Assurance Standards Board (IAASB) issued a new International Standard on Assurance Engagements: ‘ISAE 3402 Assurance Reports on Controls in a Service Organization’. The AICPA followed shortly thereafter with a revision of its own Statement on Auditing Standards (SAS) No. 70, guidance around the performance of third party service organization reports, releasing Statement on Standards for Attestation Engagement (SSAE) 16, ‘Reporting on Controls in a Service Organization’. So how does the SOC process work?
My friend’s insurance company (let’s call it Richmond Mutual) outsources (along with a number of companion companies) its claims processing functions to Fiscal Agent, Ltd. Richmond Mutual is the user organization and Fiscal Agent, Ltd is the service organization. To ensure that all the claims are processed and adequate internal controls are in place and functioning at the service organization, Richmond Mutual could appoint an independent CPA or service auditor to examine and report on the service organization’s controls. In the case of Richmond Mutual, however, the service organization itself, Fiscal Agent, Ltd, obtains the SOC report by appointing an independent service auditor to perform the audit and provide it with a SOC 1 report. A SOC 1 report provides assurance on the business processes that support internal controls over financial reporting and is, consequently, of interest to fraud examiners as, for example, an element to consider in structuring the fraud risk assessment. This report can then be shared with user organizations like Richmond Mutual and with their auditors as deemed necessary. The AICPA also provides for two other SOC reports: SOC 2 and SOC 3. The SOC 2 and SOC 3 reports are used for reporting on controls other than the internal controls over financial reporting. One of the key differences between SOC 2 and SOC 3 reports is that a SOC 3 is a general use report to be provided to anyone while SOC 2 reports are only for those users specifically specified in the report; in other words, the distribution is limited.
SOC reports are valuable to their many users for a whole host of obvious reasons but Fraud Examiners and other assurance professionals need to keep in mind some common misconceptions about them (some shared, I found, by my IT friend). SOC reports are not assurances. IASSB and AICPA guidelines specify that SOC reports are to be of limited distribution, to be used by the service organization, user organization and user auditors only and thus should never be used for any other service organization purpose; never, for example, as marketing or advertising tools to assure potential clients of service organization quality.
SOC 1 reports are used only for reporting on service organization internal controls over financial reporting; in cases where a user or a service organization wants to assess such areas as data privacy or confidentiality, they need to arrange for the performance of a SOC 2 and/or SOC 3 report.
It’s also a common mistake to assume that the SOC report is sufficient verification of internal controls and that no controls on the user organization side need to be assessed by the auditors; the guidelines are clear that while verifying controls at the service organization, controls at the user organization should also be verified. Since service the organization provides considerable information as background for the service auditor’s review, service organizations are often under the mistaken impression that the accuracy of this background information will not be evaluated by the SOC reviewer. The guidelines specify that SOC auditors should carefully verify the quality and accuracy of the information provided by the service organization under the “information provided by the service organization” section of their audit program.
In summary, the purpose of SOC 1 reports is to provide assurance on the processes that support internal controls over financial reporting. Fraud examiners and other users should take the time to understand the varied purpose(s) of the three types of SOC reports so they can use them intelligently. These reports can be extremely useful to fraud examiners assessing the fraud enterprise risk prevention programs of user organizations to understand the controls that impact financial operations and related IT controls, especially in multiple-service provider scenarios.