What SOC 2 actually is and why most explanations get it wrong

SOC 2 is not a certification. Full stop.

No certificate gets issued. No accredited body grants you a credential. No badge exists for your website, despite what hundreds of SaaS trust pages would have you believe. SOC 2 is an attestation report where a licensed CPA firm expresses a professional opinion about your controls. That’s it. And getting this basic fact wrong tells every security-literate buyer that you don’t understand the framework you claim to follow.

I’ve written about why the attestation vs certification distinction matters legally in detail, but the short version is this: calling yourself “SOC 2 certified” is a misrepresentation. It frustrates me every time I see it on a vendor’s homepage, because it means they either don’t understand what they went through or they’re being deliberately misleading. Neither is great.

At Tallyfy, we maintain a current SOC 2 Type 2 report. The process of getting there taught me more about compliance than any vendor pitch ever could. Most of what’s written about SOC 2 online is either trying to sell you a compliance platform or is so generic it’s useless. Here’s what I wish someone had told me before we started.

SOC 2 is an attestation, not a certification

The AICPA, the body that created SOC 2, defines it as “a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy.” Notice the word “report.” Not certificate. Not credential. Report.

Here’s how it actually works. Your company hires a licensed CPA firm. That firm examines your controls against the Trust Service Criteria. They test whether your controls are designed properly and, for Type 2, whether they operated effectively over a period of time. Then they write a report expressing their professional opinion. The report goes to your customers who requested it.

Compare that to ISO 27001. With ISO 27001, an accredited certification body audits your information security management system and issues an actual certificate. There are specific accreditation bodies that authorize certifiers. There’s a formal certificate document. SOC 2 has none of that infrastructure. Only licensed CPA firms can perform the examination, and the output is an opinion letter, not a credential.

This matters practically in two ways. First, when your prospect’s security team asks for your “SOC 2 certification,” they’re actually asking for your SOC 2 report. Second, when vendors put “SOC 2 Certified” on their trust page, they’re telling informed buyers they don’t understand the framework. It’s like calling yourself “audit certified” because someone reviewed your finances.

The distinction also matters for Type 1 vs Type 2 reports. Type 1 is the auditor’s opinion about your controls at a single point in time. Type 2 covers an observation period, typically three to twelve months, where the auditor tests whether controls actually worked consistently. Most enterprise buyers require Type 2 because it proves sustained operation, not just good intentions on paper.

The five trust service criteria explained simply

The Trust Service Criteria are the measuring stick. They define what your auditor evaluates. The AICPA established five categories, and only one is mandatory.

SOC 2 Trust Service Criteria hierarchy - Security is required, other criteria are optional

Security is required for every SOC 2 examination. It covers protection of systems and data against unauthorized access. Think access controls, network firewalls, intrusion detection, encryption. Security is also called the “Common Criteria” because many security criteria overlap with the other four categories. You can’t opt out of this one.

Availability addresses whether your systems are accessible and operational when customers need them. This means uptime monitoring, disaster recovery, incident response, capacity planning. If your service has an SLA promising 99.9% uptime, availability criteria test whether you have controls to actually deliver on that promise.

Processing Integrity covers whether your system processes data completely, accurately, and on time. This matters if you’re handling financial calculations, data transformations, or any processing where errors affect your customer’s business. A payroll SaaS needs this. A marketing blog tool probably doesn’t.

Confidentiality protects information designated as confidential. Different from security because it specifically addresses data classified as confidential by your organization or your customers. Encryption, access restrictions, secure disposal. It’s the “who can see what” question applied to sensitive categories.

Privacy governs personal information collection, use, retention, disclosure, and disposal. If you handle consumer personal data, this one matters. It aligns with broader privacy regulations and addresses how you manage the lifecycle of personal information.

You choose which criteria apply. Most SaaS companies start with Security alone, sometimes adding Availability. The scoping decision should reflect what your customers actually care about and what your service actually does. Don’t add criteria just to look thorough. Each one you include means more controls to maintain and more evidence to collect.

What the audit actually tests

Here’s where most explanations fall apart. They describe SOC 2 as a checklist. It isn’t. Your auditor isn’t running through a fixed list of requirements and checking boxes. They’re evaluating whether your controls are designed well and whether they operated effectively.

The word “controls” trips people up. A control is simply a process, policy, or mechanism that reduces risk. Your company defines its own controls based on the Trust Service Criteria you selected. The auditor then tests those controls.

For example, you might have a control that says: “All production code changes require peer review before deployment.” The auditor doesn’t just verify this policy exists. For Type 2, they sample actual code changes from your observation period and check whether peer reviews actually happened. If you deployed 200 changes and 15 skipped review, that’s a finding.

The audit tests design and operating effectiveness. Design means: is this control reasonably capable of achieving its objective? Operating effectiveness means: did it actually work when it was supposed to? A beautifully written access review policy that nobody follows is a design win and an operating failure.

This is fundamentally different from a checklist approach. There’s no universal list of “SOC 2 requirements.” Two companies in the same industry can have completely different control sets and both receive clean reports, because their systems, risks, and operational approaches differ. The auditor evaluates whether YOUR controls address the criteria appropriately for YOUR environment.

Common control categories include access management, change management, incident response, risk assessment, vendor management, data backup, encryption, monitoring, and employee onboarding and offboarding. But the specific implementation is yours to define. If you want to discuss how to structure this for your company, the details depend entirely on what you actually do and how you operate.

