SOC 2 Compliance Requirements: A Guide to Passing Your Audit

SOC 2 is a globally recognized security compliance framework used to demonstrate how your security controls and processes protect customer data.

But passing a SOC 2 audit and getting an unqualified (AKA,"perfect") report is easier said than done. Prepping for SOC 2 can be extremely time-consuming and costly, especially if it requires pulling your engineers and key staff members away from their day-to-day responsibilities to prepare and gather evidence.

In this guide, we’ll give you the scoop on SOC 2, what criteria you’ll need to prepare, and how to get started.

If you need a helping hand, At Workstreet we cover every aspect of SOC 2 readiness to audit management to continuous compliance and we’re a trusted partner to thousands of high-growth companies.

What is SOC 2?

Developed by the American Institute of CPAs (AICPA), SOC 2 is a security audit framework that validates how a service organization (like a SaaS company) manages sensitive data. A SOC 2 report is used to show customers and prospects that an organization has the required security controls in place — and validate that they work as described.

To get a SOC 2 report, an organization needs to pass a third-party audit covering their IT systems and security posture. The report validates that what an organization says is happening with their security posture, is actually happening.

The core of SOC 2 is based on the Trust Services Criteria (TCS). During an audit, your security controls, practices and infrastructure will be assessed against these criteria. (More on the TCS below.)

There are two types of SOC 2 report, Type 1 and Type 2:

• A SOC 2 Type 1 is a snapshot that evaluates your cybersecurity controls at a single point in time.
• A SOC 2 Type 2 report is much more in depth and assesses how your controls perform over a period of time (usually 3-12 months).

What Are the SOC 2 Compliance Requirements?

Unlike frameworks like NIST or CMMC, SOC 2 isn’t a standard list of controls you must implement in order to pass an audit. This also means there’s no specific SOC 2 requirement checklist you can simply work through and tick off.

The AICPA Trust Services Criteria instead offers guidelines and “points of focus” to help companies figure out what controls need to be in place. For example, SOC-2 Controls CC1.1. States: “Your organisation’s standards of conduct convey and define the expectations of the board of directors and senior management regarding integrity and ethical values. This should be understood throughout the organisation, as well as by service providers and business partners.

You can satisfy this requirement by implementing a code of conduct within your organisation. But because SOC 2 isn’t one-size-fits-all audit readiness can look different for different companies. ‍

The Trust Services Criteria and What Should Be in a SOC 2 Compliance Checklist?

The Trust Services Criteria are at the core of SOC 2 and the criteria your auditor will assess your controls, practices and infrastructure against. The five TSC are:

• Security
• Privacy
• Confidentiality
• Processing Integrity
• Availability
  

Security criteria (sometimes called the common criteria) are required in all SOC 2 reports. Which of the other four criteria are in scope for your CMMC audit will depend on your organization and the services/products you offer.

Because not all controls are mandatory, it’s hard to give a blanket SOC 2 checklist because what should be in a SOC 2 report is individual to your organization.

Here’s what you need to know about each of the TSC:

1. Security

Security the non-negotiable foundation of SOC 2. The Security TSC covers the protection of your systems and data against unauthorized access (requiring both logical and physical access controls:), unauthorized use, or modification.

Some example security criteria include:

• CC2.3 requires that your organisation communicates with external parties regarding issues impacting the operation of internal control.
• CC5.3 requires your organization to deploy control activities through policies that establish what is expected and in procedures that put policies into action.

Other security criteria include risk assessment, risk management, change management, and vulnerability scans.

2. Availability

Did you promise your customers 99.99% uptime in your Service Level Agreement (SLA)? This requirement validates that you have the controls to meet that promise. It's all about system resilience, performance monitoring, and disaster recovery.

Some example availability criteria include:

• A1.1 requires your organization to maintain, monitor, and evaluate current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
• A1.3 requires your organization to test recovery plan procedures supporting system recovery to meet its objectives.

3. Confidentiality

This requirement covers data that is not Personal Identifiable Information (PII) but is still sensitive and must be protected. Think of trade secrets, intellectual property, internal M&A plans, or your customers' sensitive business data. This requirement proves you can protect that data as agreed upon in an NDA or contract.

Some example availability criteria include:

• C1.1 requires your organization to identify and maintain confidential information to meet the entity’s objectives related to confidentiality.
• C1.2 requires you to dispose of confidential information to meet the entity’s objectives related to confidentiality.

4. Processing Integrity

Does your system do what you say it does, completely, validly, accurately, and on time? If you run a payroll, fintech, or complex data analytics app, this is non-negotiable. It proves you're not accidentally changing dollar amounts or corrupting calculations.

Some example availability criteria include:

• PI1.2 requires your organization to implement policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity’s objectives.
• PI1.4 requires your organization to implement policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity’s objectives.

5. Privacy

This is the one that causes the most confusion. Privacy is distinct from Confidentiality. It specifically covers how you collect, use, retain, disclose, and dispose of PII- names, email addresses, phone numbers, government IDs, etc. This often maps directly to frameworks like GDPR and CCPA.

Some example availability criteria include:

• P1.1 requires your organization to provide notice to data subjects about its privacy practices to meet the entity’s objectives related to privacy.
• P2.1 requires your organization to communicate choices available regarding the collection, use, retention, disclosure, and disposal of personal information to the data subjects and the consequences, if any, of each choice.

What is a SOC 2 Readiness Assessment?

Before you head into your SOC 2 audit, you should conduct a readiness assessment. This is a pre-audit practice exam, often performed by an experienced auditor.  

Once you’ve reviewed the TSC and determined which criteria apply to your organization and documented your controls, an auditor will review the policies, controls, and infrastructure you have in place to assess how it’d fare in a real SOC 2 audit.

After your readiness assessment you’ll have a list of to-dos and fixes to implement before you head into your real audit.

What Type of SOC 2 Report Do You Need?

As we mentioned briefly earlier on, there are two types of SOC 2 report: Type 1 and Type 2.

Type 1 assesses your controls at a single point in time to analyze the design of your security posture and to determine if you’ve put all of the needed controls in place to protect your customer’s sensitive data.

Type 2 assesses how your controls perform over time (often 3-12 months).

Both Type 1 and Type 2 reports require an audit from a qualified auditor or CPA. The major differences between the two are the time they take and the budget needed — due to the longer assessment period, Type 2 reports are much costlier. However, Type 2 is the standard most organizations should be aiming for.

Type 1 can work if you’re a fast-growing startup that needs to quickly demonstrate your security controls are in place to unblock sales and close enterprise deals. But it’s often a short-term fix. If you can, going straight for Type 2 is often the best play.

Final thoughts

Understanding the SOC 2 compliance requirements is a critical step in the process towards achieving SOC 2, without understanding which of the TSC your organization will be audited against, you don’t know what controls and practices you’ll need in place.

But SOC 2 is about more than an audit. Too many businesses just “check the box” rather than looking at SOC 2 as a marketable asset that helps your business to unlock growth. The goal is a durable security program that earns an unqualified (i.e., "perfect") report every single year. That's what unblocks enterprise deals, shortens sales cycles, and builds lasting trust.

Working with Workstreet's SOC 2 compliance service, you can achieve SOC 2 compliance faster than ever. Our expert implementation services get you audit-ready quickly. From Type I to Type II, we'll guide you through every step of the process with proven methodologies, helping you map your controls, close your gaps, and get audit-ready in a fraction of the time.

Don't let your team spend 1,000 hours in spreadsheets. If you're ready to get this done right, see how Workstreet's expert SOC 2 implementation services can help you move from "requirements" to "audit-ready" faster than you thought possible.