SOC 2 Audit Process Explained: Type I vs Type II and How to Prepare

Somewhere in your sales pipeline right now, a deal is stuck in a security review. The prospect's procurement team has sent a vendor questionnaire, your champion is asking when you'll "have SOC 2," and nobody on the engineering side is quite sure what that actually requires of them. This is the moment most B2B SaaS companies first take SOC 2 seriously — not as an abstract compliance checkbox, but as a gate blocking revenue.

SOC 2 isn't a certification you pass or fail; it's an independent auditor's opinion, delivered as a report, on whether your controls meet a defined set of criteria. Enterprise buyers treat it as a proxy for "can we trust this vendor with our data," and increasingly it's a prerequisite just to get past procurement, not a differentiator. This article walks through what actually happens during a SOC 2 audit, how Type I differs from Type II, and how to prepare your organization so the audit doesn't surface embarrassing gaps in front of a paying customer's security team.

The five Trust Services Criteria

SOC 2 reports are built against the AICPA's Trust Services Criteria (TSC) — five categories of controls an auditor can evaluate. You don't get audited against all five by default; you scope the engagement to the categories relevant to your service.

Security is the only mandatory criterion — every SOC 2 report includes it, which is why it's often called the "common criteria." It covers protection against unauthorized access, covering things like access control, network security, change management, and incident response. The other four are optional and chosen based on what you actually promise customers:

• Availability — the system is available for operation and use as committed (relevant if you have uptime SLAs).
• Processing Integrity — system processing is complete, valid, accurate, and timely (relevant for payment processors, billing systems, or anything doing computation customers rely on being correct).
• Confidentiality — information designated as confidential is protected (relevant if you handle customer business data, IP, or contracts under NDA).
• Privacy — personal information is collected, used, retained, and disposed of appropriately (relevant if you process significant PII, though many companies handle privacy separately under GDPR/CCPA programs instead).

Most SaaS companies scope Security plus Availability and Confidentiality, and skip Processing Integrity and Privacy unless their product specifically demands it. Scoping too broadly adds audit cost and control burden for criteria your customers never asked about; scoping too narrowly means you'll be back in front of the auditor next year adding categories a big customer now requires.

A SOC 2 report doesn't prove your product is secure — it proves that an independent third party checked your specific claims about your controls and didn't find them to be lying.

Type I vs Type II: point-in-time vs over-time

This is the distinction that trips up first-timers. Both report types cover the same Trust Services Criteria and the same system description — the difference is the time dimension.

A Type I report evaluates whether your controls are suitably designed as of a single specified date. The auditor looks at your policies, your access control configuration, your change management process, and confirms the design would achieve the stated control objectives — but they don't test whether those controls actually operated correctly over time. It's a snapshot: "as of March 1, these controls exist and are designed correctly."

A Type II report evaluates operating effectiveness over an observation period, typically three to twelve months. The auditor doesn't just check that an offboarding policy exists — they pull a sample of actual employee terminations from the period and verify access was revoked within the policy's stated timeframe, every time. This is a materially higher bar, because it requires your controls to have actually been running consistently, not just documented.

Most enterprise security teams will explicitly require a Type II report, because a Type I only tells them your controls looked good on paper on one day — it says nothing about whether you actually follow your own process. Type I reports are still useful, though: many first-time companies do a Type I as a faster, cheaper way to get a report in hand while their Type II observation period runs in parallel, or to prove momentum to a customer who needs something now. If you're choosing between them with no time pressure, go straight to Type II — it's the report that actually unblocks enterprise deals.

The audit process, step by step

The end-to-end process, from a standing start to a final report in hand, typically runs six to eighteen months depending on your starting maturity and whether you're pursuing Type I or Type II. The stages are consistent regardless of company size:

