When a potential customer sends a security questionnaire or the board of directors requests information about the timing for “SOC 2 ready”, many people do not receive a clear explanation of the requirements.
It is important to understand that a SOC 2 report is not a document that AWS provides, nor is it a simple setting within the cloud management console. To understand the process, you must realize that the choice of cloud provider is largely irrelevant to this specific audit. This is why most organizations turn to SOC 2 compliance services rather than expecting their cloud provider to handle it for them. A SOC 2 report is a formal document written by a licensed CPA firm. By reading this report, others can see the opinion of the auditor regarding the effectiveness of the internal security measures that your own staff created.
If you focus on the security measures of AWS instead of the controls that your team manages, you are likely to waste three months of time and a significant portion of your initial funding. There are specific factors that impact this process and they are listed here according to how frequently they cause difficulties for organizations.
SOC 2 Isn’t a Certification — It’s an Auditor’s Opinion Letter
You cannot claim SOC 2 compliance just because you host workloads on AWS EC2 and RDS. A SOC 2 report is an independent audit of your own controls, not a pass or fail certificate. It functions like an audited financial statement for your organization.
The AICPA defines SOC 2 using five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. These categories contain 61 total criteria. Security forms the core of every report, accounting for 33 of these criteria across sections CC1 through CC9. Customers care about the Security category most.
Startups often put “SOC 2 Certified” on their websites before an auditor issues a Type I or Type II report. No intermediate “certified” state exists. You either hold a completed auditor’s report or you do not. False claims on a public page create immediate problems when a prospective client asks for proof.
There is difference between achieving SOC 2 Type I and Type II in terms of complexity and timelines.
What AWS’s Own SOC 2 Report Actually Covers (and Why It Doesn’t Cover You)
AWS publishes its own SOC 2 reports in AWS Artifact. They attest to the physical security of the data centers, the hypervisor layer, the network fabric, and how AWS operates the services you consume. That’s it. It says nothing about how you configured your S3 bucket policies, whether your IAM roles follow least privilege, or whether your security groups are wide open to 0.0.0.0/0.
This distinction defines the AWS shared responsibility model. AWS secures the infrastructure of the cloud. You secure everything you build inside the cloud, and your auditor evaluates only your side of that line.
Do not hand an auditor the AWS SOC 2 report as proof of your own security controls. Auditors understand the boundary and will still demand your specific evidence. You must provide your own IAM policy exports, configuration histories, and access review tickets to pass your audit.
Scoping the Trust Services Criteria: Why Extra Categories Rarely Buy Extra Trust
Security is mandatory for almost every organization. You only include the other four categories—Availability, Processing Integrity, Confidentiality, and Privacy—if customer contracts, SLAs, or target buyers explicitly demand them.
Selecting Security alone requires meeting 33 criteria. Adding the remaining four categories raises the total to 61 criteria, which doubles your evidence workload, engineering interviews, and audit costs for items most buyers do not request.
Do not include extra categories just to look thorough. Unless contracts require them, additional categories increase costs without helping sales. Scope your audit strictly to match your customer commitments and sales pipeline requirements.
Evidence Collection Is a Logging Problem Before It’s a Security Problem
Here’s the uncomfortable truth about most SOC 2 findings: they’re rarely “your security is bad.” They’re “you can’t prove what you did for the last five months,” which reads the same to an auditor even if your actual posture is fine.
The CloudTrail Retention Trap
AWS CloudTrail’s free console Event History only retains 90 days of management events. If your Type II window is 6 months, and you haven’t configured a Trail delivering to S3 (or a CloudTrail Lake event data store) running continuously from before day one of that window, you have a gap you cannot retroactively fill. Same logic applies to access review tickets, onboarding/offboarding paper trails, and GuardDuty finding history and all of it needs to exist for the entire observation period, not just at the end of it.
Why Evidence Has to Exist for the Whole Window, Not Just the End
Setting up GuardDuty, log retention, and access reviews the week before an audit fails. Type II audits evaluate how your controls performed over an extended period. You cannot recreate months of operational history in a single week.
AWS Account Structure Is the Silent Timeline Killer
The single biggest driver of a slow, expensive audit is usually architecture, not tooling. A flat AWS account containing production, staging, and development workloads together makes proving segregation of duties very difficult. To satisfy Common Criteria CC6 and CC7, you must prove developers with staging access cannot touch production. Without account boundaries, generating that clean evidence requires significant effort.
Deploying AWS Control Tower or a basic Landing Zone solves these access control requirements structurally. Using separate AWS accounts for production, security tooling, and log archives satisfies evidence requests before you write a single policy document.
Do not separate accounts during an active observation window. Restructuring your AWS Organization mid-audit alters the environment under evaluation, which forces auditors to reset your evidence timeline.
Compliance Automation Platforms Don’t Fix a Broken AWS Foundation
Platforms like Vanta, Drata, and Secureframe connect to your AWS account via a read-only IAM role and continuously pull evidence (IAM configs, GuardDuty findings, Config rule states) instead of you screenshotting the console every quarter. What they don’t do is create the SSO setup, the IAM governance, or the account boundaries that evidence is actually about.
What These Platforms Actually Automate
They’re evidence-collection engines, not architecture engines. Connect one to a well-structured AWS environment and it turns weeks of manual screenshotting into a continuously updated dashboard. Connect it to a poorly structured one and it just gives you a faster, more visible way to watch yourself fail checks.
The Cost Math, and the Sequencing Mistake
Budget-wise, these platforms typically run $7.5K–$25K a year, often less than the audit fee itself, which for a Type II commonly lands between $15K and $60K depending on scope and firm tier. The tactical mistake: signing the GRC platform contract first, connecting it to a single flat AWS account with a root user still used for daily work, and watching the compliance dashboard light up red across the board on day one. Fix the account structure and IAM governance first. Let the platform monitor something that’s actually in shape.
The Real Timeline and Budget Your Board Should Hear Now
The audit fee is usually the smallest number on the whole project. For a small-to-mid B2B SaaS company, a Type II audit fee alone typically runs $15K–$60K depending on scope and auditor tier, but the full first-year program including readiness assessment, remediation work, platform subscription, possible penetration test, and the audit itself will commonly land at $30K–$80K, and higher once you add optional Trust Services Categories or a larger, more complex environment.
Realistic sequencing looks like this: 4–8 weeks of gap remediation, then a 3–12 month observation window for Type II (most first-timers scope 3–6 months), then several weeks for fieldwork and report issuance. That’s a 5–8 month runway from a cold start to a Type II report in hand, not the 6-week sprint that sometimes gets pitched to a board.
The tactical mistake: budgeting only the line item on the auditor’s invoice and getting blindsided by the actual cost, which is months of engineering time pulled off the product roadmap to close gaps and keep evidence flowing for the entire observation window.
Where This Actually Starts, Before You Sign With Anyone
Almost everything above comes down to the same point: SOC 2 success on AWS is mostly an architecture and evidence-discipline problem, not a paperwork problem. Get your account structure, IAM governance, and logging right first, and the audit itself becomes a formality. Get it backwards and you’ll pay for it in both time and budget.
If you want a second set of eyes on your actual AWS setup before you scope an engagement or sign with a GRC platform, grab a short call. It’s free, it’s advisory, and the goal is simple: tell you exactly where your environment stands against what an auditor will actually ask for, before you commit budget to the wrong thing first.