SOC 2 Readiness for Startups: Trust Service Criteria, Evidence Collection, and Tooling

SOC 2 Readiness for Startups

A practical guide to SOC 2 compliance that respects startup constraints: limited headcount, tight budgets, and the need to ship product.

SOC 2 is often the first compliance framework a startup encounters. Enterprise customers require it before they will evaluate your product, procurement teams ask for the report before signing contracts, and investors increasingly expect it as a sign of operational maturity. This guide covers what SOC 2 actually requires, how to prepare without hiring a compliance team, and where to invest versus where to cut corners responsibly.

Table of Contents

• 1. SOC 2 Fundamentals
  • 1.1 What SOC 2 Is (and Is Not)
  • 1.2 SOC 2 Type I vs. Type II
  • 1.3 Who Needs SOC 2
  • 1.4 The Audit Process Overview
  • 1.5 Cost and Timeline Expectations
• 2. Trust Service Criteria
  • 2.1 Security (Common Criteria) - Required
  • 2.2 Availability - Optional
  • 2.3 Processing Integrity - Optional
  • 2.4 Confidentiality - Optional
  • 2.5 Privacy - Optional
  • 2.6 Which Criteria to Include
• 3. The Common Criteria Deep Dive
  • 3.1 CC1: Control Environment
  • 3.2 CC2: Communication and Information
  • 3.3 CC3: Risk Assessment
  • 3.4 CC4: Monitoring Activities
  • 3.5 CC5: Control Activities
  • 3.6 CC6: Logical and Physical Access Controls
  • 3.7 CC7: System Operations
  • 3.8 CC8: Change Management
  • 3.9 CC9: Risk Mitigation
• 4. Building Your Control Framework
  • 4.1 Scoping Your Audit
  • 4.2 Writing Policies That Pass Audit
  • 4.3 Mapping Controls to Criteria
  • 4.4 Startup-Appropriate Controls
• 5. Evidence Collection
  • 5.1 What Auditors Actually Want
  • 5.2 Evidence Types and Sources
  • 5.3 Continuous Evidence Collection
  • 5.4 Common Evidence Gaps
  • 5.5 Evidence Retention
• 6. Technical Controls Implementation
  • 6.1 Identity and Access Management
  • 6.2 Encryption
  • 6.3 Logging and Monitoring
  • 6.4 Vulnerability Management
  • 6.5 Incident Response
  • 6.6 Business Continuity and Disaster Recovery
  • 6.7 Change Management
  • 6.8 Endpoint Security
• 7. Compliance Automation Tooling
  • 7.1 Why Automation Matters for Startups
  • 7.2 Platform Comparison
  • 7.3 Evaluating Compliance Platforms
  • 7.4 DIY vs. Platform Approach
• 8. Navigating the Audit
  • 8.1 Selecting an Auditor
  • 8.2 Readiness Assessment
  • 8.3 The Audit Process
  • 8.4 Handling Exceptions and Findings
  • 8.5 After the Report
• 9. Common Startup Mistakes
• 10. SOC 2 Readiness Checklist
• 11. Timeline and Roadmap
• 12. References and Resources

1. SOC 2 Fundamentals

1.1 What SOC 2 Is (and Is Not)

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). It evaluates whether an organization has designed and operated controls that meet one or more Trust Service Criteria (TSC) over a defined period.

What SOC 2 is:

• An independent auditor’s opinion on whether your controls are designed and operating effectively
• Based on the AICPA’s Trust Service Criteria (derived from the COSO internal control framework)
• Specific to your organization’s system description – you define the scope
• An attestation report, not a certification (there is no “SOC 2 certified” status)

What SOC 2 is not:

• A prescriptive checklist (it does not dictate specific technologies or configurations)
• A one-time achievement (Type II reports cover a time window and must be renewed)
• A guarantee of security (it confirms controls exist and operate, not that breaches are impossible)
• A replacement for other frameworks (it does not satisfy PCI DSS, HIPAA, or FedRAMP on its own, though controls overlap significantly)

1.2 SOC 2 Type I vs. Type II

Aspect	Type I	Type II
What it tests	Control design at a point in time	Control design and operating effectiveness over a period
Observation window	Single date (snapshot)	3-12 months (typically 6 or 12)
Auditor effort	Lower	Higher (sampling, testing)
Cost	Lower (typically 50-70% of Type II)	Higher
Customer acceptance	Some will accept it	Most enterprise buyers expect this
Time to complete	1-2 months	3-12 month observation + 1-2 month audit

Recommendation for startups: Start with a Type I to prove your controls are designed correctly, then transition to a Type II. Some startups skip Type I entirely and go straight to Type II with a shorter (3-6 month) observation window. Discuss this with your auditor – the right approach depends on your sales pipeline urgency and control maturity.

1.3 Who Needs SOC 2

You likely need SOC 2 if:

• You sell B2B SaaS and your customers are mid-market or enterprise
• Prospect security questionnaires ask for your SOC 2 report repeatedly
• You handle, store, or process customer data in any form
• Your sales cycle includes vendor security reviews that are blocking deals
• You are raising a Series A or later and investors expect operational maturity

You likely do not need SOC 2 (yet) if:

• You are pre-product with no paying customers
• Your customers are exclusively SMBs or consumers who do not request compliance reports
• You operate in a regulated industry where a different framework (HIPAA, PCI DSS, FedRAMP) is the primary requirement and SOC 2 would be redundant

1.4 The Audit Process Overview

Scoping          Readiness       Observation     Audit           Report
(2-4 weeks)      (4-12 weeks)    (3-12 months)   (4-8 weeks)     Delivery
    |                |               |               |               |
    v                v               v               v               v
Define system    Implement       Operate          Auditor tests   Final report
boundaries,      controls,       controls,        controls,       issued and
select TSC,      write           collect          samples         shared with
choose auditor   policies        evidence         evidence        customers

1.5 Cost and Timeline Expectations

Component	Typical Range (Startup)	Notes
Compliance platform	$10,000 - $30,000/year	Vanta, Drata, Secureframe, etc.
Auditor fees (Type I)	$15,000 - $30,000	Depends on scope and firm
Auditor fees (Type II)	$20,000 - $50,000	Depends on scope and observation period
Penetration test	$5,000 - $20,000	Not explicitly required by TSC, but expected by nearly every auditor; scope-dependent
Security tooling	$5,000 - $15,000/year	MDM, SIEM, vulnerability scanning
Internal time	200-400 hours	Spread across engineering, ops, and a compliance lead
Total first year	$50,000 - $120,000	Subsequent years are typically 40-60% of year one
Timeline to Type II	6-14 months	From decision to report delivery

