SOC 2 and SOC 3 Reports use both absolute reliability standards and standards relative to management commitments.
Doing so runs the risk of making SOC 3 reports misleading for the general public. And without close attention, they could end up a tick-box exercise before they’re established as a useful assurance tool for users.
In June 2011 the AICPA and CICA established SOC 2 Reports and SOC 3 Reports (a general summary of SOC 2) as a way for outsourcing organizations to provide assurance to their users about system reliability. This met a growing specific need, as IT outsourcing continues to grow. The reports can apply to all types of IT outsourcing firms. They cover any or all of these set Trust Services Principles:
- Processing Integrity
- Privacy. More background
To get an unqualified audit opinion, Service Organizations have to meet specified criteria under the Principles they choose.
In Australia, takeup of SOC Reporting has been relatively slow. In the US, a large number of outsourced data centres have SOC reports on Security and Availability. Other providers such as cloud Infrastructure- or Software-as-a-Service add Processing Integrity and Confidentiality of business information. Very few take on the difficulty of meeting the Privacy Principle.
New Version, Easy Gaming
In December 2013 the AICPA issued a new set of Trust Services Principles and Criteria, which are simpler and easier to use than the previous version, and a definite improvement.
It has clarified that several of the criteria are relative to what the organization management declares through contracts, SLAs or policies, rather than an implicit absolute standard. To be fair, there are plenty of strong requirements in the new version. But as in every quality-related audit (like ISO), if you keep your security, availability, processing integrity and confidentiality standards (commitments) low, and meet them, everything is fine as far as the audit is concerned. You can have your unqualified opinion.
That’s fine if users are willing to read through a service organization’s SOC 2 report, check the controls, and work out what the absolute standards are like. And major corporates and risk-educated people should – they’re the intended audience for the SOC 2 report.
But an unqualified SOC 2 report can allow service organizations to display the SOC 3 seal and publish the less-detailed SOC 3 report. The SOC 3 Report is designed for general users who may not be risk-security-control aware. And who are unlikely to make informed distinctions between absolute and relative standards on IT security, availability, or processing integrity.
This especially applies to Cloud providers whose client base is mainly personal/private or Small-Medium Enterprise.
The result? The SOC 3 seal could indicate anything from rock-solid security and so on in a high-commitment provider, to ho-hum levels in one that sets their aim low. That isn’t really the assurance for the general user that the SOC process set out to deliver, especially with the SOC 3 seal.
Does it matter?
Any security or privacy professional will tell users that if they really care about security and privacy, don’t use outsourcing and don’t use the Cloud.
Further, the SOC Criteria do contain strong standards for logical and physical access controls that do help with assurance concerns.
But two problems mean this issue does matter. One is the possibility of SOC 3 reports misleading non-technical users where standards are relative to company commitments. The other is the possibility of the framework slowly declining into irrelevance if unqualified reports don’t tell users anything concrete and intuitive about performance against SOC Principles.
Because anyone who knows compliance and audit knows that standards relative to commitments allow you to aim low, build minimum process, and tick the boxes. That does no-one any good.