It has been over a decade since SOC 2 was introduced to the audit world and organizations across the world slowly adopted its ways of working and the trust principles embedded in the program. However, there is still a lot of differentiation in the viewpoints and the aspects that need to be collated to prepare a consensus across the industry.

The primary aspect with which AICPA introduced SOC 2 can be related to the harmonization of the controls using the Common Controls (CC) criteria. Another aspect was to carve out controls from the erstwhile SAS 70 into SOC 1 and SOC 2. This allowed segregation of the audit of operations covered under the ICFR from other operational controls. However, organizations across the industry spectrum are still working with a common set of controls for both SOC 1 and SOC 2 attestation audits, and the overall cause of having segregated Audit Scope and Audit Requirements are getting impaired with this approach.

While carving out the SOC 2 Program, the first thing that organizations must ensure is to segregate the control environment from that of SOC 1. However, some controls may be overlapping because of the overall set of control domain commonality.

SOC 2 Program – Segregation from SOC 1

While carving out the SOC 2 Program, the first thing that organizations must ensure is to segregate the control environment from that of SOC 1. However, some controls may be overlapping because of the overall set of control domain commonality. This segregation can be done on the basis of identifying key controls and the control environments covered by ICFR along with the operational controls and other supporting services that are scoped out from the SOC 2 Audits.

SOC 2 Program – Trust Principles and Trust Service Criteria

From the five (5) Trust Principles of Security, Availability, Confidentiality, Processing Integrity and Privacy, the most common areas to look at are the security, availability and confidentiality aspects. These three (3) Principles make up for most of the requirements in the overall Trust Service Criteria (TSC).

TSC, as it was last revised and published in 2017 by the American Institute of Certified Public Accountants (AICPA), covers 12 areas aligned with all the five trust principles. However, a simple selection of the security trust principles covers the initial nine (9) areas of the Common Criteria (CCs):

1. CC1.0 – Common Criteria Related to Control Environment
2. CC2.0 – Common Criteria Related to Communication & Information
3. CC3.0 – Common Criteria Related to Risk Assessment
4. CC4.0 – Common Criteria Related to Monitoring Activities
5. CC5.0 – Common Criteria Related to Control Activities
6. CC6.0 – Common Criteria Related to Logical & Physical Access
7. CC7.0 – Common Criteria Related to System Operations
8. CC8.0 – Common Criteria Related to Change Management
9. CC9.0 – Common Criteria Related to Risk Mitigation

This means that a majority of the work is needed on these 9 control areas and the associated domains. While the majority of the CCs are pretty straight forward, it is specifically in the areas of logical and physical access, and the system operations where detailed control consideration is needed. Many times, there is a lot of overlapping from the way the TSC point of focus is described and it causes moments of confusion for the team working on control and the control environment definition. A key aspect here is to understand the essence of the requirement and define the control accordingly. If the derivative still sounds to be the same, then a simple cross reference to the respective control defined in another control area can be provided.

To cover the other TSCs, AICPA has then identified additional criteria for Availability, Confidentiality, Processing Integrity and Privacy. Under this area, there may be some cross reference required for point of focus as covered under availability and confidentiality with the CC6.0 and CC7.0. The overall aspects remain more or less in line with the essence of the criteria and the descriptions provided in the TSC.

Processing integrity as well as privacy, remain fairly straight forward, where the controls can be aligned in consideration with the geographical privacy law as enacted and enforced.

SOC 2 Program – Cross Compliance Dynamics

SOC 2 Program in its current design is very adaptive and can be used to create a Common Compliance Framework for the organization covering the following set of standards & regulations:

1. PCI-DSS
2. HIPAA – Security as well as Privacy by using HiTrust CSF
3. ISO 27001
4. Most of the Privacy Laws
5. FedRAMP
6. NIST-CSF and NIST 800-53
7. COBIT

The overall controls framework definition becomes much easier as the above stated standards and regulations provide the controls specific. It’s also eased as the SOC 2 TSC point of focus mapping to the majority of the standards / regulations is already available from AICPA. What remains is the scope and boundary definition for the SOC 2 applicability and identification of the support operations to define evidence requirements.

Conclusion

Even though the SOC 2 attestation was introduced more than a decade ago by AICPA, the adaptability has been slow in the industry sector. While organizations were fast to adopt the SSAE 18 (erstwhile SSAE 16) given its easy transition from SAS 70, the overall understanding on SOC 2 (following AT 101 Audit Standard) has been slower as it is deemed to be complex. However, the aspect that organizations must focus on while adopting SOC 2 Program is to segregate it from their SOC 1 program and align it with one or more industry standards (based on industry requirements). This will help them drive simplicity in controls and criteria selection as well as audit success with the adoption of the Unified Compliance Approach.