What is SOC 2? Criteria, reports, and types explained

SOC 2 is one of the most requested documents in enterprise software. At its core it is an independent auditor's opinion on how well a company protects the data its customers hand over.

Most guides explain it from one seat: the company trying to earn the report. But buyers deciding whether to trust a vendor might miss the line between what the report proves and what it quietly leaves out. This guide serves to clarify exactly what SOC 2 requires and what being compliant with it really proves.

What SOC 2 is really about

SOC 2, short for System and Organization Controls 2, lets service companies show how they protect customer data. An independent auditor checks their controls against a set of criteria from the AICPA and issues a report.

The AICPA introduced SOC reports in 2011 under its attestation rules. The version most people refer to took shape in a 2017 update that organized it around five trust service categories, refreshed in 2022.

SOC 2 is an attestation, not a certification, and the difference matters. A CPA firm gives its opinion on the controls that a company chose to be tested, and not necessarily against a fixed bar that every company clears. Two reports can therefore describe very different security postures.

So the report rewards reading, not filing. The scope, the criteria included, and any exceptions the auditor noted tell you more than the fact that a report exists.

The five trust services criteria

A SOC 2 report does not cover one fixed set of checks. Its scope comes from the trust services criteria, five categories a company picks based on what it promises customers.

Security is the only category every report includes. It carries the Common Criteria, numbered CC1 to CC9, which cover the bones of a security program. The other four are chosen, and that choice is itself reveals a lot.

When a vendor includes Availability or Confidentiality, they are inviting an auditor to test a promise they made to you. Leaving one out usually means no such promise exists, so the categories in scope tell you what the vendor takes responsibility for.

Availability is the one buyers feel most directly. It measures whether systems stay up and reachable, judged against the vendor's own uptime commitments.

The catch is that it assumes the vendor is still there to meet them. A controls audit cannot test for a company that no longer exists, which is the first hint of where SOC 2's assurance runs out.

SOC 2 Type 1 vs Type 2

Once you know which criteria a report covers, check which type you are holding. The difference is time, and it changes how much the report is worth.

• A Type 1 report is a snapshot. It confirms the controls were designed properly on one specific day, which a company can arrange shortly before the auditor arrives. It proves intent more than habit.

• A Type 2 report is the harder test. It tracks whether those controls held up across six to twelve months of normal operations, including the messy days.

That is why enterprise buyers treat it as the real standard, and often read a Type 1 as a promise the full report is coming.

Both types describe the past. A report covers a window that has already closed, so a clean report from last year says nothing about last week. Most audits cost between $12,000 and $100,000, and a first Type 2 costs more because the clock must run before testing can start.

SOC 1 vs SOC 2 vs SOC 3

SOC 2 sits in a small family of reports whose names get mixed up often enough to stall a security review.

1. SOC 1 covers controls that affect a client's financial reporting, so it matters for payroll or billing providers but says nothing about data security.

2. SOC 2 covers the trust services criteria above, and is the report a security or procurement team almost always means.

3. SOC 3 reports on the same criteria as SOC 2, but as a public summary without the detail, which makes it a website badge rather than review material.

So when someone asks for "their SOC report," the one that matters is a SOC 2 Type 2. A SOC 1 answers a different question, and a SOC 3 only signals that a SOC 2 exists behind it.

»  If you're weighing SOC 2 against ISO 27001 for your data security, I recommend checking out this comparison.

Who needs SOC 2, and who's asking for it

SOC 2 was built for service companies that hold other people's data, but who needs one is set by who is asking for it. It applies most to SaaS and cloud platforms, data centers and hosting providers, payment processors and fintech, healthcare technology vendors, and managed service providers.

No law requires SOC 2. The market made it mandatory anyway. A large buyer cannot send auditors into every supplier, so it leans on an independent report instead, a shortcut for trust that procurement accepts at scale.

For a vendor, that turns the report from a cost into a gate. Without it, you are dropped before anyone looks at your product. The report has become the price of competing.

What a SOC 2 report proves, and what it doesn't