These are rough ranges. A 5-person startup with a single SaaS product hosted on AWS will be at the low end. A 50-person company with multiple products, on-premise components, and subservice organizations will be at the high end.

2. Trust Service Criteria

The Trust Service Criteria are organized into five categories. Security (Common Criteria) is always required. The other four are optional and selected based on your system and customer expectations.

2.1 Security (Common Criteria) - Required

The Security criteria (CC1 through CC9) form the foundation of every SOC 2 report. They address:

• Governance and organizational structure
• Risk assessment and management
• Access controls (logical and physical)
• System operations and monitoring
• Change management
• Incident response

These are covered in detail in Section 3.

2.2 Availability - Optional

Availability criteria address whether the system is operational and accessible as committed or agreed upon. Relevant if your customers depend on uptime SLAs.

What it covers:

• Uptime commitments and SLA definitions
• Capacity planning and performance monitoring
• Disaster recovery and business continuity
• Backup and restoration procedures
• Incident response for availability events

Include this if: You offer uptime SLAs, your product is business-critical for customers, or customers specifically ask about availability in their security questionnaires.

Evidence examples: Uptime monitoring dashboards (e.g., status page history), DR test results, capacity planning documentation, backup restoration test logs.

2.3 Processing Integrity - Optional

Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized.

What it covers:

• Data processing accuracy and completeness
• Error detection and correction procedures
• Input validation and output reconciliation
• Quality assurance processes

Include this if: Your product performs financial calculations, data transformations, transaction processing, or other operations where processing accuracy is critical to your customers.

Evidence examples: Data validation rules documentation, reconciliation reports, QA test results, error handling procedures.

2.4 Confidentiality - Optional

Confidentiality criteria address whether information designated as confidential is protected as committed or agreed.

What it covers:

• Classification and handling of confidential information
• Encryption of confidential data at rest and in transit
• Access restrictions to confidential data
• Secure disposal of confidential information
• NDA and contractual obligations

Include this if: You handle data that customers explicitly classify as confidential (trade secrets, proprietary data, pre-release information), or if your contracts include confidentiality provisions about the data you process.

Evidence examples: Data classification policy, encryption configurations, access control lists for confidential data stores, data retention and disposal procedures.

2.5 Privacy - Optional

Privacy criteria address the collection, use, retention, disclosure, and disposal of personal information. The current TSC Privacy criteria (revised 2022) are structured within the same framework as the other Trust Service Criteria, replacing the earlier Generally Accepted Privacy Principles (GAPP) approach.

What it covers:

• Notice and consent for data collection
• Data minimization and purpose limitation
• Access and correction rights for data subjects
• Disclosure to third parties
• Data retention and disposal
• Privacy incident response

Include this if: You collect or process personal information (PII) and your customers or their end users are in jurisdictions with privacy regulations (GDPR, CCPA, etc.). Note that Privacy is the most labor-intensive optional criterion and has significant overlap with GDPR compliance.

Evidence examples: Privacy policy, consent mechanisms, data processing agreements, data subject access request procedures, privacy impact assessments.

2.6 Which Criteria to Include

For a typical B2B SaaS startup on a first SOC 2 engagement:

Criteria	Recommendation	Rationale
Security	Always include	Required for all SOC 2 reports
Availability	Include if you have SLAs	Most SaaS customers expect it
Processing Integrity	Defer unless product demands it	Add in year two if customers ask
Confidentiality	Include	Low incremental effort, high overlap with Security
Privacy	Defer unless handling significant PII	High effort, consider adding after initial report

Start lean. Every additional criterion increases scope, evidence burden, and audit cost. You can add criteria in subsequent audit cycles without invalidating prior reports.

3. The Common Criteria Deep Dive

The Security (Common Criteria) category contains nine control groups (CC1-CC9). Each maps to specific COSO principles. Below is what each group requires and how startups typically satisfy it.

3.1 CC1: Control Environment

What it requires: The organization demonstrates a commitment to integrity and ethical values, exercises board oversight, establishes structures and reporting lines, attracts and retains competent individuals, and holds people accountable.

Startup implementation:

• Code of conduct / ethics policy – Does not need to be lengthy. A one-page document that employees acknowledge annually is sufficient.
• Organizational chart – Showing reporting lines and security responsibilities. For a 10-person startup, this can be simple.
• Board or management oversight – Document that leadership reviews security posture periodically. For early-stage companies, this can be a quarterly agenda item in leadership meetings with documented minutes.
• Background checks – Run background checks on new hires. Third-party services (Checkr, GoodHire) cost $30-50 per check and integrate with most HRIS platforms.
• Security awareness training – Annual training for all employees with completion tracking. Platforms like KnowBe4 or Curricula offer startup-friendly pricing.

Common evidence:

Control	Evidence
Commitment to integrity	Signed code of conduct, ethics policy
Board oversight	Meeting minutes documenting security review
Organizational structure	Org chart, role descriptions with security duties
Competence commitment	Training completion records, job descriptions
Accountability	Performance review templates referencing security, offboarding checklists

3.2 CC2: Communication and Information

What it requires: The organization obtains or generates and uses relevant, quality information to support internal control. It internally and externally communicates information necessary for controls to function.

Startup implementation:

• Internal communication – Security policies are accessible to all employees (e.g., in a shared wiki or handbook). Changes to policies are communicated via email or Slack with acknowledgment.
• External communication – Customers and third parties can report security concerns. Publish a security.txt file and a responsible disclosure policy. Maintain a security contact (e.g., [email protected]).
• System description – Document what your system does, how data flows through it, and what infrastructure supports it. This becomes part of your SOC 2 report.

Key documents to prepare:

• Information security policy (master policy document)
• System description document (required for the SOC 2 report itself)
• Responsible disclosure / vulnerability reporting policy
• Security contact information (security.txt, public security page)

3.3 CC3: Risk Assessment

What it requires: The organization specifies objectives with sufficient clarity, identifies and analyzes risks to achievement of objectives, and considers the potential for fraud.

Startup implementation:

