SOC 2 TYPE I
FOR AWS-NATIVE TEAMS
For lean, 1–30 person AWS-native teams getting their first SOC 2. Everything you need to know about getting ready for SOC 2 compliance.
SOC 2 Type I is a point-in-time snapshot.An auditor shows up, looks at your controls, and says “yes, these are designed correctly.” With the right prep: $8–15K at a startup-friendly firm, 6–10 weeks elapsed. Most teams pay double and take twice as long because they walk in unprepared. This checklist is the prep.
A security audit framework from the AICPA. It asks: does your company handle customer data responsibly? When your customer's legal team asks for your "SOC 2 report," this is what they mean.
Type I: a photograph. "Your controls look correctly designed as of [date]." Fast, cheaper ($8–15K). Type II: a security camera recording. "Your controls actually worked consistently for 6–12 months." Type I comes first.
The five areas SOC 2 covers: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory one. For most lean AWS SaaS teams, Security alone is sufficient for Type I.
The security practices your auditor evaluates. MFA enabled? CloudTrail on? Each one is a "control." Every control needs an owner and evidence that it works.
Documentation that proves your controls are real. API responses, config exports, policy docs. The painful part isn’t the controls. It’s proving they exist.
Somewhere SOC 2 requires something you don’t have yet. Find and close these before you engage an auditor. Not at $300/hour while they’re waiting.
SCOPE IT BEFORE YOU BUILD ANYTHING
These decisions determine how much work the next few months are. Get them wrong and you'll overbuild. Most teams skip this and regret it.
Confirm you actually need a SOC 2, not just a vendor questionnaire
Ask your buyer directly: "Would a detailed security documentation package satisfy your requirements?" Many say yes. SOC 2 is 2–4 months and $10K+. Make sure it's required before you start.
Confirm Security is your only Trust Services Criterion
Add Availability only if you have contractual uptime SLAs. Add Privacy only if you process EU or health data. Every additional criterion adds scope, controls, evidence, and auditor time.
Why the auditor cares: scope defines the entire engagement. Ambiguity here adds weeks and fees on both sides.
Define your system boundary
Your "system" is the product your customer uses, not your whole company. Typically: compute (EC2/ECS/Lambda), databases (RDS/DynamoDB), customer-data storage (S3), and CI/CD pipeline.
Why the auditor cares: they write their opinion against the system boundary you define. A vague boundary means mid-engagement questions on their clock.
Assign a named owner to every control
Before you collect a single piece of evidence, decide who owns each control. Your auditor will ask "who is responsible for this?" and "the team" is not an answer.
Why the auditor cares: CC1.2 requires demonstrated assignment of responsibility.
Get actual buy-in from whoever writes the check
Type I takes 2–4 months, 1–2 engineers part-time, and $8–15K. Someone needs to say "yes, we're doing this" before you start building infrastructure for it.
KNOW YOUR AWS INFRASTRUCTURE’S ACTUAL STATE
SOC 2 isn’t just about having policies. Your infrastructure has to actually match what your policies say. For AWS teams, this is both the biggest risk and the most automatable part.
The controls in this section map directly to AWS APIs. The open-source Evidence Tracer runs these automatically, maps findings to controls, and gives you a gap report in about 5 minutes.
Run a gap assessment before you do anything else
Finding gaps yourself costs nothing. Finding them during an audit costs auditor time at $300/hour.
Why the auditor cares: they will find everything in that table. The question is whether you find it first.
Enable MFA on all IAM users and root. No exceptions.
The most common finding in AWS audits. One IAM user without MFA is a flag. Takes 10 minutes to fix.
Why the auditor cares: root without MFA is a design failure in your access model. CC6.1.
Rotate or delete stale access keys per your Access Control Policy
There is no SOC 2 “90-day rule” for key rotation. The auditor checks against whatever your own Access Control Policy says. Pick a cadence, write it in your policy, then actually follow it.
Why the auditor cares: a policy you’re not following is evidence of negligence, not compliance.
Enable CloudTrail in all regions with log file validation on
CloudTrail is your audit log. Every API call in your AWS account. Multi-region and log file validation are both required.
Why the auditor cares: CC7.2. No CloudTrail means no trail. The audit cannot proceed.
Enable GuardDuty in every region you use
2 minutes to enable. If you already have it on but have been ignoring the findings, that’s the more important conversation.
Why the auditor cares: GuardDuty off means no threat detection. CC7.3.
Lock down every S3 bucket: encryption on, public access blocked, versioning on critical buckets
A publicly accessible bucket with customer data is an immediate critical finding. Lock it before your audit starts.
Why the auditor cares: a public S3 bucket with customer data means you may have already had a breach you don’t know about.
Review VPC security groups for open inbound rules
0.0.0.0/0 on port 22 (SSH) or 3389 (RDP) gets flagged immediately. Restrict to specific IP ranges or use a bastion host.
Why the auditor cares: an open SSH port is an open invitation. CC6.6.
WRITE THE POLICIES
SOC 2 requires written policies for basically everything. They don’t need to be long. They need to be real.
Use AI to draft every policy in a day. The auditor doesn’t care if Claude wrote the first draft. They care that you reviewed and approved it, your team knows it exists, and your actual practices match what it says.
Information Security Policy
The master document. Who is responsible for security, what you’re protecting, and how. 2–3 pages is fine.
Why the auditor cares: CC1.4 requires demonstrated management commitment to security.
Access Control Policy
Who gets access to what, how you provision and deprovision users, MFA requirements, least-privilege.
Why the auditor cares: CC6.1 and CC6.2.
Incident Response Plan
Who gets called, in what order, what gets documented. Walk through it out loud with your team once.
Why the auditor cares: CC7.4.
Change Management Policy
How code goes from a developer’s laptop to production. If you’re already on GitHub with required PR reviews, write that down.
Why the auditor cares: CC8.1.
Risk Assessment
Annual exercise: what could go wrong, how likely, what are you doing about it. A 2-page Google Doc works.
Why the auditor cares: CC3. No documented risk process means every other control looks unanchored.
Vendor Management Policy
A list of your critical vendors, confirmation they’re SOC 2 compliant, and how you evaluate new ones.
Why the auditor cares: CC9.2. Your vendors are part of your attack surface.
Business Continuity / Disaster Recovery Plan
What happens if production goes down. RDS backup schedules, recovery time objectives, who calls who.
Why the auditor cares: A1.2 and A1.3.
Security training records and background checks
Training: a 30-minute read of your security policies with a signed acknowledgment per employee.
Why the auditor cares: CC1.4.
COLLECT AND ORGANIZE YOUR EVIDENCE
For Type I, you need point-in-time evidence proving your controls are real as of the audit date. Budget 40–60 hours if you’re doing it manually.
Organize evidence by control, not by AWS service
Your auditor thinks in criteria (CC6.1, CC7.2), not services (IAM, CloudTrail). A folder called "CC6.1-access-controls" is what they want.
Every piece of evidence needs a timestamp and a source
A screenshot with no date is not evidence. An API response with a timestamp and the exact call that produced it is.
Pull your IAM credential report and review it before the auditor does
One report shows who has access, last login time, MFA status, and access key age.
No control without evidence
A control with no evidence is treated as non-existent. GuardDuty enabled but can’t prove it? Same as GuardDuty off.
PICK AN AUDITOR AND DO A READINESS ASSESSMENT
Only licensed CPA firms accredited by the AICPA can issue SOC 2 reports. Who you pick affects timeline and cost significantly.
Shortlist 2–3 auditors who actually work with companies your size
Startup-friendly firms: Prescient Security, Barr Advisory, Johanson Group, Sensiba, A-LIGN, Insight Assurance.
Ask every auditor: "What does your readiness assessment look like?"
A readiness assessment is a pre-audit checkup. Good auditors run it collaboratively.
Show up with your evidence already organized
Teams that arrive with an organized evidence package move through the audit 2–3x faster.
Fix every gap before the official audit starts
Gaps found during the actual audit extend your timeline and raise costs.
Budget for a penetration test
Not required by SOC 2, but most enterprise buyers at Series A+ ask for it. Budget $3–8K.
WHAT TYPE I DOESN’T COVER
Type I is not a comprehensive security certification. Knowing what it doesn’t prove is as important as knowing what it does.
What your Type I report tells a customer: "As of [date], this company had security controls that were appropriately designed." It doesn’t say they worked, worked consistently, or that there haven’t been incidents since.
The technical controls in this doc cover a lot. The governance layer doesn’t have an API.
CC6, CC7, CC8 technical controls are highly automatable via AWS APIs. CC1–CC4 (org structure, risk processes, training) are manual.
Type I doesn’t prove your controls worked over time
That’s Type II. Type I gets you in the door. Type II keeps you there.
SOC 2 compliance does not mean you’re secure
SOC 2 measures process maturity, not security effectiveness. The report tells customers you have a security program. Treat it as a floor.
THE SIX-STEP VERSION
- 1.Scope it: Security TSC only. Define your system boundary. Assign control owners.
- 2.Know your AWS state: Find the gaps before the auditor does. IAM, CloudTrail, GuardDuty, S3, VPC.
- 3.Write the policies: Eight core documents. AI-drafted is fine. They have to match reality.
- 4.Collect evidence: Organized by criterion, timestamped, API-native where possible.
- 5.Pick the right auditor: Startup-friendly CPA firm. Readiness assessment first.
- 6.Know the limits: Type I is a photograph. It covers the technical layer, not everything.