SOC 2 Type II: What It Actually Takes

SOC 2 has become the de facto security certification for SaaS companies. Your prospects are asking for it, your enterprise sales team is tired of answering security questionnaires manually, and someone told you it takes “about three months.”

That timeline is misleading. Let’s talk about what SOC 2 actually involves, what it costs in real terms, and where companies waste the most time and money.

What SOC 2 Is and Isn’t

SOC 2 is an audit framework developed by the AICPA. An independent auditor examines your controls against five trust service criteria: security (required), availability, processing integrity, confidentiality, and privacy (the last four are optional, and you choose which ones to include).

The auditor produces a report that says whether your controls are designed effectively (Type I) and, for Type II, whether they operated effectively over a review period (typically 3-12 months).

What SOC 2 is NOT:

It’s not a certification. Technically, you receive an audit report, not a certificate. You can’t put a “SOC 2 Certified” badge on your website (though everyone does). There’s no pass/fail. The auditor issues an opinion.

It’s not a guarantee of security. SOC 2 says you have controls and they were operating during the review period. It doesn’t say you’re unhackable. Plenty of companies with clean SOC 2 reports have had breaches.

It’s not standardized in the way you’d expect. Two companies with SOC 2 Type II reports can have very different scopes, very different controls, and very different levels of rigor. The framework is flexible, which means reading a SOC 2 report requires understanding what’s actually in scope.

That said, SOC 2 is genuinely useful. It forces you to build real controls, document them, and prove they work. The process, done honestly, makes your security program better.

Type I vs. Type II

Type I evaluates whether your controls are suitably designed at a specific point in time. Think of it as a snapshot. “As of June 30, 2026, these controls existed and were designed to meet the criteria.”

Type II evaluates whether those controls operated effectively over a period of time. This is the one your customers want. “From July 1, 2025 to June 30, 2026, these controls were in place and working.”

Some companies skip Type I entirely and go straight to Type II. This works if your controls are already mature and you’re confident they’ll hold up over the review period. If you’re building from scratch, a Type I first can be smart. It validates your control design before you commit to a full observation period.

The review period for Type II is typically 6-12 months for your first audit. Some auditors will accept a 3-month window for the initial engagement. After the first year, it’s usually a 12-month rolling period.

Realistic Timeline

Here’s what a SOC 2 Type II engagement actually looks like, start to finish.

Months 1-2: Readiness assessment and gap analysis. Evaluate your current controls against the trust service criteria. Identify gaps. Produce a remediation plan. If you’re using a compliance platform, this is when you start configuring it.

Months 3-5: Remediation. Close the gaps. Write policies. Implement controls. Set up evidence collection. This is the bulk of the real work. If you have significant gaps (no formal change management, no access reviews, no incident response plan), this phase takes longer.

Months 6-8: Observation period begins. Your controls need to be operating and producing evidence. This is the period the auditor will evaluate. For a first-time audit with a shorter window, some auditors will start the observation period as early as month 4 if your controls are ready.

Months 9-10: Audit fieldwork. The auditor reviews your evidence, interviews your team, tests your controls. They’ll request specific samples: pull requests showing code review, access review evidence for a specific quarter, incident tickets from the observation period.

Month 11: Report issuance. Draft report, management review, final report.

Total elapsed time: 9-12 months from zero to report in hand. Anyone telling you 3 months hasn’t built the controls yet (they’re selling you a readiness assessment and calling it SOC 2) or they’re assuming you already have most controls in place.

The Actual Work Involved

Compliance platforms like Vanta, Drata, and Secureframe have made SOC 2 more accessible. They’re genuinely helpful for evidence collection, policy templates, and tracking. But they don’t do the work for you, and their marketing sometimes implies otherwise.

Here’s what you actually need to build.

Policies and procedures. Information security policy, access control policy, change management policy, incident response policy, risk assessment policy, vendor management policy, data classification policy. These need to be real documents that reflect how your company actually operates, not templates you downloaded and put your logo on. Auditors will interview your team, and if your people don’t know what’s in the policies, that’s a finding.

Access management. Formal onboarding and offboarding procedures. Quarterly access reviews (someone actually reviewing who has access to what and confirming it’s still appropriate). Least-privilege access. MFA enforcement. This is consistently one of the hardest areas because it requires operational discipline, not just technical controls.

Change management. Code review requirements. Approval workflows. Separation of duties (the person who writes the code shouldn’t deploy it to production without review). CI/CD pipeline controls. Auditors will sample your pull requests and verify they were reviewed and approved before merge.

