SOC 2 Trust Principles: How to Pick the Right Criteria for Your Audit

SOC 2 is designed to offer service businesses a way to prove the trustworthiness of their security posture. 

In this guide, we’ll break down each of the five SOC 2 Trust Services Principles, helping you to figure out which ones fit with your business. 

What Are the SOC 2 Trust Principles? 

The SOC 2 trust principles were established by the International Certified Professional Accountants (AICPA) in 2016 as a way to standardize the way we assess and report on an organization’s cybersecurity practices. 

The five main principles are: 

1. Security
2. Availability
3. Processing Integrity 
4. Confidentiality
5. Privacy 

One Security (known as the common criteria) is mandatory in every SOC 2 report. The other four TSC are optional and only need to be included if they are relevant to your business. 

When preparing for a SOC audit you should select the criteria that relate your business services. For example, if you hand a lot of data on behalf of customers you may want to include privacy and/or confidentiality.

During a SOC 2 audit, your auditor will assess the design (SOC 2 Type I) and/or operating effectiveness (SOC 2 Type II) of your controls and policies against your chosen TSC.

Trust Service Principles vs. Trust Services Criteria 

The Trust Services Principles and Criteria (TSPC) were officially renamed as the Trust Services Criteria (TSC) in 2018. Though the names are sometimes used interchangeably, they referred to the same five criteria: Security, Availability. Processing Integrity, Confidentiality, and Privacy. 

Breaking Down the SOC 2 Trust Principles 

Security

The Security criteria (often called the Common Criteria) is the only TSC that’s mandatory for every SOC 2 audit. The Security principle is designed to validate that your systems and data are protected against unauthorized access, unauthorized disclosure, and damage. 

Auditors assess this principle using a set of requirements known as the CC-Series (Common Criteria), which is organized into nine categories:

• CC1: Control Environment: Addresses the organization’s integrity, ethical values, governance structure, establishing accountability and oversight for security and compliance.
• CC2: Communication and Information: Covers how security and compliance information is identified, documented, and communicated internally and externally.
• CC3: Risk Assessment: This validates that you analyze risks (internal, external, and fraud-related) regularly.
• CC4: Monitoring Activities: This covers internal audits and system alerts to detect when controls fail.
• CC5: Control Activities: Do you have policies in place to mitigate identified risks?
• CC6: Logical and Physical Access Controls: Who has the keys? This ensures only authorized people can access data, covering everything from MFA to physical office keycards.
• CC7: System Operations: Can you handle incidents? This verifies you have incident response plans and backups to recover from disruptions.
• CC8: Change Management: Do you test before you deploy? This ensures code changes don't break security.
• CC9: Risk Mitigation: Do you act on risks? This checks for business continuity plans to handle residual risks.

Who needs it:

Any organization that’s getting a SOC 2 report will be audited against the Security criteria. 

Availability 

Availability addresses whether your system is operational and accessible as agreed upon in your Service Level Agreements (SLAs). Though 100% uptime is almost impossible, this TSC is designed to assure your partners that your systems are reliable and that you  can recover quickly on the (rare) occasions where things break. 

While the specific performance levels (like 99% uptime) are typically defined in your Service Level Agreements (SLAs) rather than the SOC 2 framework itself, the AICPA requires you to demonstrate controls across three specific areas known as the A-Series. 

Some example availability criteria include:

• A1.1: Capacity Management: Auditors want to see that you actively monitor current usage (like CPU, memory, and storage) and have a plan to deploy extra capacity to handle traffic spikes or rapid user growth.
• A1.2: Backup and Environmental Controls: You need to demonstrate that data is backed up (ideally in geographically separate regions to prevent total loss) and that physical infrastructure is protected by safeguards like fire suppression and power redundancy.
• A1.3: Recovery Testing: You need to prove that you regularly test your recovery procedures. 

Who needs it:

If your organization includes strict uptime agreements or if any downtime could cause financial losses for clients, this TSC should be included. If you’re a software company where a 10-minute outage is annoying but doesn’t cause any financial or long-term damage, you may be able to skip this TSC.

Confidentiality

The Confidentiality TSC can often be confused with Privacy. Here’s the difference: Privacy is focused on personal data, whereas Confidentiality protects business data and intellectual property. 

If your organization handles sensitive information for clients (like financial reports, IP, strategy documentation), this will generally fall under Confidentiality. This TSC is designed to validate that your organization can effectively protect confidential information throughout its lifecycle with your business, from the moment it’s collected to the time it’s removed from your servers. 

The Confidentiality TSC is evaluated through the C-Series controls:

• C1.1: Means you need to have procedures in place to identify and maintain confidential information. 
• C1.2: Focuses on your procedures for destroying or removing confidential information. 

Who needs it:

If your customers trust you with proprietary data or IP, adding the Confidentiality criteria to your SOC 2 audit proves you can be trusted to safeguard this sensitive information. For example, a platform for legal documents or housing proprietary code would benefit from including this TSC in a SOC 2 audit. 

Processing Integrity

This principle focuses on whether your system achieves its purpose without accidental error, delay, omission, or manipulation. It is built on four pillars: accuracy, completeness, validity, and timeliness.

The Processing Integrity TSC is all about proving operational competence and showing your customers that your system does exactly what it says it does, every single time. For example, if you’re working with financial data, does your system effectively and accurately manipulate and display data without any errors. 

The PI-Series criteria breaks this down into five key control areas:

