SOC 2 compliance:
requirements, reports and what India needs to know.
What the Trust Services Criteria ask for, how Type 1 and Type 2 differ, who is allowed to issue the report, how long it really takes, and what an Indian SaaS company selling to US buyers should check before signing an engagement letter.
Last updated Published by TryTrustableNot legal advice
What is SOC 2 compliance?
SOC 2 compliance means holding a current SOC 2 report: an independent CPA firm's opinion, under AICPA attestation standards, on whether a service organisation's controls meet the Trust Services Criteria for the categories it chose. It is an attestation, not a certificate. Nobody is certified SOC 2; you receive a report, and buyers read it.
SOC 2 is one of the AICPA's System and Organization Controls services, examinations that CPAs perform on a service organisation's controls. The auditor's opinion covers three things: whether the description of your system is fairly presented against the AICPA's SOC 2 description criteria, whether your controls are suitably designed to meet the criteria, and, for a Type 2, whether they operated effectively over the period.
The report is restricted-use. It goes to customers and prospects under NDA, not onto your website. The shorter, general-use version is a SOC 3. The practical output of a SOC 2 programme is therefore a document your sales team can send, and a set of controls that keep running so that next year's report says the same thing.
What are the SOC 2 requirements?
The SOC 2 requirements are the AICPA Trust Services Criteria. Security, the common criteria CC1 to CC9, is in every SOC 2 report. Availability, Processing Integrity, Confidentiality and Privacy are optional categories you add when your commitments to customers make them relevant. You design the controls; the criteria say what they must achieve.
The criteria are the AICPA's 2017 Trust Services Criteria, with revised points of focus (2022). They are outcome-based: CC6.1 says logical access must be restricted, not which identity provider to use. Points of focus describe what a control usually addresses and are not individually required.
| Series | What it covers | Examples an auditor tests |
|---|---|---|
| CC1 Control environment | Integrity and ethics, board oversight, structure, competence, accountability | Code of conduct acknowledgements, org chart, background checks |
| CC2 Communication and information | Quality information, internal and external communication | Security policies published to staff, customer-facing commitments |
| CC3 Risk assessment | Objectives, risk identification, fraud risk, change-driven risk | Dated risk assessment with owners |
| CC4 Monitoring activities | Ongoing and separate evaluations; deficiencies communicated | Vulnerability scanning, internal reviews, tracked remediation |
| CC5 Control activities | Selecting and deploying controls and the policies behind them | Policy set with owners and review dates |
| CC6 Logical and physical access | Access provisioning, removal, review, authentication, encryption, malware | Joiner and leaver tickets, quarterly access reviews, MFA configuration |
| CC7 System operations | Detecting and monitoring events, incident response and recovery | Alerting, incident tickets, post-incident reviews |
| CC8 Change management | Authorising, testing and approving changes | Merged pull requests with review and passing checks |
| CC9 Risk mitigation | Business disruption and vendor risk | Vendor reviews, insurance, continuity plans |
CC1 to CC5 restate the 17 principles of the COSO 2013 internal control framework; CC6 to CC9 are specific to systems. There are 33 common criteria in all.
The four optional categories each add their own criteria on top of the common ones:
- Availability (A1). Capacity, backup, recovery and its testing. Add it when you commit to uptime in contracts
- Processing Integrity (PI1). Processing is complete, valid, accurate and timely. Relevant to payments, payroll and data pipelines customers rely on for their own reporting
- Confidentiality (C1). Identifying and protecting confidential information, and disposing of it. Common for B2B SaaS holding customer business data
- Privacy (P1 to P8). Notice, choice and consent, collection, use and retention, access, disclosure, quality, monitoring. Chosen least often, because it tests commitments about personal data that many teams have not written down
Most first reports cover Security alone, or Security with Availability and Confidentiality. Adding a category later is normal. Adding one you cannot evidence produces exceptions in a document buyers read.
What is the difference between SOC 2 Type 1 and Type 2?
A SOC 2 Type 1 report gives an opinion on whether controls were suitably designed as of a single date. A Type 2 report adds whether they operated effectively throughout a period, typically three to twelve months, with the auditor sampling evidence across it. Enterprise buyers generally ask for Type 2; Type 1 is usually a first step.
The period of a Type 2 is the question buyers care about. The AICPA sets no fixed minimum, and a first report often covers three months to get a document into sales hands, with later reports moving to a rolling twelve-month period. The full comparison, including when a Type 1 is worth doing at all, is on SOC 2 Type 1 vs Type 2.
Who can issue a SOC 2 report for an Indian company?
Only a licensed CPA firm can issue a SOC 2 report, because it is an examination under AICPA attestation standards. Indian companies usually engage a US-licensed CPA firm, often one with an affiliate or delivery team in India. Whoever does the fieldwork, check which licensed firm signs the opinion, and verify its licence and peer review.
The phrase to check is who signs. A SOC 2 opinion is issued by a CPA firm licensed by a US state board of accountancy and performing the work under AICPA standards. Several large and mid-sized firms serve Indian clients through teams or affiliates in India; that is an ordinary arrangement as long as the licensed firm issues the report and takes responsibility for it.
The AICPA has said it will act against members who issue SOC reports without performing the work to professional standards, without enrolment in peer review, or without a licence, and refers unlicensed firms to state boards. Three checks before you sign:
- Licence. Look the signing firm up on CPAverify, the licensing database run for state boards
- Peer review. Ask for the firm's most recent AICPA peer review report and its rating
- Report type. Confirm the deliverable is a SOC 2 examination report. An ISAE 3000 or ISAE 3402 assurance report from another practitioner can cover similar ground, but a US buyer who asked for SOC 2 usually wants SOC 2 by name
Be wary of offers that bundle software, policies and "the audit" at a fixed price with a guaranteed clean opinion. The auditor must be independent of the controls it tests, and an opinion that cannot be qualified is not an opinion.
Why do Indian SaaS companies need SOC 2 to sell to US buyers?
Indian SaaS companies need SOC 2 to sell to US buyers because US procurement and security teams use the report as their default evidence that a vendor's controls work. Without one, the vendor answers a long questionnaire by hand, the review takes weeks, and some buyers will not proceed. SOC 2 is a commercial requirement, not a legal one.
Three things are specific to an Indian company:
- Scope the right entity. Many Indian SaaS groups sell through a US parent and build in an Indian subsidiary. The report describes a system run by a named entity; decide which one, and make sure the people and infrastructure in the description are the ones that actually operate it
- Subservice organisations. Your cloud provider is a subservice organisation. Most reports carve it out and rely on its own SOC 2, listing the complementary controls you depend on it for
- Indian law still applies. SOC 2 does not satisfy the DPDP Act or CERT-In Directions. The controls overlap; the legal duties, such as breach reporting timelines, do not substitute for each other
If your buyers are in Europe or India rather than the US, they more often ask for ISO 27001. SOC 2 vs ISO 27001 sets out when each one wins a deal.
How long does SOC 2 take?
For a company starting from scratch, a realistic SOC 2 timeline is two to four months of readiness, then either a Type 1 examination or a Type 2 observation window of three to twelve months, then weeks of testing and reporting. A first Type 2 report commonly lands six to twelve months after work begins.
The stages, in order:
| Stage | What happens | Typical length |
|---|---|---|
| Scope | Entity, system, categories, subservice organisations, the auditor chosen | Two to four weeks |
| Readiness | Gap assessment against the criteria; policies written; controls built; evidence collection automated | Two to four months from a standing start |
| Type 1 (optional) | Design tested as of one date | A few weeks of fieldwork |
| Type 2 window | Controls operate; evidence accumulates for the whole period | Three to twelve months |
| Fieldwork and report | Auditor requests populations, samples, tests, drafts; management responds to exceptions | Several weeks after the period ends |
| Continuous | The next period starts the day after the last one ended | Every year |
Lengths are common ranges, not AICPA requirements. A team that already runs the controls can skip most of readiness.
What does SOC 2 evidence look like?
SOC 2 evidence is the record that a control ran: system-generated lists, tickets, logs, configuration exports, sign-offs with dates. For a Type 2 the auditor asks for the full population, such as every change merged in the period, then samples from it and checks each sample. A screenshot taken during audit week proves only that week.
What an auditor typically asks for, and what makes it fail:
| Control | Evidence requested | Common failure |
|---|---|---|
| Change management (CC8.1) | Every merged change in the period; for samples, the review, the approver and the passing checks | A direct push to the main branch with no review |
| Access review (CC6.2, CC6.3) | Quarterly reviews with the reviewer, the date and the actions taken | A review signed off with no removals and three leavers still active |
| Offboarding (CC6.2) | The leaver list from HR; access removal times per system | Access removed days after the last working day |
| Vulnerability management (CC7.1) | Scan results and remediation within your stated SLA | Critical findings open past the policy deadline |
| Incident response (CC7.3–CC7.5) | Incident tickets, post-incident reviews, an annual test | No incidents logged at all, which auditors read as no detection |
| Vendor management (CC9.2) | Vendor list, risk tiering, reviews of critical vendors' SOC reports | A review that never read the vendor report's exceptions |
Criteria references are the common reading; auditors differ, so agree the mapping in advance.
Bridge letters. A SOC 2 Type 2 describes a past period. Between the period's end and the next report, buyers ask for a bridge letter, signed by your management, stating that there have been no material changes to the system or controls. It is not an auditor's opinion, and buyers generally accept one for a limited gap, commonly up to three months.
How SOC 2 runs in the platform
SOC 2 Type I and Type II, including the Privacy category, are on the coverage list. What the platform does against the work above:
- Per entity. The compliance programme enables a framework per legal entity, starts it empty, and computes readiness from control results rather than a field somebody sets
- Change management from CI. The SDK and CI gate run SAST, SCA, IaC, DAST and secret scanning in your own pipeline; the compliance as code guide maps those checks to CC8.1 and CC7.1
- Endpoints. Device posture syncs Intune, Jamf or Google Workspace for encryption, screen lock and OS version per device
- Populations, not screenshots. Results land in the hash-chained evidence ledger, failures included, and a scoped auditor workspace exports one entity and framework
- Policies and buyers. Policies carry versioned attestations; a trust portal with NDA-gated documents and questionnaire answers drafted from live control state covers the sales side
The platform does not issue SOC 2 reports; a licensed CPA firm does. TryTrustable does not hold SOC 2 or ISO 27001 itself yet: both are in progress, as the trust page says.
The things people ask us
What is SOC 2 compliance?
SOC 2 compliance means holding a current SOC 2 report: an independent CPA firm's opinion, under AICPA attestation standards, on whether a service organisation's controls meet the Trust Services Criteria for the categories it chose. It is an attestation, not a certificate. Nobody is certified SOC 2; you receive a report, and buyers read it.
Is SOC 2 mandatory in India?
No. No Indian law requires SOC 2, and neither does US law. It becomes necessary commercially, when a customer's security review or contract asks for a SOC 2 Type 2 report, which is common for Indian SaaS companies selling to US mid-market and enterprise buyers. Indian legal duties, such as the DPDP Act's security safeguards and CERT-In reporting, apply separately.
What is the difference between SOC 2 Type 1 and Type 2?
A SOC 2 Type 1 report gives an opinion on whether controls were suitably designed as of a single date. A Type 2 report adds whether they operated effectively throughout a period, typically three to twelve months, with the auditor sampling evidence across it. Enterprise buyers generally ask for Type 2; Type 1 is usually a first step.
Who can issue a SOC 2 report for an Indian company?
Only a licensed CPA firm can issue a SOC 2 report, because it is an examination under AICPA attestation standards. Indian companies usually engage a US-licensed CPA firm, often one with an affiliate or delivery team in India. Whoever does the fieldwork, check which licensed firm signs the opinion, and verify its licence and peer review.
How long does SOC 2 take?
For a company starting from scratch, a realistic SOC 2 timeline is two to four months of readiness, then either a Type 1 examination or a Type 2 observation window of three to twelve months, then weeks of testing and reporting. A first Type 2 report commonly lands six to twelve months after work begins.
How much does SOC 2 cost?
There is no published price list, and figures quoted online vary widely. The cost is driven by the number of categories in scope, the number of systems, locations and subservice organisations, the length of the observation window, how much evidence is produced automatically, and whether you need readiness help. Ask two or three licensed firms to quote on the same written scope.
What is a SOC 2 bridge letter?
A bridge letter, or gap letter, is a statement from your management, not the auditor, covering the period between the end of your last SOC 2 report and today. It says whether controls have changed materially. Buyers accept one for a few months; it is not an opinion and does not replace the next report.
Does SOC 2 cover privacy law such as the DPDP Act or the GDPR?
Not on its own. The optional Privacy category tests controls against the AICPA's privacy criteria, not against any statute. A SOC 2 with Privacy is useful evidence for a data protection programme, but notice, consent, rights handling and breach reporting under the DPDP Act or the GDPR have to be met as the law states them.
See SOC 2 evidence arrive as controls run.
We enable SOC 2 for one entity, connect a repository and a cloud account, and show which criteria have evidence behind them and which read as not modelled. Thirty minutes.