
What's Inside
Learn more about the SOC 2 Trust Principles—Security, Availability, Processing Integrity, Confidentiality, and Privacy—that safeguard data and ensure compliance.
SOC 2 Trust Principles: Everything You Need to Know
Learn more about the SOC 2 Trust Principles—Security, Availability, Processing Integrity, Confidentiality, and Privacy—that safeguard data and ensure compliance.
Get Started With Drata
Data breaches can stem from countless security vulnerabilities, but protecting your organization starts with having the right internal controls in place. According to IBM's 2024 Cost of a Data Breach Report, the global average cost of a data breach reached $4.88 million, a 10% increase year over year.
Thankfully, your organization can take concrete steps to protect customer data and build trust through SOC 2 compliance and its Trust Services Criteria (TSC). Below, we break down each SOC 2 Trust Principle and explain how to implement them effectively in your security program.
SOC 2 compliance relies on five Trust Services Criteria (TSC)—Security, Availability, Processing Integrity, Confidentiality, and Privacy. The American Institute of Certified Public Accountants (AICPA) developed these principles to help companies demonstrate their commitment to protecting sensitive information. Each principle addresses specific aspects of data security and operational excellence.
The Security criteria, required for all SOC 2 audits, provides specific criteria for evaluating how well your security systems protect user data throughout its lifecycle—from creation and collection to processing, storage, and transmission.
Security is defined by the common criteria (CC-series), which lays out nine control areas based on the Committee of Sponsoring Organizations of the Treadway Commission (COSO) framework. These principles guide organizations in developing, implementing, and operating effective security controls:
The control environment (CC1) sets the tone for your organization's security culture. It outlines how you establish and maintain security roles, responsibilities, and policies. A strong control environment ensures everyone understands their part in maintaining security.
Information and communication (CC2) focuses on keeping security information flowing throughout your organization. Your teams need clear channels for sharing updates about security policies and reporting potential incidents. This helps maintain consistent security practices across departments.
Risk assessment (CC3) requires a structured approach to handling security threats. Your organization needs clear processes for identifying, analyzing, and responding to risks that could impact your business objectives.
Monitoring (CC4) keeps your security program on track through regular evaluation. Your organization should continuously assess how well security controls perform and address any gaps before they become serious security risks.
Control activities (CC5) translate your security plans into action through specific procedures, including how you manage system access and how you configure security settings.
Logical and physical access controls (CC6) protect your sensitive data on two fronts. Your organization must restrict both digital access (through software and networks) and physical access (to facilities and hardware) based on user roles and responsibilities.
System operations controls (CC7) ensure your systems run as intended. This covers daily operations, incident response, and maintaining system availability.
Change management controls (CC8) help you implement system changes safely. Whether updating applications or modifying infrastructure, you need processes to ensure changes don't compromise security or affect performance.
Risk mitigation controls (CC9) help reduce the impact of security incidents. Your organization should have clear plans for responding to security events and protecting critical assets.
Of the nine criteria outlined above, the first five are deemed essential for establishing a strong security posture.
The Availability criteria addresses system accessibility and performance. While optional, this principle is of special importance for organizations providing cloud services or promising specific uptime levels to customers. It ensures systems remain operational and accessible as agreed upon in service level agreements (SLAs).
The AICPA breaks down Availability into three specific criteria that help organizations maintain reliable service delivery. They focus on capacity management, system recovery, and testing procedures to ensure your systems remain accessible when your customers need them:
The first criterion (A1.1) addresses capacity management. You should continuously monitor and evaluate your current processing capacity, from infrastructure to data storage, in order to maintain performance levels that meet your SLAs and deploy additional capacity when needed.
The second criterion (A1.2) focuses on system resilience. Your organization must design and maintain robust systems that can handle both everyday operations and unexpected challenges. This includes implementing environmental protections for your infrastructure, establishing comprehensive backup processes, and maintaining recovery systems that can quickly restore service.
The third criterion (A1.3) ensures your recovery procedures work as intended. Regular testing of your backup and restoration processes helps verify that you can meet availability objectives when issues arise.
If you provide financial reporting services or e-commerce platforms, you know that even small processing errors can have major consequences. Your customers need assurance that every transaction processes correctly, especially when handling sensitive financial data or business-critical operations.
Processing Integrity helps evaluate whether your systems perform their intended functions without delays, errors, omissions, or unauthorized manipulation. The AICPA outlines five specific criteria to help you maintain data quality throughout its lifecycle:
The first criterion (PI1.1) focuses on how you define and communicate processing requirements. You need clear specifications for how your systems should handle data, which means documenting exactly what "correct processing" looks like for your services, from initial data entry to final output.
Input validation controls make up the second criterion (PI1.2). Before your systems process any data, you need controls to verify that inputs are complete and accurate. It’s like quality control at the entry point—catching errors here prevents them from flowing through your entire system.
The third criterion (PI1.3) addresses the actual processing activities. You need well-defined procedures for how your systems handle data, including ways to monitor processing in real-time and quickly correct any issues that arise. This might include automated error checking, processing validation steps, or manual reviews for critical transactions.
Output delivery forms the fourth criterion (PI1.4). Your systems need controls to ensure that processed data reaches the right recipients, in the correct format, and without unauthorized modifications.
The fifth criterion (PI1.5) focuses on data storage and record-keeping. You need procedures to protect stored data and maintain accurate logs of all system activities.
The Confidentiality criteria applies to any organization that handles sensitive information, whether it’s client data, business plans, financial reports, intellectual property, customer lists, or proprietary algorithms.
The AICPA breaks down Confidentiality into two subcriteria that guide how you manage sensitive information throughout its lifecycle:
C1.1 addresses how to identify and classify confidential information. Clear procedures are needed to determine what qualifies as confidential and who is responsible for protecting it. This involves establishing classification levels, defining handling requirements, and assigning ownership for different types of sensitive data.
C1.2 focuses on protecting confidential information from unauthorized access or disclosure. Your organization needs controls that safeguard data at every stage, which includes implementing access restrictions, encrypting sensitive data, monitoring for unauthorized access attempts, and ensuring secure disposal when the data is no longer needed.
As privacy regulations like GDPR and CCPA continue to evolve, organizations need processes for handling personal identifiable information (PII).
The Privacy criteria focuses specifically on PII—how you collect it, use it, store it, share it, and eventually dispose of it. The AICPA organizes Privacy controls into eight categories that help organizations maintain compliance and build trust with their users:
Notice: You need to be upfront with individuals about your privacy practices. This means providing clear, accessible privacy notices that explain exactly how you'll handle their personal information.
Choice and consent: Your users should have a say in how their data is used. Beyond obtaining initial consent, you need processes for users to update their preferences and withdraw consent if and when they choose.
Collection: Addresses how you gather personal information. If you're gathering data that doesn't serve your core business functions, you're increasing risk without adding value.
Use, retention, and disposal: Is the lifecycle management of personal data. You need clear rules for how long you'll keep different types of information and secure methods for disposing of data you no longer need.
Access: Ensures individuals can view and correct their personal information. Here, your organization needs secure processes for verifying user identity and handling access requests.
Disclosure and notification: This helps manage how you share personal information with third parties. You also need procedures for notifying affected individuals if their data is compromised.
Quality: Focuses on maintaining accurate, relevant data.
Monitoring and enforcement: You need ways to verify that your privacy controls work as intended and processes for handling privacy-related complaints or concerns.
There's a good chance you're wondering which Trust Principles your organization needs beyond the required Security principle. While it might be tempting to include all of them "just to be safe," that approach could unnecessarily complicate your compliance efforts.
The truth is that each additional principle increases the number of criteria you need to comply with and controls you need to implement. Below, we break down how to evaluate which principles align with your business needs and provide real value to your customers.
The Security principle is the foundation of SOC 2, and many of its controls overlap with other Trust Principles. However, depending on your services, contractual obligations, and customer base, additional principles may be necessary to fully protect your organization and meet compliance requirements.
Consider the following scenarios as examples of when other TSC might be required:
If you provide a continuous integration/continuous deployment (CI/CD) platform, you'll want the Availability principle, as an outage would prevent clients from deploying changes to their services.
If you process financial transactions or provide financial reporting services, you'll want Processing Integrity, as your customers rely on accurate calculations and proper transaction handling.
If you store business plans, product roadmaps, or intellectual property, you'll want the Confidentiality principle, since your clients need their sensitive information protected from competitors.
If you handle customer shipping addresses, payment details, or other personal information through your e-commerce platform, you'll want the Privacy principle to ensure proper data handling.
Ultimately, your selection of Trust Principles should reflect your unique business context and obligations. When it’s time to make your choice, consider that:
The services you provide matter most. A code deployment platform needs different principles than a customer data platform.
User demands often drive principle selection. If your customers specifically request certain security assurances in their contracts, those requirements should guide your choices.
Contractual obligations might mandate specific principles. Review your service level agreements and client contracts, as they might contain security and availability requirements.
Legal requirements vary by industry and region (e.g. healthcare service providers face different obligations than financial services companies).
The type of data in your system influences which principles you need. Handling personal identifiable information requires different controls than managing business data.
Drata enables you to streamline your SOC 2 compliance journey through automation designed by auditors and security experts. Our platform provides a single source of truth for all your compliance needs, from continuous control monitoring and evidence collection to asset tracking and access reviews.
Still have questions about the SOC 2 Trust Principles? Below we answer some of the most common queries.
No. While the Security principle is mandatory for all SOC 2 audits, you can select additional principles based on your business needs and customer requirements. For example, if you don't store personal information, you might not need the Privacy principle. Similarly, if you don't process transactions or handle financial data, you might not need Processing Integrity.
The choice of principles depends largely on your services and how you handle data. Cloud storage providers might include Availability because their customers need reliable access to data. Financial software companies typically add Processing Integrity to demonstrate accurate transaction handling. Companies handling trade secrets or proprietary information might include Confidentiality to show strong data protection measures.
Implementation timelines vary based on your current security posture, organizational size, and which principles you select. Adding the Availability principle might take just a few months if you already have robust monitoring systems and backup procedures in place. However, implementing Privacy controls could take longer, especially if you need to modify how you collect, process, and store personal information.
Resource availability also affects implementation time. Organizations with dedicated compliance teams and automated security tools like Drata typically complete implementations faster than those managing everything manually. The complexity of your systems and the number of third-party vendors involved can also impact timelines.
Yes. Many organizations start with Security and gradually add other principles as their business grows or customer requirements change. This phased approach helps manage the complexity of compliance while still meeting evolving security needs.
For example, you might start with Security for your first audit, add Availability in year two as your customer base grows, and include Privacy in year three when expanding into markets with strict data protection regulations.
Many controls overlap across principles, which is great news if you want to streamline your compliance efforts. For example, access management controls support both Security and Confidentiality principles. Change management controls often satisfy requirements for Security, Processing Integrity, and Availability.
Working with your auditor during the scoping phase helps identify these overlaps. They can review your existing controls and show where they satisfy requirements for multiple principles.
If the auditor identifies gaps in your controls, they'll document them as exceptions in your SOC 2 report. However, exceptions don't automatically mean you've failed your audit. Auditors can issue four types of opinions at the end of their assessment:
An unqualified opinion means you've successfully met all SOC 2 criteria—your systems and controls work as intended.
A qualified opinion indicates you're close but didn't quite meet all criteria. While most of your controls work effectively, one or more SOC 2 criteria weren't fully satisfied.
An adverse opinion means your systems don't meet most of the SOC 2 criteria.
A disclaimer of opinion occurs when auditors can't gather enough evidence to form a proper assessment.
The good news is that not all exceptions affect your auditor's opinion. For example, if one control fails but you have other controls in place that address the same risk, the auditor might note the exception but still issue an unqualified opinion. The impact of exceptions depends on several factors, including how many exceptions were found, how severe they are, whether compensating controls exist, and whether the exceptions are one-time issues or recurring problems.
Your current and prospective customers will evaluate these exceptions based on their severity, your response plan, and whether they see the same issues appearing in future SOC reports.
Keep Reading
Take Your Learning Further
Discover research, playbooks, checklists, and other resources on SOC 2 compliance.