• Risk register – Identify risks to your system, assess likelihood and impact, and document mitigating controls. This does not need to be elaborate. A spreadsheet with 20-40 entries covering your key risk areas is sufficient for a first audit.

Example risk register format:

ID	Risk Description	Likelihood	Impact	Inherent Risk	Mitigating Controls	Residual Risk	Owner	Review Date
R-001	Unauthorized access to production database	Medium	High	High	MFA on cloud console, network segmentation, least privilege IAM, audit logging	Low	CTO	2025-Q3
R-002	Employee laptop lost with customer data	Medium	Medium	Medium	Full-disk encryption, MDM with remote wipe, no local data storage policy	Low	IT Lead	2025-Q3
R-003	Third-party vendor breach exposes customer data	Low	High	Medium	Vendor security reviews, data minimization, contractual obligations	Low	Security Lead	2025-Q3

• Annual risk assessment – Review and update the register at least annually. Document who performed the review and what changed.
• Fraud consideration – Explicitly consider fraud risk (insider threat, management override of controls). This can be a section in your risk assessment rather than a separate exercise.

3.4 CC4: Monitoring Activities

What it requires: The organization selects, develops, and performs ongoing evaluations to ascertain whether controls are present and functioning. It evaluates and communicates deficiencies in a timely manner.

Startup implementation:

• Continuous monitoring – Automated alerts for security events (failed logins, unauthorized access attempts, configuration changes). Cloud-native tools (AWS CloudTrail + EventBridge, GCP Cloud Audit Logs) provide this at minimal cost.
• Periodic reviews – Quarterly access reviews, annual policy reviews, annual penetration testing.
• Deficiency tracking – When a control gap is identified, track it to resolution. A simple issue tracker (Linear, Jira, GitHub Issues) with a “compliance” label works.

Monitoring cadence for startups:

Activity	Frequency	Responsible
Automated security alerts	Continuous	Engineering / On-call
Access reviews (user accounts, permissions)	Quarterly	Engineering Lead
Vendor security reviews	Annually or on renewal	Security Lead
Policy reviews and updates	Annually	Security Lead
Penetration testing	Annually	External firm
Risk assessment update	Annually	Leadership
Security awareness training	Annually	HR / Security Lead

3.5 CC5: Control Activities

What it requires: The organization selects and develops control activities that contribute to mitigating risks to acceptable levels. It deploys controls through policies and procedures.

Startup implementation:

This is where your policies translate into operational controls. For each risk in your register, there should be one or more controls that mitigate it. Controls can be:

• Preventive – Stop bad things from happening (e.g., MFA prevents unauthorized access)
• Detective – Identify bad things that have happened (e.g., audit logs detect unauthorized changes)
• Corrective – Fix bad things after detection (e.g., incident response procedures)

Focus on automating controls. An automated control that runs on every deployment is more reliable (and easier to evidence) than a manual quarterly review. Examples:

Manual Control	Automated Equivalent
Quarterly review of deployed configurations	Infrastructure-as-code with PR review requirements
Monthly check for unencrypted data stores	Cloud configuration scanner (AWS Config, Prowler)
Periodic vulnerability scanning	Automated scanning in CI/CD pipeline
Manual access provisioning	SSO with automated provisioning/deprovisioning

3.6 CC6: Logical and Physical Access Controls

What it requires: The organization restricts logical access, manages credentials, prevents unauthorized access, and controls physical access to facilities.

Startup implementation:

• Single Sign-On (SSO) – Use an identity provider (Google Workspace, Okta, Microsoft Entra) as the single source of truth for user access. Enforce SSO for all SaaS tools and internal systems.
• Multi-Factor Authentication (MFA) – Require MFA on all accounts. Prefer hardware keys (YubiKey) or authenticator apps over SMS.
• Least privilege access – Use role-based access control (RBAC). Engineers should not have production database admin access by default.
• Access provisioning and deprovisioning – Documented onboarding and offboarding procedures. When someone leaves, their access is revoked within 24 hours (ideally immediately via SSO deactivation).
• Physical access – If you have an office, document access controls (key cards, visitor logs). If fully remote, document that no physical infrastructure exists and all assets are cloud-hosted.

Cloud infrastructure access controls:

Developers      -> SSO + MFA -> Cloud Console (read-only by default)
                                   |
                                   +--> Production (requires approval + break-glass)
                                   +--> Staging (self-service, limited scope)
                                   +--> Development (self-service)

Infrastructure  -> SSO + MFA -> Cloud Console (admin)
Lead                              |
                                  +--> Production (full access, audit-logged)
                                  +--> Infrastructure-as-code (all changes via PR)

3.7 CC7: System Operations

What it requires: The organization detects and responds to anomalies, monitors for vulnerabilities, and responds to incidents.

Startup implementation:

• Monitoring and alerting – Monitor infrastructure and application health. Alert on anomalies (spike in error rates, unusual access patterns, resource exhaustion).
• Vulnerability management – Run regular vulnerability scans (at minimum, quarterly external scans and continuous dependency scanning in CI/CD). Track findings to resolution with defined SLAs.
• Incident response plan – A written plan that covers detection, triage, containment, eradication, recovery, and post-incident review. Test it annually (tabletop exercise at minimum).

Vulnerability management SLAs:

Severity	Remediation Timeline	Notes
Critical (CVSS 9.0-10.0)	72 hours	Network-exploitable with no user interaction; accelerate further if listed in CISA KEV
High (CVSS 7.0-8.9)	30 days	Significant risk, may require specific conditions to exploit
Medium (CVSS 4.0-6.9)	90 days	Moderate risk, typically requires chain of conditions or local access
Low (CVSS 0.1-3.9)	Next scheduled maintenance	Minimal practical risk

3.8 CC8: Change Management

What it requires: The organization manages changes to infrastructure, software, and procedures in a controlled manner.

Startup implementation:

• All code changes go through pull requests with at least one reviewer
• CI/CD pipeline runs automated tests, linting, and security scans before merge
• Production deployments are automated and repeatable (no manual SSH and edit)
• Infrastructure changes are managed via IaC (Terraform, Pulumi, CloudFormation) with version control
• Change log – Maintain a record of what changed, when, by whom, and why. Git history plus deployment logs typically satisfy this.

What auditors look for:

