What Is SOC 2? Type 1 vs Type 2, Explained

If you have ever been asked "can you send us your SOC 2?" and were not sure what that meant, this guide is the answer. What is SOC 2? It is an independent assurance report, produced by a licensed CPA firm, that describes the controls a service organization has in place to protect customer data and confirms whether those controls actually work. It is not a law, not a certificate you frame on the wall, and not something any software vendor can issue for you. This page is written for compliance managers, CISOs, and founders who sell software or services to other businesses and need to understand what a SOC 2 involves before they commit budget and calendar time to it.

What SOC 2 actually is

SOC 2 stands for System and Organization Controls 2. It is a reporting framework defined by the American Institute of Certified Public Accountants (AICPA). A SOC 2 engagement is an attestation: an independent auditor examines your organization against a defined set of criteria, tests your evidence, and issues a formal opinion. The result is a detailed report, not a pass or fail badge. Customers and their procurement or security teams read that report to decide whether they trust you with their data.

The criteria the auditor measures you against are the AICPA Trust Services Criteria. There are five of them: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory and is often called the common criteria, because it forms the backbone that every SOC 2 report shares. The other four are optional and you include them only where they are relevant to the promises you make to customers. A SaaS company that guarantees uptime will usually add Availability; a payroll processor may add Processing Integrity and Confidentiality; a health or consumer-data platform often adds Privacy.

One point worth stressing early, because it is the most common misconception: SOC 2 is an attestation report signed by a CPA firm, not a certification issued by a standards body. There is no central registry, no certificate number, and no accreditation logo that means anything on its own. When someone says they are "SOC 2 certified," what they actually have is a SOC 2 report with an auditor's opinion. The distinction matters when you are reading a vendor's claims or writing your own.

Who needs SOC 2, and who does not

SOC 2 is buyer-driven, not regulator-driven. No government requires it. Instead, your customers require it, usually as a condition of signing or renewing a contract. That single fact should shape how you think about scope, timing, and cost. You pursue a SOC 2 because a deal depends on it, or because you can see that deals will soon depend on it.

Organizations that typically need one

• US-facing SaaS and B2B software vendors that store, process, or transmit customer data.
• Cloud and infrastructure providers, data platforms, and API companies whose customers ask about security posture during procurement.
• Managed service providers, fintech and healthtech vendors, and any company that handles sensitive information on behalf of a client.
• Startups moving upmarket, where the first enterprise or regulated customer makes a SOC 2 report a hard gate in the security review.

Organizations that usually do not

• Companies with no B2B customers asking for it, where the cost buys no revenue and answers no real question.
• Businesses whose customers are satisfied by a different framework. A European buyer may prefer ISO 27001; a healthcare buyer in the US may care more about HIPAA; a payments business will focus on PCI DSS.
• Very early-stage teams with no product in production and no customer data to protect yet.

SOC 2 also lives alongside other frameworks rather than replacing them. Many organizations maintain SOC 2 and ISO 27001 together, because the underlying controls overlap heavily and the two reports answer questions from different audiences. If a specific customer or region drives you toward one framework, start there and reuse the same evidence for the others.

What a SOC 2 requires of you

Because SOC 2 is criteria-based rather than a fixed checklist, there is no single mandatory list of controls that applies identically to every company. Instead, the Trust Services Criteria describe the outcomes your controls must achieve, and you design controls that fit your own systems, size, and risk. The auditor then judges whether those controls are suitably designed and, in a Type 2, whether they operated effectively over time.

In practice, the Security common criteria cover a familiar set of governance and technical areas. You are expected to demonstrate meaningful control over most of the following:

• Governance and risk. Documented policies, defined roles and responsibilities, a risk assessment process, and management oversight.
• Access control. Unique user accounts, least-privilege access, multi-factor authentication, and periodic access reviews with evidence that they happened.
• Change management. A controlled path from code change to production, with review, testing, and approval that you can show for real changes.
• Operations and monitoring. Logging, alerting, vulnerability management, and the ability to detect and respond to anomalies.
• Incident response. A documented process for handling security incidents, including detection, escalation, and remediation.
• Vendor and third-party management. Due diligence on the subprocessors and suppliers who touch your systems or data.
• Human resources security. Background checks where appropriate, onboarding and offboarding, and security awareness training.

The defining feature of SOC 2, and the part teams underestimate, is evidence. It is not enough to have a policy that says access is reviewed quarterly. In a Type 2 audit you must produce the actual review records for each quarter in the period, showing who reviewed what and when. A SOC 2 is really a test of whether your controls run consistently and leave a reliable trail, not just whether they exist on paper.

Type 1 vs Type 2: the difference and which you need

