What Even Is a SOC 2? A Founder's Plain-English Guide to SOC 2 Reports

It usually shows up in the third or fourth call with a real customer. The champion loves the product, the pilot went well, and then procurement joins the thread with one line: “Can you send over your SOC 2?” Most founders say “of course” and then open a new tab. This is that tab.

What is a SOC 2? The two-sentence version

A SOC 2 is a report, written by an independent CPA firm, that describes your company’s security controls and states whether those controls are designed well and (for a Type 2) actually operated over a period of months. Enterprise buyers ask for it because it lets them trust your security program without sending their own team to inspect it.

That’s the whole idea. The AICPA, which owns the framework, describes SOC reports as assurance reports that give users “valuable information that is needed to assess and address the risks associated with outsourcing services” (AICPA, SOC for Service Organizations). Everything else is detail, and the details are where deals get won, so let’s go through them.

What does SOC 2 stand for, and why is a CPA firm involved?

SOC stands for System and Organization Controls. The framework is published by the AICPA, the American Institute of Certified Public Accountants, which is why the people who issue SOC 2 reports are auditors from licensed CPA firms rather than security vendors. The lineage is financial: SOC 1 covers the controls at a service provider that affect a customer’s financial reporting. SOC 2 came later, aimed squarely at the question every SaaS buyer has (if I put my data in your system, how do I know it’s safe?), and it became the default proof of security for software companies selling into US enterprises. A SOC 3 is a short, general-use summary of a SOC 2 that you can post publicly; the SOC 2 itself is the document procurement wants.

One consequence of that heritage trips people up: a SOC 2 is technically an attestation, not a certification. The auditor examines your controls under the AICPA’s attestation standards (the SSAE 18 family, AT-C section 205) and issues a professional opinion. There is no SOC 2 badge from a standards body and no pass/fail stamp. In practice everyone, including us, says “SOC 2 certified,” and buyers know exactly what you mean. It just helps to know what the document really is when you’re reading one.

If the request still feels abstract, Daniel Marashlian lived it. Before he co-founded Drata, he was the first engineer at an ed-tech startup selling to universities, and he described the moment on episode 64 of the podcast:

“Almost every time the CIO would come in and it’d be like, this looks great, love what you guys are doing. How are you going to protect our student data? And it kept coming back to the extremely long security questionnaires, or ‘let me see your SOC 2 report.’ Even a decade ago it was like, a SOC 2 what? We’re on AWS, don’t worry about it, let’s go. But then you’re like, okay, this is serious. We’re starting to block deal flow.”

Daniel Marashlian, co-founder and CTO of Drata, on episode 64

The five Trust Services Criteria (and which ones you actually need)

A SOC 2 audit measures your controls against the Trust Services Criteria, five categories you choose from. The current version is the AICPA’s 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, with revised points of focus from 2022, codified as TSP section 100.

Criterion	What it covers	Who typically includes it
Security	Protecting systems and data from unauthorized access: access control, change management, monitoring, incident response, risk management. Phishing-resistant, device-bound credentials are the kind of control auditors love to see here.	Everyone. Security is required in every SOC 2; the AICPA calls it the “common criteria.”
Availability	Uptime, capacity, backups, disaster recovery: whether the system is there when customers need it. Tested restores, not just backups, are the evidence.	Most SaaS companies, because customers have SLAs.
Confidentiality	How information designated confidential (customer data, contracts, IP) is protected and disposed of, including encryption choices that will still hold up.	Most B2B companies handling customer data.
Processing Integrity	Whether the system processes data completely, accurately, and on time.	Payments, payroll, data pipelines: anywhere a wrong output is a customer’s wrong output.
Privacy	Handling of personal information against your own privacy notice.	Consumer-facing or PII-heavy products; often deferred in favor of other frameworks.

The good news for a startup: you scope this. A typical first SOC 2 covers Security plus Availability and Confidentiality, which lines up with what buyers actually ask about. Adding criteria later is a normal part of growing up as a vendor.

SOC 2 Type 1 vs. Type 2: what’s the difference?

This is the distinction that matters most, and it comes down to time.

A Type 1 report evaluates whether your controls are suitably designed as of a single date. Think of it as a photograph: on March 3, your access reviews, your encryption, your onboarding process all existed and made sense.

