SOC 2 for SaaS Companies: Full Implementation Guide

What SOC 2 Means for a SaaS Company

SOC 2 (System and Organization Controls 2) is the dominant security compliance framework for B2B SaaS companies. Enterprise customers — particularly in financial services, healthcare, and government — require SOC 2 Type II reports before signing contracts. Many $100K+ deals require SOC 2 evidence in the security questionnaire stage. The question for SaaS founders is not whether to get SOC 2, but when and how.

SOC 2 is an attestation, not a certification. An independent CPA firm audits your controls and issues a report attesting that your controls were suitably designed (Type I) or suitably designed and operating effectively over a period (Type II). Type II is what enterprise customers want — it proves that controls were actually operating, not just documented.

For a typical SaaS company, the relevant Trust Service Criteria are: Security (the Security criterion CC1–CC9 is mandatory for all SOC 2 reports), Availability (A1 — if you have uptime SLAs), and Confidentiality (C1 — if you process confidential customer data, which most SaaS companies do). Processing Integrity and Privacy are optional and less commonly included in the first SOC 2 report.

Defining Your SOC 2 Scope

The SOC 2 scope defines which systems, services, and processes are covered by the report. A well-defined scope covers the systems that process customer data without being unnecessarily broad. Typical SaaS scope: production application (web servers, APIs, databases), production infrastructure (AWS/GCP account, Kubernetes cluster), identity management (Okta, Azure AD), source code management (GitHub organization), and CI/CD pipeline.

Typically excluded from scope: development and staging environments (unless they process production customer data), developer laptops (covered separately by endpoint policy), internal tools (Slack, Notion, email) unless they store customer data directly, and marketing systems (CMS, email marketing platform). Document your scope boundary in a System Description document — this is the first document an auditor reads.

For Indian companies targeting US enterprise customers: your scope includes your production AWS/GCP region regardless of whether it is in India or the US. Your data residency choices affect compliance with Indian DPDP Act requirements, not SOC 2 scope. SOC 2 auditors look at logical access and security controls, not geographic location of servers.

Control Selection for SaaS

The AICPA's TSC defines ~60 point-of-focus items across CC1–CC9, A1, C1, PI1, and P1–P8. Not all of them require separate controls — many are satisfied by the same underlying mechanism. For a SaaS company with under 100 employees, a practical control set covers 40–50 controls across six categories: access management (CC6), change management (CC8), monitoring and incident response (CC7), risk management (CC3, CC4), availability (A1), and confidentiality (C1).

The five highest-ROI controls for a SaaS company: (1) MFA for all production systems — covers CC6.1, CC6.2, and satisfies the most common audit finding. (2) Encryption at rest and in transit — covers CC6.1, C1.1, and is often already in place via AWS defaults. (3) Centralized logging with 12+ months retention — covers CC7.2 and CC7.3 with minimal tooling. (4) Change management via PR approvals — covers CC8.1 and is essentially free with GitHub branch protection. (5) Vendor/subservice management — covers CC9.2 and is satisfied by maintaining a vendor register with SOC 2 reports collected annually.

Implementation Timeline

Month 1 (Scoping and Gap Assessment): Define scope, conduct a gap assessment against your target control set, identify the top 10 gaps, assign owners, create a remediation Jira project. Month 2–3 (Remediation): Fix the critical gaps — enable MFA everywhere, set up centralized logging, implement branch protection, configure AWS Security Hub. Month 4 (Documentation): Write the 15–20 required policy documents (Information Security Policy, Access Control Policy, Incident Response Policy, Change Management Policy, etc.).

Month 5 (Observation Period Begins): Start the observation period with all controls operating. Some auditors will allow a 3-month observation period for Type II; most require 6–12 months. During the observation period, collect evidence monthly: export audit logs, document access reviews, log incidents, document change approvals. Month 6–10 (Observation Period): Continue operating controls and collecting evidence. Address any control gaps identified during monitoring.