Control	Evidence Source
Changes are authorized before implementation	PR approval records in GitHub/GitLab
Changes are tested before deployment	CI/CD pipeline execution logs, test results
Changes are tracked	Git commit history, deployment logs
Emergency changes follow a defined process	Emergency change policy, retrospective documentation
Separation of duties	Different person approves and deploys (or automated deployment after approval)

3.9 CC9: Risk Mitigation

What it requires: The organization identifies and assesses risk from business relationships, acquires or develops remediation activities, and mitigates risk through business continuity planning.

Startup implementation:

• Vendor management – Maintain a list of vendors who access, process, or store customer data. Review their security posture (request their SOC 2 report, review their security page). Track vendor reviews annually.
• Insurance – Cyber liability insurance is expected by many enterprise customers. Obtain a policy and document coverage limits.
• Business continuity – Document how the business continues operating during disruptions. For a cloud-hosted SaaS, this primarily means multi-region or multi-AZ architecture, automated failover, and tested backup restoration.

Vendor inventory template:

Vendor	Data Access	SOC 2 Report	Last Review	Risk Level	Owner
AWS	Hosts all infrastructure	Yes (Type II)	2025-03	High (critical dependency)	CTO
Stripe	Processes payments	Yes (Type II, PCI DSS)	2025-03	High	Engineering Lead
SendGrid	Sends transactional email	Yes (Type II)	2025-03	Medium	Engineering Lead
Slack	Internal communication	Yes (Type II)	2025-03	Low	IT Lead

4. Building Your Control Framework

4.1 Scoping Your Audit

Scoping determines what is included in your SOC 2 report. A tighter scope means fewer controls, less evidence, and lower audit costs.

In scope:

• The production system that customers interact with
• Infrastructure supporting that system (cloud accounts, databases, CDNs)
• People who can access production systems or customer data
• Processes that affect the security of the system (development, deployment, incident response)
• Vendors who process, store, or access customer data (subservice organizations)

Out of scope (if justifiable):

• Internal tools that do not touch customer data
• Development and staging environments (if properly isolated from production)
• Marketing website (if on separate infrastructure with no customer data)
• Corporate IT systems that do not connect to the production environment

Subservice organizations (carve-out vs. inclusive):

Vendors like AWS, GCP, and Stripe are “subservice organizations” in SOC 2 terminology. Your report must address them using one of two methods:

• Carve-out method (recommended for startups): Your report excludes the subservice organization’s controls and states that customers should refer to that vendor’s own SOC 2 report. You document your complementary user entity controls (CUECs) – the controls you operate on top of the vendor’s platform (e.g., “we configure IAM policies on AWS; AWS is responsible for physical data center security”).
• Inclusive method: Your report includes the subservice organization’s controls within your own. This is rare and typically only used when you manage the vendor’s environment or have deep contractual control over their operations.

Nearly every SaaS startup uses the carve-out method. Your system description should list each subservice organization, describe what they provide, and reference the availability of their own SOC 2 report.

Write a system description that clearly defines these boundaries. Your auditor will use this as the basis for the report. Ambiguity in scope leads to scope creep during the audit.

4.2 Writing Policies That Pass Audit

Auditors evaluate whether policies exist, are approved by management, are communicated to employees, and are reviewed periodically. They do not require lengthy documents.

Core policies for SOC 2:

Policy	Purpose	Typical Length
Information Security Policy	Master policy covering security objectives, roles, and responsibilities	3-5 pages
Access Control Policy	User provisioning, authentication, least privilege, deprovisioning	2-3 pages
Change Management Policy	Code review, testing, deployment, emergency changes	2-3 pages
Incident Response Policy	Detection, escalation, containment, communication, post-mortem	3-5 pages
Risk Assessment Policy	Risk identification, analysis, treatment, and review cadence	1-2 pages
Data Classification Policy	Categories of data, handling requirements per category	1-2 pages
Acceptable Use Policy	Employee responsibilities for company systems and data	2-3 pages
Vendor Management Policy	Vendor assessment, onboarding, monitoring, and offboarding	1-2 pages
Business Continuity / DR Policy	Recovery objectives, procedures, testing requirements	2-3 pages
Encryption Policy	Encryption standards for data at rest and in transit	1-2 pages

Policy writing tips:

• State what you actually do, not what you aspire to do. The auditor will test whether you follow your own policies. An aspirational policy you violate is worse than a modest policy you follow consistently.
• Include version, owner, approval date, and next review date in every policy header.
• Use clear, testable language. “Access reviews are performed quarterly” is testable. “Access is reviewed periodically” is not.
• Reference specific tools and processes. “All code changes require a pull request with at least one approving review in GitHub before merge” is better than “code changes are reviewed before deployment.”

4.3 Mapping Controls to Criteria

Create a control matrix that maps each control to the criteria it satisfies. This becomes the backbone of your audit evidence collection.

Example mapping (abbreviated):

Control ID	Control Description	TSC Criteria	Evidence Source	Frequency
AC-01	SSO enforced for all production systems	CC6.1, CC6.2	IdP configuration screenshot	Continuous
AC-02	MFA required for all user accounts	CC6.1, CC6.6	IdP MFA policy configuration	Continuous
AC-03	Quarterly access reviews performed	CC6.2, CC6.3	Access review spreadsheet, tickets	Quarterly
AC-04	Access revoked within 24 hours of termination	CC6.2, CC6.5	Offboarding ticket, IdP deactivation log	Per event
CM-01	All code changes require PR with approval	CC8.1	GitHub branch protection settings, merged PR samples	Continuous
CM-02	CI/CD runs automated tests before deploy	CC8.1, CC7.1	CI pipeline configuration, run logs	Continuous
IR-01	Incident response plan documented and tested	CC7.3, CC7.4	IRP document, tabletop exercise notes	Annual test
VM-01	Vulnerability scanning in CI/CD pipeline	CC7.1	Scanner configuration, findings reports	Continuous
RA-01	Annual risk assessment performed	CC3.1, CC3.2	Risk register, assessment report	Annual

A complete matrix for a typical SaaS startup will have 40-80 controls. Compliance platforms generate this mapping automatically.

4.4 Startup-Appropriate Controls

You do not need enterprise-grade tooling to pass SOC 2. Here is what “good enough” looks like at different company sizes:

5-15 employees (seed/Series A):

