Technically, SOC is an acronym for “System and Organization Controls.” Or is it “Service Organization Controls?” Or does it mean SAS 70? Admittedly, I am having a little fun, but here’s the bottom line: Going forward, regardless of acronym, the SOC report will mean more things to more people and provide more options than ever before.
In April of this year, the American Institute of CPAs revised the meaning of SOC from “Service Organization Controls” to “System and Organization Controls.” This change is reflective of not only the diversity of new reporting options, but also the marketplace demand for emerging business assurance and risk management needs.
A very, very brief history
Some of you may recall the SAS 70 auditing standard, which was used — and, at times, misused — as the standard for reporting on controls at organizations that performed outsourced services (a.k.a., service organizations) for their customer organizations (a.k.a., user entities), when those services impacted the system of internal controls over financial reporting of those user entities.
SAS 70 was widely adopted, not only for the assurance needed for user entity financial statement audits, but it was also mistakenly used to address control needs outside of the narrower financial reporting scope. Organizations would include control objectives specific to privacy of data, disaster recovery, or aspects of quality control, etc., and thus, the seeds were sown for the misuse of the SAS 70. There was always a separate need for this added assurance on various non-financial topics, but the SAS 70 report became so well-known and ubiquitous that there was a natural tendency to leverage that reporting framework and widespread acceptance for other relevant assurance needs.
Fast-forward now to the 21st century and the creation of the service organization control (SOC) reporting brands, which have served in many respects to address the diverse concerns and information needs of interested parties. Organizations that were accustomed to being served from the SAS 70 dinner plate could now enjoy a three-course assurance “meal.”
With the new reporting brands, organizations’ needs for reports specific to the processing of transactions regarding financial reporting services could be separate from their reporting needs on other objectives — such as the privacy of personal information provided to service organizations, the logical and physical security of the service organization’s system, the data confidentiality practices of the service organization, the reliability and availability of their outsourced service provider’s services, and the processes in place at the service organization to ensure the accuracy, completeness and timeliness of transaction processing.
Behold the SOC 1, SOC 2 and SOC 3 reporting brands. For some, this then-new reporting framework was long overdue and signaled a return of focus to ICFR (Internal Control Over Financial Reporting) purity on the SAS 70 audit and report; however, for many it was also a welcome suite of reporting options that could allow organizations to demonstrate the effectiveness of their control environments beyond the constraints of the ICFR scope, and to do so for not only existing clients as of a specified date, but also prospective clients of their services (using SOC 2 and SOC 3).
Present day
The change to “System and Organization Controls” isn’t an illusory concept, but, in my opinion, it is a deliberate and purposeful action to further enhance the reporting capabilities of SOC reports and improve their reach to a much wider audience.
A key factor in this revised suite is that the SOC brand is no longer limited to just service organizations. More entities can now undergo a SOC examination for internal entity-level controls for assurance purposes. The current suite breaks down into half a dozen different reports.
The SOC for Cybersecurity is the latest addition to the SOC suite, and according to the AICPA’s Web site, it is designed to “enable all organizations — in all industries across the world — to take a dynamic, proactive and agile approach to cybersecurity risk management.”
This could grow into a widely utilized attestation in the cybersecurity realm. Other SOC reporting options are also still under development, including SOC for Vendor Supply Chains. Regarding these, I hope there is some exploration into other opportunities in the areas of quality control, such as disaster recovery, federal agency systems, and EU data privacy.
Perhaps now is a good time to indicate that the attestation standard that governs the SOC 2 examination has actually long since allowed for the inclusion of additional subject matter, including the content mentioned above. In fact, today an organization can scope a SOC 2 to address a multitude of additional criteria in addition to the Trust Services Criteria —provided those criteria are suitable and made available to the report users.
Many service organizations have contemplated the concept of including vendor questionnaires, for example, into the scope of their annual SOC 2 examinations to kill the proverbial two (or 20) birds with one stone (or audit), as it were. Others have considered inclusion of the ISO 27001 control set in their annual SOC 2 examination for the same reason. Still others are thinking about including the HIPAA Security Rule, NIST 800-53, GLBA — the list goes on.
This attraction provided through SOC 2 adaptability has been there for some time; however, it would not have seen the widespread adoption it has without the alliances the AICPA formed with the HITRUST (Health Information Trust) Alliance and the Cloud Security Alliance, respectively, each having provided their additional criteria for inclusion and related guidance. The good news for today, though, is that we aren’t simply discussing SOC 4s and 5s, but truly a paradigm shift in the way the SOC brand will be referred to going forward.
Whether an entity is seeking a mature and familiar reporting framework to tell the story of their operations and controls, or a report user has information needs beyond the financial reporting and trust services considerations, it appears the AICPA is in tune with those evolving needs and willing to cooperatively work with other control frameworks and security organizations to provide the reporting vehicles.
This is an exciting time for SOC reporting evolution, with so much progress already — but stay tuned for upcoming changes to the SOC 2 criteria that will determine the future impact on SOC reporting options.
