SOC 2 readiness for startups: what auditors ask for

SOC 2 readiness means putting security controls in place, and the evidence that they work, before an independent CPA firm examines them. For a startup that usually means a short list of written policies, tighter access and change management in the cloud, and a few months of records. Then you choose a Type I report (design on a date) or a Type II report (operation over a period).

The work is less about documents than about habits. Auditors test what you actually did, not what your policy says you do.

What is SOC 2?

SOC 2 is a report from a licensed CPA firm on the controls at a service organization, meaning a company that holds or processes data for its customers. The firm measures your controls against the AICPA Trust Services Criteria (the 2017 criteria, with points of focus revised in 2022).

The criteria cover five categories:

• Security — required in every SOC 2. Its criteria, known as the common criteria, cover governance, risk assessment, access, operations, change management and vendor risk.
• Availability — whether the system is up and recoverable as committed.
• Processing integrity — whether processing is complete, accurate and timely.
• Confidentiality — how you protect information designated confidential.
• Privacy — how you collect, use, keep and dispose of personal information.

There is no pass or fail and no certificate. The report contains your description of the system, your written assertion, and the auditor's opinion. SOC 2 reports go to customers and prospects, usually under a nondisclosure agreement. A shorter SOC 3 report is designed for general public use.

SOC 2 Type I vs Type II

The AICPA publishes an illustrative Type 2 report that shows the structure your buyers will read.

A Type I is faster, but many buyers treat it as a step, not an answer. If your first large deal needs a report this quarter, a Type I now and a Type II later is a common path.

How long does SOC 2 take?

Timelines vary with how much is already in place. As a typical shape:

1. Readiness: a few weeks to a few months to close gaps, write policies and start collecting evidence.
2. Type I: the auditor tests design as of a date you choose once readiness is done.
3. Type II observation window: there is no AICPA minimum period. First reports commonly cover three to six months; later reports usually cover twelve months, so each report follows on from the last.
4. Fieldwork and report: the auditor tests samples after the window closes and issues the report, typically some weeks later.

The observation window is the part you cannot compress. Start it only when controls are running, because an exception inside the window appears in the report.

What do SOC 2 auditors ask for?

Expect two kinds of request: documents that describe the system, and samples that prove controls ran.

Documents

• A system description: services, infrastructure, software, people, data flows and boundaries.
• Information security policies, approved and dated, with annual review.
• A risk assessment and the controls that answer each risk.
• An organization chart, and the list of vendors and subservice organizations (for example, your cloud provider) with the controls you rely on them for.

Samples, drawn by the auditor

• New hires: signed policies, security training, background checks where your policy requires them.
• Leavers: access removed within the time your policy states.
• Quarterly access reviews for production, the cloud console, source control and key software-as-a-service tools.
• Code changes: pull request, peer review and approval before production deploy.
• Vulnerability scans, patching records, and follow-up on findings.
• Backups and at least one tested restore.
• Incidents: the log, the response, and any lessons recorded.
• Vendor reviews: security reports or questionnaires for critical vendors.

SOC 2 readiness checklist for startups

Work through this list before you start a Type II window.

1. Set scope. Pick the product and environments in scope. Start with Security; add Availability or Confidentiality only if customers ask for them.
2. Choose an auditor early. A CPA firm that works with companies your size can confirm scope and sampling expectations up front.
3. Write the core policies. Information security, access control, change management, incident response, business continuity, vendor management, data classification and retention, acceptable use.
4. Fix identity. Single sign-on for every tool that supports it, phishing-resistant multi-factor authentication (passkeys or security keys), no shared accounts, least-privilege roles.
5. Lock down the cloud foundation. Separate production accounts or projects, encryption at rest and in transit, central logging, alerting, and infrastructure as code so changes are reviewable.
6. Protect the main branch. Required reviews, required checks, no direct pushes to production, and a record of who approved each release.
7. Manage endpoints. Disk encryption, screen lock and updates on company laptops, with a way to prove it.
8. Run the people controls. Onboarding and offboarding checklists, annual security training, signed policy acknowledgements.
9. Assess vendors. Keep a vendor list, rate risk, and collect SOC 2 reports from critical vendors each year.
10. Test recovery. Document a restore test and an incident tabletop exercise.
11. Do a readiness review. Walk the controls with the evidence in hand and close gaps before the window starts.

Where compliance automation tools fit

Tools such as Vanta and Drata connect to your cloud accounts, identity provider, code host and HR system. They track control status, collect evidence on a schedule and give the auditor a shared view. For a small team, that removes a lot of manual screenshot work.

What they do not do is design your controls or run them. A tool can flag that an access review is overdue; a person still has to do the review and act on it. A tool's policy templates also need editing to match how you actually work, because auditors test against your written policy. Treat the tool as the evidence system and plan the engineering work separately.

Why SOC 2 wins enterprise deals

Enterprise buyers run a security review before they sign. A current SOC 2 Type II report answers many of the questions in that review at once, and procurement teams often ask for one by name.

It also shortens the conversation that follows. With a report and a bridge letter covering the time since the period ended, a buyer's security team can focus on the few questions specific to their use. Without one, you answer long questionnaires deal by deal.

How SOC 2 differs by company stage

• Startups: one product, a small cloud footprint, Security only. The priority is a clean foundation and the habit of keeping evidence. This is where building it right the first time costs least.
• Growing companies: more tools, more people, more customers asking. The work shifts to keeping controls running as the team grows, adding categories customers request, and mapping SOC 2 to ISO 27001 or HIPAA where needed.
• Enterprises: many systems and business units, often several reports and frameworks. The focus is shared controls, clear ownership and evidence collected once for several audits.

If you want help getting your cloud foundation and evidence ready, see our cloud and DevSecOps practice or talk to us.

Frequently asked questions

Is SOC 2 required by law?

No. SOC 2 is a voluntary examination under AICPA standards. It becomes a requirement when customers put it in their contracts or security reviews, which is common in enterprise sales.

Should a startup get a Type I or a Type II first?

It depends on deal timing. If a buyer needs something within a few months, a Type I shows your controls are designed; start the Type II window soon after. If there is no deadline, many startups go straight to a Type II.

Can we do SOC 2 without a compliance automation tool?

Yes, if you have a reliable way to collect and store dated evidence, such as tickets, exports and a shared repository. Tools reduce the manual effort, but they are not required by the AICPA or by auditors.

Which trust services categories should we include?

Security is always included. Add Availability if customers depend on your uptime commitments, and Confidentiality if you handle their confidential data. Privacy is less common and adds significant scope.

What happens if the auditor finds an exception?

The exception is described in the report, along with your response. A few exceptions do not necessarily mean a qualified opinion, but the auditor decides, so fix root causes quickly and record what you did.