Month 11–12 (Audit Preparation): Compile evidence package, conduct internal readiness review, select auditor, schedule fieldwork. Month 13 (Fieldwork): Auditors conduct walkthroughs and test controls against your evidence. Month 14–15 (Report Issuance): Auditors draft the report, you review and respond to any exceptions, the final SOC 2 Type II report is issued. Customer-facing: publish a summary or share the full report via NDA.

Evidence Collection Strategy

Evidence collection is the most time-consuming part of SOC 2. For each control, you need evidence that it was operating throughout the audit period — not just a screenshot of the configuration taken during the audit. There are three evidence strategies: (1) Manual screenshots: collected monthly by a designated team member. Time-intensive and error-prone. (2) Automated exports: scheduled API calls that pull data (audit logs, scan results, access reviews) and store them in a compliance platform. (3) Continuous monitoring: tools like AWS Security Hub, Snyk, and Datadog provide real-time evidence of controls operating.

For a SaaS company, the recommended approach is a hybrid: automate what can be automated (AWS Config rules, Snyk reports, Datadog SLO reports), use a compliance platform (AuditPath, Vanta, Drata) to aggregate automated evidence, and reserve manual screenshots for the handful of controls that require human attestation (quarterly access reviews, annual security training completion). This hybrid approach can reduce audit preparation from 200+ hours to under 50 hours.

Vendor and Subservice Management

CC9.2 requires monitoring of vendor risks. For SOC 2, you need a vendor register listing all third-party services that process customer data or provide services within your SOC 2 boundary. For each vendor, collect: their SOC 2 Type II report (or equivalent), their data processing agreement (DPA), their breach notification terms, and a summary of their security practices.

Key subservice organizations for most SaaS companies: AWS/GCP/Azure (compute and storage), GitHub (source code), Okta (identity), Stripe or Razorpay (payments), Twilio/SendGrid (communications), Datadog (monitoring). For each, download their SOC 2 report annually and check for new exceptions or qualified opinions. Include a section in your own SOC 2 report that acknowledges these subservice organizations and states that your report relies on them for complementary user entity controls (CUECs).

For Indian companies, include Indian-specific vendors (Razorpay, AWS Mumbai region, MSG91) in the vendor register. DPDP Act requirements for data processor agreements overlap with SOC 2 vendor management requirements — the DPA that satisfies DPDP Act also satisfies SOC 2 CC9.2 in most cases.

Audit Preparation and Auditor Selection

Select a SOC 2 auditor (a licensed CPA firm) 3–6 months before your desired report date. For Indian SaaS companies targeting US enterprise customers: use a US-licensed CPA firm, not an Indian CA firm. US CPA firms issue SOC 2 reports under SSAE 18, which is the standard US enterprise procurement teams expect. Firms with SaaS-focused SOC 2 practices include Prescient Assurance, BARR Advisory, A-LIGN, and Sensiba. Fees typically range from $15,000–$40,000 for a first-time SaaS audit.

Before fieldwork begins, conduct a readiness assessment (internal or with a consultant). Walk through each control in your framework, test your evidence collection, and identify any operating gaps. Fix them before the auditor sees them — a gap found in a readiness review costs you a day to fix; a gap found by the auditor becomes an exception in the report that enterprise customers will scrutinize.

Common SaaS SOC 2 Gaps

The most common audit findings for SaaS companies, in order: (1) Former employees with access — de-provisioning not completed within 24 hours. Fix: automate with Okta Lifecycle Management. (2) No MFA on production systems — engineers using username/password only for AWS console or GitHub. Fix: enforce MFA everywhere, no exceptions. (3) No formal access review — access is provisioned but never reviewed for appropriateness. Fix: quarterly group membership exports reviewed and approved by managers.

(4) No vulnerability management SLA — Snyk or Dependabot running but no documented policy for how fast to fix. Fix: document SLAs and show compliance history. (5) CI/CD bypasses — developers can deploy directly to production without PR approval, usually for hotfix scenarios. Fix: document and restrict the break-glass procedure. (6) Vendor register incomplete — major subservice organizations missing DPAs or SOC 2 reports. Fix: assign ownership of vendor register maintenance to a specific team member with a quarterly review calendar.