"How do we pass SOC 2" is the question most first-time startups ask, and the honest answer starts by correcting the premise. SOC 2 is not an exam with a passing score and it does not produce a certificate. An independent CPA firm audits your controls against the AICPA Trust Services Criteria and issues an opinion, a written report saying whether the controls were suitably designed and, for the report type almost every buyer actually wants, whether they operated effectively over an observation period. "Passing" means the auditor's opinion comes back unqualified: no exceptions serious enough to qualify it. Everything below is the process that gets a startup to that unqualified opinion, and it is mostly about scope and discipline, not a checklist of code changes.
Type I versus Type II, and why Type II is the one that matters
A Type I report checks whether your controls are suitably designed as of a single date. It answers "if these controls operated as described, would they meet the criteria," but it says nothing about whether they actually held up in practice. A Type II report checks the same controls for operating effectiveness across an observation window, commonly three months for a first report and six to twelve months for a renewal. It answers the question a buyer's security review actually cares about: did access control, change management, and monitoring hold up over real time, not just look right on paper.
Most startups eventually need Type II, because that is what enterprise procurement and vendor-security questionnaires increasingly ask for by name. Type I still has a role: it is faster to produce (no window to wait out) and some startups use it as a first artifact to show momentum to an early enterprise deal while the Type II window runs in parallel. Neither report is a certification and neither has a numeric score; the deliverable is a report containing your (management's) description of the system and controls, your assertion, the auditor's tests and results for a Type II, and the auditor's opinion.
Scope before you build a single control: only Security is mandatory
SOC 2 is organized around five Trust Services Categories: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Security, the Common Criteria (the CC-numbered criteria, CC1 through CC9), is the only mandatory category; every SOC 2 report includes it. The other four are opt-in, and a startup that scopes all five by default is usually building and evidencing controls nobody asked for.
Scope from what your buyers' security reviews actually ask, not from a template. A B2B SaaS company is typically Security plus Availability (you commit to uptime) and Confidentiality (you handle customer business data under an NDA-like duty). Processing Integrity mostly matters if your system's core function is processing transactions where completeness and accuracy of that processing is the product's promise, think payments or billing, not just "we have a database." Privacy is the AICPA category for personal information handling commitments in your own privacy notice, a separate thing from GDPR or other statutory privacy law; most startups meet buyer expectations on personal-data handling without adding it. Ask your first few enterprise prospects what their vendor-security team requires before committing to a scope; it is far cheaper to add a category later than to have evidenced one nobody needed.
The realistic timeline
Readiness comes first: a gap analysis against the criteria you scoped, writing the policies the criteria require (access control, change management, incident response, and others), and closing control gaps in your actual systems (enforcing MFA, turning on audit logging, formalizing a change-approval step). For a small startup using a compliance-automation platform to track evidence and controls, readiness commonly takes four to eight weeks; longer if a control has to be built rather than just documented, like standing up centralized logging that did not exist before.
For a Type II report, the observation window comes next, and its length is not something a vendor can shortcut: the controls have to operate for an agreed period before the auditor can test them, so a three-month window is three calendar months, not a batch of evidence assembled after the fact. There is no universal statutory minimum; the period is agreed with your CPA firm and shaped by what your intended report users expect. First reports commonly cover three to six months, renewals often six to twelve. During the window, controls in scope need to operate consistently: a gap can become a sampled exception depending on the auditor's testing, its nature, frequency, and significance, not automatically.
Audit fieldwork follows the window: the auditor reviews evidence, samples transactions and changes, interviews control owners, and drafts findings, typically two to four weeks, then issues the final report. Altogether, a startup's first Type II report is realistically five to nine months from kickoff to report in hand as a typical benchmark, not an AICPA requirement. Treat a promise of "SOC 2 in a month" carefully: it commonly means readiness work, a Type I report, or an unusually short reporting period a specific auditor accepted, not a conventional multi-month Type II.
What actually breaks an observation window
The window is where most first-time startups get an unpleasant surprise, because it is long enough for normal engineering work to quietly undo a control the readiness phase just finished setting up. A one-line pull request that widens an IAM policy to a wildcard for convenience, a cleanup that drops the audit log line for a privileged action, a hotfix that skips the usual change-approval step under deadline pressure: none of these look like compliance work while they are happening, and each is exactly the kind of thing that can become a sampled exception if it lands inside the window and the auditor's testing catches it. The control-level detail on which criteria actually show up in a diff, mostly the CC6 logical-access family plus CC7.2 monitoring and CC8.1 change management, is in the SOC 2 framework deep dive and the companion guide on what SOC 2 checks in your repo.
This is the layer a pull-request-level compliance check adds during the window: it reads each change against the criteria you scoped and names the one it touches, for example CC6.1 on the widened IAM policy, as a review comment at the moment the change is proposed. Caught there, the team can assess and fix it before it ever ships, usually far cheaper than after the fact. Missed, it is a change the auditor could sample as an exception you would have to explain, which can complicate the opinion you spent months working toward.
What this does not replace
A pull-request check is one layer of a much larger process, and it is worth being precise about the rest of it, because none of it is heygrc's job. Choosing your auditor, scoping your trust categories, writing your policies, running the readiness gap analysis, collecting evidence across your whole stack (identity provider, cloud config, HR onboarding and offboarding, vendor management) for the full observation window, and issuing the opinion: all of that is the compliance program, usually run through a platform built for exactly that (the guide on compliance automation tools maps that layer) plus your auditor. heygrc is built to read pull requests against the criteria you selected and name the control a change touches. It does not perform your audit, does not replace your auditor, and does not itself get you to an unqualified opinion; it is built to help the team catch control-relevant pull-request changes early, during the program, before they can turn into the kind of exception that makes the opinion harder to earn.