The buyer's side of the table needs to be wary, because a report is precise about some things and silent about others.

A SOC 2 report proves that a vendor's controls were designed properly and, in a Type 2, that they operated across the audit window. That is real assurance about how your data is handled while the relationship holds.

What it does not do is tell you the vendor will stay in business. It does not promise you will keep access to their software if they fail. And it says nothing about whether you could recover on your own.

This is not a gap the auditor forgot to fill. An audit measures controls, and a company's survival is not a control. No amount of well-run security stops a vendor from running out of money, getting acquired, or shutting a product down.

So if you hold that report, you hold proof of good housekeeping, not a guarantee of continuity. Those are two separate questions, and the second stays open no matter how clean the report is.

SOC 2 and vendor management

SOC 2 has a feature that surprises teams pursuing it for the first time. The moment you commit to the report, your own suppliers come into its scope.

One of the common criteria, CC9.2, states plainly that "the entity assesses and manages risks associated with vendors and business partners." SOC 2 vendor management means doing that for every supplier that touches your systems or data:

• an inventory of who you depend on

• due diligence before you sign

• monitoring through the relationship

• clean offboarding when it ends

Most teams satisfy this with a security questionnaire, which is where the obligation gets misread. CC9.2 asks you to manage vendor risk, and the largest risk a questionnaire never captures is dependency. A vendor with flawless security can still be one you cannot replace if they vanish.

Auditors have started pressing on this. They want evidence of two things: that a critical vendor is secure, and that you have a documented answer for the day it is gone. Being safe today is not the same as operating tomorrow.

How software escrow supports SOC 2 continuity

That gap between safe-today and available-tomorrow is where software escrow earns its place. It is a documented way to show a buyer can recover if a critical vendor fails, which speaks to both the Availability criterion and the CC9.2 obligation.

The mechanics are simpler than they sound: a neutral third party holds the vendor's source code, data, and documentation, and an escrow agreement spells out the conditions that release it. It runs in five steps:

1. The vendor deposits source code, data, and documentation.

2. An escrow agreement defines the trigger conditions, such as insolvency or discontinued support.

3. The deposit is verified to confirm it is complete and buildable.

4. A trigger event occurs.

5. The materials are released to the buyer.

Step three is the one people overlook. A deposit only helps if it has been tested and can be rebuilt, and a verified deposit is the recovery evidence an auditor wants when checking continuity claims. For cloud-hosted tools, the same logic extends to SaaS escrow.

Escrow does not replace any SOC 2 criterion. It answers the continuity question the report leaves open.

How to get SOC 2 set up

If you are the company that needs to produce a SOC 2 report, the path is well worn:

1. Scope your systems and pick which criteria apply. Choose conservatively, since every extra category adds testing and exposure. 

2. Run a gap analysis to find where your controls fall short of the criteria.

3. Put the missing controls in place and collect evidence, the part that eats the most time.

4. Engage a licensed CPA firm, since only a CPA can issue it.

5. Sit through the audit, and for a Type 2, the observation period before it.

6. Maintain it, because the report expires and evidence has to keep flowing.

SOC 2 is not an exam you sit once and pass, though. The controls have to keep running and the evidence has to keep flowing. Teams that treat the report as a finish line find themselves starting from scratch twelve months later.

The question the report was never built to answer

A SOC 2 report is a strong signal that a vendor takes data security seriously. It tells you their controls were designed properly, tested over time, and working as intended across the audit window. For most buyers, that is exactly what they needed to know before signing.

What it cannot tell you is whether that vendor will still be around to honour those controls. It says nothing about financial stability, business continuity, or what happens to your access if the relationship ends. That is not a flaw in the framework — it was never designed to answer those questions.

That is why SOC 2 and software escrow tend to work well together. The report covers how a vendor handles your data today. Escrow covers what happens to your access if they are gone tomorrow. Neither replaces the other, and together they close most of the picture.

»  If you want to close that gap, see how Codekeeper supports SOC 2 readiness.