SOC 2 compliance: Type 1 vs Type 2, timeline, cost and checklist

What is SOC 2? (and why "SOC 2 certification" isn't a thing)

SOC 2 is an attestation standard from the AICPA, the American accountants' body. A licensed CPA firm examines the controls you use to protect customer data and issues a SOC 2 report describing what they found. That's it. There is no certificate, no badge issued by a standards body, and nobody "passes" in the way you pass an exam. People say SOC 2 certification anyway, including most of the buyers who'll ask you for one, so don't correct your customers. Just know that what you're producing is a report with an auditor's opinion in it.

The report matters because enterprise buyers use it as a shortcut. Instead of sending you a 300-question security questionnaire and taking your word for the answers, they read a document in which a third party has tested the claims. If you sell software to companies in the US, or to anyone with a US-style procurement process, you'll be asked for one eventually. Usually at the worst possible moment, in the middle of a deal.

SOC 2 Type 1 vs Type 2

Two flavours, and the names confuse everyone.

A Type 1 is a photograph; a Type 2 is a film. Buyers increasingly ask for the Type 2 and treat a Type 1 as a promise to get one. The sensible pattern for a first-timer is Type 1 as soon as controls are in place, with the Type 2 observation window starting the next day, so the same evidence serves both.

SOC 2 requirements: the Trust Services Criteria

There's no fixed SOC 2 controls list handed down from above. The AICPA publishes five Trust Services Criteria, you choose which are in scope, and you design controls that satisfy them. The auditor then tests your controls, not a checklist of theirs. That flexibility is the thing people find hardest about SOC 2 requirements, and also the reason a ten-person SaaS can get a report without pretending to be a bank.

Security is mandatory. The other four are optional and you add them when customers care.

SOC 2 controls list: what the auditor actually tests

Because you design your own controls, every SOC 2 controls list on the internet is really an example set. Here's what turns up in almost every SaaS report we've helped prepare, grouped the way the evidence requests arrive.

Access. MFA on everything that touches production or customer data. SSO where you can. Role-based access and no standing admin rights. A joiner and leaver process with leaver access removed promptly. Access reviews on a schedule, with a record that they happened.

Change management. Code changes reviewed in a pull request by someone other than the author, tests run in CI, deployment through a pipeline, infrastructure changed through the same process. Emergency changes have a path and get reviewed afterwards.

Logging and monitoring. Cloud audit logs (CloudTrail, Azure Activity Log, GCP audit logs), authentication logs and application logs retained and protected. Alerts on security-relevant events, and someone who responds.

Vulnerability management. Dependency and image scanning, a patch cadence, and SOC 2 penetration testing by an outside firm with findings fixed or risk-accepted in writing. Pen testing isn't literally required by the criteria, but we have never seen an auditor who didn't expect one.

Resilience. Automated, encrypted backups with a tested restore. An incident response plan that has been used or exercised. Availability monitoring and post-incident reviews if the Availability criterion is in scope.

Governance. A risk assessment with owners. Vendor management: a list of suppliers who touch customer data and their reports reviewed. Security awareness training. Background checks where the law allows. And the SOC 2 policies that describe all of it: information security, access control, change management, incident response, vendor management, acceptable use, data retention.

A lot of these controls are a query away once they exist. This is the kind of thing an auditor will ask you to prove and the kind of thing you should be able to show in thirty seconds:

# IAM users in this AWS account without an MFA device: the answer should be an empty list
aws iam generate-credential-report >/dev/null && sleep 2
aws iam get-credential-report --query Content --output text | base64 -d \
  | awk -F, 'NR>1 && $4=="true" && $8=="false" {print $1}'

How long does SOC 2 take?

The honest answer to "how long does SOC 2 take" is: readiness time plus the observation window plus the audit itself, and only the middle one is fixed.

• Readiness depends entirely on where you start. A team already deploying through CI/CD with MFA everywhere and Infrastructure as Code is mostly writing policies and collecting evidence. A team with console-built infrastructure and shared logins has engineering work to do first.
• The Type 2 observation window is agreed with your auditor and is typically between three and twelve months. Shorter windows are common for a first report; a twelve-month window is the norm once you're renewing yearly.
• The audit itself is a few weeks of evidence requests, walkthroughs and sampling, then the firm writes up the report.

So a first Type 2 report is rarely something you can produce in a quarter from a standing start, which is why buyers accept a Type 1 as a stepping stone. If you've been asked for a report with a deadline, start the readiness work now and get the Type 1 out; the Type 2 follows naturally.

SOC 2 cost: what you actually pay for

We don't publish numbers, and you should be suspicious of anyone who quotes a single figure before looking at your environment. What we can tell you is what the SOC 2 cost is made of:

1. The SOC 2 audit cost. The CPA firm's fee. It scales with the criteria in scope, the number of systems and locations, the length of the observation window and the size of the firm. Type 2 costs more than Type 1 because there's more to sample.
2. Readiness help. Optional. A consultant or engineering partner who does the gap assessment, builds the missing controls and organises evidence. Worth it if your team doesn't have the time or hasn't been through an audit before; a waste if you have a security lead who has.
3. Tooling. Compliance automation platforms (Vanta, Drata, Secureframe and others) connect to your cloud, identity provider and source control and collect evidence continuously. Paid yearly. Not required, but they cut the evidence work enormously and most auditors are used to them.
4. A penetration test. From an outside firm, yearly.
5. Your own time. The one nobody budgets. Control owners answering evidence requests, engineers fixing findings, someone project-managing the whole thing.

The cheapest SOC 2 is the one where your controls were already good engineering practice before anyone mentioned an audit. That's not a sales line; it's why we push the technical work first.

SOC 2 compliance checklist: a readiness assessment you can run now

Every "SOC 2 compliance checklist xls" you can download is a list of controls with a tick box. Useful, but it tells you nothing about how far from a report you are. This self-check is closer to a SOC 2 readiness assessment: twenty statements an auditor would effectively test, scored.

If you scored well, your next conversation is with an auditor. If you didn't, the gaps are almost certainly in access and change management, and both are engineering work rather than paperwork.

SOC 2 evidence collection and compliance automation

Evidence is where first audits go wrong. The controls exist, but nobody can show that the access review happened in March or that the backup restore was tested in June. SOC 2 evidence collection has to be designed in from the start of the observation window, not reconstructed at the end.

What works in practice:

• Put the evidence where it is generated. Pull requests are change-management evidence. CI logs are deployment evidence. Your identity provider's audit log is access evidence. Don't copy these into spreadsheets; point the auditor at the source.
• Calendar the manual controls. Access reviews, restore tests, risk assessment reviews, vendor reviews, training. Each one is a recurring ticket with an owner and a done-state that includes a record.
• Use SOC 2 compliance automation if you can justify the subscription. The platforms watch your cloud accounts, repos and identity provider for drift (an IAM user without MFA, a repo without branch protection) and gather evidence continuously. They also store policies and training records. Vanta vs Drata vs Secureframe is mostly a question of integrations and price; ask your auditor which ones they've worked with.
• Collect your vendors' reports. AWS, Azure and Google Cloud all publish their own SOC 2 reports (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager). You rely on them as subservice organisations; your auditor will want to see you reviewed them.

SOC 2 vs ISO 27001

The SOC 2 vs ISO 27001 question comes up in every scoping call. The short version: SOC 2 is an auditor's report on controls you designed, favoured by US buyers; ISO 27001 is a certificate that your information security management system meets an international standard, favoured by European and public-sector buyers. The technical controls overlap heavily. If you sell on both sides of the Atlantic you will probably end up with both, and doing SOC 2 first means ISO 27001 becomes largely a documentation exercise on top of controls you already run.

SOC 2 for startups

SOC 2 for startups has its own rhythm. You usually don't need it until a customer asks, and then you need it faster than it can be done. A few things we tell early-stage teams:

• Scope Security only for the first report. Add Availability if your contracts have uptime commitments. Leave the rest for later.
• Don't build controls you can't sustain. A monthly access review you'll actually do beats a weekly one you'll skip. The auditor tests what you said you'd do.
• Make the engineering decisions now, before the audit forces them. CI/CD, Infrastructure as Code, SSO and MFA, a secrets manager, centralised logs. These are good for the business regardless, and they're most of the Security criteria. Our DevOps maturity assessment covers the same ground from the operations side.
• Get a Type 1 out to the customer who asked, then roll straight into the Type 2 window.

Mistakes we see on first audits

• Policies downloaded from a template that describe a company you are not. The auditor tests the policy you wrote, so if it says quarterly reviews and you do them yearly, that's a finding.
• Scope creep: including every system you own instead of the ones that handle customer data.
• Evidence started three weeks before the audit instead of on day one of the window.
• Nobody owns the controls. "The team" doesn't do access reviews; a named person does.
• Treating the compliance platform as the project. It collects evidence; it doesn't make the controls exist.
• Booking the audit before the readiness work, then burning the auditor's hours on things that should have been fixed first.

How Autostat fits in

We do readiness, not audits. Our SOC 2 readiness service, with a fixed-price infrastructure package listed on the pricing page, covers the gap assessment, control mapping, access management, change-management workflows, logging and backups, policies that match how you work, and evidence collection processes, with engineers doing the technical implementation rather than handing you a list. The independent CPA firm you choose performs the examination and issues the report; we work alongside them and we don't promise an outcome, because it isn't ours to promise. Teams that want the security review and the operations side handled together usually take the Secure SaaS Growth Bundle or pair readiness with cybersecurity services.