SOC 2 for Startups — Complete Guide

What Is SOC 2, Really?

SOC 2 is not a certification. It's an audit report prepared by a CPA that says you defined some policies and (maybe) followed them. Companies as small as 3 employees have completed SOC 2 audits. But understand that this does not measure your organization's ability to withstand cyber attacks—it measures whether you follow documented processes.

Type I: "We Have Policies"

Point-in-time assessment showing you designed controls.

Proves controls are suitable
No proof you're following them
Optional stepping stone to Type II
Audit cost: $3k-6k (small startups), $15k-40k (larger/complex)
Duration: 2-6 months

Type II: "We Follow Policies"

3-12 month assessment proving operational effectiveness.

Proves controls operated effectively
This is what customers want
Requires evidence trail
Audit cost: $5k-8k (small startups), $30k-100k+ (larger/complex, incl. tools)
Duration: 6-12+ months

What You Get

SOC 2 Report - 50-200 page document with your policies and audit results
SOC 2 Badge - Most compliance platforms provide a badge for your website; you can also create your own
Validation - Customers ask fewer security questions

Recommendation: Start with Security-only (most companies) or Security + Confidentiality (professional services). You can expand scope later. Over-scoping just costs more.

Why choose Type I first? If you're 3-6 months away from needing the full report, Type I lets you validate your control design before committing to a 3-12 month audit period. Some organizations use it to identify gaps, remediate, then immediately proceed to Type II. The downside: Type I doesn't necessarily satisfy customer/client requirements, so you're paying for something that won't close deals—only do this if you have time and want validation.

The system description is your claim. You write a document describing your systems, processes, and controls. Auditors test whether reality matches what you wrote. Write less, test less. This isn't about hiding things—it's about not committing to controls you don't actually operate. If you describe a weekly vulnerability scan, they'll verify you ran 52 scans. If you just say "regular" scans, you have more flexibility.

Example Report: Curious what a real SOC 2 report looks like? Kolide (now part of 1Password) published their complete Type II report publicly (archived copy). Worth reviewing to understand the format, details, and control descriptions.

Trust Service Categories (Pick Your Scope)

You define what's in scope. Product companies often start with Security-only, while professional services typically add Confidentiality:

Category	What It Covers	Recommendation
Security	Protection against unauthorized access, system abuse, theft	Always include.
Confidentiality	Protection of confidential information beyond normal security	Add if you handle highly sensitive data (PHI, financial records, legal matters, proprietary business information). Recommended for professional services, may be optional for most product companies.
Availability	System uptime and operational performance	Add if you have SLAs or high-availability commitments. Common for SaaS companies with uptime guarantees.
Processing Integrity	System processing is complete, valid, accurate, timely	Add if you're doing financial calculations, payment processing, tax preparation, or other computation-dependent services
Privacy	Collection, use, retention, disclosure of personal information	Add if consumer-facing with significant PII collection or subject to GDPR, CCPA. Note: SOC 2 Privacy TSC does not satisfy HIPAA compliance on its own—HIPAA has its own separate framework.

Subservice Organizations (Your Vendors)

Every third party that plays a material role in delivering your service needs to be disclosed in your system description. For most startups, that's your cloud provider (AWS, GCP, Azure), plus tools like Datadog, PagerDuty, Stripe, etc. Each gets designated as either carved-out or inclusive:

Method	What It Means	When to Use
Carve-out	You disclose the vendor and its role, but their controls are excluded from your audit. Your report tells customers to evaluate the vendor's own SOC report.	Almost always. This is how you handle AWS, GCP, Stripe, Datadog, etc.
Inclusive	The vendor's controls are included in your audit and tested by your auditor.	Rare. Only when a vendor is so deeply embedded that its controls are inseparable from yours and your auditor can gain access to test them.

Practical impact: Carve-out is the default for virtually every startup. Your auditor will ask for a list of subservice organizations during scoping. For each one, you should be able to point to their SOC 2 report (most major vendors publish them or share on request). If a vendor doesn't have a SOC 2 report, you'll need to document how you monitor and manage the risk of using them.

Opinion Types: What You're Aiming For

Unqualified Opinion

This is what you want. No issues found. Clean bill of health. When people say they "passed" SOC 2, they mean unqualified opinion.

Qualified Opinion

Significant issues found. One or more material departures from the criteria—not just minor exceptions. A qualified opinion means something structurally didn't meet the standard. Minor exceptions (e.g., a new hire completing training late) typically appear as noted exceptions in an otherwise unqualified report and are manageable. Section 5 of the report lets you explain context and describe remediation for any exceptions.

Adverse Opinion

You failed. Material control failures. This report is unusable for sales. Fix issues and re-audit.

A Potential Timeline

From decision to report: 4-12 months depending on your readiness. Here's a common path with practical implementation steps:

Preparation

Get Your House in Order

Define scope (what's in, what's out)
Write core policies (InfoSec, Access Control, Incident Response)
Implement foundational controls (SSO, MFA, logging)
Choose automation platform and auditor
Conduct readiness assessment

Show practical getting started steps

Scoping - What's In, What's Out

For product companies (SaaS, tech platforms): Systems that store, process, or transmit customer data - production environment, databases, authentication systems, APIs, admin access, payment processing.
For professional services (consulting, advisory, technical services): Systems handling client data - document management, email, client portals, file sharing, CRM, collaboration tools. For technical services (pentesting, DevOps): include cloud resources you manage and tools that access customer systems. Most should include Confidentiality TSC given the nature of client engagements.
Commonly in scope for both: Identity/access management (SSO/IdP), email systems, document storage (Google Drive, SharePoint), production databases, logging/monitoring, backup systems.
Out of scope: Development/staging (unless they contain production/client data), internal-only systems with no customer data, marketing website (unless it processes sensitive data), personal devices without MDM.
Common mistake: Over-scoping by including office networks when fully remote, or systems that never touch customer/client data. Keep it narrow for your first audit.
Gray areas: CI/CD pipelines that deploy to production (usually in scope for product companies), internal wikis (in scope if documenting customer matters), time tracking (usually out unless integrated with billing).
Physical considerations: If you have office space, expect questions about visitor access, paper document storage/destruction, workstation security, clean desk policies.
Customer responsibilities (CUECs): Your SOC 2 report will include Complementary User Entity Controls — things your customers are responsible for on their end (e.g., managing their own user access, protecting their API keys, configuring SSO on their side). Define these during scoping so expectations are clear in the report.
Document it: Create a simple system boundary diagram showing what's included and excluded. Your automation platform will help with this, but start with a whiteboard sketch.

SSO/Identity (Free/Built-in Options)

Google Workspace: Built-in SSO, enable MFA in Admin Console → Security → 2-Step Verification → Enforcement
Microsoft 365: Microsoft Entra ID (formerly Azure AD) included, enable MFA via Conditional Access policies
Important nuance: SSO isn't strictly mandatory if you can demonstrate centralized access control and deprovisioning across all business-critical platforms. This means maintaining a documented process for adding/removing access, quarterly reviews, and audit logs for each platform. However, SSO makes this infinitely easier and is expected by most auditors—manual tracking across 20+ tools is painful and error-prone.

Logging Setup (Free Tier Available)

AWS: aws cloudtrail create-trail --name soc2-audit-trail --s3-bucket-name your-bucket
GCP: Enable in Console → Logging → Audit Logs → Enable all services
Azure: Azure Monitor automatically enabled, configure Activity Log retention
Log aggregation: Grafana Loki (free), AWS CloudWatch (pay per GB), or Papertrail (free 50MB/month)

Policy Templates (Free)

Start here: Tailscale's SOC 2 policies on GitHub
Alternative: JupiterOne policy templates
Tool: Use Claude or ChatGPT to customize for your company (see AI Assistance section)

