SOC 2: The Basics

What is SOC 2?

Technically, a SOC 2 isn't a "certification." It's an attestation report based on the American Institute of Chartered Public Accountant's (AICPA) Trust Services Criteria (TSC). Basically, a service provider claims they have specific controls for things like security, availability, and privacy.

Then, an independent CPA firm comes in to audit those claims and issue a report saying whether or not they agree.

SOC 1 vs. SOC 2

The distinction is really about the data’s impact.

SOC 1

Is for vendors that handle things affecting a client's financial statements, e.g. payroll or claims processing.

SOC 2

Is about the security of the technology itself—how data is handled and hosted in the cloud or a data center.

Who gets audited?

Any tech or service organization handling customer data should be looking at SOC 2. It’s a voluntary standard, but most enterprise customers won't sign a contract without seeing a report.

Deployment Models:
Where the Security Actually Sits

Multi-tenant SaaS (The Gold Standard)

If your vendor runs a true multi-tenant SaaS, a SOC 2 is a very good sign. In this model, the vendor takes on the "end-to-end responsibility" for the whole stack. Every customer is on the same audited hosting infrastructure and uses the same code base. When an auditor looks at their access management or incident response, they’re looking at exactly what you’ll be using.

It’s the most transparent way to buy software because there are no variables or "one-off" customizations for the vendor to hide behind.

The On-Premise Reality Check

If you’re running a vendor's software on your own local servers (on-prem), their SOC 2 is honestly pretty limited.

It tells you they build and support their code securely, but it says nothing about how that software is actually running in your environment. You are 100% responsible for the "last mile"—server hardening, OS patching, and network security.

A vendor can have a SOC 2 badge, but if your internal team misconfigures the server, the system is still insecure.

If you’re running a vendor's software on your own local servers (on-prem), their SOC 2 is honestly pretty limited.

A vendor can have a SOC 2 badge, but if your internal team misconfigures the server, the system is still insecure.

Single-Tenant / Dedicated Cloud

This is where it gets tricky. In a dedicated cloud setup (where you have your own software instance), the scope of the SOC 2 is everything: Most vendors have a report that covers their baseline infrastructure, but it might not extend to your specific tenant’s settings or customizations.

Unlike multi-tenant SaaS, these "one-off" environments introduce gaps, in particular if your system has significant customizations that are not covered by any cyber-security patches of your vendor, let alone that an auditor might not have even looked at.

Don't assume their badge covers your specific deployment. AI-powered hackers have been particularly skilled at identifying, targeting and exploiting these security vulnerabilities in heavily customized on single tenant systems.

Contact Us

Type I vs. Type II

Type I

This is a "snapshot." It proves the controls were designed correctly on the day the auditor showed up.

Type II

This is the one you actually want. It tests the operating effectiveness of those controls over a window (usually 6 to 12 months).

The Bottom Line: A Type I shows they have a plan; a Type II proves they actually follow it when no one is watching. If you're reviewing a vendor, always push for the Type II.