SOC 2

SOC 2 is an independent attestation engagement: a licensed CPA firm evaluates whether your service organization's controls meet the AICPA Trust Services Criteria (TSC) for one or more categories — Security, Availability, Processing Integrity, Confidentiality, and Privacy. The deliverable is a report, not a public certificate. Nearly every US mid-market and enterprise SaaS buyer eventually asks for a recent Type II report covering Security (the Common Criteria). Type I speaks to design at a point in time; Type II tests operating effectiveness over an observation window, typically three to twelve months.

Buyers treat the report as a reusable due-diligence packet that reduces questionnaire churn. You still answer product-specific questions, but a clean SOC 2 opinion plus a readable system description often unblocks legal and security review weeks faster than ad-hoc screenshots. The examination is principles-based: you invent controls that satisfy criteria, not a fixed product checklist. Auditors sample evidence — access reviews, change tickets, logging alerts, vendor assessments — and opine on suitability of design and, for Type II, operating effectiveness.

Most early-stage teams start Security-only, keep the system boundary tight (production SaaS plus the people and cloud accounts that touch it), and avoid stacking Availability or Confidentiality until contracts force the issue. Expect a program arc of scoping, gap remediation, evidence cadence, fieldwork, draft review, and NDA distribution. First-year all-in spend commonly lands in the tens of thousands of dollars when auditor fees, tooling, and engineering time are combined — see /costs/soc-2/overview for ranges and variance drivers. This hub orients decisions; control pages such as /controls/soc-2/cc6-1 and /controls/soc-2/cc8-1 show evidence patterns auditors actually sample.

Independence note: this site explains criteria, sequencing, and tradeoffs without selling a compliance product. Prefer primary AICPA sources linked in Sources over vendor marketing when a Point of Focus or criterion language is disputed.

SOC 2 sits inside the AICPA's System and Organization Controls family. The governing criteria are TSP Section 100 — the 2017 Trust Services Criteria with 2022 Revised Points of Focus. Those Points of Focus help interpret criteria; they are not separately opinioned line items. A SOC 2 report typically includes management's assertion, the independent auditor's opinion, a detailed system description, and the control descriptions and tests of design (and operating effectiveness for Type II). The report is usually restricted-use: intended for management, specified users with sufficient knowledge, and parties who understand the system and criteria — not a marketing seal for a public homepage badge without context.

Security is the baseline category. It embeds the Common Criteria (CC1 through CC9), which cover control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access, system operations, change management, and risk mitigation. Availability, Processing Integrity, Confidentiality, and Privacy add category-specific criteria when customer contracts, SLAs, or data sensitivity justify the extra evidence burden. A multi-tenant B2B SaaS product that stores customer configuration and application data almost always needs Security; Availability becomes relevant when uptime commitments are contractual; Confidentiality when you handle particularly sensitive customer content beyond ordinary SaaS data; Privacy when personal information processing is central and customers want TSC Privacy alignment in addition to legal privacy programs.

SOC 2 is customer-driven, not a statute. Nothing in US federal law requires a SaaS company to hold a SOC 2 report the way HIPAA Security Rule obligations apply to covered entities and business associates. Market force does the enforcing: procurement checklists, security questionnaires, and enterprise MSAs that condition go-live on a current Type II. Geographic gravity matters. North American B2B buyers default to SOC 2 language; EU and UK buyers more often cite ISO/IEC 27001 certification. Many mature vendors eventually hold both artifacts because control work overlaps heavily while buyer audiences differ — see /compare/soc-2-vs-iso-27001.

The examination is performed under AICPA attestation standards by a CPA firm (or under arrangements that meet those standards). Your job as management is to define the system, design controls, operate them, assert that the description is fair and controls meet criteria, and provide complete populations for sampling. The auditor's job is independence, risk-based testing, and opinion language — unmodified, qualified, or adverse depending on findings. Understanding that split prevents the common mistake of treating the auditor as an unpaid consultant who will design your control set for you.

Version literacy matters in RFPs. When a questionnaire asks "Are you SOC 2 compliant?" the precise answer is that you have obtained an attestation report against the TSC for a defined system and period. Cite the categories in scope, Type I versus Type II, and the period end date. Bridge letters from your auditor may cover the gap between period end and today for customers who need continuity language; ask your firm what they will support before promising bridge letters in sales cycles.

