SOC 2 Complete Guide: Understanding AICPA Trust Services Criteria

Maya Chen had built Lumenpath Analytics from a two-person side project into a 40-person healthcare logistics platform in four years, and on a Tuesday afternoon in March she was 25 minutes from closing the biggest contract in the company's history. Meridian Health Systems, a regional hospital network with 14 facilities, wanted Lumenpath's route-optimization platform for its medical courier fleet — a three-year, $2.3 million deal that would let Maya finally hire the platform team she'd been promising her board since the last funding round.

Then Meridian's procurement lead asked a question that stopped the call cold: "Can you send over your SOC 2 Type II report?"

Maya said she'd follow up. She did not have a SOC 2 report. She wasn't entirely sure what one was, beyond a vague sense that it was "the audit thing" enterprise customers sometimes asked about. Her VP of Sales, on the same call, tried to bridge with "we take security very seriously and can walk you through our practices," which is the sentence every procurement analyst on earth has learned to hear as we do not have the paperwork. Meridian's security team came back a week later with a 40-page vendor security questionnaire and a note: without a current SOC 2 Type II report, the deal would need to go through an extended security review that typically added four to six months — and even then, approval wasn't guaranteed.

Six months and one uncomfortable board conversation later, Lumenpath had its first SOC 2 Type II report in hand, the Meridian deal closed, and Maya had become the person on her leadership team who understood SOC 2 well enough to explain it to anyone — investors, customers, new hires — without hedging. This guide is the explanation she wishes someone had handed her on that March afternoon.

Who This Is For / What You'll Walk Away With