• Google Workspace or Microsoft 365 as IdP with enforced MFA
• GitHub or GitLab with branch protection and required reviews
• AWS/GCP/Azure with SSO federation, CloudTrail enabled, and root account locked down
• A compliance platform (Vanta, Drata) to automate evidence collection
• Laptops with full-disk encryption and MDM (Kandji, Jamf, or Fleet)
• Annual third-party penetration test
• Policies written from templates (compliance platform provides these)

15-50 employees (Series A/B):

Everything above, plus:

• Dedicated security or compliance role (can be part-time or a compliance-focused engineer)
• SIEM or log aggregation (Datadog, Elastic, or cloud-native equivalents)
• Automated vulnerability scanning (Snyk, Trivy, or Dependabot)
• Formal vendor management program
• Quarterly access reviews with documented evidence
• Security awareness training platform (KnowBe4, Curricula)

5. Evidence Collection

5.1 What Auditors Actually Want

Auditors need to see that controls are designed (policy exists, configuration is in place) and operating (the control was followed consistently during the observation period). For Type II, they will sample events across the observation window.

The auditor’s mental model for every control:

1. Does a policy or procedure define this control?
2. Is there a configuration or mechanism that implements it?
3. Can you show me evidence that it operated during the review period?
4. If there were exceptions, were they detected and addressed?

If you can answer yes to all four, the control passes.

5.2 Evidence Types and Sources

Evidence Type	Examples	Collection Method
Configuration screenshots	MFA enforcement, branch protection rules, encryption settings, IAM policies	Manual or automated capture via compliance platform
System-generated logs	CloudTrail events, CI/CD pipeline runs, access provisioning/deprovisioning logs	Automated export
Signed documents	Policies with approval signatures, employee acknowledgments, training completion records	Document management system
Lists and inventories	Asset inventory, vendor inventory, user access list	Automated via IdP/cloud provider APIs
Reports	Penetration test report, vulnerability scan results, access review results	Annual or quarterly deliverables
Tickets and records	Incident response tickets, change requests, exception approvals	Issue tracker (Jira, Linear, GitHub Issues)
Meeting artifacts	Security review meeting minutes, risk assessment meeting notes	Calendar events with attached minutes

5.3 Continuous Evidence Collection

Manual evidence collection does not scale and introduces human error. Automate as much as possible:

Cloud infrastructure evidence:

# AWS: list CloudTrail trails and check multi-region status
aws cloudtrail describe-trails \
  --query 'trailList[*].{Name:Name,IsMultiRegion:IsMultiRegionTrail,HomeRegion:HomeRegion}'

# AWS: verify a specific trail is actively logging
aws cloudtrail get-trail-status --name your-trail-name \
  --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime}'

# AWS: verify S3 default encryption
aws s3api get-bucket-encryption --bucket your-bucket-name

# AWS: list IAM users without MFA
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F',' '$4 == "true" && $8 == "false" {print $1, "has no MFA"}'

GitHub evidence collection:

# Verify branch protection on main branch
gh api repos/{owner}/{repo}/branches/main/protection \
  --jq '{
    required_reviews: .required_pull_request_reviews.required_approving_review_count,
    dismiss_stale: .required_pull_request_reviews.dismiss_stale_reviews,
    enforce_admins: .enforce_admins.enabled,
    require_status_checks: .required_status_checks.strict
  }'

# List organization members WITHOUT MFA enabled
gh api "orgs/{org}/members?filter=2fa_disabled" --jq '.[].login'
# An empty result means all members have MFA enabled

# Export merged PRs for the observation period (change management evidence)
gh pr list --repo {owner}/{repo} \
  --state merged \
  --search "merged:2025-01-01..2025-06-30" \
  --json number,title,author,mergedAt,reviews \
  --limit 500

Compliance platforms automate this by connecting to your cloud providers, IdP, version control, HR system, and other tools via API integrations. They continuously collect evidence and flag gaps.

5.4 Common Evidence Gaps

Issues that frequently surface during audit preparation:

Gap	Impact	Fix
No documentation of access reviews	CC6 finding	Schedule quarterly reviews, save spreadsheet evidence
Policies not reviewed/updated annually	CC1, CC2 finding	Update policy headers, document review in meeting minutes
No evidence of security training	CC1 finding	Deploy training platform, track completion
Offboarding lacks evidence of access revocation	CC6 finding	Add IdP deactivation screenshot to offboarding ticket
No vendor security review records	CC9 finding	Create vendor inventory, request SOC 2 reports, document reviews
Emergency changes bypass normal process without documentation	CC8 finding	Create emergency change procedure, require retroactive documentation
No penetration test in the observation period	CC7 finding	Schedule annual pentest, retain full report
Backup restoration not tested	A1 finding (if Availability included)	Run quarterly restore tests, document results
No risk assessment documentation	CC3 finding	Complete risk register, document the assessment process

5.5 Evidence Retention

Retain evidence for the duration required by your auditor and customers:

• Minimum: 1 year beyond the observation period
• Recommended: 3 years (some enterprise contracts require this)
• Logs: Retain security-relevant logs for at least 1 year (CloudTrail, access logs, CI/CD logs)
• Policies: Retain prior versions to demonstrate evolution and regular review

Store evidence in a system with access controls and audit logging. A dedicated Google Drive folder with restricted sharing, a compliance platform’s evidence vault, or a versioned S3 bucket with access logging all work.

6. Technical Controls Implementation

6.1 Identity and Access Management

Minimum requirements:

• Centralized identity provider (Google Workspace, Okta, Microsoft Entra)
• SSO enforced for all SaaS tools and cloud consoles
• MFA required for all accounts (no exceptions)
• RBAC with documented roles and permissions
• Automated provisioning and deprovisioning tied to HR events
• Quarterly access reviews with documented remediation

Cloud IAM checklist:

• Root / super-admin accounts secured with hardware MFA and used only for break-glass
• SSO federation configured for cloud console access
• Service accounts use short-lived credentials or workload identity
• IAM policies follow least privilege (no wildcard permissions in production)
• Unused accounts and credentials are removed (automate detection)
• Access to production is separate from access to development/staging

6.2 Encryption

Data at rest:

• All databases encrypted (RDS encryption, DynamoDB encryption, etc.)
• All object storage encrypted (S3 default encryption, GCS)
• All block storage encrypted (EBS encryption)
• Laptop full-disk encryption enforced via MDM (FileVault, BitLocker)
• Encryption keys managed via cloud KMS (not stored in application code)

