Complete guide
SOC 2 for AWS startups
A SOC 2 report is a CPA firm's written opinion on whether your security controls are designed and operating the way you claim. For an AWS-native startup with a blocked enterprise deal, the practical question is narrower: which controls, what evidence, how long, and how much. This guide answers all four.
SOC 2 is an attestation, not a certification. AWS covers its own layer and nothing above it. A typical seed-stage AWS startup needs roughly 35 controls, spends about $20,000 to $25,000 all-in for the first year, and can be audit-ready in six to eight weeks if someone does the engineering work instead of reading a dashboard about it.
What a SOC 2 report actually is
SOC 2 is an attestation examination performed by a licensed CPA firm under AICPA standards (SSAE 18, AT-C section 205). Management asserts that its system is described accurately and that its controls are in place. The CPA examines that assertion and issues an opinion.
Three consequences fall out of that definition, and every one of them matters commercially:
- There is no certificate and no pass mark. "SOC 2 certified" is not a thing that exists. The deliverable is a report, typically 40 to 80 pages, that your customer's security team reads. Anyone who sells you a guaranteed pass is describing an outcome they do not control.
- You write the controls. The AICPA publishes criteria, not a control list. You decide what controls meet them, which is why two companies with the same report can have very different security postures, and why over-claiming in your own control descriptions is the most common self-inflicted wound in a first audit.
- The auditor must be independent. A CPA firm cannot examine controls it designed or implemented. That single rule shapes the entire vendor landscape, and it is why readiness and the audit are two different firms.
The two report types
A Type 1 reports on whether controls are suitably designed at a point in time. A Type 2 reports on whether they operated effectively across a period, commonly three to twelve months. Type 1 is issued in weeks; Type 2 cannot be issued faster than its observation window. Nearly every startup should get Type 1 first and start the Type 2 clock immediately. The full comparison, including what to say when a customer asks for Type 2 today, is in Type 1 vs Type 2.
The five Trust Services Criteria categories
| Category | What it covers | In a first startup report? |
|---|---|---|
| Security (Common Criteria, CC1 to CC9) | Governance, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, risk mitigation | Always. Every SOC 2 report includes it, and for most startups it is the whole report |
| Availability | Uptime commitments, capacity, backup and recovery | When you have signed an uptime SLA with a customer |
| Confidentiality | Handling of information designated confidential, including retention and disposal | When your MSA or DPA carries confidentiality commitments |
| Processing Integrity | Completeness, accuracy, and timeliness of processing | Rarely. Mostly transaction and payments processors |
| Privacy | Collection, use, retention, and disclosure of personal information | Rarely at seed stage. Usually a separate program |
The categories are not free add-ons in operational terms. Every category you scope in adds criteria that the auditor tests and that you must evidence for the entire observation window. The right move is to scope in exactly what your customer contracts already commit you to, and nothing more. If you have already signed a 99.9% uptime SLA, you are carrying Availability commitments whether or not the report says so.
What AWS gives you, and what it doesn't
This is where the most expensive misunderstanding lives. AWS maintains its own SOC 1, SOC 2, and SOC 3 reports, available in AWS Artifact. Under the carve-out method, which is the standard treatment for a startup, your auditor describes AWS as a subservice organization and relies on that report rather than testing AWS themselves.
What that covers: physical data center security, environmental controls, hypervisor and hardware isolation, the availability of the underlying services. Genuinely valuable, and it is why an AWS-native startup starts ahead of one running its own racks.
What it does not cover is everything you configure:
| Question your auditor will ask | AWS's report answers it? | Where the answer actually comes from |
|---|---|---|
| Is every S3 bucket blocked from public access? | No | Your account-level Block Public Access setting and bucket inventory |
| Is MFA enforced on every human AWS principal? | No | Your IAM credential report and identity provider configuration |
| Is API activity logged and retained tamper-evident? | No | Your organization CloudTrail, delivering to a locked archive bucket |
| Are management ports open to 0.0.0.0/0? | No | Your security group rules and documented exceptions |
| Is data encrypted at rest? | Partly. The capability exists; using it is yours | Your EBS, RDS, and S3 default encryption settings and resource inventory |
| Was the datacenter physically secured? | Yes. This one is genuinely AWS's | AWS's SOC 2 report, referenced in your system description |
There is a second half of the shared boundary that surprises founders: complementary user entity controls. AWS's report lists controls that you are expected to implement for AWS's controls to be effective. Your auditor may ask whether you have read them. Most teams have not.
Roughly 70 to 80% of the remediation for an AWS-native startup can be delivered as infrastructure-as-code: CloudTrail, GuardDuty, AWS Config, Security Hub routing, VPC flow logs, AWS Backup plans, account-level encryption defaults, and public access blocks are all deployable as a stack in an afternoon. The other 20 to 30% is judgment work that no template does for you: tightening IAM policies that your application actually depends on, separating production from development, writing policies that describe how your team really operates, and running the reviews on schedule for the entire observation window.
The controls a seed-stage AWS startup needs
We deploy a standard catalog of 35 controls in six groups. It is not the only valid list, but it is calibrated to what auditors examining small AWS-native SaaS companies actually test, and every control maps to at least one Common Criteria point.
| Group | Controls | Representative examples |
|---|---|---|
| A. Governance and policies | 6 | Information security policy suite, annual risk assessment, security awareness training, vendor management, background checks, leadership oversight cadence |
| B. Identity and access | 6 | Centralized SSO, MFA everywhere, IAM least privilege, quarterly access reviews, offboarding within one business day, secrets management |
| C. AWS infrastructure and monitoring | 12 | Organization CloudTrail to a central archive, GuardDuty with delegated admin, AWS Config rules, S3 public access block, encryption at rest and in transit, VPC flow logs, centralized alerting, backups with a tested restore, vulnerability management, security group hygiene, environment separation |
| D. Software development lifecycle | 4 | Branch protection with required review, CI/CD-only production deploys, dependency and static analysis scanning, documented change management |
| E. Endpoints and people operations | 3 | Device management with disk encryption and screen lock, onboarding checklist, acceptable use policy acknowledged |
| F. Operations and incident response | 4 | Incident response plan with severity levels, annual tabletop exercise, incident tracking and postmortems, uptime monitoring |
The full list, with the specific AWS service that satisfies each control and the exact evidence an auditor asks for, is in the 35-control SOC 2 checklist. It is the most useful page on this site if you are trying to estimate your own gap.
Where AWS startups actually fail their first gap assessment
After scanning AWS environments against this catalog, the failures cluster in predictable places. None of them are exotic. All of them take longer to fix than founders expect, which is why they belong in your plan and not in week seven.
- Wildcard IAM policies wired into the application. A role with
s3:*on*that some service depends on in a way nobody documented. Tightening it is a code and deploy cycle for your engineers, not a console change, and it is the single most common cause of a slipped timeline. - Unencrypted legacy resources. Setting account-level encryption defaults takes minutes and covers everything created afterwards. Existing unencrypted RDS instances and EBS volumes need a snapshot, copy, restore, and cutover. That is a maintenance window, and if it is large enough it changes the scope of the engagement.
- No production and development separation. One account, one VPC, everyone with access. Auditors ask about it under change management and logical access, and the fix is an account restructure, which is a project, not a task.
- Secrets in the repository. Usually found in git history rather than in the working tree. Rotation plus a migration to Secrets Manager or SSM Parameter Store, plus history scrubbing, plus proving it does not recur.
- Access reviews that were never run. A quarterly access review control is easy to write and easy to fail, because a Type 2 auditor will ask for the review records covering the whole window. You cannot backfill a review you did not do.
- Controls written more strictly than the company operates. A policy promising 24-hour patching when the team patches monthly creates exceptions in every single Type 2 sample. Right-sizing the stated control to the real, defensible practice is free and prevents a qualified opinion.
- Non-AWS SaaS. The data warehouse, the support tool, the analytics platform. Every critical tool in scope needs SSO, MFA, access reviews, and an offboarding path, and the ones that do not integrate with your compliance platform become manual evidence for the full window.
What it costs
Published market ranges for a first SOC 2 vary widely because they measure different things. Here is the honest structure of the spend:
| Line item | Typical range | Notes |
|---|---|---|
| Gap assessment | $2,500 with us, credited toward readiness | Market range for a consultant-led readiness assessment runs roughly $5,000 to $25,000 |
| Readiness and remediation | From $10,000 fixed with us | The largest variance in the market, because most of it is billed hourly elsewhere |
| The audit itself | Typically $5,000 to $10,000 through our partner firms | Paid directly to the CPA firm. Never to us, for independence reasons |
| Penetration test | $5,000 to $15,000 | Not required by SOC 2. Frequently required by your customer's security questionnaire |
| Compliance platform | Varies by size and discount | Optional. Useful for continuous monitoring, not a substitute for the engineering work |
| Type 2 window support | From $1,000 per month with us | Runs for the length of your observation window |
| Your engineering time | The line nobody quotes | Commonly a quarter to half of an engineer for three to six months if you do it internally |
Most first-year journeys with us land around $20,000 to $25,000 all-in. Teams assembling the same outcome from hourly consultants and audit shopping commonly spend $30,000 to $65,000. The full cost breakdown goes line by line, including the costs that only appear in year two.
How long it takes
Six to eight weeks from kickoff to audit-ready is achievable for an AWS-native startup with an executive sponsor and a little engineering capacity. The sequence:
| Weeks | Phase | What happens |
|---|---|---|
| 1 to 2 | Scan and scope | Read-only role deployed, environment scanned against all 35 controls, process interview, commitments inventory, prioritized gap report, fixed quote |
| 2 to 6 | Remediate | Security baseline deployed as infrastructure-as-code, policy program written, application-level fixes ticketed to your engineers with exact remediation steps |
| 5 to 7 | Collect evidence | Every control mapped to its artifact and organized to the auditor's request list before they ask |
| 8+ | Mock audit and hand-off | A rehearsed walkthrough, then introduction to an independent CPA firm and support through fieldwork |
Then the examination itself, then a three to twelve month observation window before Type 2. What causes slips, and how to sequence around them, is in the SOC 2 timeline guide.
Who does the work
There are four common ways to get a first SOC 2, and they fail in different ways.
| Approach | What it does well | Where it breaks |
|---|---|---|
| Compliance platform alone | Continuous monitoring, policy templates, a clear view of what is failing | It tells you what is broken and does not fix it. The unpriced line is your engineers' time |
| Platform plus your own engineers | Builds lasting in-house capability | Competes with the product roadmap. Three to six months is typical, and it is usually the deal that pays for it |
| Hourly consultant | Judgment and auditor familiarity | Advice rather than execution, and the hourly structure means the estimate is not a commitment |
| One firm doing readiness and the audit | Simple to buy | Independence. The firm grades its own work, and enterprise security teams increasingly flag it during vendor review |
What each option is actually good for is covered in compliance platform vs security engineer and readiness vs the audit.
Where to start this week
- Find out what your customer is actually asking for. Type 1 or Type 2, which categories, and by when. This single answer determines the entire program, and it is often looser than the first email suggested.
- Run the checklist against your own environment. The 35-control checklist is free and specific. An hour with the AWS console will tell you which band you are in.
- Inventory your critical tools. Every non-AWS system that touches customer data or production. This drives more evidence effort than anything except IAM.
- Read your own contracts. Uptime SLAs and confidentiality clauses decide whether Availability and Confidentiality are in scope. Do not let the auditor find that out first.
- Pick your auditor before you finish remediating. Their request list format shapes how you should organize evidence, and organizing it twice is pure waste.
Frequently asked questions
Is SOC 2 a certification?
No. SOC 2 is an attestation examination performed by a licensed CPA firm. The deliverable is a report containing the auditor's opinion, not a certificate. "SOC 2 certified" is common in sales conversations and wrong in every one of them. The accurate phrasing is that a company has a SOC 2 Type 1 or Type 2 report covering a stated period and stated criteria.
Does running on AWS make us SOC 2 compliant?
No. AWS's own SOC 2 report covers the controls AWS operates, such as data center security and hypervisor isolation. Under the carve-out method your auditor describes AWS but does not test it. Everything you configure on top, including IAM, encryption, logging, network exposure, and all of your policies and processes, is yours to control and evidence.
How many controls does a seed-stage AWS startup need?
There is no fixed number in the standard. The AICPA publishes criteria, and each company designs controls to meet them. For a 5 to 100 person AWS-native SaaS company we deploy a standard catalog of 35 controls across six groups. A larger or more complex environment gets scoped individually.
Should we get Type 1 or Type 2 first?
Type 1, in almost every case. It can be issued within weeks of being ready, which unblocks the deal, and the Type 2 observation window starts running immediately after. Going straight to Type 2 means waiting the full window before you have anything to show a customer.
Do we need a penetration test for SOC 2?
Not to satisfy the criteria. SOC 2 does not mandate a pentest. In practice your customer's security questionnaire often asks for one, and some auditors expect vulnerability management to include periodic testing. Budget for it as a sales requirement rather than an audit requirement.
What happens if we fail a control during the audit?
A failed test becomes an exception, and enough exceptions produce a qualified opinion rather than a clean one. A qualified report is not fatal (customers read the exceptions and judge), but it is worth avoiding. The usual cause is not weak security; it is a control description written more strictly than the company operates. Right-sizing stated controls to real, defensible practice is the cheapest risk reduction available.
Find out where you actually stand
The $2,500 gap assessment scans your AWS environment against all 35 controls, interviews you on the process side, and gives you a prioritized gap report with a fixed readiness quote. It is credited in full toward the engagement, and the report is yours either way.
Book a 30-minute scoping callNo pitch deck. We look at your stack and tell you exactly what an audit would flag.
Keep reading
- The 35-control SOC 2 checklist for AWSEvery control, the AWS service that satisfies it, and the evidence your auditor asks for.
- How much SOC 2 costs in 2026Line by line, including the costs that only appear in year two.
- The auditor's evidence request listWhat a PBC list contains and where each artifact comes from in AWS.