Developed by the American Institute of CPAs (AICPA), SOC 2 defines criteria for managing customer data based on five “trust service principles”—security, availability, processing integrity, confidentiality, and privacy.
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 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.
SOC 2 Certification
SOC 2 certification is issued by outside auditors. They assess the extent to which a vendor complies with one or more of the five trust principles based on the systems and processes in place.
Trust principles are broken down as follows:
Security
The security principle refers to the protection of system resources against unauthorized access. Access controls help prevent potential system abuse, theft or unauthorized removal of data, misuse of the software, and improper alteration or disclosure of information.
IT security tools such as network and web application firewalls (WAFs), two-factor authentication and intrusion detection are useful in preventing security breaches that can lead to unauthorized access of systems and data.
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.
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.
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.
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).
Personally 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.
What is SOC 2 Compliance?
Service Organization Control (SOC) 2 is a set of compliance requirements and auditing processes targeted at third-party service providers. It was developed to help companies determine whether their business partners and vendors can securely manage data and protect the interests and privacy of their clients.
SOC 2 was developed by the American Institute of Certified Public Accountants (AICPA). Within its procedures, there are two types of SOC 2 reports:
SOC 2 Type 1 details the systems and controls you have in place for security compliance. Auditors check for proof and verify whether you meet the relevant trust principles. Think of it as a point-in-time verification of controls.
SOC 2 Type 2 assesses how effective your processes are in providing the desired level of data security and management over a period of time.
What are the Essential SOC 2 Compliance Requirements?
SOC 2 compliance is based on specific criteria for managing customer data correctly, which consists of five Trust Services Categories: security, availability, processing integrity, confidentiality, and privacy.
Security is the baseline for SOC 2 compliance, which consists of broad criteria that is common to all five trust service categories.
The security principle focuses on the protection of the assets and data of the service in scope for SOC 2 compliance against unauthorized use. You can implement access controls to prevent malicious attacks or unauthorized removal of data, misuse of company software, unsanctioned alterations, or disclosure of company information.
When it comes to security, the most basic SOC 2 compliance checklist (which will satisfy an auditor) is detailed in the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy Document, and should address these controls:
Logical and physical access controls—How you restrict and manage logical and physical access, to prevent any unauthorized access.
System operations—How you manage your system operations to detect and mitigate deviations from set procedures.
Change management—How you implement a controlled change management process and prevent unauthorized changes.
Risk mitigation—How you identify and develop risk mitigation activities when dealing with business disruptions and the use of any vendor services.
Some SOC 2 criteria are very broad and more policy-driven, whereas some are technical—but even the technical criteria won't tell you exactly what you need to do. As such, SOC 2 criteria are somewhat open to interpretation. It is up to each company to achieve the goal of each criterion by implementing various controls. The Trust Services Criteria document includes various “points of focus” to guide you.
For example, to meet the criteria for Logical and Physical Access Controls, one company may implement new onboarding processes, two-factor authentication, and systems to prevent the downloading of customer data when performing support, while another may restrict access to data centers, conduct quarterly reviews of permissions, and strictly audit what is done on production systems. No combination is perfect or even specifically required. What is required is to achieve the end state desired by the criteria.
When you address the aforementioned common criteria, you cover the security principles, which is the minimum requirement to become SOC 2 compliant.