Data in transit:

• TLS 1.2 or higher for all external connections
• TLS for all internal service-to-service communication
• HSTS headers configured on all web endpoints
• Certificate management automated (ACM, Let’s Encrypt)

What auditors verify: Encryption configuration is enabled (screenshot or API output), key management is centralized, and deprecated protocols (TLS 1.0, 1.1, SSL 3.0) are disabled.

6.3 Logging and Monitoring

What to log:

Event Category	Examples	Retention
Authentication	Login success/failure, MFA events, SSO assertions	1 year minimum
Authorization	Permission changes, role assignments, access denials	1 year minimum
Data access	Database queries to sensitive tables, file downloads, API access to customer data	1 year minimum
Infrastructure	Cloud API calls (CloudTrail/Cloud Audit Logs), network flow logs, configuration changes	1 year minimum
Application	Errors, security events, business logic anomalies	90 days minimum

Monitoring and alerting:

• Alert on root/admin account usage
• Alert on failed authentication exceeding threshold
• Alert on infrastructure configuration changes outside IaC
• Alert on unauthorized access attempts
• Alert on anomalous data access patterns

Cloud-native services (CloudWatch Alarms, GCP Monitoring, Azure Monitor) provide sufficient alerting for most startups. Centralize logs in a SIEM or log aggregation tool if budget allows.

6.4 Vulnerability Management

Program components:

1. Dependency scanning – Automated in CI/CD (Dependabot, Snyk, Trivy). Runs on every pull request.
2. Container image scanning – Scan images before pushing to registries. Block deployment of images with critical vulnerabilities.
3. Infrastructure scanning – Run cloud security posture management (CSPM) tools (Prowler for AWS, ScoutSuite, or cloud-native tools like AWS Security Hub).
4. Annual penetration test – Engage an external firm. Ensure the report covers your SOC 2 system scope. Retain the full report as evidence.
5. Tracking and remediation – All findings are logged in your issue tracker with severity-based SLAs. Track mean time to remediate.

6.5 Incident Response

Plan requirements:

An incident response plan must cover:

• Roles and responsibilities – Who is the incident commander, who communicates externally, who makes containment decisions
• Classification and severity levels – Define what constitutes a SEV-1, SEV-2, SEV-3 and the corresponding response expectations
• Communication procedures – Internal escalation paths, customer notification criteria, regulatory notification requirements (breach notification laws)
• Response procedures – Detection, triage, containment, eradication, recovery, post-incident review
• Contact information – On-call rotation, legal counsel, PR/communications, insurance carrier, law enforcement

Testing the plan:

Auditors look for evidence that the plan has been tested. At minimum, conduct an annual tabletop exercise:

1. Present a realistic scenario (e.g., “An engineer’s credentials were compromised, and the attacker accessed the production database for 3 hours before detection”)
2. Walk through the response plan step by step
3. Identify gaps and areas for improvement
4. Document the exercise: date, participants, scenario, findings, action items

6.6 Business Continuity and Disaster Recovery

Required if you include the Availability criteria, but good practice regardless:

• Recovery Point Objective (RPO) – Maximum acceptable data loss (e.g., 1 hour means backups every hour)
• Recovery Time Objective (RTO) – Maximum acceptable downtime (e.g., 4 hours)
• Backup strategy – Automated, encrypted backups with off-site/cross-region storage
• Restoration testing – Test backup restoration at least quarterly and document results
• Multi-AZ or multi-region architecture – Document your high availability design

DR test documentation template:

DR Test Record
==============
Date:           2025-04-15
Participants:   [Names]
Scenario:       Complete RDS restoration from automated snapshot
Target RPO:     1 hour
Target RTO:     4 hours
Actual RPO:     45 minutes (snapshot was 45 min old)
Actual RTO:     2 hours 15 minutes
Result:         PASS
Issues Found:   DNS TTL was 3600s, slowing failover. Reduced to 300s.
Action Items:   Update runbook with DNS TTL pre-staging step.
Next Test:      2025-07-15

6.7 Change Management

Most engineering teams already follow change management practices but lack the documentation auditors need.

What you likely already do:

• Code review via pull requests
• CI/CD pipeline with automated testing
• Version control for all code and infrastructure

What you might need to add:

• Branch protection rules requiring approving reviews (if not already enforced)
• Emergency change procedure – When you need to hotfix production outside normal process, define how: who can authorize it, what must be documented retroactively, and how it is reviewed post-deployment
• Change log – If your deployment tool does not maintain one automatically, aggregate it from git history and deployment records

6.8 Endpoint Security

Employee devices are in scope. Auditors will verify that laptops and workstations are secured.

Minimum controls:

• Full-disk encryption enabled and enforced (FileVault for macOS, BitLocker for Windows)
• MDM deployed to all company devices (Kandji, Jamf, Fleet, Mosyle, Intune)
• Screen lock after inactivity (5-15 minutes)
• Automatic OS and application updates enabled
• Antivirus/EDR deployed (some auditors accept macOS built-in protections – XProtect, Gatekeeper, MRT – but others require a dedicated endpoint security agent; confirm with your auditor before relying on built-in tools alone; Windows requires a dedicated solution)
• Ability to remote wipe lost/stolen devices

MDM as evidence source: Your MDM dashboard becomes a primary evidence source for endpoint controls. Compliance platforms integrate with MDMs to pull device posture data automatically.

7. Compliance Automation Tooling

7.1 Why Automation Matters for Startups

Manual SOC 2 compliance requires someone to periodically screenshot configurations, chase employees for policy acknowledgments, track training completion in spreadsheets, and compile evidence binders for auditors. This is error-prone and drains engineering time.

Compliance automation platforms connect to your existing tools (cloud provider, IdP, version control, HR system, MDM) and continuously:

• Collect evidence from integrated systems
• Monitor control health and alert on failures
• Track policy acknowledgments and training completion
• Map controls to framework criteria
• Generate audit-ready evidence packages

The cost ($10K-30K/year) typically pays for itself by reducing internal hours and accelerating the audit timeline.

7.2 Platform Comparison