This is the cornerstone guide to SOC 2 for anyone who needs the full picture before diving into narrower topics. If you're a founder, CTO, VP of Engineering, or first compliance hire at a SaaS or service organization fielding SOC 2 questions from customers, investors, or your own sales team, this article is your starting point. You'll walk away understanding exactly what SOC 2 is (and isn't), how the Trust Services Criteria and Common Criteria are structured, the real difference between a Type I and Type II report, who the players are in a SOC 2 engagement, what a finished report actually contains, and a realistic view of the journey — timeline, cost drivers, and where organizations most often stumble. Where a topic deserves its own deep dive, this guide links you to the dedicated article rather than trying to cover everything at the same depth.

What SOC 2 Actually Is (and What It Isn't)

Let's start by fixing the single most common misconception, because it colors everything else: SOC 2 is not a certification. There is no pass/fail badge, no certificate with a registration number, no accreditation body stamping your organization as "SOC 2 certified." SOC 2 is an attestation — specifically, an independent examination performed by a licensed CPA firm, resulting in a report that expresses the auditor's opinion on whether your organization's controls meet a defined set of criteria.

That distinction is not pedantic. A certification, like ISO/IEC 27001, involves a certification body auditing an organization against a published standard and issuing a certificate that says "conforms" or "does not conform." An attestation is different in structure: a CPA firm examines management's own written claims about its system and controls (called the management assertion) and issues an opinion on whether those claims are fairly stated and whether the controls are suitably designed and, for a Type II report, operating effectively. Vendors and marketing copy across the industry routinely say "SOC 2 certified" — you'll hear it from competitors, and you may even be tempted to use the phrase yourself because customers search for it. Resist it in anything customer-facing that matters (contracts, security pages, sales decks). The accurate phrasing is "we have completed a SOC 2 Type II examination" or "we hold a current SOC 2 Type II report." If you want the fuller comparison between attestation and certification models, our ISO 27001 vs SOC 2: which one do you need article walks through it side by side.

The second thing to fix early: SOC 2 is not a law, and it is not a regulation. No government agency requires it. It is a voluntary, market-driven mechanism that emerged because customers — especially enterprise buyers, financial institutions, and healthcare organizations — needed a standardized way to get assurance about a vendor's controls without personally auditing every SaaS provider in their supply chain. It is US-in-origin but used globally today; I've run readiness work for service organizations in the UK, Ireland, Singapore, and Australia whose customer base is concentrated in the US, or who simply found the framework a useful baseline regardless of geography.

Who Is the AICPA, and What Is SSAE 18?

SOC 2 belongs to the AICPA — the American Institute of Certified Public Accountants, the professional body that sets auditing and attestation standards for CPAs in the United States. The AICPA doesn't audit anyone directly; it develops the standards and criteria that licensed CPA firms then apply when they perform SOC examinations for their clients. This matters practically: your SOC 2 report must be issued by a CPA firm licensed to perform attestation engagements, not by a generic "security auditor" or consultancy without CPA licensure, no matter how technically capable that firm is.

The governing standard is SSAE 18 — Statement on Standards for Attestation Engagements No. 18. SSAE 18 is the AICPA's attestation standard, organized into AT-C sections, that lays out how CPAs plan, perform, and report on attestation engagements generally. SOC 2 examinations specifically follow AT-C section 105 (concepts common to all attestation engagements) and AT-C section 205 (examination engagements), applied to the Trust Services Criteria, which is the actual content framework the auditor tests your controls against. Think of SSAE 18 as the rulebook for how the audit is conducted and reported — due professional care, evidence standards, independence requirements — and the Trust Services Criteria as what gets tested.

One historical note worth knowing because it still shows up in older vendor documentation: SOC examinations were previously governed by SSAE 16 (which itself replaced the much older SAS 70 standard). SSAE 18 superseded SSAE 16 in 2017. If you ever see a vendor reference "SAS 70 compliant," treat it as a signal the vendor's compliance messaging hasn't been updated in over a decade — SAS 70 was a financial-reporting-controls standard, not a security framework, and has been obsolete for SOC purposes for years.

Table 1: SOC 2 Terminology — Getting the Language Right

The Five Trust Services Criteria

Everything in a SOC 2 examination is organized around the Trust Services Criteria (TSC) — five categories of criteria that define what "good controls" look like for a service organization. Only one is mandatory in every SOC 2 engagement; the other four are selected based on the commitments your organization actually makes to customers.

Security — often just called the Common Criteria or CC-series — is required in every single SOC 2 report, Type I or Type II, regardless of industry or scope. It covers the baseline expectation that an organization protects its systems against unauthorized access, both physical and logical, and maintains the processes to detect and respond to security events. There is no such thing as a SOC 2 report without the Security category; it is the floor.

The four optional categories are layered on top of Security based on what your system actually does and what you've promised customers:

• Availability addresses whether systems are available for operation and use as committed or agreed — relevant if customers care about uptime SLAs, redundancy, and disaster recovery.

• Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized — relevant for platforms that process transactions, calculations, or data transformations customers rely on being correct (payment processors, billing engines, e-commerce platforms).

• Confidentiality addresses protection of information designated as confidential (which may be broader than personal data — think trade secrets, business plans, source code) through its lifecycle.

• Privacy addresses the collection, use, retention, disclosure, and disposal of personal information in conformity with an organization's privacy notice and AICPA privacy criteria — relevant when you directly handle end-consumer personal data as a core part of the service.

I walk clients through a deceptively simple exercise to pick the right categories: pull up your customer contracts and your marketing site and highlight every sentence that makes a promise about your system. "99.9% uptime" triggers Availability. "Bank-grade encryption of your financial data" triggers Confidentiality and probably Processing Integrity if you're doing calculations on that data. "We never sell your personal information" triggers Privacy. Whatever's left unhighlighted after that exercise usually doesn't need its own category — you don't need Privacy just because you have a login page. For the full breakdown of each criterion with control examples, see our dedicated SOC 2 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy article.

Table 2: The Five Trust Services Criteria at a Glance

"The single biggest scoping mistake I see is a company adding every optional category because they think more criteria signals more maturity. It doesn't — it signals you didn't read your own contracts. I've cut engagement scope by half for clients just by walking through what they'd actually committed to in their MSA." — Elena Vasquez, CISSP, Principal Auditor, Ferris & Cole CPAs

The Common Criteria: SOC 2's Non-Negotiable Foundation

Because Security is mandatory in every report, the Common Criteria are the part of SOC 2 you cannot avoid learning, no matter how narrow your scope otherwise is. The AICPA structures the Common Criteria into nine series, numbered CC1 through CC9, and — this is the detail that surprises people who assume SOC 2 was built from scratch as a security framework — they are directly mapped to the COSO Internal Control–Integrated Framework, the internal-controls model originally developed for financial reporting by the Committee of Sponsoring Organizations of the Treadway Commission. The AICPA didn't invent a new control philosophy for SOC 2; it took a battle-tested governance framework already trusted by auditors and financial regulators and extended it with points of focus specific to information security.

Understanding this lineage helps explain why a SOC 2 report reads the way it does — heavy on governance, risk assessment, and monitoring, not just technical controls. A auditor testing your Common Criteria isn't just checking whether you have a firewall; they're checking whether your organization has a functioning control environment with real accountability, communicated risk appetite, and management oversight, because that's the COSO DNA underneath.

Table 3: Common Criteria (CC1–CC9) Mapped to COSO Principles

CC1 through CC5 map directly onto COSO's five components — this is the "shared DNA" every SOC 2 report has with a financial-controls audit. CC6 through CC9 are the AICPA's security-specific extensions layered on top, and this is where most of the technical control testing you'd recognize as "cybersecurity" actually lives: access reviews, least privilege enforcement, vulnerability scanning and patch cadences, change management approval workflows, and vendor risk management for your own subprocessors. If you've ever wondered why a SOC 2 readiness assessment asks about board meeting minutes and org charts before it asks about your firewall rules, CC1's control-environment testing is why.

"Engineers walk into their first SOC 2 kickoff expecting a technical audit and get thrown by the first hour of questions about org charts and board reporting lines. I tell every team the same thing: half of this audit is proving you have a functioning company, not just a functioning product." — Marcus Whitfield, CISO, Northbridge Payments

Type I vs. Type II: The Distinction That Actually Matters Most

If you remember one distinction from this entire guide, make it this one, because it's the question that determines almost everything about your timeline, cost, and what customers will actually accept.

A Type I report examines whether your controls are suitably designed at a single point in time — essentially, a snapshot that says "as of this date, here's the system we described, and here's whether the controls we've documented would work if operated." A Type II report examines whether those same controls operated effectively over a period of time, commonly three, six, or twelve months, with the auditor pulling actual evidence — access logs, ticket records, review sign-offs — across that entire window rather than a single day.

The practical difference is enormous. A Type I report can be produced relatively quickly once controls are documented and implemented, because the auditor is testing design, not sustained operation. A Type II report requires you to actually run the controls, consistently, generating evidence, for the entire observation period before the audit fieldwork can even begin — there is no way to compress a six-month Type II observation window into six weeks by working harder.

Here's the part that surprises first-time buyers of SOC 2: most enterprise customers want Type II, and increasingly won't accept Type I as a final answer. A Type I report tells a customer "this company built the right controls." A Type II report tells them "this company has been running the right controls, consistently, for months, with an auditor checking the evidence." Type I has a legitimate place — it's common for a first-time SOC 2 program to start with a Type I to get something in hand for sales conversations while the Type II observation period runs in parallel — but treat it as a stepping stone, not a destination. For the complete decision framework, including when Type I genuinely makes sense as a strategic first step, see SOC 2 Type I vs Type II: Choosing the Right Audit Type.

Table 4: Type I vs. Type II Report Comparison

The SOC Report Family: Where SOC 2 Fits

SOC 2 is one member of a small family of AICPA-governed report types, and mixing them up in a customer conversation is an easy way to look like you don't know your own compliance posture. SOC 1 examines controls relevant to a user entity's financial reporting — internal control over financial reporting, or ICFR — and is what you'd pursue if your platform touches customers' financial statements (payroll processors, fund administrators, billing systems that feed general ledgers). SOC 2 examines controls against the Trust Services Criteria — security and operational trust, not financial reporting. SOC 3 is a general-use, publicly distributable summary report, built from the same underlying SOC 2 examination, but stripped of the detailed control descriptions and test results so it's safe to post on a public website or hand to a prospect who doesn't need (or isn't entitled to see) the full report.

That last point matters operationally: SOC 1 and SOC 2 reports are restricted-use documents, typically shared under NDA with existing or prospective customers and their auditors — you shouldn't post your full SOC 2 report on a public marketing page. A SOC 3 report, by contrast, is designed to be freely distributed; some organizations post a "SOC 3 seal" and downloadable summary on their trust center precisely so top-of-funnel prospects get some assurance without a full report request. Many organizations that need public-facing proof pursue both: a restricted SOC 2 for the detailed customer diligence process and a SOC 3 for the public trust page. This guide covers SOC 2 specifically; for the full comparison across all three, see SOC 2 vs SOC 1 vs SOC 3: Understanding the SOC Framework Family.

Table 5: The SOC Report Family

What's Actually Inside a SOC 2 Report

The first time most executives see an actual SOC 2 report, they're surprised by two things: how long it is (Type II reports commonly run 60 to well over 150 pages depending on scope and control count) and how much of it isn't marketing-friendly at all — it's dense, evidentiary, and written for a security or audit reader, not a prospect's CEO. A complete report has four core sections, and knowing them means you can navigate a vendor's report quickly during your own third-party risk reviews, not just hand yours out.

Section I is the independent auditor's report — the CPA firm's actual opinion. This is the section everyone flips to first. Section II is management's assertion — a written statement, signed by your organization's leadership, describing the system and asserting that the description is accurate and the controls are suitably designed (and, for Type II, operated effectively) throughout the period. Section III is the system description itself: a detailed narrative of your infrastructure, software, people, procedures, and data, along with the boundaries of what's in scope and what isn't. Section IV, present only in Type II reports, is the description of tests of controls and results — literally a table listing every control, the test the auditor performed against it, and the result, including any exceptions found. Many reports also include a Section V with additional information provided by management, such as planned remediation for any noted exceptions.

Table 6: Anatomy of a SOC 2 Report

Auditor's Opinion Types: What "Passing" Actually Looks Like

There's no pass/fail grade on a SOC 2 report — there's an auditor's opinion, and the wording of that opinion is what customers and their security teams will scrutinize closely. Four opinion types exist, borrowed from standard attestation and financial-audit language.

An unqualified opinion — sometimes called a "clean opinion" — is the one everyone is working toward. It states that the system description is fairly presented and the controls are suitably designed and (for Type II) operating effectively throughout the period, with no material exceptions the auditor couldn't get comfortable with. A qualified opinion notes that, except for one or more specific issues, the controls are suitably designed/operating — essentially, "clean, with an asterisk." A single control exception during a Type II period (say, one instance of a terminated employee's access not being revoked within your stated SLA) doesn't automatically tank your report to qualified; auditors weigh materiality and pervasiveness. An adverse opinion is far more serious: it states the system description is not fairly presented or the controls are not suitably designed/operating, essentially a failing grade. A disclaimer of opinion means the auditor couldn't obtain sufficient evidence to form any opinion at all, often due to scope restrictions.

In fifteen years of this work, I have seen exactly a handful of adverse opinions and disclaimers — they are rare because a competent auditor, and a competent readiness process beforehand, generally surfaces problems in time to fix them before the audit locks in, or the engagement gets rescoped. What you should actually expect, and what I tell every first-time client to expect, is an unqualified opinion with a handful of noted exceptions in Section IV that get addressed in your remediation plan for next cycle. That's normal. That's not a failure. Customers reviewing your report understand that a Type II report with zero exceptions across dozens of controls tested over months, for a real operating company, can actually read as less credible to a sophisticated reviewer than one with a couple of minor, well-remediated exceptions.

Table 7: SOC 2 Auditor Opinion Types

Key Parties in a SOC 2 Engagement

A SOC 2 examination involves more parties than the two people in most executives' mental model (us, and the auditor). Understanding all four categories matters because your own report's credibility depends on how you handle the fourth one.

The service organization is you — the entity whose system and controls are being examined. The user entities are your customers, the ones relying on your controls to manage their own risk (and often flowing your SOC 2 report up into their own compliance programs). Subservice organizations are the vendors you rely on to deliver your service — your cloud hosting provider, a payment processor, a customer support platform with access to customer data. And complementary user entity controls (CUECs) are controls your report explicitly states the customer themselves must operate for the overall system to work as intended — for example, "the user entity is responsible for promptly notifying [service org] of any changes to their authorized user list," or "the user entity is responsible for configuring their own SSO session timeout policy."

CUECs trip people up because they feel like a cop-out — "we're passing responsibility to the customer" — but they're a standard and expected part of any report, and a sophisticated customer's own security team will specifically check whether your CUECs list is realistic and whether they can actually fulfill their side. A report with no CUECs at all is often a sign the auditor didn't push hard enough on the boundary between your responsibilities and the customer's, not a sign of a stronger system.

Table 8: The Four Parties in a SOC 2 Engagement

Subservice Organizations: Carve-Out vs. Inclusive Method

Almost no modern SaaS company runs its entire stack in-house — you're on AWS or Azure or GCP, maybe a managed database provider, maybe a third-party identity platform. Because your system description has to account for those dependencies, SOC 2 gives auditors two ways to handle subservice organizations in scope.

Under the carve-out method, the subservice organization's controls are excluded from your examination; your system description acknowledges the subservice organization exists and identifies the controls it's expected to provide (relying on the subservice org's own SOC 2 report as evidence those controls exist), but your auditor doesn't test them directly. This is by far the most common approach for cloud infrastructure — nobody expects you to have your auditor personally test AWS's physical data center controls; you carve out AWS and reference the fact that AWS maintains its own SOC 2 reports.

Under the inclusive method, the subservice organization's controls ARE included in your examination scope, meaning your auditor directly tests them (often requiring the subservice organization's cooperation and access). This is rarer and typically reserved for smaller or more specialized vendors without their own SOC 2 report, where carve-out isn't a realistic option because there's no independent report to point to.

In practice, expect carve-out to cover essentially all of your major cloud infrastructure, and expect your own customers' security teams to specifically ask which method you used and to request copies of your major subservice organizations' own SOC 2 reports as part of their vendor risk review of you. Keep a running folder of your key vendors' current reports; you'll be asked for it repeatedly.

Table 9: Carve-Out vs. Inclusive Method

The SOC 2 Journey, End to End

Zoom out, and every SOC 2 program — mine included, across roughly 200 organizations at this point — follows the same basic shape, even though the timeline and difficulty vary enormously by company size and starting maturity. Here's the journey mapped out:

The loop back at the end isn't decorative — SOC 2 isn't a one-and-done event. A Type II report covers a defined historical period, and it ages. Most organizations run this cycle annually, with each new report's observation period picking up roughly where the last one left off, so there's rarely a true gap in coverage as long as you keep the program running.

Phase 1: Scoping and Readiness Assessment

Before an auditor ever gets involved, you need to decide what system is in scope, which Trust Services Criteria apply, and — critically — where you actually stand against the Common Criteria today. This is the readiness assessment: a structured gap analysis comparing your current controls, policies, and evidence-generating processes against what SOC 2 will require. Most organizations run this with either an internal team stretched thin on time or, more commonly, an outside consultant or the CPA firm's own readiness service (some firms separate readiness consulting from the audit itself to preserve independence; some outsource it to a partner).

A good readiness assessment produces a prioritized gap list, not just a scary spreadsheet. In my experience the same handful of gaps show up in probably 80% of first-time engagements: no formal risk assessment process, access reviews that happen ad hoc rather than on a documented cadence, no centralized logging/monitoring with alerting, incomplete onboarding/offboarding procedures for system access, and policies that exist as a single "IT Policy" document written five years ago rather than the dozen-plus discrete policies SOC 2 expects (access control, incident response, change management, vendor management, and more).

Phase 2: Remediation

This is where the actual work happens, and it's almost always the longest phase for a first-time program — commonly two to six months depending on how far off the gap list left you. Remediation means implementing missing technical controls (MFA enforcement, centralized SIEM/logging, formal access control provisioning workflows), writing the policy documents that don't yet exist, and — the part engineers underestimate — establishing the evidence trail for each control, because a Type II auditor won't take your word for it; they'll want tickets, logs, sign-off records, and screenshots dated across the entire observation period.

Phase 3: The Audit Period

For a Type II report, once controls are in place, you enter the observation period itself — commonly three months for a first report (to get something in hand faster) extending to six or twelve months for renewal reports, since longer periods generally carry more weight with sophisticated buyers. Nothing shortens this phase; it is literally the passage of time during which your controls must operate correctly and generate evidence. This is also where organizations most often get tripped up — not because the controls fail, but because evidence-generation habits slip after the initial push (someone forgets to document a quarterly access review in month four, for instance), creating an avoidable exception.

Phase 4: Fieldwork and Report Issuance

Once the observation period closes (or, for Type I, once the design is ready to examine), the CPA firm conducts fieldwork: requesting evidence, interviewing control owners, sampling tickets and logs, and testing whether what you documented matches what actually happened. You'll typically get a draft report to review — this is your chance to catch factual errors in the system description, not to negotiate the opinion — before the final signed report is issued.

Phase 5: Distribution and Continuous Compliance

The finished report gets distributed to customers and prospects, almost always under NDA given its restricted-use status, often via a secure portal or trust-center gated download rather than email attachment. Then the cycle resets: you either continue accumulating evidence for a rolling next period, or you take a short gap and start a new observation window, in which case a bridge letter — a short letter from you (not the auditor) covering the interval between your last report's end date and a customer's current need — fills the gap for any customer asking about coverage in between.

Table 10: The SOC 2 Journey by Phase

"The companies that struggle aren't the ones with weak controls on day one — everybody starts somewhere. The ones that struggle are the ones who treat remediation as a sprint and then let evidence collection lapse the moment the auditor isn't actively watching. SOC 2 punishes inconsistency more than it punishes imperfection." — Priya Raghunathan, Compliance Director, Cascadia Cloud Systems

Cost and Timeline: What to Actually Budget For

Every company asks the same two questions in the first call: how much, and how long. The honest answer is "it depends on your starting point and scope" — but that's not a useful budgeting answer, so here's the illustrative range I quote prospective clients based on patterns across dozens of first-time engagements, with the caveat that these are ballpark figures tied to typical mid-market SaaS scope, not a quote for your specific organization.

There are four cost buckets: the readiness assessment/consulting (if you use outside help), the tooling (compliance automation platforms that handle evidence collection are now near-standard, running roughly $10,000–$30,000+ annually depending on headcount and integrations), the audit fee itself (paid to the CPA firm, scaling with the number of Trust Services Criteria in scope and control count), and the often-underestimated internal cost — engineering and operations time pulled away from roadmap work to build and operate controls. That last bucket is frequently the largest and the easiest to forget when a board asks "why does a compliance checkbox cost six figures."

Table 11: Illustrative SOC 2 Cost and Timeline Ranges (First-Time Program)

Two timeline traps catch first-timers every time. First, people quote the audit fieldwork duration (a few weeks) as if it's the whole timeline, forgetting the audit period itself has to elapse first — you cannot buy your way past a six-month Type II observation window. Second, people underestimate remediation time because the gap list "doesn't look that long" on paper, without accounting for how long it takes to actually operationalize a new control across a whole engineering org (a policy is a document; a functioning quarterly access review that engineering managers actually complete on time is a habit, and habits take longer to build than documents take to write).

Choosing a CPA Firm and Compliance Tooling

Two decisions shape a SOC 2 program more than any other, and both get rushed by first-time teams under deal pressure: which CPA firm performs the examination, and what tooling you use to manage evidence.

On the auditor side, price matters less than fit. I've seen organizations choose the cheapest quote available and end up with an auditor who has never examined a company in their industry, doesn't understand their tech stack (a firm used to examining traditional financial services controls can be genuinely thrown by a cloud-native, Kubernetes-based SaaS architecture), and communicates on a cadence that turns a three-week fieldwork window into an eight-week one. Ask any CPA firm you're evaluating three questions: how many SOC 2 examinations have they completed in your industry in the last year, who specifically will be assigned to your engagement (not just the partner who sold it), and what's their typical turnaround from evidence submission to draft report. A firm that answers vaguely on any of the three is worth a second look elsewhere.

On tooling, the compliance automation category (platforms that connect to your cloud infrastructure, HR system, and ticketing tools to continuously pull evidence rather than making someone manually screenshot access logs every quarter) has become close to standard for any organization pursuing SOC 2 in the last several years, and for good reason: manual evidence collection is exactly the kind of activity that quietly slips during month four of a six-month observation period, which is precisely when a lapse becomes an exception on your final report. That said, tooling doesn't replace the underlying work of actually building sound controls — I've watched teams buy a compliance platform and treat the dashboard's "readiness score" as the finish line, only to find their auditor still flags real gaps the tool never surfaced because the tool checks for evidence of a control existing, not whether the control is actually well-designed for your specific risk profile. Treat automation as an evidence-collection accelerant, not a substitute for judgment. If you're comparing platforms before you commit budget, our roundup of the best SOC 2 compliance software is a useful starting point for shortlisting vendors against your scope and headcount.

Table 16: Auditor and Tooling Evaluation Checklist

"I ask every prospective client the same question before we start: who's going to own evidence collection day-to-day, by name? If the answer is 'the team,' I know we're going to have a rough month six." — Sarah Kowalski, Head of GRC, Bluepeak SaaS

Who Needs SOC 2, and What It Actually Buys You

If your customers are enterprises, healthcare organizations, financial institutions, or increasingly any organization with a security-conscious procurement process, you will eventually be asked for a SOC 2 report — often as a hard gate before a contract can be signed, not a nice-to-have. B2B SaaS companies handling customer data, cloud infrastructure and platform providers, HR tech, fintech, healthtech, and managed service providers are the most common adopters, but I've run engagements for companies in categories that would surprise you (a marketing automation platform, a scheduling tool, a niche industrial IoT company) simply because one large customer's security team made it a contractual requirement.

The business case goes well beyond "customer asked for it," though that's the trigger for most first engagements. A completed SOC 2 report shortens sales cycles by letting you skip lengthy custom security questionnaires, differentiates you from competitors who can't produce one, and — the underrated benefit — forces internal discipline that generally makes the organization genuinely more secure, not just paper-compliant, if the program is run well rather than treated as a check-the-box exercise. For the full business case, including how to frame the investment to a board that sees compliance as a cost center, see SOC 2 Business Benefits: Why Service Organizations Need Certification.

Table 12: Who Typically Needs SOC 2

Common Mistakes I See Organizations Make

Across roughly 200 organizations, the same failure patterns recur often enough to be worth naming directly, because avoiding them is cheaper than fixing them mid-engagement.

Table 13: Common SOC 2 Mistakes and How to Avoid Them

"I've watched two companies with nearly identical control maturity get very different outcomes because one assigned a single accountable owner per control category and the other spread ownership across 'whoever has time.' Evidence doesn't collect itself." — Tom Alderidge, VP of Security, Fenwick Data Systems

Case Study: Lumenpath Analytics Closes the Deal

Return to Maya Chen at Lumenpath Analytics from the opening of this guide. After the Meridian Health Systems call stalled, Maya's board authorized a compressed SOC 2 program: a readiness assessment in weeks one and two turned up nineteen gaps, the largest being no centralized logging, no documented access review cadence, and policies that hadn't been touched since the company's Series A. Lumenpath spent ten weeks on remediation — standing up a SIEM, implementing quarterly access reviews with named owners in each department, and rewriting eleven separate policy documents from the single outdated one they'd had. They opted for a three-month Type II observation period covering Security and Availability only (Meridian's contract language, once Maya actually read it carefully, made commitments about uptime but nothing about processing integrity or the other categories), which kept scope — and cost — tighter than a full five-category engagement would have.

The Type II report was issued five and a half months after the original stalled call. Lumenpath's report had two noted exceptions, both minor (a single access review that ran eleven days past its documented 30-day SLA, and one server patch that landed four days outside the patching policy window) — both remediated and both disclosed transparently in the report, exactly the kind of "clean with minor, well-handled exceptions" outcome that reads as credible rather than alarming to a sophisticated reviewer. Meridian's security team approved the vendor within two weeks of receiving the report, and the $2.3 million deal closed. More valuable long-term: Lumenpath's next three enterprise deals closed an average of 60 days faster than deals closed before they had a report in hand, because the report answered most of the security questionnaire before it was even sent.

Case Study: Northbridge Payments Rebuilds After a Rough Readiness Assessment

Northbridge Payments, a mid-market payment processing platform, came to their first SOC 2 readiness assessment expecting a light lift — they'd always considered themselves security-conscious, with encryption everywhere and a capable engineering team. The readiness assessment found fourteen gaps, several more serious than Lumenpath's: no formal risk assessment process at all, privileged access to production systems that wasn't consistently logged, and a change management process that existed in engineering culture but nowhere in writing or in an approval workflow an auditor could actually test. Given Northbridge's payment processing function, their scope needed Security, Availability, and Processing Integrity — a heavier engagement than a typical SaaS company's.

Remediation ran four months, including building out a formal risk register, implementing a documented and evidenced change approval workflow in their ticketing system, and centralizing privileged access logging through a dedicated PAM tool. The six-month Type II observation period that followed came back with an unqualified opinion and zero exceptions — a genuinely strong outcome given the starting gaps, driven largely by assigning a single accountable control owner for each of the fourteen original gap areas rather than leaving remediation as a shared engineering responsibility. Northbridge's CISO estimated the completed report helped retain roughly $180,000 in annual recurring revenue from two enterprise customers who had explicitly flagged the missing report as a renewal risk, and it became a standard, expected attachment in every subsequent enterprise sales cycle.

Case Study: Cascadia Cloud Systems Runs ISO 27001 and SOC 2 Together

Not every organization is starting from zero. Cascadia Cloud Systems had already achieved ISO 27001 certification two years before their first enterprise customer asked for a SOC 2 report — a common situation for companies with a global customer base, where European and APAC customers had driven the ISO 27001 investment and a new wave of US enterprise customers were now driving the SOC 2 ask. Rather than building a second, parallel compliance program, Cascadia's compliance director mapped their existing ISMS controls directly against the SOC 2 Common Criteria, finding that a large majority of the evidence they already generated for ISO 27001 surveillance audits — risk assessments, access reviews, incident response records, vendor risk documentation — satisfied SOC 2 evidence requirements with only modest adjustment to formatting and cadence.

The result was a SOC 2 readiness-to-report timeline of just over three months, roughly half of what a from-scratch program would have taken, and an estimated 35% reduction in ongoing dual-framework audit administration by consolidating evidence collection into a single GRC workflow rather than running two disconnected compliance calendars. Cascadia's experience is common enough — and valuable enough — that it's worth its own deep dive if you're managing (or considering) both frameworks; see Running ISO 27001 and SOC 2 Together and the ISO 27001, SOC 2 & NIST CSF Crosswalk for the detailed control mapping.

"We didn't rebuild a compliance program for SOC 2 — we translated the one we already had. The framework names are different, the underlying discipline of risk-based, evidenced controls is the same." — Priya Raghunathan, Compliance Director, Cascadia Cloud Systems

Table 14: Case Study Outcomes at a Glance

SOC 2 and ISO 27001: Should You Pursue Both?

If your customer base spans US enterprise buyers (who lean SOC 2) and international or government-adjacent customers (who more often expect ISO 27001 certification), you may end up needing both — and as Cascadia's case study shows, that's far less painful the second time you build the underlying control discipline than the first. The frameworks aren't competitors; they're different lenses (attestation vs. certification, US market convention vs. international standard) applied to largely overlapping underlying security practices. If you're trying to decide which to pursue first, our ISO 27001 vs SOC 2: which one do you need guide walks through the decision factors directly, and ISO 27001 vs NIST/SOC 2/PCI DSS compared sets SOC 2 alongside the other frameworks you're likely to be asked about. If you're brand new to ISO 27001 itself and want the equivalent cornerstone guide on that side, start with What Is ISO 27001: Beginner's Guide to Information Security Management.

Getting Started: Your First 90 Days

If you're standing where Maya Chen stood before her SOC 2 program started, here's the sequence I recommend to every first-time client, roughly ordered.

Table 15: First 90 Days — A Practical Starting Checklist

A SOC 2 Readiness Checklist and a SOC 2 Trust Services Criteria Mapping Template can shortcut steps 1 through 4 considerably if you'd rather start from a structured worksheet than a blank page. If you're still weighing whether your organization is genuinely ready to start the clock, our "Are You SOC 2 Ready?" quiz is a fast, honest gut-check before you commit budget.

SOC 2 as a Growth Lever, Not Just a Gate

I understand why SOC 2 gets framed internally as a cost center — it consumes engineering time, it's not a feature customers see in the product, and the first invoice from a CPA firm always lands a little harder than expected. But every leadership team I've worked with that treated SOC 2 purely as a defensive compliance exercise — the minimum needed to unblock one deal — got less value out of the investment than teams that treated it as a growth lever from day one. A completed report doesn't just unblock deals in flight; it changes what your sales team can promise upfront, shortens security review cycles across your entire pipeline rather than one account, and gives your engineering org an evidence-based, externally validated answer the next time a customer's security team asks "how do we know you're actually secure" instead of a slide deck built for the occasion.

There's also a compounding effect worth planning for explicitly: the controls, evidence habits, and governance discipline you build for your first SOC 2 report don't expire when the report is issued — they become organizational muscle memory that makes every subsequent framework (a second Trust Services Criteria category, an ISO 27001 program, a customer-specific security addendum) meaningfully faster to achieve, the way Cascadia's existing ISMS cut their SOC 2 timeline roughly in half. Budget for SOC 2 as infrastructure, not as a one-time hurdle, and the second and third years get dramatically cheaper and faster than the first.

If you're mapping out where SOC 2 fits alongside a broader security program — including whether ISO 27001, NIST CSF, or another framework belongs in your roadmap too — PentesterWorld's SOC 2 and ISO 27001 content pillars are built to be read together. Explore our SOC 2 Cost Calculator to model your own scope and budget, download the SOC 2 Report Reader's Guide eBook to learn how to evaluate a vendor's SOC 2 report during your own third-party risk reviews, or reach out to the PentesterWorld team to talk through your specific readiness picture before you commit to an audit timeline.