Monitoring and alerting. You need to demonstrate that you monitor your infrastructure for security events and respond to alerts. This means actual monitoring, not just a tool that’s installed but nobody watches. Auditors will ask to see alert tickets, response times, and resolution documentation.

Incident response. A documented plan that your team has rehearsed. Evidence of tabletop exercises. If you’ve had real incidents during the observation period, evidence of how you handled them.

Risk assessment. A formal, documented risk assessment performed at least annually. This needs to identify risks, evaluate likelihood and impact, and document treatment decisions. It can’t just be a spreadsheet you filled out the week before the audit.

Vendor management. A process for evaluating third-party risk. At minimum, collecting and reviewing SOC 2 reports from your critical vendors. Maintaining a vendor inventory with risk classifications.

Business continuity. Backup procedures, disaster recovery plans, recovery testing. Auditors will verify that you test your backups. Having backups that you’ve never restored is a common finding.

What Auditors Really Look For

Having worked through many SOC 2 audits (both as the team being audited and as the team preparing companies for audit), here’s what actually matters in the fieldwork.

Consistency. Auditors sample your evidence over the observation period. If your policy says code reviews are required, they’ll pull 25-40 pull requests at random and check that all of them were reviewed. Three PRs that went straight to main without review will become a finding. Consistency over time is the core of Type II.

Evidence of operation, not just existence. A policy document proves the control is designed. What proves it’s operating? Meeting minutes from quarterly access reviews. Tickets showing incident response. Logs showing monitoring alerts were investigated. You need to produce evidence, not just show that you wrote a document.

Honest scoping. Auditors respect companies that scope their audit appropriately. If your product has a mobile app, a web app, and an API, but only the web app handles sensitive data, scope the audit to the web app. Auditors get nervous when companies scope too narrowly to avoid findings, but reasonable scoping is expected and fine.

People who understand their own controls. Auditors interview team members. They’ll ask your on-call engineer about the incident response process. They’ll ask your DevOps lead about change management. If your people can’t describe the process without reading from a document, that’s a yellow flag.

Cost and Effort Honestly

Audit fees. For a first-time SOC 2 Type II at a startup or mid-stage company, audit fees vary significantly depending on scope, auditor, and complexity. Big Four firms charge more. Boutique firms that specialize in tech companies are often a better fit and more affordable.

Compliance platform. Worth it for most companies. The evidence collection automation alone saves significant engineering time.

Internal effort. This is the cost most people underestimate. Plan for one person spending 50-75% of their time on SOC 2 for the first 6 months. After that, it drops to 20-30% for ongoing maintenance. Policy writing, control implementation, evidence collection, gap remediation, auditor questions. It adds up.

Remediation costs. Depends entirely on your gaps. If you need to implement a new IAM solution, deploy EDR across your fleet, or rebuild your CI/CD pipeline, those carry their own costs. Budget for remediation tooling proportional to the size of your gaps.

Total realistic cost for a first-time SOC 2 Type II is a significant investment when you factor in platform, audit, tooling, and internal time. This is for a typical 50-200 person SaaS company.

The variance comes from your starting maturity. A company that already has strong engineering practices, uses infrastructure as code, and has some basic policies in place will spend far less. A company starting from zero will invest considerably more.

Making It Sustainable

The first SOC 2 is the hardest. Year two gets significantly easier if you’ve built the right foundation.

Automate evidence collection. Pull request data, access logs, deployment records, uptime metrics. As much as possible, evidence should be collected automatically and continuously. This is where compliance platforms earn their cost.

Build controls into your workflow. If code review is required, enforce it with branch protection rules, not policy documents. If access reviews are quarterly, put them on a calendar with assigned owners. Controls that depend on human memory will fail eventually.

Assign clear ownership. Every control needs an owner. Not “the security team.” A specific person who’s responsible for making sure it operates and producing evidence. Distribute this across the organization. SOC 2 is not one person’s job.

Keep auditor communication open. Your auditor is not your adversary. Talk to them throughout the year, not just during fieldwork. If you’re making a significant change to your infrastructure, ask how it affects your controls. Good auditors appreciate proactive communication and will help you avoid findings.

When to Start

If you’re going to need SOC 2 in the next 12 months, start now. The most expensive part of SOC 2 is the rush. Companies that start 3 months before they need the report end up paying premium rates for auditors, cutting corners on controls, and stressing out their teams.

We help companies through the full SOC 2 lifecycle: readiness assessment, remediation, evidence collection, and audit coordination. The companies that have the smoothest experience are the ones that treat SOC 2 as a byproduct of good security practices, not as a standalone compliance project.

Build real security. Document it. Prove it works. That’s all SOC 2 is asking.