SOC 2 and the Trust Services Principles/Criteria

In my first post, way back on June 1ˢᵗ, I provided a brief overview of the System and Organization Controls (SOC) 1, 2, and 3 reports. Since then the posts have mostly been from the SOC 1 perspective, although the concepts still mostly apply to SOC 2 reports. Either way, I figured it would be beneficial to go into a little more detail about SOC 2 reports.

Example cover page for an SOC 2 Type 2 report.

Trust Services Principles/Criteria:

SOC 2 examinations were born out of the Trust Services Principles (TSP) and were later renamed as Trust Services Criteria (TSC). There are 5 TSCs that can be included in an SOC 2 report. Service organizations have the option to include 1 or more of these in their report depending on the needs of their clients.

Security / Common Criteria: The Security criteria ensures systems and information are protected against unauthorized access and disclosure. Initially, there were some security criteria that spanned all 5 TSCs. As a result, those criteria were consolidated into what is now known as the Common Criteria (CC), which also include aspects of the organizations overall control environment, risk assessment processes, and monitoring activities. There are 9 overall Common Criteria (CC1 – CC9).

The Security / Common Criteria is the baseline for inclusion in all SOC 2 reports. In other words, a service organization can choose to include just the Security / Common Criteria in their examination / report or include 1 or more of the remaining TSCs at their discretion.

Availability: The Availability criteria ensures systems are accessible and operational based on internal and/or contractual requirements. The criteria in this principle include performance monitoring, data backup, and testing of disaster recovery plans. There is 1 overall Availability criteria (A1).

Example availability criteria (A1) as noted in the TSC.

Included in the image above are the A1: Additional Availability criteria. The service organization would document 1 or more of their controls for each of the 3 sub-criteria noted. Those controls are what the service auditor would assess.

Processing Integrity: The Processing Integrity criteria ensures system processing is complete, valid, accurate, timely, and authorized. In essence, the controls supporting this criteria ensure the systems do what they were intended to do, without errors. There is 1 overall Processing Integrity criteria (PI1).

Confidentiality: The Confidentiality criteria ensures the organization is able to identify, maintain, and protect sensitive data thought the use of encryption, access controls, and data disposal procedures. There is 1 overall Confidential criteria (C1).

Privacy: The Privacy criteria ensures Personal Identifiable Information (PII) is collected, used, retained, and disclosed in accordance with the organizations own privacy policy and generally accepted privacy principles.

The Privacy criteria is expansive and requires a lot of time to assess. As a result, including the Privacy criteria in an SOC 2 examination / report substantially increases the overall cost to complete the engagement, compared to just including the 1ˢᵗ 4 TSCs, making it the least likely to be included in an SOC 2 examination / report. There are 8 overall Privacy criteria (P1 – P8).

SOC2+:

Service organizations also have the option to complete an SOC 2+ examination / report. This report would include an assessment of 1 or more TSCs along with other criteria specified by the service organization. The other criteria can be objectives typically included in an SOC 1 report for clients that are also interested in the financial statement impact of the services provided by the service organization. Or, for example, the service organization could include requirements under the Health Insurance Portability and Accountability Act Security Rule (e.g., HIPAA) in the SOC 2+ report. I haven’t seen organizations used this option often, rather deciding to have separate SOC 1 and SOC 2 examinations completed, with either/both provided to clients based on their specific needs.

What is an SOC Examination/Report?

It’s hard for me to believe, but I originally got started with SOC examinations around 2004 when it was referred to as a SAS 70 (Statement on Auditing Standards No. 70). I was an internal auditor for a financial services company back then tasked with managing the individual SAS 70’s of various business units, of which there were upwards of 20 per year, and also managing the relationship with the audit firm performing the audits.

At the time, service organizations used the SAS 70 as an all-encompassing internal controls audit of operations and technology/security. It didn’t matter what type of company was providing the services, be it a payroll processing company or data center services provider, or who the prospective reader of the report was going to be, the SAS 70 report was used to fit the bill.

The industry realized there was a need to create separate report types to meet the unique requirements of service organization and their customers. This brought about the SOC 1, SOC 2, and SOC 3 examinations and reports.

The System and Organization Controls (SOC) examination was designed to help service organizations that provide services to other entities (clients/customers) build trust in the services being performed by assessing the controls over the services provided. A service organization could be a payroll processing company, credit card processing company, or just about any X as a service company (e.g., SaaS).

The independent service auditor SOC examination report provides assurance to the service organization’s clients on the suitability of design and operating effectiveness of the controls in place at the service organization to achieve the related control objectives. The independent service auditor is what many would refer to as a CPA firm.

Included below is a brief breakdown of the 3 SOC reports:

SOC 1

This examination and report most closely aligns with the former SAS 70, so much so that it’s still somewhat common to see references to SAS 70 in contracts between service organizations and their customers. This report is prepared in accordance with AT-C Section 320, “Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting”.

These reports are typically triggered by clients interested in the financial statement impact of the service provided by the service organization. With that said, the examinations will still include control objective and controls covering both operations and technology / security, similar to its predecessor, SAS 70.

Example cover page for an SOC 1 Type 2 Report.

SOC 2

This examination and report was created to meet the needs of modern IT and cloud services providers, focusing on the 5 trust services principles. The trust services principles include security, availability, processing integrity, confidentiality, and/or privacy. I’ll get into more detail regarding the trust services principles in a future post.

These reports are typically triggered by clients interested in the protection of data. Distribution of these reports tends to be more restrictive.

Example cover page for an SOC 2 Type 2 Report.

SOC 3

This report is based on the SOC 2 report, but is meant as a general use report that can be distributed more freely. The report includes a less detailed description of the system and does not include tests of controls and results. I like to refer to it as an executive summary of the SOC 2 report.