1. Readiness assessment / gap analysis. Either run internally or with a compliance consultant, this maps your existing controls against the TSC and flags what's missing — no formal access review process, no documented incident response plan, secrets in a shared spreadsheet, whatever it is. This is where scope (which TSC categories apply) also gets decided.
2. Remediation. You close the gaps: write missing policies, implement technical controls (SSO enforcement, MFA, centralized logging, vulnerability scanning), and assign control owners. This is usually the longest phase and the one most often underestimated.
3. Choosing an auditor. SOC 2 reports must be issued by a licensed CPA firm. Firms vary widely in cost, turnaround, and industry familiarity — get references from other companies your size, and confirm the firm has audited companies with a similar tech stack (cloud-native, containerized, CI/CD-heavy) rather than only traditional enterprises.
4. The observation period (Type II only). Your controls need to run, unmodified in substance, for the full window — commonly 3 months for a first report, extending to 6 or 12 months in later years. Nothing about the audit "happens" during this window except your normal operations generating evidence.
5. Evidence collection. Throughout the observation period (or continuously, if you're using automated tooling), you gather proof that controls operated: access review sign-offs, change tickets linked to deployments, vendor risk assessment records, onboarding/offboarding tickets, and so on.
6. Fieldwork. The auditor requests evidence samples, interviews control owners, and tests a subset of instances for each control — not every access grant, but a statistically reasonable sample across the period.
7. Draft report review. The auditor circulates a draft. This is your chance to catch factual errors in the system description or push back on findings before anything is final — not to negotiate away legitimate exceptions.
8. Final report. You receive the signed SOC 2 report, typically restricted-use (shared under NDA with prospects and customers, not published publicly).

What auditors actually ask to see

Auditors don't take your word for it — every control needs corroborating evidence, and for Type II that evidence has to span the whole observation period, not just the week before fieldwork. The recurring categories:

• Access control reviews. Periodic (usually quarterly) evidence that someone actually reviewed who has access to production systems, critical SaaS tools, and customer data, and revoked what shouldn't be there.
• Change management logs. Evidence that code changes went through review and approval before deployment — pull requests with required approvals, linked tickets, CI pipeline gates.
• Vendor risk assessments. Documentation that you evaluated the security posture of subprocessors and critical vendors before onboarding them, and periodically thereafter.
• Incident response records. Evidence your incident response plan isn't just a document — tickets or postmortems from actual (even minor) incidents showing the process was followed.
• Employee onboarding/offboarding evidence. Proof that new hires completed security training and background checks where applicable, and that terminated employees had access revoked within the committed window across every system, not just the obvious ones.

Manually assembling this evidence every quarter is why compliance automation platforms like Vanta, Drata, and OneTrust have become standard in this space. They connect via API to your cloud provider, identity provider, HR system, and code repositories, and continuously pull evidence — flagging a control as failing the moment an offboarded employee still has GitHub access, rather than letting your team discover it during fieldwork. They don't replace the auditor or the underlying controls, but they turn evidence collection from a quarterly scramble into a standing dashboard, which is a meaningful difference when you're trying to run this as an ongoing program instead of a project.

A real-world example

Consider a 40-person SaaS startup that just had a $200K ARR enterprise deal stall because the buyer's security team requires a SOC 2 Type II report from any vendor touching their data. The company has never done a formal audit before.

Month 0–1: readiness assessment reveals the expected gaps — no formal access review cadence, MFA not enforced org-wide, no documented incident response plan, and vendor risk assessments that exist only as informal Slack threads. They also discover their AWS account has several engineers with standing production access nobody remembers granting.

Month 1–3: remediation. They enforce SSO and MFA across all critical systems, stand up a compliance automation tool to start evidence collection immediately, write and socialize an incident response plan, and implement a quarterly access review process — the first cycle of which becomes their first piece of Type II evidence.

Month 3: they select an auditor and formally begin the observation period, choosing Security and Availability as their scope (they skip Confidentiality initially since the deal in question doesn't require it).

Month 3–6: the three-month observation period runs. This is the phase that actually took longest in practice — not because remediation was hard, but because the company had to demonstrate consistent operation, and one missed quarterly access review or one change deployed without a linked approval ticket would have meant restarting the clock on that control. Engineering discipline during this window, not the initial fix-up work, is what determined the report's cleanliness.

Month 6–7: fieldwork and draft report review. The auditor samples a handful of deployments, a handful of access changes, and interviews the engineering lead and the person handling HR offboarding. One minor exception is noted — a single offboarding ticket closed two days past the policy's stated window — and the company writes a remediation note rather than contesting it.

Month 7: final report in hand, roughly seven months after the readiness assessment began. The stalled deal closes within weeks of the report being shared under NDA.

Common mistakes to avoid

• Starting the observation period before controls are actually operating consistently. Teams under deal pressure sometimes start the Type II clock the same week they wrote a new policy, before anyone has actually followed it even once. The result is predictable: the first quarterly access review either doesn't happen on schedule or happens sloppily, and it shows up as an exception in the final report. Wait until a control has run at least one full cycle before the observation period officially begins.
• Treating SOC 2 as a one-time project instead of an ongoing program. A Type II report covers a fixed historical window and expires; customers expect a new one annually, with no coverage gap between reports. Companies that disband their compliance effort right after the first report often scramble to reconstruct evidence a year later. Access reviews, vendor assessments, and evidence collection need to keep running continuously, ideally on automated tooling, so the next audit is a formality rather than a re-do.
• Not involving engineering early enough on technical controls. Access reviews, centralized logging, and change management approval gates live in engineering's tooling, not in a policy document. When compliance or legal teams try to define these controls without engineering input, they end up writing policies the team can't actually satisfy technically — or duplicating access review work across five different systems because nobody consolidated identity to a single SSO provider first. Bring engineering into scoping and control design from day one, not at fieldwork.

Frequently asked questions

Do we need Type I before Type II, or can we skip straight to Type II?
You can go straight to Type II — there's no requirement to complete a Type I first. Companies choose Type I as an interim step mainly when they need something to show customers faster than a full observation period allows, or when their controls are too new to have a meaningful operating history yet. If you have the runway, skipping directly to Type II saves an audit cycle and cost.

How long is a SOC 2 report valid for?
Indefinitely in a technical sense, but practically it has a shelf life of about 12 months. The report only covers a specific historical period (a date for Type I, a window for Type II), so enterprise customers typically require a report dated within the last year — which is why this needs to be an annual, recurring exercise, not a one-time achievement.

Can a small startup with no dedicated compliance team realistically get through this?
Yes, and it's common — many of the companies going through their first SOC 2 are under 50 employees. The key enabler is compliance automation tooling to keep evidence collection from consuming a person's full-time attention, plus clear ownership: someone (often a founder, head of engineering, or first compliance hire) needs to own the program even if it's not their only job.

SOC 2 is ultimately a forcing function: it pushes companies to formalize security practices that good engineering teams often do informally anyway, and it gives customers a standardized way to verify that. Treat the audit date as a checkpoint on an ongoing program rather than a finish line, resource the observation period with the same seriousness as remediation, and the report becomes a routine annual artifact instead of a recurring fire drill.