US and Canada-facing B2B SaaS companies encounter SOC 2 most sharply once mid-market or enterprise procurement runs a security review. Trigger events include a first six-figure ACV deal with a security questionnaire, a marketplace or partner program that lists SOC 2 as a listing requirement, a cyber-insurance renewal that asks for attestation status, or a board that wants an external signal before expanding production access. Fintech, developer infrastructure, HR tech, and health-adjacent (non-HIPAA) products see the ask earlier because buyers are themselves regulated or heavily questionnaire-driven.

You do not need SOC 2 on day one of a pre-seed prototype with no paying customers and no production customer data. Waiting too long is also expensive: when three enterprise opportunities stall in security review simultaneously, opportunity cost often exceeds a bounded Security-only Type II program. A practical heuristic for many Series A and B teams is to start readiness when pipeline consistently includes buyers who ask for a report, or when a single strategic deal makes the report a hard gate — then keep scope tight rather than boiling the ocean with every Trust Services Category.

Persona lenses help sequencing. A CTO at Series A usually owns budget and auditor selection and cares about deal unblock versus engineering distraction. A security or compliance engineer owns control mapping, evidence tooling, and sample responses. A VP of Engineering cares that change management and access reviews fit existing deploy and IAM workflows rather than inventing parallel rituals. Legal and privacy counsel care that the system description matches contracts and that Privacy category scope does not accidentally imply GDPR certification. Align those stakeholders early so category selection and boundary decisions are not reopened mid-fieldwork.

Geography and vertical still dominate. If your next twelve months of revenue are almost entirely US SaaS with SOC 2 in every RFP, prioritize SOC 2. If EU or UK enterprise contracts already name ISO 27001, you may lead with certification and treat SOC 2 as a parallel or follow-on artifact. If you process PHI as a covered entity or business associate, HIPAA obligations apply regardless of SOC 2 — the attestation does not replace the Security Rule, Privacy Rule, or Breach Notification Rule. GDPR applies when you process personal data of people in the EEA under GDPR's territorial scope; SOC 2 Privacy is not a GDPR compliance certificate.

Avoid vanity scope. Adding Availability and Confidentiality because a competitor's marketing page lists them, without contractual or risk drivers, lengthens observation windows and sample sets. Match artifacts to buyer geography and contract language first, then expand categories in a later report period when evidence muscle exists.

A SOC 2 program has three interlocking layers: the system you describe, the criteria you claim, and the controls and evidence that satisfy those criteria. The system boundary defines products, environments, infrastructure accounts, people roles, and subprocessors in scope. Everything material to how the service is delivered and how security commitments are met should be either in scope or explicitly out of scope with a rationale customers can understand. Ambiguous boundaries — for example marketing a "platform" while the report only covers one microservice — create customer trust risk and late-stage description rewrites.

Trust Services Categories determine which criteria apply. Security brings CC1–CC9. Those Common Criteria are the spine of almost every SaaS report. CC1 and CC2 address culture, integrity, board or governance oversight where applicable, and how security commitments are communicated. CC3 covers risk assessment and fraud considerations relevant to the system. CC4 addresses monitoring, including how deficiencies are identified and remediated. CC5 covers selection and development of control activities and technology general controls. CC6 is logical and physical access — identity lifecycle, authentication, authorization, secrets, network boundaries, and related topics; SaaS teams live here daily, and /controls/soc-2/cc6-1 is a typical entry point for access-control evidence patterns. CC7 covers system operations: detection, response, backup, and related operational monitoring. CC8 covers change management — authorize, design, test, approve, and implement changes — with /controls/soc-2/cc8-1 a common deep dive. CC9 covers risk mitigation including vendor and business disruption considerations that interact with your subprocessor program.

When you add Availability, you take on criteria around capacity, environmental protections as applicable, recovery, and monitoring against availability commitments. Processing Integrity adds expectations that system processing is complete, valid, accurate, timely, and authorized for the defined processing. Confidentiality adds identification and protection of confidential information per commitments. Privacy aligns to the TSC Privacy criteria, which are related to but not identical to legal privacy regimes — treat legal counsel as authoritative for GDPR, CCPA, and similar statutes.

Type I versus Type II is an examination design choice, not a maturity badge by itself. Type I evaluates whether controls are suitably designed and described as of a point in time. Type II evaluates design and operating effectiveness over a period. Enterprise buyers overwhelmingly prefer Type II with a recent period end. Some organizations obtain a Type I to prove design readiness while the observation window runs; others go straight to Type II. Compare the tradeoffs at /compare/soc-2-type-1-vs-type-2.