Platform	Starting Price	Strengths	Considerations
Vanta	~$10,000/year	Largest integration library, strong automation, guided onboarding	Can be prescriptive in control requirements
Drata	~$12,000/year	Clean UI, strong monitoring dashboards, custom control support	Newer platform, smaller auditor network
Secureframe	~$10,000/year	Good policy templates, trust center included, fast onboarding	Fewer integrations than Vanta
Thoropass (formerly Laika)	~$15,000/year	Combines platform with auditor services	Higher price point, bundled approach
Sprinto	~$8,000/year	Lower price point, good for smaller startups	Less mature automation for complex environments
Tugboat Logic (acquired by OneTrust)	Varies	Part of larger GRC platform	May be overly complex for early-stage startups

Prices are approximate and vary based on company size, scope, and contract terms. Most platforms offer startup discounts.

7.3 Evaluating Compliance Platforms

Key questions when selecting a platform:

Integrations:

• Does it connect to your cloud provider(s), IdP, version control, HR system, MDM, and ticketing system?
• Does it support your specific tools (e.g., Google Workspace vs. Okta, GitHub vs. GitLab)?
• Are integrations read-only, or do they require write access?

Audit support:

• Does the platform have a network of auditors familiar with the platform’s evidence format?
• Does the auditor portal streamline evidence sharing (versus manual export)?
• Can you use your own auditor, or are you locked into the platform’s partners?

Framework coverage:

• Can the platform support additional frameworks later (ISO 27001, HIPAA, SOX)?
• Does it handle cross-mapping between frameworks to reduce duplicate effort?

Operational fit:

• Does it require a dedicated compliance person to manage, or can it be run by an engineer part-time?
• How much manual work remains after integration setup?
• Does it provide policy templates and readiness assessments?

7.4 DIY vs. Platform Approach

Approach	Pros	Cons
Compliance platform	Faster time to audit, less manual work, continuous monitoring, auditor familiarity	Annual cost, some vendor lock-in, may be prescriptive
DIY (spreadsheets + scripts)	No platform cost, full control over process	Significant manual effort (400+ hours), error-prone, difficult to maintain, auditors may push back on evidence format

Recommendation: Use a compliance platform unless your budget absolutely does not allow it. The time savings alone justify the cost for a team of 5 or more. If you must go DIY, use a spreadsheet-based control matrix, scheduled scripts for evidence collection, and a shared drive with strict access controls for evidence storage.

8. Navigating the Audit

8.1 Selecting an Auditor

SOC 2 audits must be performed by a licensed CPA firm. Key selection criteria:

• Experience with startups and SaaS – A firm that primarily audits large enterprises may not understand your environment and may impose unnecessarily rigid expectations.
• Familiarity with your compliance platform – If you use Vanta or Drata, select a firm that has audited other companies on the same platform. This dramatically reduces friction.
• Responsiveness – The audit will involve back-and-forth on evidence. A firm that takes two weeks to respond to questions will extend your timeline significantly.
• Clear pricing – Get a fixed-fee quote that covers the full engagement, including a defined number of revision cycles for the system description and report.
• Bridge letter capability – Between audits, customers may request a bridge letter confirming that no material changes have occurred. Ensure your auditor offers this.

Firms commonly used by startups:

Prescient Assurance, Johanson Group, A-LIGN, Schellman, Coalfire, Sensiba (formerly Sensiba San Filippo), and Barr Advisory are firms frequently mentioned in startup compliance discussions. Get quotes from 2-3 firms and ask for references from companies similar to yours in size and stack.

8.2 Readiness Assessment

Before the formal audit, conduct a readiness assessment (either internally or with a consultant):

1. Map controls to criteria – Verify that every applicable TSC point-of-focus has at least one control addressing it
2. Collect a sample of evidence – For each control, gather evidence as if the audit were happening today
3. Identify gaps – Where evidence is missing, a control is not implemented, or a policy does not match practice
4. Remediate – Fix gaps before the observation period starts (for Type II) or before the audit date (for Type I)
5. Validate – Re-check that remediated controls are operating correctly

Most compliance platforms include a readiness assessment feature that automates steps 1-3.

8.3 The Audit Process

Type II audit flow:

1. Planning – Auditor reviews system description, control matrix, and scope. Agrees on testing procedures.
2. Walkthrough – Auditor conducts interviews with control owners to understand how controls operate in practice.
3. Evidence request – Auditor provides a request list (often called a PBC – Prepared By Client list). Typically 50-150 line items.
4. Testing – Auditor samples evidence to verify controls operated during the observation period. For a 6-month period, they may sample 5-25 items per control.
5. Exception identification – If a control did not operate as described, the auditor notes an exception.
6. Management response – You provide context or corrective actions for any exceptions.
7. Draft report – Auditor issues a draft for your review. Check the system description for accuracy.
8. Final report – After your review and any corrections, the final SOC 2 report is issued.

8.4 Handling Exceptions and Findings

Exceptions are not failures. An exception means a control did not operate as designed for one or more sampled items. The auditor will assess whether exceptions are:

• Isolated – A single instance where the control was not followed (e.g., one PR merged without review during an emergency)
• Systemic – A pattern indicating the control is not operating effectively

How to handle exceptions:

1. Do not hide them. Auditors find them. Attempting to conceal exceptions damages trust and can result in a qualified opinion.
2. Provide context. Explain why the exception occurred (e.g., emergency production fix at 2 AM).
3. Show corrective action. Document what you did to prevent recurrence (e.g., updated emergency change procedure, added retrospective review requirement).
4. Demonstrate compensating controls. If the primary control failed, what other controls mitigated the risk?

A clean report (no exceptions) is ideal but not required. Most startup SOC 2 reports have 1-3 exceptions. Customers understand this. What matters is that exceptions are isolated, explained, and addressed.

8.5 After the Report

• Distribute the report under NDA to customers and prospects who request it. SOC 2 reports contain sensitive details about your controls and should not be posted publicly.
• Set up a trust center where customers can request and access the report. Compliance platforms (Vanta Trust Center, Drata Trust Center, SafeBase) offer this as a feature.
• Plan the next audit cycle. Type II reports have a defined observation period. Plan so that your next observation period starts when the current one ends, avoiding coverage gaps.
• Maintain controls continuously. The worst outcome is passing the audit and then letting controls decay. Continuous compliance (via platform monitoring) is far easier than annual scrambles.

9. Common Startup Mistakes

