SOC 2 Compliance for Indian SaaS Companies: A Practical Guide

A US buyer sends your Bengaluru startup a 200-line security questionnaire on a Friday. Somewhere around row 40 there is a single cell that reads: Do you hold a current SOC 2 Type 2 report? Yes or No. Your sales lead pings you. You do not have one. The deal, worth maybe 40 lakh a year, quietly moves to the vendor who does.

That is what SOC 2 actually is for an Indian SaaS company. Not a compliance ideal. A gate on the pipeline. And the thing nobody tells founders is that the report itself is the easy part. The hard part is that a Type 2 report is an observation of how you behaved over a window of time you cannot go back and re-run. If your controls were sloppy in April, no amount of effort in September fixes April. You are always auditing your past.

SOC 2 stands for System and Organisation Controls 2. It is an attestation report produced under the AICPA (American Institute of Certified Public Accountants) framework, specifically the SSAE 18 attestation standard and the AT-C 205 examination sections. A licensed CPA firm examines your controls against the Trust Services Criteria and issues an opinion. That is the key word. Opinion, not certificate.

This trips up almost every Indian founder I have sat across from. There is no SOC 2 certificate you frame on a wall like an ISO 27001 certificate. There is a report, typically 40 to 90 pages, and the value lives in the auditor's opinion paragraph and the detailed table of controls tested. A buyer's security team reads that table. They are not impressed that you passed. They read which exceptions the auditor noted.

SOC 2 is also not a legal requirement anywhere in India. No RBI circular, no SEBI CSCRF mandate, no DPDP Act rule tells you to get one. It is a commercial requirement. Your customers, mostly North American and increasingly European, impose it through procurement. That distinction matters because it changes who you are optimising for. You are not satisfying a regulator. You are satisfying a buyer's third-party risk team, and they are far pickier than most regulators.

Practically, if your customers are Indian banks or government, ISO 27001 and CERT-In empanelled audits carry more weight. If your customers are US SaaS platforms, fintechs, or anyone selling into the US, SOC 2 is the currency. Many Indian companies end up needing both. The good news is that ISO 27001 and SOC 2 share roughly 70 to 80 percent of their control substance, so doing one makes the second dramatically cheaper.

This is the single most misunderstood decision in the whole process, so let me be blunt about it.

A Type 1 report says: as of a single date, say 30 June, your controls were designed appropriately. It is a snapshot. The auditor looks at your policies and configuration on one day and confirms they exist and are suitably designed. You can get a Type 1 in a few weeks.

A Type 2 report says: over a period, typically 3 to 12 months, your controls were not only designed well but operated effectively the entire time. The auditor pulls samples from across the window. They will ask for the access review you did in month two and the incident ticket you closed in month five. They test evidence, not intentions.

Here is the practitioner's honest take. Buyers tolerate a Type 1 as a promissory note. They will accept it once, usually with a written commitment that a Type 2 follows within a year. They do not accept a Type 1 twice. If your renewal comes around and you are still on Type 1, the risk team flags you. So do not think of Type 1 as a cheaper alternative. Think of it as the down payment on a Type 2 you have already committed to.

My standard advice to Indian SaaS founders: if a deal is stuck this quarter, get a Type 1 to unblock it, but start the clock on a Type 2 the same week. Choose a 3-month observation window for your first Type 2 to prove the model, then move to a rolling 12-month window for annual reports thereafter.

SOC 2 is built on five Trust Services Criteria, abbreviated TSC. You do not have to include all five. You scope in the ones your buyers care about. Choosing more than you need is a common and expensive mistake.

The Security criterion, also called the Common Criteria or CC series, is non-negotiable. It maps to nine control families, CC1 through CC9, covering everything from the control environment and governance through logical access, system operations, change management and risk mitigation. The other four are optional bolt-ons.

The trap: an over-eager consultant convinces a 15-person startup to scope in all five criteria to look impressive. Now the auditor is testing your privacy notices and processing integrity controls that no buyer ever asked about, your fieldwork doubles, and your report is full of exceptions in areas that were never material to your business. Scope Security plus Availability plus Confidentiality for most B2B SaaS. Add Privacy only when you directly control end-user consumer data. Add Processing Integrity only if you move money or compute regulated financial outputs.

Let me walk you through what really happens, because the vendor sales decks make it sound like a two-week affair. It is not.

Months zero to one is scoping and gap assessment. You pick your criteria, define your system boundary (which products, which infrastructure, which teams), and a readiness assessor maps your current state against the TSC. This is where you discover you have no formal access review, your onboarding checklist lives in one person's head, and your production database has been accessible from three engineers' laptops over the public internet. This list of findings is your remediation backlog.

Months one to three is remediation. You write the policies you never had, turn on the logging you always meant to, enforce multi-factor authentication everywhere, close the direct production access, and stand up a ticketing discipline so change management leaves an evidence trail. Crucially, you start behaving like a company that has controls, because the observation window is about to open and everything you do inside it becomes evidence.

Months three to nine is the observation window itself for a Type 2. The clock is running. Every quarterly access review, every vulnerability scan, every incident, every offboarding must generate a dated artefact. This is the phase Indian teams underestimate. It is not about heroics at the end. It is about boring consistency, month after month, that you can prove.

The final month is fieldwork. The CPA firm requests samples. They will say: give me the JIRA ticket and approval for this deploy on 14 August, show me the offboarding record for the employee who left in July, produce the board minutes where security was discussed in Q2. If the artefact exists and is dated correctly, you pass that test. If it does not, the auditor writes an exception, and exceptions are what your future buyers read.

An auditor asks a founder to show the quarterly user access review for the March quarter. The founder confidently shares a spreadsheet. The auditor asks one question: when was this file created? The metadata says two days ago. The review was supposed to happen in March. That single answer converts a passing control into an exception noted for operating effectiveness. The lesson every Indian SaaS team learns the hard way: an artefact created after the fact is not evidence, it is a liability. Do the work on time, or do not claim the control.

Vendors are cagey about pricing, so here is a realistic range for an Indian SaaS company in 2026. Costs split into three buckets: the readiness and remediation work, the compliance automation platform, and the CPA audit fee itself. Note that the audit opinion must come from a US-licensed CPA firm, which is a fixed cost you cannot localise away.

For a lean B2B SaaS scoping Security plus Availability plus Confidentiality, budget somewhere between 12 and 25 lakh for your first full Type 2 cycle including tooling, then 8 to 18 lakh annually thereafter. The automation platform is optional in theory. In practice, collecting a year of evidence by hand across cloud accounts, HR systems and code repositories is so painful that almost everyone buys one. The platform does not make you compliant. It makes proving compliance survivable.

Everything above applies globally. These next points are the ones that bite Indian teams specifically, and no California-authored guide will warn you.

If you want to compress the timeline without faking evidence, this is the practical order of operations. Work top to bottom. Each item is something an auditor will actually test.

Come back to that Friday questionnaire. The reason the deal moved was not that you were insecure. It may well be that you were more secure than the vendor who won. The difference was that they could prove it over a period, on demand, with dated evidence, and you could not. SOC 2 is not a security upgrade. It is the discipline of making your security legible to a stranger's risk team. Build that discipline into how you operate, and the report writes itself.

At CyberSigma we run these engagements hands-on as senior CERT-In empanelled auditors and PCI QSAs, mapping your existing Indian audit and ISO evidence into a SOC 2 scope so you are not paying twice for the same controls. If you want a straight readiness assessment before you commit to a window, that is a conversation worth having early rather than during fieldwork.