• PI1.1: This criteria ensures you have generated and shared quality information about your processing objectives.
• PI1.2: You need controls that validate data before it enters the system to ensure accuracy and completeness.
• PI1.3: You must demonstrate that your system processes data exactly as intended and has a way to catch itself if it fails.
• PI1.4: This checks that outputs are accurate, timely, and distributed only to authorized recipients.
• PI1.5: This ensures that stored data isn't corrupted or altered while sitting in your database.

Who needs it:

If you are a SaaS platform that just hosts documents, this TSC may not be needed. However, if you’re a fintech, payroll, eCommerce, or healthtech organization where a decimal point error could cost a user real money or trigger a lawsuit, this criteria is essential. 

Privacy 

The Privacy principle deals with Personally Identifiable Information (PII). This includes names, emails, IP addresses, location data, or anything that can be linked to a specific individual. It validates that you don't just collect data, but that you respect the rights of the people it belongs to, giving them control over how it is gathered, stored, and eventually destroyed.

The Privacy criteria are broken down into eight categories known as the P-Series:

• P1.0: You must clearly tell users what you are doing with their data before you collect it.
• P2.0: You can’t force data collection and must offer meaningful choices (think opt-in checkboxes for marketing).
• P3.0: Means you only collect what is strictly necessary to meet your objectives.‍
• P4.0: You must use data only for the purposes you promised, keep it only as long as needed, and destroy it securely when done.
• P5.0: Users have the right to see and correct their own data.
• P6.0: How you share data with third parties and how you tell users if that data is breached.
• P7.0: You have a responsibility to ensure the personal data you hold is accurate and up-to-date.
• P8.0: Finally, you must enforce your own policies to ensure these rules are actually followed.

Who needs it:

B2C companies, HealthTech, or any platform storing vast amounts of consumer PII. If you are a pure B2B SaaS dealing mostly with business emails, you can often skip Privacy in favor of Confidentiality. However, if you are selling to large enterprises who send you security compliance questionnaires heavily focused on GDPR, this principle might bridge the gap.

The SOC 2 Supplemental Criteria 

The SOC 2 TSC also includes a subset of supplemental criteria under the Security principle. These criteria originated from the COSO framework (Committee of Sponsoring Organizations of the Treadway Commission).

COSO was created in 2013 with similar goals to SOC 2 (helping service organizations to protect sensitive data). The supplemental criteria fall under the Security TSC and include: 

• CC6: Logical and physical access controls 
• CC7: System operations 
• CC8: Change management 
• CC9: Risk mitigation

How to Select the Right Trust Principles for Your Organization

As we’ve mentioned, Security is the only mandatory principle in SOC 2. That means the other four TSC are optional, putting the onus on you to select the right ones for your organization. 

Security is mandatory because it helps organizations to achieve a security foundation that means you can be trusted to handle data. The Seucity TSC also gives customers confidence in your posture and policies, reducing the risk of working with your organization. 

Security also provides a baseline for the other TSC so without it, you couldn't really implement controls to satisfy the Integrity or Availability TSC.

But how do you decide which additional TSC to include in your audit? Here are two tips:

1. Consider Your Business Model

What your business does and who your customers are should be the #1 factor you consider when deciding which additional TSC to include alongside Security. To help you decide, here is a quick recap of which business models typically require each criteria:

• Availability: Can make sense to include if you have uptime agreements or SLAs.
• Confidentiality: Should be included if you handle IP and confidential business information. 
• Processing Integrity: If important if you deal with a lot of data and accuracy is essential (think: fintech, payroll, eCommerce, or healthtech). 
• Privacy: Is needed if you handle PII. 

2. Think About Scope

Every additional principle you add to your audit increases the costs (both in audit fees/time and internal time preparing for audit). 

If you’re a young startup preparing for your first audit, it can be beneficial to keep your audit scope as small as possible — focusing only on Security with a view to adding on additional principles in the future. However, in some cases, you may need to add additional principles from the start. 

The timeline drag of adding additional TSC can also slow down your pipeline. If you only need Security to get deals flowing, tick that box first before tacking on more TSC.

Often, it’s best to work with a compliance partner who can help guide you through the scoping process to ensure you’re tackling SOC 2 in the most time and cost effective way possible. 

Achieve SOC 2 Quicker with Workstreet

If you are ready to start but aren't sure which principles fit your specific business model, Workstreet's SOC 2 compliance services can guide you through the scoping process. We help you build a right-sized program that gets you audit-ready fast.

SOC 2 TSC FAQs

Do I Need All 5 Trust Principles?

No, only Security is mandatory. The other TSC should be added as and when they are necessary for your business. 

What's the Difference Between Confidentiality and Privacy?

Confidentiality protects data restricted to specific parties (often B2B data, IP, trade secrets). Privacy protects personal information and individual rights (PII, consent, GDPR alignment).

Can I Add Principles Later?

Yes. You can (and often should) start with Security in Year 1. As you mature, can add additional TSC to your SOC 2 report.

What Happens If I Fail Controls for Just One Principle?

You receive a "qualified opinion" on your report. This flags the failure to every customer who reads it. Your goal should always be to achieve an unqualified report, working with a SOC 2 compliance partner can help ensure you head into your audit with confidence. 

Do These Principles Map to Other Frameworks Like ISO 27001?

Yes, there is significant overlap. The Security principle covers the majority of ISO 27001 controls, meaning a strong SOC 2 program gets you about 70-80% of the way toward ISO certification.