Pursuing SOC 2 compliance can feel like cooking without a recipe.

Your ingredients are the controls your company puts in place. The final dish is a robust security posture and trusting customers.

But with no set compliance checklist — no recipe — how are you supposed to know what to prioritize?

This article will tell you everything you need to know about SOC 2 requirements.

What is a SOC 2 Report?

A SOC 2 report is a way to build trust with your customers. As a third-party service organization, you work directly with a lot of your clients’ most sensitive data. A SOC 2 report is evidence that you’ll handle that customer data responsibly.

To get a SOC 2 report, you have to undergo an audit by a third-party auditor. A SOC 2 auditor will be either a CPA or a firm certified by the American Institute of Certified Public Accountants (AICPA). They’ll evaluate your security posture to determine if your policies, processes, and controls comply with SOC 2 requirements. 

SOC 2 is just one type of SOC report. There are three total: SOC 1, SOC 2, and SOC 3.

SOC 1 is designed specifically for service organizations that provide financial reporting services.

SOC 2 is a standard for information security based on the Trust Services Criteria. It’s open to any service provider and is the one most commonly requested by potential customers.

SOC 3 is also based on the TSC but is less thorough, with results that can be shared publicly.

SOC 1 and SOC 2 come in two subcategories: Type I and Type II. A Type I SOC report focuses on the service organization’s data security control systems at a single moment in time.

A Type II SOC report takes longer and assesses controls over a period of time, typically between 3-12 months. The auditor runs experiments such as penetration tests to see how the service organization handles actual data security risks.

What are the AICPA Points of Focus?

In contrast to a rigid certification process like ISO 27001, there is no specific SOC 2 requirements checklist.

Instead, the AICPA Trust Services Criteria provide guidelines to structure each audit. They also offer “points of focus” to help companies implement controls.

These points of focus share examples of how an organization can satisfy requirements for each Trust Services Criteria. Here’s an example from the AICPA guide to the Trust Services Criteria:

The second point of focus listed discusses standards of conduct that are clearly defined and communicated across all levels of the business. Implementing a Code of Conduct policy is one example of how organizations can satisfy CC1.1’s requirements.

Still, every business will need to decide which controls they'll need to bring their systems into compliance with SOC 2 standards.

What Are the Requirements for SOC 2 Compliance?

Before you begin a formal SOC 2 audit, you’ll need to understand the details of the TSC since they're the basis for all SOC 2 requirements.

• Information security: How do you protect your data from unauthorized access and use?
• Logical and physical access controls: How does your company manage and restrict logical and physical access to prevent unauthorized use?
• System operations: How do you manage your system operations to detect and mitigate process deviations?
• Change management: How do you implement a controlled change management process and prevent unauthorized changes?
• Risk mitigation: How do you identify and mitigate risk for business disruptions and vendor services?

To meet the Logical and Physical Access Controls criteria, one company might establish new employee onboarding processes, implement multi-factor authentication, and install systems to prevent downloading customer data.

Another company might restrict physical access to data centers, conduct quarterly user access and permissions reviews, and monitor production systems.

Again, no specific combination of policies or processes is required. All that matters is the controls put in place fulfill that particular Trust Services Criteria.

The video below can help you better understand the steps involved in getting SOC 2 ready.

What are the Trust Services Criteria?

This section lays out the five Trust Services Criteria, along with some examples of controls an auditor might derive from each.

Security

All SOC 2 requirements are optional, except those that fall under Security.

This category covers defenses against all forms of attack. This covers everything from man-in-the-middle attacks to malicious individuals accessing your servers.

An auditor might check for two-factor authentication systems and web application firewalls. But they’ll also look at things that indirectly influence security, like policies determining who gets hired for security roles.

Privacy

Privacy applies to any information that’s considered sensitive because of its personal nature.

To meet the SOC 2 requirements for privacy, an organization must communicate its policies to anybody whose data they store.

If your organization collects any sensitive information, it must:

• Get consent from the subject
• Limit the amount of private information it collects as much as possible
• Gather it by lawful means
• Use it only for the purposes it was collected for
• Dispose of it at the end of a defined data retention period

SOC 2 requirements include:
-Communicate policies to affected parties: Do you have a process for obtaining consent to collect sensitive information? How do you communicate your policies to those whose personal data you store?
-Use clear language: Is the language used in your company’s privacy policy free of jargon and misleading language?
-Collect information from reliable sources: How do you ensure that your data collection processes are legal and your data sources are reliable?

Confidentiality

Confidential information is different from private information in that, to be useful, it must be shared with other parties.

The most common example is health data. It’s highly sensitive, but it’s worthless if you can’t share it between hospitals and specialists.

Instead of keeping the information totally secure, the confidentiality category focuses on exchanging it securely.

SOC 2 requirements include:
-Identify confidential information: Are processes in place to identify confidential information once it’s created or received? Are there policies to determine how long it should be retained?
-Destroy confidential information: How will confidential information be deleted at the end of the retention period?

Processing Integrity

Do the systems used to store, process, and retrieve information work the way they’re supposed to?

Processing integrity backs away from information security to ask whether you can trust a service organization in other areas of its work.

Some controls in the PI series refer to the organization’s ability to define what data it needs to achieve its goals. Others define processing integrity in terms of inputs and outputs.

For example, if a customer inputs an order on an e-commerce website, the output is prompt delivery of the product.

SOC 2 requirements include:
-Create and maintain records of system inputs and outputs: Do you have accurate records of system input activities? Are outputs only being distributed to their intended recipients?
-Detect and address errors: Is there a process to detect and correct errors as fast as possible?
-Define processing activities: Have you defined processing activities to ensure products or services meet their specifications?

Availability

The Availability controls in SOC 2 focus on minimizing downtime. Risk assessment is vitally important for this category.

With A1 series controls, companies need to:

• Predict system capacity
• Identify and mitigate environmental threats
• Identify data that needs to be backed up

SOC 2 requirements include:
-Minimizing downtime: Are the systems of the service organization backed up securely? Is there a recovery plan in case of a disaster? Is there a business continuity plan that can be applied to unforeseen events?
-Measuring current usage: Is there a baseline for capacity management? How can you mitigate impaired availability due to capacity constraints?
-Identifying environmental threats: What environmental hazards could impact system availability? E.g., Hurricanes, tornadoes, earthquakes, wildfires, power loss, etc.

What is a SOC 2 Readiness Assessment?

Most companies conduct a readiness assessment before seeking a SOC 2 audit. 

A SOC 2 readiness assessment is like taking a practice exam. You’ve reviewed the TSC, determined which criteria apply, and documented internal controls. The readiness assessment serves as a practice run, estimating how the audit would go if you completed it today.

A readiness assessment is conducted by an experienced auditor — almost always someone also certified to perform the SOC 2 audit itself. In the end, you’ll receive a letter explaining where you might fall short of being SOC 2 compliant. Use this letter to determine what you still need to do to meet SOC 2 requirements and fill any gaps.

If you follow the advice you get from your readiness assessment, you’re far more likely to get a favorable SOC 2 report.

Understanding SOC 2 Requirements

While the AICPA does provide helpful guidance in the form of the TSC points of focus, there is no clear-cut list of requirements. At first glance, that might seem frustrating. But the farther you get in the compliance process, the more you’ll begin to see this absence as a feature, not a bug.

If the SOC 2 requirements were too rigid, they might not make sense for your business. The Trust Services Criteria make SOC 2 a versatile, adaptable standard.

And there are resources, like our SOC 2 Kit, that can help you simplify compliance.