The single most important choice in a SOC 2 engagement is Type 1 versus Type 2, and the distinction is simpler than it sounds. A Type 1 report assesses the design of your controls at a single point in time. The auditor asks: are the right controls in place today, and are they suitably designed to meet the criteria? It is a snapshot.

A Type 2 report assesses the operating effectiveness of those same controls over a period, commonly three to twelve months. The auditor asks a harder question: did these controls actually work, consistently, throughout the review window? To answer it, the auditor samples evidence from across the whole period, not just from the day of the assessment. A Type 2 is a video, not a snapshot.

Type 2 is what most customers eventually want, because it demonstrates that your security is a durable operating reality rather than a one-day arrangement. A common and sensible path is to start with a Type 1 to prove the design is sound, then run the observation window and produce a Type 2. Some organizations skip the Type 1 entirely and go straight to a Type 2 once their controls are stable. The right choice depends on how quickly a customer needs proof: a Type 1 can be produced sooner, while a Type 2 requires you to operate the controls for the full period first. Bear in mind that a SOC 2 report has a defined coverage window, so most companies renew annually to keep continuous coverage for customers.

How to actually get a SOC 2: a practical program

1. Decide why and when. Confirm which customer or deal is driving the requirement, and whether they need a Type 1 quickly or a Type 2 in full. Let that set your timeline.
2. Set the scope. Choose which Trust Services Criteria apply. Start with mandatory Security and add Availability, Processing Integrity, Confidentiality, or Privacy only where they reflect real customer commitments. Define which systems and services are in scope.
3. Run a readiness assessment. Map your current controls against the criteria and find the gaps. This is where you learn how far you actually are from audit-ready.
4. Remediate the gaps. Write the missing policies, turn on the missing technical controls, and fix broken processes. Make each control something that produces evidence automatically wherever you can.
5. Operate and collect evidence. For a Type 2, run the controls through the full observation window while capturing the records: access reviews, change approvals, incident tickets, training logs, monitoring alerts.
6. Select an independent CPA firm. Only a licensed CPA firm can perform the SOC 2 examination and issue the report. Choose your auditor early so their expectations shape your evidence.
7. Complete the audit. The auditor tests your design and, for a Type 2, samples evidence across the period, then issues the report with their opinion.
8. Maintain and renew. Keep the controls running, refresh evidence continuously, and plan the next report so your coverage does not lapse.

If you want to see how the controls, evidence collection, and audit preparation come together in one place, read how Venvera handles SOC 2, and for a broader market view see our roundup of SOC 2 compliance software compared.

Frequently Asked Questions

Is SOC 2 a certification?

No. SOC 2 is an attestation report issued by a licensed CPA firm, not a certification from a standards body. There is no certificate number or central registry. When a vendor says they are "SOC 2 certified," what they hold is a SOC 2 report containing an independent auditor's opinion.

What is the difference between Type 1 and Type 2?

A Type 1 report evaluates whether your controls are suitably designed at a single point in time. A Type 2 report evaluates whether those controls operated effectively over a period, commonly three to twelve months, using evidence sampled across the whole window. Type 2 is the report most customers ultimately want.

How many Trust Services Criteria are there and which are required?

There are five: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, the common criteria, is mandatory in every SOC 2. The other four are optional, and you include only the ones that match the commitments you make to customers.

Do we legally have to be SOC 2 compliant?

No law requires SOC 2. It is buyer-driven: customers request it during procurement or as a contract condition. You pursue it because revenue depends on it, not because a regulator mandates it. If your customers are satisfied by ISO 27001, HIPAA, or another framework, that may serve you better.

Can Venvera or any software issue our SOC 2 report?

No. Only an independent, licensed CPA firm can perform the examination and issue the report. Compliance software helps you build controls, collect evidence, and prepare for the audit, but the opinion itself must come from the auditor. Be cautious of any tool that implies otherwise.

How long does it take to get a SOC 2?

A Type 1 can be produced relatively quickly once your controls are designed and in place. A Type 2 takes longer because you must operate the controls for the full observation period, commonly three to twelve months, before the auditor can test them. Readiness and remediation add time before either report begins.

Primary sources

• AICPA Trust Services Criteria - the definitive criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy that a SOC 2 is measured against. Trust Services Criteria.
• AICPA SOC 2 overview - the AICPA's own explanation of SOC 2 reports, their purpose, and how they are used. SOC 2 for service organizations.

Scope note. This guide summarizes how SOC 2 works in general terms. The precise criteria, scope, and control expectations for your organization should be confirmed against the current AICPA Trust Services Criteria and with your chosen CPA firm.

By Alexander Sverdlov, CEO and Founder, Venvera. Published 20 July 2026 - Last reviewed 20 July 2026.