What is SOC 2?

Software-as-a-Service (SaaS) providers that are SOC 2 compliant enjoy a competitive advantage over those that are not.

The SOC 2 security standard was developed by the American Institute of CPAs (AICPA), which governs and standardizes how organizations manage customer data. SOC 2 compliance is viewed through the lens of five Trust Services Criteria, including processing integrity, availability, security, confidentiality, and privacy.

SOC 2 can be customized by each organization per its business practices. Organizations may create two different types of reports that specify how data is managed which can be shared with regulators, suppliers, and other partners:

• Type I reporting documents the organization’s systems and confirms if the system design is compliant with relevant trust principles.
• Type II reporting documents the operational efficiency of each system.

The key difference between the SOC 2 standard and other compliance requirements like PCI DSS is that SOC 2 reports are unique and tailored to each organization. Each company can create its own set of controls that align and comply with relevant trust principles.

What Does SOC 2 Look Like in Action?

Outside auditors look at an organization’s systems and processes to see how compliant they are against one or more of the trust principles. Compliance with the principles may be summarized in the following ways:

1. Security – Are systems resources protected from people that shouldn’t have access? Compliance might include access controls that can reduce the possibility of system abuse, software misuse, or data getting into the wrong hands. Security tools may include multi-factor authentication (MFA), web application firewalls (WAFs), and intrusion detection.
2. Availability – Are services, systems, and products accessible and available in the ways outlined in agreements and contracts? While usability or functionality don’t fall under this umbrella, it does pertain to security-related issues that could impact availability. Tools and processes may include network performance and availability monitoring, security incident response, and site failover.
3. Processing integrity – Do processing systems do what they say they will do and deliver data completely, accurately, and quickly – and is that data transmission valid and authorized? It’s important to point out that processing integrity is not the same as data integrity. This means that data errors that exist before input into the system do not fall under the processor’s responsibility. Tools may include data processing monitoring along with thorough quality assurance procedures.
4. Confidentiality – Is data access and disclosure restricted to a specific set of people or organizations? Data includes intellectual property, internal documents, business plans, or sensitive financial information that is only intended for specific people. Encryption, firewalls, and strict access controls are the primary tools used to ensure data confidentiality for both stored and processed data.
5. Privacy – Does the organization follows its own privacy protocol and that of the AICPA’s generally accepted privacy principles (GAPP)? The privacy principle looks at how an organization collects, uses, stores, disseminates, and disposes of personally identifiable information (PII). Tools to ensure layers of protection with this data include controls to guard against unauthorized access.