Evidence is population-based. Auditors ask for complete lists — all production engineers in the period, all production deploys, all new vendor contracts — then sample. Dated, attributable artifacts beat undated screenshot binders. Points of Focus from the 2022 revision help you interpret what "good" looks like for a criterion, but the opinion still maps to criteria. Your system description must match reality: services named in sales decks, regions of data residency, and subprocessors listed in your trust center should reconcile with the report. Mismatches are a frequent source of customer follow-up questions even when the opinion is unmodified.

Complementary user entity controls (CUECs) appear in many SaaS reports: responsibilities customers must fulfill for the system to meet commitments — for example configuring SSO, managing their own user access, or encrypting data before upload when that is the design. Sales engineers should know the CUECs so customer security reviews do not treat shared-responsibility language as a gap in your opinion. Subservice organizations similarly appear when you carve in or carve out cloud providers and critical platforms; the description must state whether you use inclusive or carve-out methods and how you monitor those providers.

Start with scoping decisions that you will defend for a year: which products and environments are in the system, which Trust Services Categories apply, whether you pursue Type I, Type II, or Type I then Type II, and which legal entities and cloud accounts are covered. Write a draft system description outline early — data flows, customer responsibilities, subprocessors, and complementary user entity controls — so engineering and sales share one narrative.

Run a gap assessment against the in-scope criteria. Map each criterion to one or more controls you already operate or must build. Typical SaaS gaps cluster around formal access reviews, documented change approvals that match how you actually ship, incident classification and communication, vendor risk reviews for material subprocessors, and endpoint or production access hygiene. Prefer controls that ride existing systems (IdP logs, CI/CD, ticketing, cloud config) over parallel spreadsheets that rot.

Remediate in priority order: identity and access, change management, logging and alerting, risk assessment cadence, and vendor management unlock the most criteria per unit of effort. Publish policies that match practice — auditors and customers both notice theater policies. Stand up evidence workflows: weekly or monthly exports, owner assignments, and retention so the observation window accumulates proof automatically instead of in a pre-audit scramble.

Readiness is a dry run. Walk your own populations, pull sample-sized evidence, and fix broken links between tickets and deploys. Optional readiness assessments from advisors can help, but they do not replace management ownership of the assertion. Select a CPA firm with SaaS and cloud experience; agree on period dates, walkthrough schedules, and how samples will be requested. Avoid changing IdP or ticketing systems mid-window without a migration evidence plan.

Fieldwork includes management interviews, walkthroughs of critical processes, and sample testing. Respond with complete populations first, then sample items, with clear timestamps and system of record citations. When exceptions appear, document remediation and compensating controls rather than arguing aesthetics. Review the draft report for factual accuracy in the system description and control wording — opinion shopping is inappropriate, but correcting misstatements about your architecture is required.

Distribute under NDA or appropriate agreements. Maintain continuous evidence so the next Type II period is incremental. Bake access reviews, deploy logs, vulnerability remediation tracking, and vendor reviews into ordinary ops. Assign named control owners with backups; orphan controls fail both audits and incident response when the only person who understood the control leaves.

Timeline is mostly a function of control maturity and observation-window length, not auditor calendar magic. Teams that already enforce SSO, documented deploys, centralized logging, and quarterly access reviews often reach Type II readiness in roughly three to six months of focused remediation and evidence hygiene. Organizations inventing those practices from scratch commonly need six to twelve months before a credible Type II window can start — starting the clock before controls operate simply produces exceptions.

Type I can complete faster because it is point-in-time design testing, sometimes in a few months after remediation. Many buyers still insist on Type II, so a Type I-only strategy may unblock a subset of deals while leaving enterprise cycles waiting. Observation windows of three months appear in earlier reports; six to twelve months are preferred by mature procurement teams. Longer windows mean more samples and more chances for exceptions, but they also read as stronger operating history.

Critical path items that routinely slip schedules: agreeing the system description across product and security, completing the first clean access review with a full population, collecting cloud and IdP evidence without admin bottlenecks, scheduling auditor fieldwork around freezes and launch weeks, and remediating penetration-test or vulnerability findings that management wants closed before period end. Parallelize auditor selection and contracting with remediation; the longest path is usually evidence maturity.

Build a shared calendar that includes access-review due dates, vulnerability remediation SLAs, vendor review cycles, and quiet periods around fieldwork. If you plan a major infrastructure migration, either finish it before the window or document the dual-running controls. For planning ranges and cost coupling, use /costs/soc-2/overview and /costs/soc-2/type-2 alongside this timeline guidance — shorter calendars rarely survive first contact with incomplete populations.