Mistake	Consequence	Prevention
Writing aspirational policies	Auditor finds policies do not match practice	Write policies that describe what you actually do today
Scoping too broadly	Increased cost, more controls, longer audit	Define tight boundaries around the production system
Starting the observation period before controls are ready	Exceptions during early months sink the Type II	Complete readiness assessment first, then start the clock
Treating SOC 2 as a one-time project	Controls decay, next audit reveals regression	Assign a compliance owner, use continuous monitoring
Ignoring vendor management	CC9 findings for undocumented vendor relationships	Build vendor inventory early, request SOC 2 reports from critical vendors
No offboarding evidence	CC6 finding for access not revoked promptly	Add access revocation screenshots to every offboarding ticket
Relying on a single person	Compliance program stalls when that person leaves	Document processes, use platforms that persist institutional knowledge
Delaying the penetration test	Pentest report not ready during observation period	Schedule the pentest at least 2 months before the audit window closes
Not communicating with the auditor early	Surprises during the audit	Have a kickoff call, agree on scope and expectations before the observation period
Over-engineering controls	Unnecessary complexity, harder to maintain and evidence	Implement the simplest control that satisfies the criteria

10. SOC 2 Readiness Checklist

Governance and Policy

• Information security policy approved and communicated
• All required policies written, approved, and versioned (see Section 4.2)
• Code of conduct signed by all employees
• Organizational chart with security responsibilities documented
• Security awareness training completed by all employees (with records)
• Background checks completed for all employees
• Board or management security review documented (meeting minutes)

Access Control

• Centralized IdP (SSO) deployed for all systems
• MFA enforced for all accounts (no exceptions)
• Least privilege access implemented (RBAC documented)
• Onboarding procedure documented with access provisioning steps
• Offboarding procedure documented with access revocation steps and evidence capture
• Quarterly access reviews scheduled and first review completed
• Root/admin accounts secured with hardware MFA and restricted to break-glass

Technical Controls

• Encryption at rest enabled for all data stores
• TLS 1.2+ enforced for all data in transit
• CloudTrail (or equivalent) enabled in all regions
• Centralized logging with 1-year retention
• Monitoring and alerting configured for security events
• Vulnerability scanning automated in CI/CD
• Annual penetration test scheduled or completed
• Backup and restoration tested and documented

Change Management

• Branch protection rules enforced (required reviews, status checks)
• CI/CD pipeline with automated testing before deployment
• Infrastructure managed via IaC with version control
• Emergency change procedure documented
• Deployment logs retained

Risk and Vendor Management

• Risk register created with likelihood, impact, and mitigating controls
• Annual risk assessment documented
• Vendor inventory created with data access and risk levels
• SOC 2 reports collected from critical vendors
• Cyber liability insurance obtained

Incident Response

• Incident response plan written and approved
• Incident severity classification defined
• Communication and escalation procedures documented
• Tabletop exercise conducted (with documented results)
• Post-incident review template created

Business Continuity (if Availability criteria included)

• RPO and RTO defined for critical systems
• Backup strategy documented and automated
• DR test conducted and documented
• High availability architecture documented

Endpoint Security

• MDM deployed to all company devices
• Full-disk encryption enforced
• Screen lock timeout configured
• Automatic updates enabled
• Remote wipe capability confirmed

Audit Preparation

• System description written
• Trust Service Criteria selected
• Auditor selected and engaged
• Compliance platform integrated (if using one)
• Control matrix mapped to TSC criteria
• Evidence collected for all controls (sample review)
• Readiness assessment completed and gaps remediated

11. Timeline and Roadmap

Months 1-2: Foundation

Week	Activities
1-2	Select Trust Service Criteria. Choose compliance platform. Begin platform onboarding and integrations.
3-4	Write core policies (information security, access control, change management, incident response). Deploy MDM. Enforce MFA and SSO.
5-6	Build risk register. Create vendor inventory. Deploy security awareness training.
7-8	Complete readiness assessment. Identify and prioritize gaps. Begin remediation.

Months 3-4: Remediation and Hardening

Week	Activities
9-10	Close critical gaps (access reviews, offboarding evidence, logging retention). Enforce branch protection rules.
11-12	Schedule penetration test. Conduct first quarterly access review. Test backup restoration.
13-14	Conduct tabletop exercise for incident response plan. Complete all policy reviews and approvals.
15-16	Engage auditor. Agree on scope, observation period, and timeline. Conduct kickoff call.

Months 5-10: Observation Period (Type II)

Activity	Cadence
Continuous evidence collection via platform	Ongoing
Monitor control health dashboard	Weekly
Address platform alerts for control failures	As they occur
Quarterly access reviews	Q1, Q2 of observation
Receive penetration test report	During observation period
Mid-period check-in with auditor	Month 7 or 8

Months 11-12: Audit and Report

Week	Activities
1-2	Auditor issues PBC (evidence request list). Provide evidence via platform or shared repository.
3-4	Auditor conducts walkthroughs and interviews. Respond to follow-up questions.
5-6	Receive draft report. Review system description and any noted exceptions. Provide management responses.
7-8	Final report issued. Set up trust center. Begin sharing with customers. Plan next audit cycle.

This timeline assumes a 6-month Type II observation period. A Type I (no observation period) can be completed in months 3-4, with the audit in months 5-6.

12. References and Resources

Standards and Frameworks

• AICPA Trust Service Criteria (2017) – The authoritative source for SOC 2 criteria
• AICPA SOC 2 Reporting Guide – Official guidance on SOC reporting
• COSO Internal Control Framework – The foundation underlying SOC 2’s Common Criteria
• NIST Cybersecurity Framework – Complementary framework with significant SOC 2 overlap

Tools Referenced

• Vanta – Compliance automation platform
• Drata – Compliance automation platform
• Secureframe – Compliance automation platform
• Sprinto – Compliance automation platform
• Thoropass – Compliance automation and audit platform
• KnowBe4 – Security awareness training
• Curricula – Security awareness training
• Kandji – Apple MDM
• Jamf – Apple MDM
• Fleet – Open-source cross-platform MDM
• Prowler – AWS/Azure/GCP security assessment tool
• ScoutSuite – Multi-cloud security auditing tool

Further Reading

• SOC 2 Academy (Secureframe) – Free educational resources on SOC 2 compliance
• AICPA SOC for Service Organizations – Official AICPA guidance
• CIS Controls – Practical security controls that map well to SOC 2 requirements