A Type 2 report evaluates design and operating effectiveness over an observation window, typically three to twelve months. Now the auditor doesn’t just confirm the quarterly access review exists; they sample the quarters and check that it happened. Think of it as the film rather than the still.

Buyers know the difference, which is why the report procurement teams actually want is the Type 2. A Type 1 has its place as a stepping stone when a deal needs paper quickly, but most of the companies we work with go straight to Type 2, because that’s what unlocks the enterprise pipeline without a follow-up question. A first Type 2 usually runs a three-month window, so the observation period is shorter than most founders fear; the opportunity is in everything around it.

What’s in a SOC 2 report (and what procurement reads first)

If you’ve never opened one, a SOC 2 Type 2 is a long PDF with four main parts and an optional fifth, and each one is useful to you as a seller.

The auditor’s opinion. One or two pages up front. The word you’re hoping to see is unqualified, meaning the auditor found your controls designed and operating effectively. A qualified opinion means an exception was significant enough to note. This page is what a buyer’s security team reads first.

Management’s assertion. Your company’s own statement that the system description is accurate and the controls did what you say they did. You sign this, which is a healthy reminder that the auditor is verifying your claims rather than inventing them.

The system description. Your architecture, your people, your processes, your vendors, the boundaries of what was audited. This is also where you name the subservice organizations you rely on (AWS, Google Cloud) and the complementary user entity controls, the handful of things your customers must do on their side, like managing their own users. Written well, this doubles as the best security overview your sales team will ever have.

The controls, tests, and results. The heart of the report: every control, how the auditor tested it, and what they found. This is also where exceptions live. Here’s something first-timers find reassuring: a report with a couple of well-explained exceptions is still a clean, usable report. Buyers expect real companies to have a missed access review or a late patch. What they’re reading for is whether you noticed and how you responded.

Other information (optional). Management’s response to any exceptions, and anything else you want on the record. Use it.

Two practical notes. A SOC 2 is a restricted-use document, normally shared under NDA or through a trust portal rather than posted on your website (the public version is a SOC 3). And it’s dated: the report covers a specific window, so vendors renew annually and use a bridge letter, signed by your management rather than the auditor, to cover the gap between the end of one window and the delivery of the next report.

A SOC 2 is a floor, and the best programs build on it

Two of our guests put the nuance well. Phil Howie, founder and CTO of Sydekick, who builds security programs for small companies, told us on episode 83: “Being compliant doesn’t mean you’re secure. Compliance is someone else’s checklist. Resilience is what your business actually needs.” Jonathan Mortensen, CEO of Confident Security, made the same point from the product side on episode 75: the enterprise buyers who trust him most are the ones who can verify that “no one sees your data, not even us,” rather than taking a contract’s word for it.

Both are right, and both are good news for you. The controls a SOC 2 asks for (access reviews, change management, logging, incident response, vendor management) are the same controls that make a company hard to breach. Build the program for real, and the report becomes a by-product you happen to be able to hand to procurement. (If AI agents are already writing and reviewing your code, Paddy Roberts of Augment Code has written what the change-management criterion actually requires when the reviewer is an agent.)

Who needs a SOC 2 report, and when should a startup start?

If you sell software or services that touch a customer’s data, and your customers are mid-market or enterprise companies in the US, you will be asked for a SOC 2. The request tends to arrive precisely when the company is ready to graduate from selling to fellow startups to selling to the logos that make a Series A story. Internationally, ISO 27001 plays a similar role, and buyers in regulated sectors may layer HIPAA or HITRUST on top; the controls overlap heavily, so a SOC 2 program is a strong foundation for whatever comes next.

The bar is also rising with AI. Munam Wasi, co-founder of the prompt-injection security startup Mighty, described what he sees in vendor reviews on episode 101: “Lots of people are shipping AI products, and the vendor qualification sheets they rely on to get their product into other companies’ hands are rapidly evolving to ask about these security concerns. People want extra guarantees.” A SOC 2 answers the first hundred of those questions in one document; an AI management system certification like ISO 42001 is becoming the companion request, a shift we wrote about in AI Agents Are Now on Both Sides of the Breach.