A realistic first Type II plan for a Series B SaaS company with partial controls might allocate: one month to freeze scope and draft the system description; two to three months to close high-priority gaps in access reviews, change tickets, and logging; a three- or six-month observation window with monthly evidence hygiene; then four to six weeks of fieldwork and draft cycles. Compressing the observation window below what buyers will accept may win calendar bragging rights and still lose deals. Confirm target customers' freshness and duration expectations before locking period dates with your CPA firm.

All-in first-year SOC 2 cost for a small or mid-size SaaS company commonly spans the tens of thousands of dollars when you combine CPA firm fees, optional compliance automation or GRC tooling, penetration testing if required by your risk program or customers, policy and training effort, and — most underestimated — internal engineering and security time. Type II costs more than Type I because operating-effectiveness testing spans the observation window and usually involves more samples and follow-ups.

Auditor fees vary with system complexity, number of Trust Services Categories, multi-product or multi-cloud boundaries, and firm positioning. A single-product, Security-only SaaS on one cloud account is priced differently from a platform with multiple customer-facing services, many subprocessors, and Availability plus Confidentiality in scope. Automation platforms can reduce spreadsheet toil for evidence collection; they do not replace control ownership, and they become a line item you should compare against the hours they actually save your team.

Hidden and soft costs dominate many post-mortems. Engineers pulled into evidence archaeology during fieldwork are not shipping product. Deals that slip a quarter waiting for a report have a real revenue cost. Reworking the system description after sales has promised a broader boundary than security scoped is expensive politically and financially. Treating published educational ranges as quotes is a planning error — obtain firm proposals for your boundary and categories.

Compare structured ranges and variance drivers on /costs/soc-2/overview and Type II-specific notes on /costs/soc-2/type-2. When you also pursue ISO 27001, model shared control spend once and certification or attestation fees separately; the /compare/soc-2-vs-iso-27001 page discusses sequencing so you do not double-pay for parallel consultancies that reinvent the same IAM and change-management narratives. Revisit budget each report period: surveillance-like continuous evidence is cheaper than rediscovering owners every year.

Budget line items worth listing explicitly for finance: CPA firm engagement letter amount and out-of-scope rate cards; compliance automation annual seats; penetration test if in the year's assurance plan; security training platform; and a contingency for remediation engineering during fieldwork exceptions. Contrast those with the non-cash cost of delaying an enterprise renewal. When leadership asks for a single number, give a range tied to Security-only versus multi-category scope and point to /costs/soc-2/overview for structured variance drivers rather than inventing false precision.

ISO/IEC 27001 overlaps heavily with SOC 2 at the technical and organizational control layer — access control, logging, change, supplier security, incident response — but the output differs. ISO 27001 yields an accredited certification of an Information Security Management System; SOC 2 yields a CPA attestation report against the Trust Services Criteria. US procurement language usually asks for SOC 2; EU and UK schedules often ask for ISO 27001. Sequencing guidance and overlap framing live at /compare/soc-2-vs-iso-27001. Many teams complete a Security Type II first for US revenue, then extend ISMS documentation, internal audit, and management review for ISO certification without rebuilding IAM from scratch.

Inside SOC 2, Type I versus Type II is its own decision tree: design-only speed versus operating-effectiveness credibility. Use /compare/soc-2-type-1-vs-type-2 when stakeholders confuse "we have SOC 2" with the report type buyers actually require. Category expansion (Availability, Confidentiality, and others) is another internal comparison — add categories when contracts and risk assessments justify them, not when marketing wants a longer acronym list.

Legal regimes are not substitutes. GDPR imposes obligations for personal data in scope of the Regulation; Article 32 security-of-processing measures often look familiar to SOC 2 and ISO control owners, but a SOC 2 report does not prove GDPR compliance. HIPAA applies to covered entities and business associates handling PHI; SOC 2 may support a vendor review narrative but does not replace required HIPAA safeguards or BAAs. NIST CSF can help you structure risk discussions and communicate maturity to boards without replacing either attestation or certification.

Operate one crosswalk for SOC 2 criteria, ISO Annex A themes, and legal articles that affect your product so engineering implements a single control set with multiple mappings. Link outward from this hub to control references (for example /controls/soc-2/cc6-1) and cost pages rather than maintaining conflicting checklist copies in Notion and the wiki.