One thing that surprised me during our first audit: the auditor spent very little time reading our policies. They spent most of their time sampling evidence. They pulled specific code deployments and checked for peer review. They looked at specific access provisioning events and verified the approval process. They reviewed specific incident tickets and checked response times against our stated procedures. The policies set the standard. The evidence proved whether we met it.

Why most companies overcomplicate this

The compliance platform industry has a financial incentive to make SOC 2 feel overwhelming. More complexity means more perceived need for their product. But the actual requirements are more straightforward than the marketing suggests.

I’ve written about how we replaced our compliance platform with AI and Google Drive at Tallyfy. The core insight was embarrassingly simple: the platform was doing what a well-organized folder structure and some scripts could handle. The only cheque with legal weight goes to the CPA firm performing the actual examination. Everything else is organization.

Companies overcomplicate SOC 2 in predictable ways.

Buying a platform before understanding the framework. Compliance automation tools charge thousands annually. Some companies sign up before they even know which Trust Service Criteria they need. Start by understanding what you’re doing and why. Then decide if software helps.

Adding unnecessary Trust Service Criteria. Every additional criterion means more controls, more evidence collection, more auditor time, and higher fees. If your customers only ask about security and availability, don’t add processing integrity because it sounds impressive. Scope to what matters.

Writing policies nobody follows. A 40-page information security policy downloaded from a template means nothing if your actual practices differ. Auditors test operating effectiveness. Write policies that describe what you actually do. Short policies that reflect reality beat long policies that describe fiction.

Treating the audit as annual panic rather than ongoing process. Companies that ignore compliance for 10 months and then scramble for two months before the audit spend more time, produce worse evidence, and create more stress. Continuous maintenance costs less total effort than periodic crisis mode.

Confusing the platform with the audit. No compliance platform performs your SOC 2 examination. They help you organize for it. That distinction matters because companies sometimes believe buying a platform means they’re “compliant.” They’re not. They just have better-organized folders.

There’s also a knowledge problem. Most founders encounter SOC 2 for the first time when a potential customer’s security questionnaire lands in their inbox. The natural reaction is to Google “SOC 2 compliance” and get buried in vendor marketing. The compliance platforms show up first in search results because they spend heavily on content marketing. So the first thing most founders learn about SOC 2 comes from companies trying to sell them something. That shapes how they think about the entire process.

The real cost of SOC 2 is the CPA firm’s fee plus the internal time to maintain controls and collect evidence. Everything else is optional tooling. Some companies genuinely benefit from compliance platforms, especially at scale. But most early-stage SaaS companies can handle this with simpler tools.

What this looks like in practice

Our compliance repository structure

At Tallyfy, our SOC 2 compliance system tracks 67 controls, 123 evidence items, and 42 risks. All in structured YAML files, version controlled in a Git repository. Here’s a scrubbed example of what a control definition looks like:

- id: backup-schedule
  name: Backup Schedule
  description: Data is backed up following a set schedule...
  frequency: Weekly
  owner: [redacted]
  status: In Place
  soc2_criteria:
  - CC.7.5
  - A.1.2
  - PI.1.5

Real control definitions from our compliance repository

Each control maps directly to specific Trust Service Criteria codes. CC.7.5 is a Common Criteria control about system operations. A.1.2 relates to availability. PI.1.5 addresses processing integrity. The auditor can see exactly which criteria each control satisfies, and we can see exactly which controls support each criterion.

Evidence collection follows defined schedules. Some items need refreshing every 90 days because the underlying data changes quickly. Employee access lists fall into this category because people join, leave, and change roles. Other evidence refreshes annually because the source material itself updates on that cycle, like vendor SOC 2 reports.

The practical workflow looks like this. A script checks which evidence items are approaching their due dates. Someone collects the evidence: takes a screenshot of a configuration page, exports a user list, runs a security scan, reviews a policy document. The evidence gets stored with clear naming conventions and metadata. When audit time comes, the CPA firm gets access to an organized collection of evidence, mapped to controls, mapped to criteria.

Policies exist in three formats. Editable source files for internal updates. Markdown versions for AI-assisted review, which catches inconsistencies and outdated references faster than human review alone. PDF exports for the auditors.

Git handles the audit trail automatically. Every change to every control, policy, and evidence record is tracked with who changed it, when, and why. This is actually better than what most compliance platforms provide, because git’s history is immutable and complete. When an auditor asks “when was this policy last reviewed?” the answer is a git commit with a timestamp and a diff showing exactly what changed.

The whole system runs without a compliance platform. The CPA firm conducts the examination. We organize the evidence. The auditor writes the report. The only ongoing cost beyond internal time is the audit itself.

That said, this approach requires someone who understands both the framework and the tooling. It’s not for companies that want compliance handled entirely by a third party. It’s for teams that want to understand what they’re doing and maintain control over the process. For us, it works because compliance isn’t something we hand off. It’s part of how we operate.

SOC 2 doesn’t have to be the overwhelming, expensive, confusing process that the compliance industry wants you to believe it is. Understand that it’s an attestation, not a certification. Pick the right Trust Service Criteria. Design controls that reflect what you actually do. Collect evidence continuously. Hire a good CPA firm. That’s the whole thing.