The right time to start is a few months before the first real enterprise deal, not the week procurement asks. Companies that plan for it treat the report as a growth asset: it shortens security reviews, replaces hundreds of questionnaire answers with one document, and signals to investors that the house is in order. Augment Code went from zero to SOC 2 in five months and saw enterprise lead growth follow; Robust Intelligence had theirs in three months on the road to a $400M exit. Those are sales stories that happen to involve compliance.

The SOC 2 audit process, step by step

Every SOC 2 follows the same arc, whether you run it yourself or bring in help:

1. Scope. Pick your criteria, define the system boundary, choose the observation window that matches your deal timeline.
2. Readiness. Compare what you do today against the criteria, then close the distance: written policies people actually follow (your AI acceptable-use policy included), access reviews, vendor management, logging and alerting, incident response, background checks, and secure development practices that survive AI-generated code. Most buyers also expect a recent penetration test alongside the report. Compliance platforms like Vanta or Drata automate evidence collection across your cloud, HR, and code tooling, which is a huge time-saver when they’re wired correctly.
3. Observation window. Operate the controls. Collect evidence as you go. The quieter this phase is, the better.
4. Audit. The CPA firm samples your evidence, interviews your team, tests the controls, and writes the report.
5. Use it. Hand it to every buyer who asks, refresh it annually, and let your security review cycle shrink.

Step two is where the hours go, and Daniel Marashlian is candid about how it feels from the inside:

“I don’t think anyone’s excited about having meetings, collecting screenshots, and getting evidence of how I effectively operate a security control in my business. That’s not the fun part. The cool part is setting up structure for your business to run secure, a well-oiled machine, and the output is this artifact that you can use to build trust as you continue to grow your brand.”

Daniel Marashlian, Drata, episode 64

His numbers for the ongoing work: “On average, it takes roughly 500 hours to maintain your SOC 2 report. We get that down to about 50 hours, roughly an hour a week.” Automation handles the collecting. Someone still has to design the controls, run them, and answer the auditor, and at a startup that someone is usually an engineer you’d rather keep on the roadmap. Daniel again, on his own first SOC 2: “We had six engineers at that startup. Ripping three engineers off to go get a SOC 2 report is no joke. It’s a big decision.”

That decision, who does this work and what it costs you in roadmap, is exactly what we wrote about in In-House, On-Demand, or YOLO?, and it’s the subject of our live founder webinar on October 6. Done with a team that has run dozens of these, the full arc from kickoff to Type 2 report has landed in as little as five months, and we hold a 99% audit pass rate because nobody enters the observation window with open items.

How long does SOC 2 take, and what does it cost?

Honest answer: it depends on where you start, so here is how to think about both.

Time. The observation window is fixed once you choose it, usually three months for a first Type 2. Audit fieldwork and report writing take a few weeks. Readiness is the variable: a team that already has SSO, code review, logging, and a few written policies can be audit-ready in weeks; a team starting from a shared root password will take longer. Compliance platforms publish six to twelve months as the typical start-to-report range; with dedicated operators running readiness in parallel with the business, three to five months is what we see, and the case studies above are the receipts.

Money. Three buckets. The auditor’s fee, which platform vendors publish as roughly $10,000 to $80,000+ depending on scope and firm (Drata’s published range for small companies is $12,000 to $20,000), so budget low-to-mid five figures for a startup-scale Type 2. A compliance automation platform subscription. And the people-hours to design and run the controls, which is the largest bucket and the one you actually control. Those vendor ranges are marketing figures rather than audited data, so treat them as a sanity check and get real quotes from two or three CPA firms once your scope is set.

The way to keep both numbers small is the same: decide early who owns readiness, and start before procurement asks.

The short answer to “can you send over your SOC 2?”

A SOC 2 is an independent auditor’s report on your security controls. Type 2 proves they work over time. Security is always in scope and you choose the rest. The report is confidential, annual, and perfectly readable once you know where the opinion and the exceptions live. Treated as a growth asset instead of a tax, it opens the enterprise pipeline, and the companies that closed their first big deal cleanly had one ready before they needed it.

If that procurement email is somewhere in your near future, a free SOC 2 readiness assessment will show you how close you already are and how fast the rest can realistically go. If you’d rather hear the story first, Sasha and I tell it in eighteen minutes on episode 37.