A customer just asked for your SOC 2 report. Maybe a Series A enterprise prospect. Maybe a bank doing vendor due diligence. Maybe a procurement team that won't engage without one.
You don't have a SOC 2 report. You're not even sure what one is.
This guide is the checklist I wish founders had when they first hit this wall — written by someone who's helped multiple companies get audit-ready. No fluff, no consultant-speak, just what you actually need to do.
What SOC 2 actually is
SOC 2 is a report — not a certification — issued by a licensed CPA firm after they audit your security controls. It says "this company does what they claim about how they protect customer data."
Two flavors:
- SOC 2 Type 1: a snapshot. "On this specific date, here are the controls in place." Faster and cheaper. Roughly $15-30K and 2-3 months.
- SOC 2 Type 2: proof that the controls actually worked over a period (usually 6-12 months). What enterprise customers actually want. $25-50K+ and at least 6 months.
Most founders start with Type 1 to unblock the deal in front of them, then run a Type 2 audit period in parallel.
The five Trust Service Criteria
SOC 2 audits cover up to five "trust services criteria." You only need to be audited on the ones you claim:
- Security (mandatory) — the baseline
- Availability — uptime guarantees
- Confidentiality — protecting confidential business info
- Processing Integrity — accurate data processing
- Privacy — handling personal information
For 95% of B2B SaaS startups, just Security is enough. Don't add the others unless a customer specifically asks. Each one significantly expands the scope.
The actual checklist
Here's what you need to be ready, organized by what you can do this weekend vs. what takes longer.
Phase 1: This weekend (8-12 hours)
These are the "policies on paper" parts. Auditors need to see documented policies covering specific topics. You can write or generate them in a weekend.
Required policies (write or use templates):
- Information Security Policy
- Acceptable Use Policy
- Access Control Policy
- Password Policy
- Data Classification Policy
- Incident Response Plan
- Business Continuity / Disaster Recovery Plan
- Vendor Management Policy
- Risk Assessment Policy
- Change Management Policy
- Backup Policy
- Encryption Policy
- Physical Security Policy (yes, even if you're remote)
- Asset Management Policy
- Termination / Offboarding Policy
Don't pay $20K for these. Use templates from Vanta, Drata, or even free templates from SANS. Customize the names and a few specifics. Auditors care that the policies exist, are realistic for your company, and actually get followed — not that they're prose poems.
Other this-weekend items:
- Set up a single source of truth for who has access to what (a spreadsheet works)
- Document your architecture (one diagram showing services + data flow)
- Make a list of every vendor that touches customer data (AWS, GitHub, Slack, etc.)
- Get every founder/employee to sign the security policies acknowledgment
Phase 2: This month (40-60 hours)
These require some technical and process work. They're the controls that actually protect you — auditors will sample evidence.
#### Access management
- [ ] MFA on every administrative account (AWS root, AWS IAM, GitHub admin, GCP, your domain registrar, your DNS, your CI/CD, your email admin)
- [ ] SSO for any team app that supports it (Google Workspace or Okta as the IdP)
- [ ] Principle of least privilege documented and enforced — engineers don't have prod access by default; access requests go through a documented process
- [ ] Quarterly access reviews — review who has access to what, document the review, remove anything stale
- [ ] Onboarding checklist that grants only the access needed for the role
- [ ] Offboarding checklist that revokes access within 24 hours of an employee leaving
#### Code & change management
- [ ] Pull requests required for production code (no direct pushes to main)
- [ ] Code review by another engineer before merge — required, not optional
- [ ] Branch protection enabled in GitHub
- [ ] CI/CD must pass before deploys (tests + security scans)
- [ ] Production deployment process documented (who can deploy, how, with what approvals)
#### Vulnerability management
- [ ] Dependency scanning running on every commit (Dependabot, Renovate, or Shielda)
- [ ] Static code analysis for security issues (Semgrep, GitHub CodeQL, Shielda)
- [ ] Secret scanning so leaked credentials get caught before they ship
- [ ] Documented remediation timelines — critical findings within 7 days, high within 30, medium within 90, etc.
- [ ] Tracked register of findings with their status
#### Encryption
- [ ] Data encrypted in transit — TLS 1.2+ everywhere, no exceptions
- [ ] Data encrypted at rest — your databases, your S3 buckets, your backups
- [ ] HSTS enabled on your web properties
- [ ] Modern cipher suites only (no SSL 3.0, no TLS 1.0, no RC4)
#### Monitoring & logging
- [ ] Application logs flowing to a central place (CloudWatch, Datadog, anything searchable)
- [ ] Audit logs for admin actions (who logged into AWS, who accessed prod database, who changed permissions)
- [ ] Alerting on critical events (root login, failed MFA, unusual data exports)
- [ ] Log retention documented (typically 1 year minimum)
#### Backups & recovery
- [ ] Automated backups of production data (daily minimum)
- [ ] Backups stored separately from production (different account / region / provider)
- [ ] Backup restoration tested at least quarterly — and document the test
- [ ] RTO / RPO documented (how long can you be down, how much data can you lose)
#### Incident response
- [ ] Incident response plan with named roles (incident commander, communications lead, etc.)
- [ ] Tabletop exercise at least annually — walk through a hypothetical incident
- [ ] Post-mortem template for documenting actual incidents
- [ ] Customer notification process for security incidents
Phase 3: This quarter (ongoing)
These are operational practices that need to be visible during the audit period.
- [ ] Quarterly access reviews actually happening, with evidence
- [ ] Annual security training for all employees — recorded completion
- [ ] Vendor reviews when you sign new vendors that touch customer data
- [ ] Risk assessment documented and reviewed annually
- [ ] Penetration test annually (required for many SOC 2 audits)
- [ ] Background checks for new hires (yes, really)
- [ ] Security policies reviewed and updated annually
What auditors actually check
Auditors don't just read your policies. They sample evidence. For a Type 2 audit, expect them to ask things like:
- "Show me the last 5 employees you offboarded. Show me when their access was revoked."
- "Show me the last 10 production deploys. Show me the PR, the review, the test results, the deployment record."
- "Show me your last quarterly access review. Show me what you removed."
- "Show me an incident from this period. Show me the response, the post-mortem, the customer notification."
- "Show me a backup restoration test from this period."
If your policy says "we do quarterly access reviews" but you can't produce evidence of one, that's a finding. Worse than not having the policy at all.
The single most useful thing you can do right now: set up a folder structure where you save evidence as it happens. Each quarter, drop in screenshots of the access review, the backup test, the security training completions. By audit time, you have a year of evidence ready.
How much it costs
Realistic numbers for a small startup (10-30 people):
- DIY policies + tools: $5-15K/year for a compliance platform like Vanta or Drata to track everything
- Auditor (Type 1): $15-30K, one-time
- Auditor (Type 2): $25-50K/year
- Penetration test: $10-25K depending on scope
- Engineering time to remediate findings: 80-200 hours
- Time to first audit: 4-8 months realistically
Total first-year cost: $50-100K and one founder/eng-week per month for the audit period.
What to do this week
If a customer just asked for your SOC 2 report and you're starting from zero:
- Tell them honestly you're working on it. Most enterprise customers will accept a security questionnaire + roadmap to SOC 2 + reasonable contractual commitments in the meantime.
- Sign up for a compliance platform (Vanta or Drata) — they make this 10x faster.
- Get MFA enabled everywhere today.
- Set up a vulnerability scanner so you have ongoing evidence of remediation.
- Pick a target audit date 4-6 months out and work backward.
Most founders procrastinate because the whole thing feels overwhelming. It's actually a finite list. Run the list, document everything, hire a small auditor, get the report.
If you want to understand why this checklist matters — read 7 real security disasters that followed from companies skipping exactly these controls. And if you're earlier-stage and not sure whether to tackle SOC 2 at all yet, here's the honest answer for solo founders and vibe-coders.
How Shielda helps with the technical parts
A lot of the SOC 2 checklist is security controls — the things Shielda automates. We handle the vulnerability scanning, secret detection, dependency monitoring, infrastructure misconfigurations, audit logging, and findings register out of the box. We can also fill SOC 2 questionnaires automatically using your real scan data.
Free for solo founders. 14-day trial on paid plans. The fastest way to get the technical evidence stack auditors want to see.
The rest of SOC 2 — the policies, the access reviews, the offboarding process — is on you. But having the security technology in place is the part that takes the longest. Start there.