Initial Risk Assessment (Spreadsheet)

Simple spreadsheet: Columns: Risk Description, Likelihood (1-5), Impact (1-5), Score (L×I), Mitigation, Owner, Status
Common risks to include: Unauthorized access to customer data, ransomware, key employee departure, vendor outage, data breach
Treatment: For each risk, document: Mitigate (implement control), Accept (leadership approves risk), Transfer (insurance), or Avoid (don't do activity)

Minimum Viable Compliance Setup (Phased)

Phase 1 (Week 1-2): Deploy MDM, enable MFA everywhere, set up centralized logging. These take time to generate evidence—start first.
Phase 2 (Week 2-4): Create core policies using templates, implement security training, document onboarding/offboarding checklists.
Phase 3 (Week 4-8): Conduct formal risk assessment, establish quarterly access reviews, implement change management, schedule vulnerability scanning.
Phase 4 (Week 8+): Set up compliance automation platform to centralize evidence collection before engaging your auditor.

Remediation

Fix the Gaps

Implement missing controls from readiness assessment
Deploy MDM, secrets management, vulnerability scanning
Start quarterly access reviews (need 2+ cycles)
Begin change management process (need 3+ months history)
Get all employees to sign policies

Show practical implementation tools

MDM - Device Management (Free Tier Options)

Mac: Kandji (trial available), Mosyle (free tier available), or Fleet (open source)
Windows: Microsoft Intune (included with M365 E3+), or ManageEngine (free tier available)
Cross-platform: JumpCloud (free tier available), Fleet (open source)
Must enforce: Full disk encryption, screen lock timeout, OS updates, remote wipe capability
For professional services: Include document management platforms (Google Workspace, O365) in MDM scope for client file access controls

Secrets Management

HashiCorp Vault: Industry standard, but now under Business Source License (BSL)—not open source. For an open-source alternative, consider OpenBao (community fork). vault server -dev for testing
AWS Secrets Manager: ~$0.40/secret/month + $0.05 per 10K API calls
GCP Secret Manager: Free tier available, then pay per access (check current pricing)
Doppler: Free tier available for small teams
Scan for exposed secrets: trufflehog filesystem --directory=. or GitGuardian

Vulnerability Scanning (Free Options)

Container scanning: Trivy (free, open source) - trivy image your-image:tag
Dependency scanning: Dependabot (free on GitHub), Snyk (free tier)
Infrastructure: Prowler (free, open source AWS scanner), AWS Inspector (pay per scan)
Web scanning: OWASP ZAP (free), Burp Community (free)

Access Review Template (Free Spreadsheet)

Create Google Sheet with columns: Email, Name, Systems, Access Level, Manager, Review Date, Manager Approval, Notes
Export from Okta/Google Workspace: Admin Console → Users → Download CSV
Send to managers quarterly for review and sign-off
Keep signed copies (digital signature via DocuSign free tier or typed name with date)

Policy Signing Process

E-signature tools: PandaDoc (free tier), or paid options like DocuSign, Adobe Sign, HelloSign
Budget option: Google Drive with typed name + date, or email confirmation with policy PDF attached
Track completions: Spreadsheet with Employee Name, Policy Name, Date Signed, Method (digital signature link or email confirmation)
Store evidence: Keep signed PDFs or email confirmations in employee folders for auditor review

Evidence Collection

Evidence Collection - Build Your Audit Trail

Let processes run to generate evidence (cannot backdate)
Collect quarterly access reviews
Document change tickets and deployments
Run tabletop exercises for incident response
Test backup restoration
Gather vendor SOC 2 reports

Audit readiness = four elements per control: (1) documented policy explaining what you do, (2) communications showing responsible parties were informed, (3) procedures detailing exact steps, and (4) evidence proving the control operated as documented. For Type II, evidence must show consistent operation throughout the observation period—not just a single snapshot.

Show evidence collection specifics

Change Management Evidence

GitHub: Branch protection screenshot + sample PRs with reviews + deployment logs
Export PRs: gh pr list --state merged --json number,title,author,reviewers --limit 100
Jira/Linear: Filtered view of "Production Change" tickets from last 3-6 months
Need to show: Ticket → Approval → Code review → Deployment → Verification

Incident Response Testing

Tabletop scenario: "Ransomware detected on employee laptop at 2am Sunday"
Document: Attendees, timeline of actions taken, decisions made, lessons learned
Store: Meeting notes in Google Docs with timestamps and attendee list
Follow-up: Update incident response plan based on findings

Backup Testing Evidence

Test: Actually restore a backup to new environment/database
Document: Date, who performed it, backup timestamp, restoration time, verification steps
Screenshot: Restored data showing it's functional
Frequency: Quarterly minimum, monthly better

Vendor SOC 2 Reports

AWS: Request via AWS Artifact (Console → Security, Identity & Compliance → Artifact)
GCP: Request via compliance reports manager or contact support
Other vendors: Look for "Security" or "Trust Center" page, or email security@vendor.com
Typical turnaround: 2-4 weeks after NDA signed

Vendor Risk Assessments

Not just SOC 2 reports: Auditors want to see YOU assessed vendor risks, not just collected their reports
Simple spreadsheet: Vendor Name, Services Provided, Data Access (Yes/No/What), Risk Level (High/Medium/Low), SOC 2 Status, Review Date, Notes
For critical vendors without SOC 2: Send security questionnaire (use SIG Lite as template) and document review
Document decisions: Why you accepted vendor despite no SOC 2, or compensating controls you implemented

Confidentiality Evidence (If Including Confidentiality TSC)

NDA tracking: Spreadsheet of all employees/contractors who signed confidentiality agreements, with signed copies stored
Engagement access logs: For professional services - who accessed which client matters/files, when, and audit trail of access reviews
Data classification evidence: Sample documents showing confidentiality labels/markings in use
Confidential data disposal: Certificates of destruction for paper records, secure deletion logs for digital

Professional Services Considerations

Client file handling: Screenshots showing matter/engagement isolation in document management (separate folders, access controls by engagement team)
Chinese walls: If applicable, document procedures and access reviews showing conflicts are managed
Client portal access: Logs showing which clients accessed their portals, when, and for what purpose

Audit Kickoff

Start Type I (Optional) or Go Straight to Type II

Auditor reviews system description
Submit initial evidence package
Schedule interviews with control owners
Define audit period (typically 3-6 months for first Type II)

Fieldwork

Auditor Does Their Work

Interviews with key personnel
Evidence review and testing
Sample testing of controls
Follow-up questions and evidence requests
Preliminary findings review

Expect walkthrough questions like: "Walk me through how a new employee gets access to systems." "Show me a recent change ticket from request to deployment." "Tell me about a security incident and how you handled it."

Sampling: Auditors select evidence randomly across your observation period. If you claim quarterly access reviews, they'll examine all four. If you processed 100 changes, they might sample 25 tickets. Controls must work every time—not just when you're watching.

Report Delivery

Get Your Badge

Review draft report
Management response to any findings (Section 5 lets you explain context)
Final report issued—valid for 12 months
Post AICPA logo on website
Start planning for renewal 3-4 months before expiration

Renewal reality: Reports expire after 12 months. Customers expect continuous coverage—"bridge letters" confirming ongoing compliance only buy limited time. Annual renewal costs roughly 40% of initial investment ($10k-40k typical). Start the renewal process early; gaps in coverage raise questions.

The audit period for Type II is 3-12 months. This means you need to have controls running for months before the auditor will look at them. You cannot rush this.

Small team reality: segregation of duties. Auditors expect different people to request, approve, and deploy changes. When one person wears multiple hats, document compensating controls: require PR approval from a peer before merge, use branch protection rules, log all deployments with timestamps. The key is proving someone else reviewed the work—even if you're both developers. Many 5-person teams pass SOC 2 by documenting their peer review process clearly.

Preparation Checklist

Auditors are looking to ensure Trust Services Criteria are followed according to an internal control framework and described according to the Description Criteria. This checklist is a practical guide to help you prepare and contains 118 items organized by priority and owner.

What You Actually Need vs. What Makes It Easier

SOC 2 is criteria-based, not tool-based. The Trust Services Criteria describe outcomes, not products. For every expensive tool commonly recommended, there's a manual or lower-cost alternative that satisfies the same criteria. The trade-off is always more manual evidence collection and potentially more auditor questions. At ~10 people, manual alternatives are viable. At 25+, the manual burden often becomes untenable.

Tool Category	TSC Reference	What the Criteria Actually Require	Minimum Viable Alternative	When It Becomes Worth It
SSO Okta, OneLogin, JumpCloud	CC6.1, CC6.2, CC6.3	Logical access security, authorized credential issuance, access modification/removal when roles change	Google Workspace or M365 acts as your IdP. Maintain per-app access lists, documented onboarding/offboarding checklists, quarterly access reviews per platform. Works fine with fewer than ~15 apps.	15+ SaaS apps, frequent employee turnover, or when manual offboarding across platforms takes more than an hour per departure
EDR CrowdStrike, SentinelOne, Carbon Black	CC6.8	Controls to prevent or detect and act upon introduction of malicious software	Built-in OS protections: Windows Defender (free, enterprise-grade), macOS XProtect + Gatekeeper. Document that these are enabled and auto-updating. Screenshot evidence of settings.	Handling highly sensitive data (financial, healthcare), or when customers specifically require EDR in security questionnaires
MDM Jamf, Kandji, Intune, Fleet	CC6.1, CC6.6, CC6.7	Endpoint security controls: encryption, screen lock, OS currency, ability to restrict/wipe lost devices	Acceptable use policy requiring FileVault/BitLocker, screen lock, OS updates. Periodic screenshots from employees as evidence. Device inventory spreadsheet. Document remote wipe capability via Google Workspace/M365 device management (built-in).	15+ devices, BYOD environment, or when quarterly screenshot collection takes more time than an MDM subscription costs
Compliance Platform Vanta, Drata, Secureframe, Sprinto	N/A (workflow tool)	Evidence organized and available for auditor review	Google Drive folders following the evidence folder structure in this guide, plus spreadsheets for tracking. More manual work, but fully functional for a small team with discipline.	15+ employees, 10+ integrations to monitor, or limited bandwidth for manual evidence collection. Platforms also reduce audit fees (auditors work faster with them).
SIEM Splunk, Elastic, Datadog Security	CC7.1, CC7.2	Detect anomalies and monitor system components for deviations	CloudTrail + CloudWatch Alarms (AWS), Cloud Audit Logs + Cloud Monitoring (GCP), or Azure Monitor. Set up basic alerts for unauthorized access attempts, config changes, root account usage. Free/low-cost tiers available.	Multi-cloud, complex infrastructure, or when you need log correlation across many sources
Vulnerability Scanner Qualys, Tenable, Rapid7	CC7.1	Vulnerability management process with identification and remediation	Trivy (free, containers/IaC), Dependabot (free on GitHub), Prowler (free, AWS). Run on a schedule, export reports, track remediation in a spreadsheet.	Large attack surface, multiple production environments, or when you need consolidated dashboards across scan types
Secrets Manager HashiCorp Vault, Doppler	CC6.1	Secrets are protected and not exposed in plaintext	AWS SSM Parameter Store (free), GCP Secret Manager (free tier), environment variables in CI/CD with restricted access. Run TruffleHog or GitGuardian to prove no secrets in code.	Many services sharing secrets, frequent rotation requirements, or teams larger than ~10 engineers
Penetration Testing	Not in TSC	Not required by SOC 2 criteria	Not needed for SOC 2 compliance. Consider if customers explicitly request it, you've made major architectural changes, or you handle highly sensitive data. A boutique penetration testing firm can likely provide a better value, cost-effective solution such a Security Architecture Review & Configuration Assessment.	When customers require it in contracts, or your prospectes are asking to demonstrate these security assurances
Background Checks Checkr, GoodHire, Sterling	CC1.4	The entity "considers background screening in the hiring process" — note the word considers, not performs	A documented hiring risk assessment process: reference checks, structured interviews, evaluation of competence, and a recorded decision on whether formal screening is warranted for each role. Document the risk assessment and outcome. The criteria require you to consider it and make a deliberate, documented decision — not necessarily to run a criminal background check on every hire.	Roles with admin access to sensitive systems, regulated industries (finance, healthcare), or when customer contracts require it

The pattern: For each of these, the criteria require a control and evidence it operates. The tool is just one way to implement the control. If you choose manual alternatives, document your process, collect evidence consistently, and be prepared to explain your approach to the auditor. Many small teams pass SOC 2 without SSO, EDR, MDM, or a compliance platform — but they have strong documentation habits.

Actually Required (Non-Negotiable)

These are controls where there's no practical manual alternative — the criteria effectively mandate them:

Control	TSC Reference	Why It's Non-Negotiable	Cost
MFA on all production systems	CC6.1	Auditors universally expect this. No practical compensating control exists for "we don't use MFA."	Free (built into Google Workspace, M365, AWS, GitHub)
Cloud audit logging	CC7.1, CC7.2	Must show who did what, when, across your infrastructure. Cannot be generated retroactively.	Low — CloudTrail, GCP Audit Logs. Enable early since you need months of log history.
Encryption at rest and in transit	CC6.1, CC6.7	Explicit criteria requirement. TLS 1.2+ for transit, disk/database encryption at rest.	Free — most cloud services encrypt by default. Verify and screenshot.
Documented policies	CC1.1, CC2.1, CC5.1	Auditors test against what you wrote. No policies = nothing to audit.	Free — use Tailscale/open source templates, customize with an LLM.
Quarterly access reviews	CC6.2, CC6.3	Auditors check these every time. Need 2+ completed cycles before audit.	Free — spreadsheet with manager sign-off. Start immediately.
Change management process	CC8.1	Every production change needs a ticket, review, and deployment record. Need 3+ months of history.	Free — GitHub PRs with branch protection and required reviews.
Risk assessment	CC3.1, CC3.2	Documented risk identification, analysis, and treatment decisions.	Free — spreadsheet with likelihood, impact, mitigation, and owner columns.
Incident response plan	CC7.3, CC7.4	Documented plan for detecting, responding to, and recovering from incidents.	Free — document from template. Run at least one tabletop exercise before audit.

The non-negotiable controls are mostly free. The expensive tools are optional. SOC 2 compliance costs come primarily from the audit itself and the time investment.

P0 Must Have Before Audit Starts

[IT] Establish centralized access management - Either deploy SSO (Okta, Entra ID) or use Google Workspace/M365 as your IdP with documented per-app access lists and offboarding checklists. SSO makes this easier but isn't mandatory — what auditors need is evidence of controlled provisioning, deprovisioning, and access reviews across all business-critical platforms (CC6.1-6.3).

[IT] Enforce MFA on all production systems and SSO - Cannot be bypassed, enforced for 30+ days. Take screenshot of enforcement policy.

[DevOps] Enable cloud provider audit logging - AWS CloudTrail, GCP Audit Logs, Azure Activity Logs enabled for ALL regions. Must be enabled before audit period starts.

[DevOps] Encrypt data at rest and in transit - RDS/S3 encryption enabled, all customer-facing endpoints use TLS 1.2+.

[Engineering] Implement change management process - All prod changes have ticket, approval, deployed via CI/CD with audit trail. Need 3+ months of change tickets.

[IT/Managers] Conduct quarterly access reviews - Spreadsheet showing all users, their access levels, and manager sign-off. Need 2+ completed cycles before audit starts. This is one of the most commonly failed controls — start immediately (CC6.2, CC6.3).

+ 54 more P0 items covering policies, risk assessment, incident response, vendor management, access controls, and confidentiality controls

P1 Should Have for Strong Audit

[IT] Enforce endpoint security controls - Either deploy MDM (Jamf/Intune/Kandji) or document manual alternatives: acceptable use policy requiring FileVault/BitLocker, screen lock, OS updates, with periodic employee-submitted screenshots as evidence. MDM automates evidence collection; manual works for small teams (CC6.1, CC6.6).

[DevOps] Implement vulnerability scanning - Free options: Trivy (containers), Dependabot (dependencies), Prowler (AWS). Paid options: AWS Inspector, Qualys, Tenable. Run on a schedule and retain reports. Need scan history for 3+ months (CC7.1).

[DevOps] Test backup restoration process - Documented test where backup was actually restored to verify it works, done quarterly.

[CISO] Conduct incident response tabletop exercise - Simulated incident with notes, attendees, lessons learned documented. Do this before audit starts.

+ 54 more P1 items covering SAST/DAST, dependency scanning, business continuity, vendor reviews, and confidentiality-specific controls

Download Full Checklist (118 items)

Note that there's no real checklist to be graded against. You should work with your auditor to understand what they need and will be looking to assess.

Evidence Folder Structure

Organize your evidence in a shared drive (Google Drive, Dropbox, SharePoint). Separate design evidence (policies, configurations) from operating evidence (proof controls worked over time).

Show folder structure and naming conventions

File naming convention: Use YYYY-MM-DD format. Example: 2024-Q2-access-review-APPROVED.xlsx or 2024-06-15-cloudtrail-config.png

SOC2-Evidence/
├── 00-EVIDENCE-INDEX.xlsx              ← Map evidence to TSC control IDs
├── 01-Scope-and-Description/
│   ├── system-boundary-diagram.pdf
│   ├── data-flow-diagram.pdf
│   ├── network-architecture.pdf
│   ├── system-narrative.docx
│   └── in-scope-vs-out-of-scope.xlsx
├── 02-Policies-Procedures/            [DESIGN EVIDENCE]
│   ├── information-security-policy-v2.1-FINAL.pdf
│   ├── access-control-policy-v1.0-FINAL.pdf
│   ├── incident-response-policy-v1.0-FINAL.pdf
│   ├── acceptable-use-policy-v1.0-FINAL.pdf
│   └── employee-acknowledgments/
│       ├── 2024-all-employees-signed.pdf
│       └── signature-log.xlsx
├── 03-Access-Management/              [OPERATING EVIDENCE - TIME SERIES]
│   ├── access-reviews/
│   │   ├── 2024-Q1-access-review-APPROVED.xlsx
│   │   ├── 2024-Q2-access-review-APPROVED.xlsx
│   │   ├── 2024-Q3-access-review-APPROVED.xlsx
│   │   └── manager-approval-emails/
│   ├── provisioning-deprovisioning/
│   │   ├── 2024-Q2-new-hire-checklist-samples.pdf
│   │   ├── 2024-Q3-termination-checklist-samples.pdf
│   │   └── offboarding-ticket-exports/
│   ├── SSO-MFA-config/                [DESIGN + OPERATING]
│   │   ├── 2024-06-01-okta-MFA-enforcement-screenshot.png
│   │   ├── 2024-09-15-okta-MFA-enforcement-screenshot.png
│   │   └── SSO-app-integration-list.xlsx
│   └── privileged-access-logs/
│       └── 2024-Q2-to-Q3-admin-access-samples.csv
├── 04-Change-Management/              [OPERATING EVIDENCE - TIME SERIES]
│   ├── change-control-process.pdf     [DESIGN]
│   ├── github-branch-protection-config.png
│   ├── sample-changes/
│   │   ├── 2024-06-changes-sample-5-PRs.pdf
│   │   ├── 2024-08-changes-sample-5-PRs.pdf
│   │   └── 2024-09-changes-sample-5-PRs.pdf
│   └── emergency-change-log.xlsx
├── 05-Encryption-Secrets/             [DESIGN EVIDENCE]
│   ├── 2024-06-15-rds-encryption-at-rest-screenshot.png
│   ├── 2024-06-15-s3-encryption-config.png
│   ├── TLS-certificate-config.png
│   ├── secrets-manager-setup.png
│   └── encryption-key-management-procedure.pdf
├── 06-Logging-Monitoring/             [DESIGN + OPERATING]
│   ├── 2024-06-01-cloudtrail-config-all-regions.png
│   ├── 2024-09-15-cloudtrail-config-all-regions.png
│   ├── log-retention-policy-12-months.png
│   ├── SIEM-alerting-rules-export.pdf
│   └── sample-security-alerts/
│       └── 2024-Q2-Q3-alert-response-samples.xlsx
├── 07-Vulnerability-Management/       [OPERATING EVIDENCE - TIME SERIES]
│   ├── vulnerability-scanning-policy.pdf [DESIGN]
│   ├── scan-results/
│   │   ├── 2024-06-trivy-scan-report.pdf
│   │   ├── 2024-07-trivy-scan-report.pdf
│   │   ├── 2024-08-trivy-scan-report.pdf
│   │   └── 2024-09-trivy-scan-report.pdf
│   └── remediation-tracking.xlsx      ← Track critical/high findings to closure
├── 08-Incident-Response/
│   ├── incident-response-plan-v1.2-FINAL.pdf [DESIGN]
│   ├── 2024-05-15-IR-tabletop-exercise.pdf
│   ├── incident-log.xlsx              [OPERATING - if any real incidents]
│   └── lessons-learned/
├── 09-Business-Continuity/
│   ├── disaster-recovery-plan-v1.0-FINAL.pdf [DESIGN]
│   ├── backup-testing/                [OPERATING EVIDENCE - TIME SERIES]
│   │   ├── 2024-Q1-backup-restore-test.pdf
│   │   ├── 2024-Q2-backup-restore-test.pdf
│   │   └── 2024-Q3-backup-restore-test.pdf
│   └── RTO-RPO-documentation.pdf
├── 10-Vendor-Risk-Management/
│   ├── vendor-inventory-2024.xlsx
│   ├── vendor-risk-assessment-template.xlsx
│   ├── vendor-assessments/            ← Individual risk assessments per vendor
│   │   ├── AWS-risk-assessment.pdf
│   │   ├── Auth0-risk-assessment.pdf
│   │   └── Stripe-risk-assessment.pdf
│   └── vendor-soc2-reports/
│       ├── AWS-SOC2-Type-II-2024.pdf
│       ├── Auth0-SOC2-Type-II-2024.pdf
│       └── [Add NDA-protected reports here]
├── 11-HR-Security/
│   ├── background-check-policy.pdf    [DESIGN]
│   ├── security-training-materials/
│   │   └── 2024-security-awareness-training-deck.pdf
│   ├── training-completion-records/
│   │   └── 2024-training-completions-all-employees.xlsx
│   └── background-checks/
│       └── background-check-confirmations-log.xlsx
├── 12-Risk-Management/
│   ├── 2024-Q2-risk-assessment.xlsx
│   ├── 2024-Q3-risk-assessment-update.xlsx
│   └── risk-register.xlsx
├── 13-Client-Confidentiality/         [FOR CONFIDENTIALITY TSC - DELETE IF NOT IN SCOPE]
│   ├── confidentiality-policy-v1.0-FINAL.pdf [DESIGN]
│   ├── data-classification-policy.pdf
│   ├── NDA-tracking/
│   │   ├── client-NDA-log.xlsx
│   │   ├── employee-NDA-log.xlsx
│   │   └── sample-signed-NDAs/
│   ├── matter-engagement-isolation/
│   │   ├── client-separation-controls.pdf
│   │   ├── access-control-matrix-by-engagement.xlsx
│   │   └── chinese-wall-procedures.pdf
│   ├── document-retention-destruction/
│   │   ├── retention-schedule-policy.pdf
│   │   ├── 2024-Q2-destruction-log.xlsx
│   │   ├── 2024-Q3-destruction-log.xlsx
│   │   └── secure-destruction-vendor-cert.pdf
│   └── professional-liability-insurance/
│       └── 2024-E&O-insurance-certificate.pdf
├── 14-Engagement-Access-Controls/     [FOR CONFIDENTIALITY TSC - DELETE IF NOT IN SCOPE]
│   ├── client-data-access-policy.pdf [DESIGN]
│   ├── engagement-access-reviews/    [OPERATING - TIME SERIES]
│   │   ├── 2024-Q1-engagement-access-review.xlsx
│   │   ├── 2024-Q2-engagement-access-review.xlsx
│   │   └── 2024-Q3-engagement-access-review.xlsx
│   └── client-portal-access-logs/
│       └── 2024-Q2-Q3-portal-access-samples.csv
└── 15-Audit-Correspondence/
    ├── auditor-questions-responses.docx
    ├── management-response-to-findings.pdf
    └── final-report/
        └── [SOC2 report goes here after completion]

Google Apps Script: auto-create this folder structure in Google Drive

How to use: Open script.google.com → New project → paste the code below → click Run → authorize when prompted. The script creates the full folder structure in your Google Drive root. Move the top-level folder wherever you want afterwards.

function createSOC2Folders() {
  var root = DriveApp.createFolder('SOC2-Evidence');

  var structure = {
    '01-Scope-and-Description': [],
    '02-Policies-Procedures': ['employee-acknowledgments'],
    '03-Access-Management': [
      'access-reviews', 'provisioning-deprovisioning',
      'SSO-MFA-config', 'privileged-access-logs'
    ],
    '04-Change-Management': ['sample-changes'],
    '05-Encryption-Secrets': [],
    '06-Logging-Monitoring': ['sample-security-alerts'],
    '07-Vulnerability-Management': ['scan-results'],
    '08-Incident-Response': ['lessons-learned'],
    '09-Business-Continuity': ['backup-testing'],
    '10-Vendor-Risk-Management': [
      'vendor-assessments', 'vendor-soc2-reports'
    ],
    '11-HR-Security': [
      'security-training-materials',
      'training-completion-records', 'background-checks'
    ],
    '12-Risk-Management': [],
    '13-Client-Confidentiality': [
      'NDA-tracking', 'matter-engagement-isolation',
      'document-retention-destruction',
      'professional-liability-insurance'
    ],
    '14-Engagement-Access-Controls': [
      'engagement-access-reviews',
      'client-portal-access-logs'
    ],
    '15-Audit-Correspondence': ['final-report']
  };

  for (var folder in structure) {
    var parent = root.createFolder(folder);
    structure[folder].forEach(function(sub) {
      parent.createFolder(sub);
    });
  }

  Logger.log('Created: ' + root.getUrl());
}

Note: If you're only doing Security TSC (no Confidentiality), delete folders 13 and 14 after creation. The script takes about 10 seconds to run.

For professional services firms: Folders 13-14 (Client Confidentiality, Engagement Access Controls) are specifically for the Confidentiality TSC. If you're only doing Security TSC, delete these folders. Most professional services firms should include Confidentiality given the sensitive nature of client matters, engagements, and proprietary information handled.

Sampling for Type II: Auditors need evidence distributed across your audit period. For a 6-month audit, collect quarterly access reviews (at least 2), vulnerability scans (monthly), and change samples from beginning/middle/end. The EVIDENCE-INDEX.xlsx should map each file to TSC control ID(s) - this should save time during auditor requests.

The most commonly failed controls are quarterly access reviews (not started early enough) and change management (insufficient history). Start these now.

Budget Planning

Costs scale primarily with environment complexity—not headcount. A 10-person fintech with microservices spends more than a 100-person company with a simple monolith.

Tier	Profile	First-Year Total
Simple	Single app, managed hosting, <10 integrations	$12k–$55k
Moderate	2–5 services, single cloud, standard CI/CD	$55k–$110k
Complex	Microservices, multi-region, regulated-adjacent	$100k–$200k
Highly Complex	Multi-cloud, on-prem, HIPAA/PCI overlay	$180k–$450k+

Simple Tier Breakdown

Most early-stage startups fall into Simple or Moderate tiers. Here's what Simple typically looks like:

$12k vs $80k? The gap comes from company size and security tooling you already have. A small startup (<10 people) with existing tooling, a GRC platform ($6-10k), and a boutique auditor ($5-8k) can come in under $20k. Larger companies or those needing MDM ($3-8k), EDR ($3-10k), SSO ($2-5k), and consulting help ($5-15k) push toward the high end.

The hybrid approach: Platform + consultant guidance is often the sweet spot. Platforms automate evidence collection, but configuring them correctly and knowing which controls actually matter requires experience. A consultant helps you get it right the first time instead of discovering gaps during fieldwork. This front-loaded cost typically pays for itself in reduced audit friction and fewer remediation cycles.

Readiness Assessment + Platform Guidance

$8k-20k+

Written gap analysis against TSC, scope recommendation, platform comparison for your stack, and auditor introductions. At the higher end: hands-on platform configuration, control mapping setup, policy customization, and ongoing guidance through your first audit. Worth it because platforms only automate ~30% of the work—the rest is knowing which controls matter and how to document them. Someone who's done a dozen audits helps you avoid the "we configured this wrong and now we have gaps" discovery during fieldwork.

Compliance Platform

$6k-25k+

Vanta, Drata, Secureframe, Sprinto. Small startups (<10 people) can expect $6k-10k/year for a single framework—auditors often offer discounts when you're on a GRC platform. Worth it if: 15+ employees, 10+ integrations, or limited bandwidth for manual evidence collection. Skip if: <10 employees, simple architecture, strong existing documentation habits. Spreadsheets + screenshot folders genuinely work for small teams with discipline—but platforms pay for themselves in reduced audit fees and time savings at scale.

External Audit

$5k-25k+

Small startups (<10 people): Type I $3k-6k, Type II $5k-8k from boutique specialists—especially with GRC platform discounts. Larger Simple tier ($10-15k). Mid-market firms ($20-50k) for Moderate complexity. Big 4 ($50k+) if enterprise customers explicitly require the name recognition.

Penetration Testing

$10k-40k+

SOC 2 doesn't strictly require penetration testing, but consider it if you handle sensitive data, or customers are asking for it. Price increases with complexity. Simple web app: $9-15k. Web app + API + cloud config review: $15-30k+. Shop around—quality varies significantly. Ask for sample reports and check references.

Simple Tier First-Year Total

$12k-80k

Low end (small startup <10 people): GRC platform ($6-10k) + boutique auditor ($5-8k) + minimal consulting = $12k-25k+. High end: need tools and enteprise tier licensing, MDM/EDR/SSO, comprehensive readiness assessment with remediation guidance, mid-market auditor, comprehensive testing.

Year 2+ Renewal

$10k-40k

Small startups: audit renewal ($5-8k) + platform renewal ($6-10k) = $11k-18k. Larger companies: annual audit ($10-20k, often ~40% less than initial), platform renewal ($10-15k), security posture assessment ($5-10k). Internal time drops significantly because you're maintaining, not building. The painful part is Year 1.

For platform and auditor comparisons with pricing: Visit soc2.fyi - they maintain a community comparison table of vendors. By the team at Authress.

Choosing Your Auditor

The auditor choice matters more than platform choice. You'll work closely with them for 3-6 months, and their experience directly impacts your success.

Show auditor selection guide

Big 4 vs Regional vs Boutique Firms

Firm Type	Typical Cost	Pros	Cons	Best For
Big 4 (Deloitte, PwC, EY, KPMG)	$100k+	Brand recognition, global reach	Expensive, junior staff doing fieldwork, slow, rigid processes, not startup-friendly	Post-Series C, enterprise sales to Fortune 500
Regional Firms (Top 20-100 CPA firms)	$20k-50k+	Solid reputation, experienced, reasonable pricing	Variable startup experience, may not understand modern tech stacks	Series A-B companies, traditional tech stacks
Boutique Firms (Specialized SOC 2 shops)	$3k-15k+	Best service for startups, partners directly involved, modern tech expertise, flexible, fast, understand lean teams	Less brand recognition (but most customers don't care)	Seed to Series B startups, modern tech companies

What to Expect in Initial Auditor Conversations

Discovery call: They'll ask about your business, what customer data you handle, why you need SOC 2, and your timeline. Expect questions like "What type of data do you store—SSNs, financial info, health data?" and "Do you have documented policies and procedures?"
Scoping discussion: Define the "system" under audit—infrastructure, software, people, procedures, and data. They'll want to understand what's in vs. out of scope.
Engagement letter: Formalizes the relationship with systems in scope, TSC included, timeline, fee arrangement, and responsibilities of each party.

Questions to Ask in Your RFP

How many SOC 2 Type II audits have you completed in the last 12 months? (More is better)
What's your average client size? (Make sure they have startup experience, not just enterprise)
Who will actually do the fieldwork? (Try to get names, LinkedIn profiles, years of experience)
How many clients are you currently auditing with similar tech stacks? (AWS/GCP, containers, serverless, SaaS tools)
What's your typical timeline from kickoff to report delivery? (Will vary after observation period)
How do you handle questions during the audit? (Response time expectations, availability)
Can you provide references from companies similar to ours? (Similar size, similar tech)
Do you work with our automation platform? (Most do, but confirm)
What happens if we need to remediate issues mid-audit? (Good auditors are flexible and consultative)

How to Check References

Ask previous clients: "How responsive were they during the audit?" "Did they help you understand requirements or just check boxes?" "Would you use them again?"
Cautionary responses: "They were fine I guess", "We had to chase them for updates", "They didn't understand Tailscale"
Green flag responses: "They taught us a lot", "Very responsive to Slack/email", "They understood our cloud environment", "Felt like a partner, not just an auditor"

Product vs Service Company Experience

Product companies (SaaS, tech platforms): Auditor needs to understand CI/CD, cloud infrastructure, API security, modern dev practices. Ask: "How many SaaS companies have you audited with container-based deployments?"
Professional services firms: Auditor needs to understand Confidentiality TSC, client engagement isolation, document retention for professional work product, matter-based access controls. Ask: "Have you audited consulting/advisory/legal/accounting firms? How do you assess engagement-level access controls?"
Why it matters: An auditor experienced with traditional enterprise software won't understand serverless architectures. An auditor who only does product companies will struggle with professional services engagement models.

Red flags when evaluating consultants or auditors:

"Guaranteed attestation" — No one can guarantee you'll pass. The auditor's judgment is independent.
Same firm offers to prepare AND audit you — This violates independence rules. Use separate firms.
Won't tell you who actually does the work — Ask for resumes. Some firms sell senior expertise but staff with junior analysts.
"SOC 2 in weeks" without knowing your maturity — Unrealistic timelines indicate inexperience or overselling.
Checkbox approach — If they don't take time to understand your business, you'll get generic guidance that leaves gaps.
Upselling through fear — Some consultants emphasize problems to justify expanded engagements rather than helping efficiently.

Who Needs to Be at the Table (and When)

SOC 2 is a cross-functional effort. Here's who you'll need, when to engage them, and how they can help:

Security Lead / Compliance Officer / CISO

When: Day 1 - owns the entire journey (internal staff or fractional/virtual CISO)

The quarterback. Owns the entire process.

Scope definition: What's in, what's out
Policy writing: Draft or adapt templates
Vendor management: Platform and auditor selection
Evidence coordination: Collect and organize everything
Audit liaison: Primary contact during fieldwork

Engineering / DevOps / IT Lead

When: Months 1-5 - heavy involvement during prep and remediation

The implementers. Make technical controls real.

For product companies: Infrastructure diagrams, data flow, logging setup (CloudTrail, SIEM), vulnerability management, CI/CD controls, backup testing
For professional services: SSO/IdP deployment, email/document system configuration, access controls, network security
For all: System architecture documentation, backup/recovery testing, endpoint security (MDM)

IT / System Administrators

When: Months 1-3 for setup, then ongoing for quarterly access reviews

The access gatekeepers. Manage identity and endpoints.

SSO/IdP management: Okta, Google Workspace, Entra ID
User provisioning: Onboarding/offboarding workflows
Access reviews: Quarterly audits of who has access to what
MDM deployment: Endpoint management and compliance
Password policies: Enforce length requirements and MFA. Avoid forced rotation unless compromise is suspected (per NIST SP 800-63B)
Asset inventory: Track all devices and software

HR / People Ops

When: Months 1-2 for policy rollout, ongoing for onboarding/offboarding

The people process owners.

Background screening: Document a risk-based hiring process — reference checks, interviews, and a recorded decision on whether formal background checks are warranted per role (CC1.4 requires you to consider screening, not necessarily perform it for every hire)
Onboarding/offboarding: Document the process
Policy acknowledgments: Get everyone to sign security policies, acceptable use, confidentiality agreements
Training tracking: Security awareness, confidentiality training completion
Professional credentials: Verify licenses where applicable

Product / Engineering / Operations Leadership

When: Month 1 for scoping, Months 9-11 for auditor interviews

The decision makers and interviewees.

System descriptions: Explain what you built/how services are delivered
Data handling: Describe customer/client data workflows and controls
Risk acceptance: Approve documented risks
Policy approval: Sign off on security policies
Auditor interviews: Answer questions about controls
Priority calls: When to fix gaps vs document exceptions

Executives / Partners / Founders

When: Month 1 for commitment and budget, Month 12 for final review

The sponsors.

Budget approval: $20k-50k+ for first audit
Resource allocation: Staff time commitment
Strategic alignment: Why this matters for growth
Management responses: Sign off on any audit findings
Customer/client communication: Leverage report in sales/business development

Using AI to Accelerate SOC 2 Prep

LLMs like Claude, ChatGPT, and others can significantly speed up SOC 2 preparation. But they have blind spots.

Where LLMs Excel

Great AI Use Cases

Policy drafting: "Write an incident response policy for a 25-person SaaS startup"
System descriptions: "Describe our AWS architecture for SOC 2 report" (paste diagram)
Control mapping: "Map these 15 controls to TSC categories"
Evidence checklists: "What evidence do I need for quarterly access reviews?"
Gap analysis: "Compare our current state to SOC 2 requirements"
Risk assessments: "Identify security risks for our stack"
Template adaptation: "Customize this policy for our company"

Show starter prompts for these use cases

Policy Writing

I need to write a [Policy Name] for SOC 2 Type II compliance.

This policy should map to TSC criteria: [e.g., CC6.1-CC6.3 for access control, CC7.3-CC7.4 for incident response]

Our company:
- Industry: [SaaS, Consulting, Technical Services, etc.]
- Size: [X] employees, [Y] contractors
- Client types: [Financial services, Healthcare, Government, SMB, etc.]
- Systems: [Google Workspace/O365], [cloud provider], [key tools]
- TSC scope: [Security only / Security + Confidentiality / other]

The policy should:
- Be concise (2-3 pages max)
- Match what we actually do, not aspirational
- Include specific controls we can implement
- Reference relevant tools we already use
- Owner/responsible party for each control
- How violations get detected and handled
- Integration points with existing workflows (not net-new processes)
- Frequency of reviews/updates

Current state: [Describe what you're already doing, even informally]

Please draft a policy that our auditor will accept but our team will actually follow.
                            

Gap Analysis

Help me identify gaps for SOC 2 Type II readiness.

TSC scope: [Security only / Security + Confidentiality / other]

Current state:
- Access management: [SSO provider or manual per-app / MFA enforced or optional]
- Logging: [Centralized/Per-service/Minimal, retention period]
- Cloud: [AWS/GCP/Azure, audit logs enabled?]
- Access reviews: [Never/Ad-hoc/Quarterly]
- Change management: [PR reviews + CI/CD / Informal / None]
- Vulnerability scanning: [Tool name / None]
- Encryption: [At rest/In transit/Both/Neither]
- Endpoint security: [MDM / Manual policy / None]
- Secrets management: [Tool / Env vars / Hardcoded]
- Hiring process: [Background checks / Reference checks / Informal]
- Incident response: [Documented plan / Ad-hoc / None]
- Business continuity/DR: [Documented / Untested / None]
- Security training: [Annual / Ad-hoc / None]
- Vendor reviews: [Formal process / None]
- Backup testing: [Never tested / Annually / Quarterly]

Team size: [X] engineers, [Y] total employees

Create a prioritized list of gaps with:
1. Impact (P0 = audit blocker, P1 = should have, P2 = nice to have)
2. Estimated effort to fix
3. Free or low-cost solutions where available
4. Timeline to implement

Focus on what we need before starting the audit. Don't recommend tools or controls beyond what's needed for our scope.
                            

Evidence Planning

I need to collect evidence for SOC 2 Type II control: [Control ID and description]

Our setup:
- [Describe relevant systems/processes]
- [Tools we use]
- [Current documentation]
- Audit period: [X months, start/end dates]

Generate a specific evidence collection plan with:
- What artifacts to collect (screenshots, logs, reports, tickets)
- How often to collect (one-time, quarterly, per-event)
- What the evidence should show (specific data points)
- Where to get it (which system, menu, report)
- Acceptable formats (PDF, CSV, screenshot with annotations)
- How many samples needed across the audit period
- Retention requirements (per our policy and applicable regulations)
- Who's responsible for collection
- What to do if evidence is missing or incomplete
- Cross-reference to specific TSC criteria

Be specific - I should be able to hand this to someone and they can execute.
                            

Control Testing Procedures

Create control testing procedures for SOC 2 Type II control: [Control ID and description]

For this control, create a testing procedure that includes:
- What the control claims to do
- Observable outcome that proves it worked
- How to test it (step-by-step)
- Pass/fail criteria
- Testing frequency
- Who should perform the test
- How to document results
- Common failure modes and what to do if the test fails
                            

System Description

Help me write the system description for our SOC 2 report.

Our company:
- What we do: [1-2 sentence description of product/service]
- Customers: [Who uses it, typical size, industries]
- Team: [X] employees across [departments/roles]

Infrastructure:
- Cloud: [AWS/GCP/Azure, key services used]
- Application: [Monolith/Microservices, languages, frameworks]
- Data stores: [Databases, object storage, caches]
- CI/CD: [GitHub Actions/GitLab CI/Jenkins, deployment process]
- Identity: [SSO provider, how users authenticate]
- Monitoring: [Logging, alerting, APM tools]

Data handled:
- Customer data types: [PII, financial, health, business data]
- Data flow: [How data enters, is processed, stored, and exits]
- Integrations: [Third-party services that touch customer data]

TSC scope: [Security only / Security + Confidentiality / other]
Subservice organizations (carve-out): [AWS, Stripe, etc.]

Write the system description in the format auditors expect. Be precise about what's in scope. Don't describe controls we don't actually operate.
                            

Where LLMs Fail

TSC accuracy: LLMs don't have the full Trust Services Criteria memorized accurately — paste the specific criteria text into your prompt for grounded output
Over-scoping: LLMs tend to recommend everything. They don't know your budget, team size, or what your specific auditor cares about. Always ask "is this actually required for my scope?"
Vendor selection: Training data is outdated, pricing changes constantly
Current tool recommendations: May suggest deprecated or acquired tools
Audit scope decisions: Requires understanding of your specific business context
Technical implementation: Can't access your actual infrastructure
Compliance validation: Can't guarantee what auditors will accept
Legal interpretation: Not a lawyer, can't advise on contractual obligations

Caution! Always validate LLM output against official frameworks. LLMs can hallucinate control IDs or requirements. Cross-reference with AICPA Trust Services Criteria (TSC) and your automation platform's requirements.

Consultants vs. Auditors: Distinct Roles

First-timers often confuse these roles. They're deliberately separate, and understanding why saves confusion and money.

Readiness Consultants

They fix things. Gap analyses, control design, policy writing, tool configuration, training. They can log into your systems and build documentation from scratch. No CPA license required—often cybersecurity specialists or former auditors.

Cost: $5k-25k for assessment only. $25k-85k for full readiness engagement with remediation support.

Auditors (CPA Firms)

They evaluate things. Test evidence, assess controls, issue the formal SOC 2 report. Must be licensed CPA firms under AICPA standards. They can tell you your access controls are insufficient, but they cannot help you fix them.

Cost: $5k-8k for small startups (<10 people), $10k-30k for larger companies (boutique firm).

Why they must be separate: Auditor independence rules (AICPA Code 1.200.001) prohibit "self-review"—if someone helped design your controls, they can't objectively audit them. The same firm cannot prepare you and audit you. Some large firms offer both through separate teams, but for small companies, use entirely different firms.

Before you commit to a platform or timeline

Some decisions are annoying to reverse once you've started. If you're going to pay someone, this is where outside perspective is most useful:

Platform selection

Vanta, Drata, Secureframe, Sprinto, or just spreadsheets? They all work. The question is which one fits your stack and how much hand-holding you want, and how much you want to pay.

Scope definition

Security-only or add Confidentiality? Include the staging environment or not? Over-scoping adds cost. Under-scoping means awkward conversations with your auditor later.

Gap identification

You probably have gaps. Most companies do. The question is whether they're "fix in a week" gaps or "delay the audit 3 months" gaps. Better to know before you've promised a customer a completion date.

Timeline reality-check

Type II requires 3-12 months of evidence. If you're missing quarterly access reviews, that's calendar time you can't compress. A quick assessment tells you whether "done by Q2" is realistic or wishful.

What deliverables to expect from a readiness engagement

Gap analysis report (20-50 pages): Current state vs. SOC 2 requirements, color-coded by severity (green/yellow/red), organized by Trust Services Criteria with specific recommendations.
Remediation roadmap: Prioritized action plan with tasks, owners, target dates, and dependencies. Critical gaps first.
Policy templates (15-25 policies): Information security, access control, incident response, business continuity, change management, vendor management, etc. Consultants provide templates; you customize; they review.
Control matrix: Mapping of your specific controls to SOC 2 criteria, showing how each requirement is addressed and what evidence demonstrates it.
System description draft: Documentation of systems, processes, data flows in the format auditors expect. Based on discovery interviews.
Evidence collection checklist: Itemized list of required evidence per control, acceptable formats, and collection procedures.

Division of labor: Consultants write the gap analysis, roadmap, control matrix, and system description. For policies, they provide templates that you customize. Technical configurations, system logs, and operational evidence are your responsibility to produce; consultants review them for adequacy.

Red flags when evaluating consultants: Guaranteed pass promises (auditors decide, not consultants). "We'll do everything for you" claims (you have to operate the controls). Pressure to use their preferred auditor (suggests kickback arrangements). Lack of specific SOC 2 experience (HIPAA/PCI expertise doesn't fully transfer). Fixed-fee engagements with unclear scope (expect change orders).

Realistic Time Commitment

The hours are real. During active readiness phases, expect ~8 hours per week for 6-8 weeks from your core team. This isn't a "set it and forget it" project.

IT/DevOps Lead

Access reviews, logging configs, encryption evidence, change management tickets

HR Lead

Background checks, training records, onboarding/offboarding docs

Compliance Owner

Policy customization, evidence organization, auditor coordination

Executive Sponsor

Policy approval, risk acceptance decisions, auditor interviews

The observation period (3-6 months for Type II) is lighter—just operating controls you've already set up. The bulk of the work is in the initial 2-3 months of preparation.

Platform Reality Check

Compliance platforms (Vanta, Drata, Secureframe, Sprinto) automate about 30% of total compliance work. Vendor marketing claims of 80-90% automation reflect aspirational numbers, not typical outcomes.

What they actually do well:

Evidence collection: Automatic screenshots of configs, user lists, security settings
Continuous monitoring: Alerts when MFA gets disabled or configs drift
Auditor workflow: Evidence sharing, request tracking, communication logs

What they don't do:

Write policies that actually reflect your operations
Conduct access reviews (they remind you; you still do the work)
Fix gaps in your technical architecture
Train employees or run tabletop exercises
Answer auditor interview questions

Platforms are worth the $10k-25k/year for organizations that would otherwise track everything in spreadsheets. But they're a tool, not a shortcut.

When to Get Expert Help

Don't try to DIY everything. Get human experts for:

EXPERT HELP #1

Readiness assessment

$5k-15k for a written gap analysis, scope recommendation, and platform advice. You can skip this if you've done compliance work before. If you haven't, you're basically guessing which controls auditors care about based on blog posts.

EXPERT HELP #2

Complex Technical Architecture

Multi-cloud, microservices, multi-tenant? Get a security architect to review your system description and controls.

EXPERT HELP #3

Remediation of Critical Gaps

If readiness shows you're missing logging, encryption, or access controls - hire someone to implement properly.

EXPERT HELP #4

Your First Audit

Don't cheap out on the auditor. Large firms bring name recognition but cost more and are likely to assign junior staff. Boutique firms often provide a good balance - experienced partners who guide you through the process, competitive rates, and startup-friendly approaches.

EXPERT HELP #5

Security Testing & Validation

SOC 2 doesn't require pentesting or adversarial testing, but you should consider it if you have data-sensitive apps. Also implement phishing-resistant auth (WebAuthn, passkeys, hardware keys), and conduct credential audits to hunt for exposed secrets. SOC 2 proves process compliance, not attack resilience.

Frequently Asked Questions

Real questions from IT teams, developers, product owners, and founders:

Do I need an automation platform or can I just use spreadsheets?

Short answer: You technically can use spreadsheets, but how valuable is your time?

Why? Many auditors expect or even require automation platforms. You'll spend many, many hours manually collecting screenshots, updating spreadsheets, and chasing evidence - time that costs more than the platform fee. Platforms also reduce audit time (lower audit fees) and catch missing evidence before the auditor does.

But if you're a 5-person team with simple infrastructure, already have strong documentation habits, and found an auditor who accepts manual evidence, spreadsheets might work for your first audit. But plan to get a platform if you're scaling.

Will this slow down our service delivery or billable work?

Short answer: Yes, temporarily. But less than you think for most professional services.

The first month will be time intensive with technical control implementation, MFA, logging, access controls, documenting client data handling. Expect administrative overhead. The ongoing overhead is maybe several hours/week for the security/compliance lead plus quarterly access reviews.

But proper access controls, document retention policies, and incident response planning often catch issues earlier. For technical services firms, the controls you implement often become capabilities you can sell.

Can we do this without hiring a dedicated security or compliance person?

Short answer: Probably. But it depends more on deal size and customer pressure than headcount.

When your internal person starts spending more than a few days per month on compliance, or when deals stall because you can't respond to security reviews quickly enough, outside help starts to make sense.

Under $2M ARR with smaller contracts, an internal owner (technical lead, operations manager) and an automation tool can likely handle the checkbox compliance questions. Budget maybe 2 days a month, give or take.

$2-10M ARR or closing $200K+ deals: Customers start shifting from "Do you have SOC 2?" to sending detailed questionnaires and requesting security calls. A fractional advisor (maybe $3-8K/month) could take the brunt of expertise requirements, while internal staff handles day-to-day tasks.

When to hire: When security gaps starts blocking deals, starts adding delays to sales cycles, or becomes an uncomfortable part of every enterprise conversation. Also hits earlier if you're in regulated sectors (healthcare, financial, legal) or handling sensitive data as clients expect deeper security programs regardless of your size. The threshold is more about when your internal owner is in over their head or security questions are costing you revenue.

What happens if we fail the audit?

Short answer: You don't get a satisfactory report, you've spent a lot of money, and you start the audit period over.

If there are material control failures, the auditor won't issue a report at all - they'll stop fieldwork. You fix the gaps and begin again from scratch (new timeline, new fees). If there are minor exceptions, you get a "qualified opinion" which is usable but looks bad and requires explanation to clients. Some clients may accept it, others won't.

How to avoid: Do a readiness assessment before the audit. Fix the critical gaps before starting. Don't start the audit to "see what happens" - that's expensive. For professional services, common failure points are inadequate client data classification, weak document retention policies, or lack of evidence for access reviews.

We're fully remote. Does that make SOC 2 harder?

Short answer: No, it makes some things easier.

Remote-first companies skip physical security controls (office badges, visitor logs, camera systems). Your scope is cleaner: cloud infrastructure, endpoint security (MDM), and network access (VPN/zero-trust). Most automation platforms are built for cloud-native, remote-first companies.

What you need: Strong MDM enforcement (laptop encryption, screen lock), VPN or zero-trust network access, and solid employee device offboarding process. That's it for physical/endpoint controls.

Can we scope it to just specific service lines or client types if we have multiple?

Short answer: Yes, but be strategic about boundaries.

You can limit scope to specific service offerings or client segments (e.g., "Financial advisory services only" or "Services for healthcare clients only"). But shared infrastructure gets complicated — if Service Line A and B share any of the following, the auditor will pull those shared components into scope regardless of what your system description says:

Cloud accounts (AWS org, Azure subscription, GCP project)
Identity provider (Okta, Google Workspace, Entra ID)
CI/CD pipelines
Monitoring and logging infrastructure
Team members with cross-product access

You can't claim your access controls are effective for Service Line A while Service Line B's people have equivalent access through the same mechanisms. The control environment is the control environment.

Best approach: Either accept the shared layer and include it in scope (simpler), or segment the infrastructure so the boundary is real — separate cloud accounts, separate IAM groups, separate deployment pipelines. Trying to draw arbitrary lines through shared infrastructure creates audit headaches and credibility issues. If you can't create real separation, just bring it all in and accept the larger audit surface.

How much does this distract from actually serving clients?

Short answer: A fair bit at first. Then a smaller bit.

Preparation phase: Security/compliance lead spends tons of time on SOC 2, IT/operations spends a lot on implementing controls. Evidence collection phase: several hours/week for security lead, minimal for others. Audit fieldwork: lots of interviews, then waiting. Post-audit: Back to normal with ongoing quarterly reviews.

SOC 2 is the price of admission to enterprise clients and regulated sectors. The alternative is losing large engagements to firms that have the attestation. So most accept the 3-month heavy lift to unblock growth. For professional services, this also demonstrates to clients that you take their data seriously - which can be a relationship strengthener, not just a compliance box to check.

SOC 2 Complete Guide