Systems and Organization Controls 2 (SOC 2) is a framework and audit process created by the American Institute of Certified Public Accountants (AICPA). SOC 2 evaluates an organization’s ability to securely manage sensitive data. By undergoing a SOC 2 audit, performed by a Certified Public Accountant (CPA), an organization can demonstrate it has effective controls to protect customer data and systems, reducing risk for customers and partners.
Unlike PCI DSS, which has very rigid requirements, SOC 2 reports are unique to each organization. In line with specific business practices, each designs its own controls to comply with one or more of the trust principles.
These internal reports provide you (along with regulators, business partners, suppliers, etc.) with important information about how your service provider manages data.
There are two types of SOC reports:
- Type I describes a vendor’s systems and whether their design is suitable to meet relevant trust principles.
- Type II details the operational effectiveness of those systems.
What Are the Trust Services Criteria (TSC)
The Trust Services Criteria (TSC) are the AICPA-defined set of control objectives and criteria used to evaluate a service organization’s controls for SOC reports. They define what a service organization should do to protect customer data and provide reliable services. There are five criteria categories:
1. Security
The Security principle in SOC 2 (often called the "common criteria" or "common security") is the only mandatory criterion among the five Trust Services Criteria (TSC). It requires protecting system information and data against unauthorized access, unauthorized disclosure, or damage.
Key components of security principle include:
- Access Control: Limiting access to authorized individuals.
- Data Security: Identifying and securing sensitive information at rest and in motion.
- Internal Control Evaluations: Assessing existing security measures.
- Physical Security: Protecting physical assets.
- Monitoring & Logging: Detecting unauthorized activity, responding to incidents.
- Manage Vendor Risk: Reduce third party risk (e.g. Cloud platform providers).
2. Availability
The availability principle refers to the accessibility of the system, products or services as stipulated by a contract or service level agreement (SLA). As such, the minimum acceptable performance level for system availability is set by both parties. This principle does not address system functionality and usability, but does involve security-related criteria that may affect availability. Monitoring network performance and availability, site failover and security incident handling are critical in this context.
3. Processing integrity
The processing integrity principle addresses whether or not a system achieves its purpose (i.e., delivers the right data at the right price at the right time). Accordingly, data processing must be complete, valid, accurate, timely and authorized. However, processing integrity does not necessarily imply data integrity. If data contains errors prior to being input into the system, detecting them is not usually the responsibility of the processing entity. Monitoring of data processing, coupled with quality assurance procedures, can help ensure processing integrity.
4. Confidentiality
Data is considered confidential if its access and disclosure is restricted to a specified set of persons or organizations. Examples may include data intended only for company personnel, as well as business plans, intellectual property, internal price lists and other types of sensitive financial information. Encryption is an important control for protecting confidentiality during transmission. Network and application firewalls, together with rigorous access controls, can be used to safeguard information being processed or stored on computer systems.
5. Privacy
The privacy principle addresses the system’s collection, use, retention, disclosure and disposal of personal information in conformity with an organization’s privacy notice, as well as with criteria set forth in the AICPA’s generally accepted privacy principles (GAPP).
Personal identifiable information (PII) refers to details that can distinguish an individual (e.g., name, address, Social Security number). Some personal data related to health, race, sexuality and religion is also considered sensitive and generally requires an extra level of protection. Controls must be put in place to protect all PII from unauthorized access. Each criterion is broken into points of focus and control activities that auditors test. Organizations choose which of the optional criteria (availability, processing integrity, confidentiality, privacy) apply based on services offered and customer expectations; security is always included.
Why does SOC 2 Matter to Enterprises?
SOC 2 provides enterprises with confidence that a service provider has mature security and risk management practices in place to protect sensitive data. It is often a mandatory requirement in enterprise procurement processes, serving as a standardized way to assess vendor security without conducting bespoke audits.
SOC 2 also supports alignment with broader regulatory and security frameworks such as ISO 27001, NIST, GDPR and PCI DSS helping enterprises manage compliance obligations more efficiently. Most importantly, it builds trust when enterprises share sensitive or regulated data with third parties, including data used for AI training, fine-tuning, or inference, where data exposure and misuse risks are especially high.
Can You Leverage Your ISO 27001 or NIST CSF 2 Compliance Efforts for SOC 2?
Yes, SOC 2, ISO 27001 and NIST Cybersecurity Framework 2 share many similarities even though they differ in structure and certification approach. Investment to support one certification or compliance effort should help support the efforts of the others and vice versa. For example all 3 frameworks call for a risk-based approach to security, ensuring the confidentiality, integrity, and availability of information, having secure governance practices, strong access controls, third party risk management and incidence response and monitoring.
Which Organizations Need SOC 2 Compliance?
In the absence of a strong federal privacy regulation in the United States, SOC 2 has become a popular voluntary framework used to evaluate the ability of service providers to protect customer data. For SOC 2, the key point is that the service provider—not the customer—is audited. The entities that “need” a SOC 2 audit are those that operate systems handling customer data on behalf of others.
Data processing or storage organizations such as SaaS and IaaS cloud providers, AI platforms, data & analytics, managed service providers (MSPs), FinTech, Healthtech and others, need to show their SOC 2 certifications in order to be able to handle customer data from other organizations (the data owners).
Are There Penalties for Not Having SOC 2?
SOC 2 has no direct penalties or fines for non-compliance. However, the indirect consequences can be significant as large enterprise clients often require a SOC 2 report from a vendor is they are handling their sensitive data. It provides a strong signal that an organization has strong internal controls for security, availability, processing integrity, confidentiality, and privacy.
What Is the SOC 2 Audit Process?
Organizations typically begin by scoping the audit and preparing their controls, followed by an independent CPA firm reviewing documentation, testing procedures, and validating evidence. The result is a formal SOC 2 report that customers and partners use to assess the organization’s security maturity and risk posture. Key steps in the SOC 2 audit process include:
- Define scope, systems, and applicable Trust Services Criteria.
- Perform a readiness assessment and remediate control gaps.
- Implement and document security, operational, and governance controls.
- Engage an independent CPA firm to conduct the audit.
- Provide evidence and undergo control testing (over time for Type II).
- Receive the final SOC 2 report with the auditor’s opinion.
How Encryption, IAM, and AI Security Controls Support SOC 2 Privacy
Thales cybersecurity solutions help organizations implement and demonstrate the technical and organizational controls required by the SOC 2 Trust Services Criteria for Privacy, particularly where sensitive, personal, or regulated data is processed across cloud, hybrid, and AI environments.
Data protection and minimization
Thales data security products enable encryption, tokenization, and masking of personal data at rest, in use, and in motion. These controls support SOC 2 privacy requirements around data minimization, confidentiality, and restricted use of personal information by reducing exposure even when systems are compromised or accessed by authorized users. Thales also supports the requirements for disposal of personal information when required by law.
Access control and purpose limitation
Thales identity and access management solutions enforce a Zero Trust Architecture with strong Multi-Factor Authentication (MFA), role-based access, and least-privilege policies. This aligns with SOC 2 expectations that personal data is accessed only by authorized individuals and only for defined, legitimate purposes, a core principle of privacy protection.
Key ownership and cryptographic control
With customer-managed keys, Hardware Security Modules (HSMs), and Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK) models, Thales allows organizations to retain control over encryption keys used to protect personal data. This supports SOC 2 privacy criteria related to data custody, third-party risk, and transparency—especially important in cloud and AI scenarios where data may otherwise be exposed to providers or model operators.
Monitoring, auditability, and incident response
Thales data security posture management solution provide centralized logging, monitoring, and policy enforcement that help organizations demonstrate continuous oversight of personal data usage. Thales application security solutions monitor for threats, uncover vulnerabilities, and stop attacks that can lead to sensitive data disclosures. These capabilities support SOC 2 requirements for audit trails, detection of unauthorized access, and timely incident response related to privacy events.
Privacy in AI and advanced analytics
AI apps and agents are being deployed across organizations with access to sensitive data, often without adequate security - introducing new risks. Thales AI cybersecurity solutions help enforce privacy controls by identifying sensitive data before ingestion into AI systems, and protecting it with encryption, access controls, and runtime protection, reducing the risk of data leakage, secondary use, or model exposure. This directly supports SOC 2 privacy expectations in emerging AI use cases where traditional controls often fall short.
Other key data protection and security regulations
PCI HSM
MANDATE | ACTIVE NOW
The PCI HSM specification defines a set of logical and physical security compliance standards for HSMs specifically for the payments industry. PCI HSM Compliance certification depends on meeting those standards.
DORA
REGULATION | ACTIVE NOW
DORA aims to strengthen the IT security of financial entities to make sure the financial sector in Europe is resilient in the face of the growing volume and severity of cyber-attacks.
Data Breach Notification Laws
REGULATION | ACTIVE NOW
Data breach notification requirements following loss of personal information have been enacted by nations around the globe. They vary by jurisdiction but almost universally include a “safe harbor” clause.
GLBA
REGULATION | ACTIVE NOW
The Gramm-Leach-Bliley Act (GLBA)--also known as the Financial Services Modernization Act of 1999--requires financial institutions to explain their information-sharing practices to their customers and to safeguard sensitive data.