Updated: Sep 20

Why is a cyber security standard issued by the AICPA and audited by accountants?

Some of our more inquisitive clients query why a security standard is issued and maintained by an accountancy body. What does the AICPA know about technology risk and security practices?

As an accounting graduate lacking inspiration to be an accountant - I was glad to realise that joining an accounting firm didn’t mean I would be a “bean counter”. My role was in the Risk & Controls Solutions team as it was known at the time, before it was Risk Assurance Solutions, Third Party Assurance, Performance Assurance, Trust & Transparency.... I’m not even sure what the latest name is - but it’s not accounting!

A major role of accounting firms is signing off on the accuracy of company financial statements. That became reliant on IT systems, which required IT audits to be performed. Companies increasingly outsourcing IT or other material processes led to third-party assurance standards to save the need for multiple audits by different customers auditors. That approach and standard was called SAS 70. It was designed to be a form of auditor to auditor communication that would maintain Chinese walls between the audit firms but address the requirements for signing off the accuracy of financial statements.

It may have been a natural evolution, the lack of any better standards out there, or that it was just a good fit for broader user requirements, that led to the SAS 70 reports being used by non-auditors as well. It helped Boards, exec management, investors, regulators, and customers to know the systems and operations were secure, reliable and appropriately managed. It's now more commonly known as "SOC" reporting, for Service Organisation Control.

During the earlier years of my career, there was a constant push and pull when we issued these reports. The standards and our approach was designed to communicate to other auditors, but we often knew that was not the real purpose or intention of our clients. The big taboo topic, was that some clients would use our reports in sales conversations. To demonstrate to prospective customers, their “gold standard” operations.

SAS 70 branched out into varying country-specific standards, some with more specific frameworks for each type of service provider. SSAE 16, ISAE/ASAE 3402, GS 007 and AAF 01/06. These became known as "SOC 1 reporting" in 2009, when "SOC 2 reporting" was introduced. More on this below.

Throughout the years, the strict nature of these standards and the high quality imposed by the issuing bodies and accountancies, has maintained a leading reputation and trust by users of these reports. Many other standards have been degraded by the flood opportunistic companies providing low cost (and perhaps lower quality), “certifications”. The barriers to becoming a chartered accountancy firm are much higher, which naturally prevents this flood of providers in the market.

So the reason the leading third party assurance standard for cyber security is issued by the AICPA - an accountancy body - is because it evolved from financial statement audits. The high quality audit approach has stood the test of time to provide the greatest value and peace of mind to end users of these reports.

This background also explains the difference between SOC 1 and SOC 2 reporting. SOC 1 remains focused on the financial reporting objectives from where these standards originated, while SOC 2 provided a new framework designed to meet broader end user requirements. Whether intended or not, SOC 2 is now a key “sales” report that demonstrates good security practices and simplifies the onboarding of enterprise customers. For anyone that’s worked at an enterprise business and knows the pain of trying to onboard any new service or product, you’ll understand why a four letter acronym that represents systems security and robust operations like “SOC 2” is incredibly helpful!!