There’s a reason we almost always recommend SOC 2 as the solution to your InfoSec requirements...
Most of our clients are looking to solve their information security assurance goals with a single standard. That achieves lower costs, reduces the upfront work, and saves maintaining multiple frameworks and (often) separate audit processes.
The three main assurance solutions used are SOC 1, SOC 2 and ISO 27001. There are various preferences and perceptions about all three in the market. That often results in multiple being required across a broad customer base, particularly across different industries. ISO 27001 is a widely-used standard that leads the way for designing and implementing an information security management system. However, it has limited role in providing assurance over the operation and effectiveness of the information security. SOC provides that operating effectiveness assurance, which led to the rise of SOC 1 being used for information security and integrity of systems. SOC 2 provides the "best of both worlds" by setting a more comprehensive framework for the management of technology risks (compared to SOC 1), while retaining the benefits of operating effectiveness that customers require to verify your InfoSec practices.
The flexibility offered by SOC 2 makes it a broadly applicable solution to meet the many different end customer needs. As you may know it’s not just security, but offers the optional areas of availability, confidentiality, processing integrity and privacy. But what many don’t know is how many other standards, compliance requirements and other end user needs can be addressed with this little super standard.
At this point, I’m sure you’re thinking; yeah right, it’s just another “one of those standards”. If someone gave you a Swiss Army knife and you used it as a screw driver, it would be just another screw driver in the toolbox. Same goes for SOC 2; it can be used much more broadly than just what's specified in the Trust Services Criteria.
The Trust Services Criteria categories include Availability, Confidentiality, Processing Integrity, and Privacy. These are optional and often not included in first time SOC 2 reports; but they provide an opportunity to expand the assurance within the same framework. Availability and Processing Integrity cover broader assurance goals outside of the core information security that's about protecting the data.
Broader control activities
SOC 2 and ISO 27001 have about 80% overlap in the control activities they report over. Due to the different approach; SOC 2 focused on operation, ISO 27001 focused on design, these control activities are worded differently. But they are substantively the same. ISO 27001 is more prescriptive to follow predefined controls, whereas SOC 2 allows for any control activities to be included to satisfy the criteria. What that means is you can effectively report over ISO 27001 controls within a SOC 2 report; to demonstrate your compliance with both standards. Or in some cases, your customers may expect you to have specific control activities that can be included in a bespoke way.
The SOC standards (SOC 1, SOC 2, ASAE 3150, etc.), enable the concept of a "plus" report. That is, you report over the standard criteria, plus add in additional criteria or control objectives to report over. Any areas can be covered; as long as it's possible to have an objective means for assessing the controls against a defined objective. For example, if your customer contracts set out it's your responsibility to reconcile their financial transactions; you can include that as a control objective and report over the control activities that achieve that.
SOC 2+ HIPAA Safeguards
Following that "plus" approach to expanding a SOC report; a common use of this is adding in HIPAA safeguards to your report. HIPAA is a regulation rather than a certifiable standard. A common way to demonstrate to your enterprise healthcare companies that you support their compliance with HIPAA, is through this reporting approach that confirms you have the right safeguards in place. It fits well with SOC 2 in particular, given the high degree of overlap in what's already covered by a standard SOC 2 report.
Similar to HIPAA, GDPR is not a certifiable standard. But your customers (data controllers), that use your services (data processor), need to satisfy themselves that you protect their data subjects privacy rights. A common way of doing that is through a GDPR disclosure notice that describes your control activities that align to the GDPR principles and requirements. That's usually included in Section V of a SOC report; which is unaudited but often verified indirectly by Section IV of your report that attests to your control activities.
SOC Reporting is used for a wide variety of assurance goals; most commonly for the integrity of financial reporting data (SOC 1) and cybersecurity (SOC 2). It extends to a wide-variety of areas; only limited by the imagination of its users, the costs associated with bespoke approaches, and the suitability to end users of the reports. That includes everything from food safety, to commercial arrangements, to claims made by brands like "free-range" and "organic". SOC 2 uses that same flexibility in the context of technology risk to provide your customers with one report that can cover all of their assurance needs.