One of the first decisions that is going to be made after your organization has decided you need a SOC 2 report is which Trust Services Categories (TSCs) to include in the report. The TSCs determine what controls are going to be examined during the actual SOC 2 audit and what controls are going to be included within the report that you provide to your customers. There are five TSCs which can be included within a SOC 2 report which are:
Security (Common Criteria)
Confidentiality
Availability
Privacy
Processing Integrity
Out of these five, only one category is required for every SOC 2 report, which is Security, also referred to as the Common Criteria. Many organizations might think that it makes sense to include all 5 TSCs. Including all 5 TSCs is perfectly acceptable, but it is not required and may not make sense for all organizations. The inclusion of TSCs should be a business decision made on the basis of customer requirements, the service provided by your organization, and discussions held between you and your auditor. Below, we will be discussing each of the TSCs, what they cover, and the types of organizations that usually include them. At the end of the day, these are examples based on what we have seen from assisting customers select TSCs, there is no “wrong” answer to selecting TSCs, as long as the Security Category is included. All decisions should be made with respect to your business’ requirements.
Security (Common Criteria)
Security is the only required TSC within all SOC 2 reports. Because the Security Category includes controls that overlap with all four of the other TSCs, it is sometimes referred to as the “Common Criteria”.
Specifically, the Security Category is going to contain controls related to protecting information throughout its lifecycle. This will include controls related to preventing unauthorized access, change management, and logging and monitoring, but also organization-level controls such as risk management.
Since the Security Category is required for all SOC 2 reports, any business which is considering a SOC 2 report should be prepared to implement the controls within the Security Category.
Confidentiality
Confidentiality is an optional TSC which contains controls related to maintaining data confidentiality. Or more simply, controls around ensuring that information is appropriately protected and that only authorized parties have the ability to access the information. Another important idea within Confidentiality is the idea of Data Minimization. Once data is no longer required to meet your organization’s objectives, it should be disposed of in a secure manner.
The Confidentiality Category is going to contain controls related to ensuring that access to data is limited to only those parties with a legitimate need to interact with that data. There are going to be controls around maintaining a Data Classification Policy, ensuring that users can only view data they have been authorized to view, and disposing of data in a secure manner.
Confidentiality is a TSC that is commonly included within SOC 2 reports. There is no set type of business that includes Confidentiality more than any other, but if your customers would be concerned with ensuring that access to their data is appropriately restricted, including Confidentiality as a TSC may make sense.
Availability
Availability is another optional TSC which contains controls related to ensuring that information and the system or service being audited is available when customers need it. Most people believe this refers to uptime, but service uptime is only part of this Category. Other important areas covered by this category include managing data backups and restoring system functionality after a disruption.
The Availability Category will include controls related to making sure the system can meet your business objectives. These will be controls such as monitoring capacity, performing data backups, testing data backups, and testing your Business Continuity and Disaster Recovery Plans.
Availability, like Confidentiality, is another TSC that is commonly included within SOC 2 report. There is also no set type of business that includes Availability within their SOC 2 report. The driving reason behind including Availability as a TSC is whether or not your business wants to provide assurance to customers that your system will be available to them when they need it.
Privacy
Privacy is the next optional TSC that can be included within a SOC 2 report. This category deals with collecting, using, retaining, disclosing, and disposing of Personally Identifiable Information (PII). The Privacy Category does not fulfill requirements related to HIPAA, GDPR, the CCPA, or other Data Privacy Laws. While there may be some overlap within the controls being tested, getting a SOC 2 report that includes the Privacy Category will not eliminate your requirements related to demonstrating compliance with the Data Privacy Laws applicable to your business by itself. If you do wish to demonstrate compliance with these laws, you will need to work with your auditor to determine the best path forward, whether that is adding an additional framework into the SOC 2 report (such as having a SOC 2 + HIPAA audit performed) or completing a separate audit.
The Privacy Category is a larger TSC and will cover controls related to ensuring that your business is properly handling the PII of its customers. This will often include controls related to maintaining a Privacy Policy, allowing users to update their PII, and the actions your business performs to confirm that you are complying with any relevant laws.
Privacy is a TSC that is included less often than Availability or Confidentiality. Generally speaking, businesses that collect and use a large volume of PII may want to consider including Privacy. Some examples of this would be businesses in the healthcare, financial, or education industries who are collecting a large volume of Personally Identifiable Information. These organizations might want to include Privacy to show their customers that they are properly managing the information provided to them.
Processing Integrity
The last of the TSCs is Processing Integrity, which is the final optional TSC. Processing Integrity is concerned with verifying that system processing activities are complete, valid, accurate, timely, and authorized. This Category is going to focus on validating that the processing activities performed by your system are executed in a predictable manner and produce accurate results.
The specific controls that will be included within the Processing Integrity category are going to be very specific to your system. If you decide to include Processing Integrity, you will need to work with your auditor to develop the controls applicable to your system. At a general level, Drata includes controls that will likely be examined by your auditor such as ensuring that data is entered into the system correctly, that processing will not complete if required information is not provided, and regression testing. These may be enough to satisfy your business’ requirements as they relate to Processing Integrity, or your auditor may decide to create additional custom controls. This decision will depend on what processing your system performs.
Processing Integrity is a TSC that is also included less often than Availability or Confidentiality. Businesses that include Processing Integrity are primarily businesses who perform a large volume of processing on behalf of their customers or where the complete accuracy of their processing requires assurance. Some examples would be financial processing, data processing/preparation, or pharmaceutical systems.