Short answer
SOC 2 is an audit of how well a company protects customer data, based on the AICPA's Trust Services Criteria. For startups, readiness means putting controls in place, like access management, logging, encryption and change management, and keeping evidence that they work. A licensed CPA firm performs the audit itself.
Key takeaways
- SOC 2 is a report from a CPA firm, not a certificate you buy.
- Type I checks design at a point in time. Type II checks operation over a period.
- Most technical controls live in your cloud and CI/CD.
- Evidence matters as much as the controls themselves.
What Is SOC 2?
SOC 2 is a report, written by an independent CPA firm, on how well your company's controls protect customer data. It is measured against the Trust Services Criteria defined by the AICPA: security, availability, processing integrity, confidentiality and privacy. Security is always in scope. The others are included when they matter to what you promise customers, for example availability if you offer uptime commitments.
For a startup, SOC 2 usually arrives as a sales requirement. An enterprise customer's security team sends a questionnaire, and a SOC 2 report answers most of it at once. Understanding what the audit actually checks makes the preparation far less daunting.
What Is the Difference Between Type I and Type II?
| Type I | Type II | |
|---|---|---|
| What it checks | Whether controls are designed properly | Whether controls worked over a period of time |
| When | At a single point in time | Over an observation period, often several months |
| Typical use | A first report to unblock early deals | The report most enterprise customers ask for |
Many startups start with Type I to unblock early deals, then move to Type II. The important consequence of Type II is that controls have to run consistently for months, which is why they need to be automated rather than remembered.
Which Infrastructure Controls Matter Most?
Access control comes first: single sign-on, multi-factor authentication and least-privilege roles, with access reviewed on a schedule and removed promptly when people leave. On AWS that usually means IAM Identity Center rather than long-lived IAM users and access keys. Logging and monitoring come next: an audit trail of who did what, such as CloudTrail enabled across all accounts and regions, with alerts on suspicious activity.
Encryption in transit and at rest is expected everywhere data lives. Change management means every change is reviewed and deployed through a pipeline: branch protection, required pull request approvals and no manual changes in production. Backups need tested restores, not just scheduled snapshots. And vulnerability management means dependency and container scanning, plus a written process for patching what the scans find.
Why Does Evidence Matter So Much?
An auditor does not take your word for it. For each control they ask for evidence: access review records, pull request histories, alert configurations, restore tests. Teams that collect this by hand at audit time lose weeks. Teams whose controls are built into the infrastructure, such as access defined in code, changes recorded in Git and alerts kept in configuration, can produce most of the evidence on demand.
How Do You Prepare for a SOC 2 Audit?
Decide which Trust Services Criteria apply to you, then run a gap assessment against them. Fix the gaps in order of risk, usually starting with access control and logging. Write down the policies you actually follow, rather than templates you do not. Then collect evidence continuously and engage an auditor once the controls have been running long enough to show they work.
Related service
Cloud/DevOps management
Your cloud, CI/CD and security run for you. Starts with a free audit.