This blog supports AJ's Live Stream: SOC 2 TSCs.
One of the most critical decisions when pursuing a SOC 2 is deciding which Trust Services Categories to include in your scope. If you get it wrong, this decision can be costly, both for your operations and finances. In this blog, we will discuss what the five Trust Service Categories (TSCs) are and how you should select which TSCs to include in the scope of your report.
What are the five TSCs?
There are five TSCs that any company can choose to include in their SOC 2 report. The five Trust Services Categories and their definitions as defined by the AICPA are:
- Security: Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and Privacy of data or systems and affect the entity's ability to meet its objectives.
- Availability: Information and systems are available for operation and use to meet the entity's objectives.
- Processing Integrity: System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives.
- Confidentiality: Information designated as confidential is protected to meet the entity's objectives.
- Privacy: Personal information is collected, used, retained, disclosed, and disposed of to meet the entity's objectives.
There is a subset of criteria called the AICPA Trust Services Criteria within each category. The criteria are what you and your auditor will use as the basis for developing your control set and determining if you are correctly handling security, availability, or processing integrity of the information you process. In addition, the criteria cover how that system manages the privacy or confidentiality of that information.
That's a lot of AICPA jargon that can be confusing. Let's discuss each of these categories in simple terms.
Security Category
The Security TSC is the baseline TSC included in 99.9% of all SOC 2 reports. The Security category covers security audit topics you'd expect to see in a cybersecurity assessment, such as onboarding, offboarding, risk assessments, vulnerability management, access control, and vendor management. In the Security TSC, you will find nine common criteria (CC1.0-CC9.0) to develop controls to address. The Security category includes nine criteria, which are:
- CC1.0 - The Control Environment
- CC2.0 - Communication and information
- CC3.0 - Risk assessment
- CC4.0 - Monitoring of controls
- CC5.0 - Control activities related to the design and implementation of controls
- CC6.0 - Logical and physical access
- CC7.0 - System operations
- CC8.0 - Change management
- CC9.0 - Risk Mitigation
Availability Category
The Availability TSC is a common category in modern SOC 2 reports because most service organizations or SaaS companies are hosted in the cloud. This category makes a ton of sense for cloud-hosted companies because the native features of the cloud make it easy to address the criteria. In this category, you will find controls related to backups, processing capacity, replication, multi-location strategies, business continuity, and disaster recovery planning and tests. The Availability category includes three criteria, which are:
- A1.1: The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
- A1.2: The entity authorizes, designs, develops, or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives.
- A1.3: The entity tests recovery plan procedures supporting system recovery to meet its objectives.
Confidentiality Category
The Confidentiality category is another common SOC 2 category you'll find in most SOC 2 reports. This category focuses on handling confidential information, including data classification and how you handle confidential information in non-production environments. A critical section of this category is the criterion that tests your data deletion and removal practices. You should include the Confidentiality category if you make commitments to your customers that you will delete their data when they leave your service or terminate their contract. For example, if your MSA says that you will delete all customer data within 30 days of contract termination, you should include this category in your SOC 2 report. The Confidentiality category consists of two criteria, which are:
- C1.1: The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.
- C1.2: The entity disposes of confidential information to meet the entity's objectives related to confidentiality.
Processing Integrity Category
Processing Integrity is a category you will not find in most SOC 2 reports. The Processing Integrity TSC discusses the completeness and accuracy of your system's information processed and produced. You'll often see companies like payroll companies include the Processing Integrity category in their SOC 2 because it is critical payroll companies have controls that ensure the information produced is complete and accurate. The Processing Integrity category includes four criteria, which are:
- PI1.1: The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.
- PI 1.2: The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
- PI 1.3: The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity's objectives.
- PI 1.4: The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
- PI 1.5: The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
Privacy Category
The Privacy category is a TSC that gets a lot of attention but is often not relevant to most organizations undergoing a SOC 2. The SOC 2 privacy category covers how you handle and protect Personally Identifiable Information or PII. Before deciding whether or not to include the SOC 2 Privacy category in your SOC 2, you should consider whether or not your company is a data controller or data processor. The privacy category makes sense if you're a data controller and interact directly with data subjects (people like you and me). On the other hand, if you are a data processor and only process PII but do not interact with the data subjects, the Confidentiality TSC should suffice for your report. When I say "should suffice," I am referring to the readers of your report. In this scenario, the readers of your report should be fine with the Confidentiality category instead of the Privacy category.
The Privacy category adds a ton of complexity on the reporting and testing side, so you want to be sure you get this right before making that operational and financial commitment. Many companies mistakenly include Privacy and end up overpaying for their auditors to write "This criterion is not applicable." several times. The Privacy category consists of eight criteria, which are:
- P1.0: Privacy Criteria Related to Notice and Communication of Objectives Related to Privacy
- P2.0: Privacy Criteria Related to Choice and Consent
- P3.0: Privacy Criteria Related to Collection
- P4.0: Privacy Criteria Related to Use, Retention, and Disposal
- P5.0: Privacy Criteria Related to Access
- P6.0: Privacy Criteria Related to Disclosure and Notification
- P7.0: Privacy Criteria Related to Quality
- P8.0: Privacy Criteria Related to Monitoring and Enforcement
Choosing the TSCs for your SOC 2
Now that you have a solid understanding of each TSC and when they would be relevant, how do you go about making the decision? The decision of which TSCs to include in-scope of your SOC 2 report starts with a simple question: "What are we committing to?" Your SOC 2 report is about your commitments and system requirements necessary to meet your objectives. Generally, these commitments are outlined in Master Services Agreements, Service Level Agreements, or other contractual documents where your company would outline its commitments that relate to each TSC.
For example, if you are wondering whether or not you should include the Availability TSC. Take a look at your contracts and agreements and identify any service level agreements or commitments that would require you to have strong Availability controls. For example, maybe you commit to 99.98% uptime. Your customers will expect to see what controls are in place for you to meet that commitment.
It's essential to focus on your commitments and not what your auditor suggests. Your report should be relevant to your customers and other entities who will receive this report. Randomly selecting TSCs without considering your commitments is a fast way to waste time and money during a SOC 2.
About the Author
AJ Yawn is Co-Founder and CEO at ByteChek and a Founding Board Member of the National Association of Black Compliance and Risk Management Professionals (NABCRMP). AJ has earned 6 AWS certifications including the AWS Solutions Architect-Professional and AWS Security-Specialty. Prior to ByteChek, AJ spent over a decade in the cybersecurity industry both in the US Army and as a consultant. He is a regular speaker at SANS Cloud Security curriculum events such as BIPOC in Cloud Forum and CloudSecNext Summit, and can be found teaching SEC557: Continuous Automation for Enterprise and Cloud Compliance. Read AJ's full bio here.
