Skip to content

InfoSec 5 min read

SOC 2 Type II for Indian SaaS: what the auditor actually samples

Type I asks whether the control exists. Type II asks whether it worked every time, for months — and that is a different kind of company.

CA Praveen·Chartered Accountant·

Most Indian SaaS companies meet SOC 2 the way they meet a funding round: late, urgently, and with someone's weekend. The framework does not require that. It requires that the things you already claim to do actually happened, and that you can prove it without reconstructing anything.

The distinction that decides your timeline

A Type I report is a photograph: controls are suitably designed as at a date. A Type II report is a film: controls operated effectively over a period, typically three to twelve months. Your enterprise customer's procurement team wants the film.

This matters for planning, because the observation window cannot be created retrospectively. If you want a Type II report in March, the period has to start months earlier and the evidence has to accumulate as you go. The single most common reason an Indian SaaS company misses a deal deadline is starting the clock too late.

What gets sampled, in practice

Auditors do not read your policy PDF with much interest. They pull samples and test them:

  • Access provisioning and revocation. Pick ten joiners and ten leavers. Was access granted on approval, and removed on the last working day? Offboarding is where most first-time audits fail — a departed contractor with live production access is a finding every time.
  • Change management. Pick thirty deployments. Was there a reviewed pull request, an approval by someone other than the author, and a rollback path?
  • Access reviews. Quarterly, evidenced, with someone's name against the decision — not a screenshot of a user list.
  • Backups and restoration. Not that backups ran. That a restore was tested, and the test was documented.
  • Vendor management and incident response. Including at least one incident walked end to end, even a minor one.

Where the audit discipline comes from

This is the part we find Indian SaaS teams underestimate: SOC 2 is an attestation engagement, governed by audit standards. The evidence standard is the same one that governs a statutory audit — completeness, accuracy, a population you can defend, and sampling that is not simply the ten easiest cases.

A firm that runs statutory audits tests controls the same way an information-security auditor does. That is why we run the two disciplines off one bench rather than treating compliance as a separate industry.

Start with the population

Before any gap assessment, answer one question: can you produce, today, a complete and accurate list of your employees, contractors, production systems, third-party processors and deployments for the last quarter? If that list takes a week to assemble, fix that first. Everything in SOC 2 is downstream of knowing what you have.

One further decision saves real money: settle early which Trust Services Criteria you are reporting on. Security is mandatory; availability, confidentiality, processing integrity and privacy are choices. Customers rarely demand all five, and each one you add expands the evidence you must produce across the entire observation window. Scope it to what your contracts actually require, and revisit it only when a contract changes.

Written for general guidance as at 11 Sep 2026. Tax and regulatory positions change, and the right answer depends on facts we have not seen. Please do not act on this note alone — put your situation to us first.