A founder I spoke with last quarter described what happens when a US SaaS company with an India engineering team meets enterprise procurement for the first time. They had built a strong product, signed a verbal commitment from a regional bank, and entered the procurement phase. Three weeks in, the buyer’s vendor risk team asked the question that derails so many deals at this stage: “Where is your SOC 2 Type 2 report, and how is your India team scoped in?”
The founder had a SOC 2 Type 1, issued by a small CPA firm in Bangalore. The audited entity was their India private limited subsidiary. The contracting entity was their Delaware C-Corp. The bank’s procurement team rejected the report. The deal stalled for four months while the company restructured the audit. By the time they re-issued under the correct scope, the budget cycle had closed.
This is the most common failure pattern I see, and it’s entirely preventable. The challenge isn’t technical — your engineers know how to implement controls. The challenge is structural. The question of which legal entity gets audited, and how the India team is scoped in, has to be answered before you start the engagement. Once an audit is underway, restructuring the scope adds 4–8 weeks and meaningful cost.
This article walks through the decisions you need to make, in the order you need to make them, before kicking off a SOC 2 audit with an India team in the picture. It covers legal entity scoping, the inclusive-vs-carve-out subservice decision, the controls auditors specifically test for India-based personnel, BYOD contractor challenges, vendor selection, cost benchmarks, and timeline planning.
Why this is more confusing than it should be
SOC 2 was designed in 2010 for a world where service organizations were largely US-based with US-based personnel. The Trust Services Criteria were last revised in 2017 (effective 2018, with point-of-focus updates in 2022). They don’t explicitly contemplate the now-common pattern of a US legal entity holding all customer contracts while engineering and operations happen entirely in India.
The AICPA’s guidance is that the entity providing the service is the service organization, and the service organization is what gets audited. In most US SaaS companies with India teams, the US entity is what the customer contracted with — so the US entity is the service organization. The India team’s activities are inputs to that service. They get scoped in, but they don’t become the service organization themselves.
This means several things:
- The SOC 2 report names the US legal entity. Not “Acme India Private Limited.” It says “Acme Inc., a Delaware corporation.”
- The audit is performed by a US-licensed CPA firm. A purely Indian audit firm cannot issue a SOC 2, regardless of expertise, because SOC 2 is an AICPA framework requiring US licensure.
- The India team’s controls are tested. Either as part of the audited entity’s operations (inclusive scope) or as a subservice organization with complementary user entity controls (carve-out).
Most US SaaS founders learn this the hard way, after spending months auditing the wrong entity or working with an auditor who couldn’t issue a report enterprise customers would accept. Let’s prevent that.
Decision 1: Legal entity scoping
You almost certainly want the US legal entity as the named service organization on the SOC 2 report. Here’s the logic chain:
Who does the customer contract with? Your US entity (Delaware C-Corp, typically). That entity is what appears on the MSA, the order form, the DPA. Enterprise buyers will demand that the SOC 2 report names that exact entity.
Who owns the codebase, the cloud accounts, the customer data? If these are also owned by the US entity (which is the standard structure when an India private limited subsidiary exists primarily as a cost-center for engineering staff), then the US entity is unambiguously the service organization.
What if the India entity owns IP or contracts directly with customers? This is rare in well-structured US SaaS companies but does happen. If the India entity has signed customer contracts (often for India-based customers), then the India entity is a service organization for those customers — and would need its own SOC 2 or equivalent. For US-customer-facing services, the US entity remains the service organization.
The audit you commission is for the US entity. The India team is scoped in.
Special case: India-headquartered SaaS. If you are an India private limited company selling to US customers (not a US C-Corp with an India subsidiary), the calculus changes. You can still get a SOC 2, but the audit must be performed by a US-licensed CPA firm, and you’ll need to work with an Indian audit firm that has US partnerships. Several US-licensed CPA firms now offer SOC 2 audits to India-headquartered companies, with on-the-ground Indian auditors handling fieldwork and US CPAs performing engagement quality review. This is a workable model. Expect higher costs than a comparable US-headquartered audit, and budget 6–12 weeks of additional scoping time to align expectations.
Decision 2: Inclusive scope or carve-out subservice
This is the decision most founders get wrong, and it has major implications for cost, complexity, and auditor selection.
Inclusive scope means the India team’s activities are part of the audited service organization’s operations. Their controls are tested directly. They’re not a separate entity in the report; they’re part of the operating environment. The auditor will perform fieldwork on India-based personnel, India-based systems, and India-based facilities (or remote-work equivalents).
Carve-out means the India team is treated as a subservice organization providing services to your US entity. The report identifies the India entity, describes the services they provide, and lists the controls you (the US entity) maintain over them. The India team’s own controls are not tested in this report; the customer is expected to obtain assurance over them separately.
For most US SaaS with India teams, inclusive scope is the correct default. Here’s why:
The carve-out model was designed for situations where a service organization uses a third-party vendor (like AWS, or a payroll processor) whose controls are governed independently. The vendor is genuinely separate. The service organization’s customers can obtain assurance over the vendor’s controls via the vendor’s own SOC 2 report.
A wholly-owned India subsidiary, providing engineering services to the US parent, is not a third-party vendor. It’s part of the same organization. Treating it as a carve-out creates several problems:
- Enterprise customers will ask for the India entity’s separate assurance. Since the India entity typically has no separate SOC 2, you can’t provide it. This kills the procurement value of your report.
- Auditors will scrutinize whether the carve-out is legitimately a subservice organization or whether you’re trying to scope out controls that should be tested. Many will refuse to issue a clean opinion on a structure that doesn’t pass smell tests.
- Vendor risk teams reviewing your report will note the carve-out and treat it as an audit gap.
Inclusive scope is more work — your auditor has to test India-side controls — but it produces a report enterprise buyers actually accept.
When carve-out actually makes sense: If you genuinely contract with a third-party Indian engineering firm (not a wholly-owned subsidiary) for a clearly delimited service, like managed database administration. In that case, the firm is a vendor, you should obtain a SOC 2 from them or perform your own vendor due diligence, and you list them as a carve-out subservice in your report.
Decision 3: Controls auditors specifically test for India personnel
Once you’ve committed to inclusive scope, your auditor will test the same Trust Services Criteria as for US personnel — but with India-specific evidence. Here’s what they’ll ask for:
CC1.1 Integrity and ethical values. Code of conduct signed by India staff. Annual ethics training completed by India staff. Disciplinary procedures for violations, including those applicable to India staff under India labor law. Most US codes of conduct need adaptation for India to handle local labor law specifics around grievance procedures and disciplinary processes.
CC1.4 Commitment to competence. Background checks for India staff. India has no equivalent to a US SSN-based national background check; the standard practice is verification through services like AuthBridge or HireRight India, covering employment history, education, address verification, and police verification (where permissible). Auditors expect background check evidence for any India staff with access to customer data.
CC2.1 Communication of information internally. Documentation accessible to India staff. Security policy training delivered in a format India staff can complete. Evidence of acknowledgement.
CC6.1 Logical access controls. This is where most India scoping goes wrong. Auditors will test:
- Whether India staff access production systems via the same identity provider as US staff (best practice) or separate systems (problematic).
- Whether India access is restricted by network controls (VPN, conditional access).
- Whether multi-factor authentication is enforced for all India access to production.
- Whether access is reviewed quarterly for India staff with the same rigor as US staff.
If your India team has shadow access through legacy accounts, shared credentials, or unmanaged personal email logins, this will fail audit. Plan to consolidate India authentication through your primary IdP (Okta, Microsoft Entra, Google Workspace) before kicking off the audit.
CC6.2 Access provisioning and de-provisioning. Onboarding workflow for India staff. Offboarding workflow for departing India staff, with evidence of access revocation within defined SLA (typically same-day to 48 hours). India terminations are particularly important — Indian employment law has notice period requirements (typically 30–90 days), and access during the notice period is often a control gap.
CC6.6 Logical access to data. Logging of all India access to production. Centralized log aggregation. Alerts on anomalous access patterns. Note that some India staff may access from public Wi-Fi or personal hotspots — make sure your logging captures connection metadata sufficient to investigate.
CC6.8 Endpoint security. This is where BYOD becomes a major issue. If India staff use company-issued, MDM-managed devices, you have a straightforward control. If they use personal devices, you’ll need compensating controls covered below.
CC7.4 Vulnerability management. Patching SLAs apply to India-managed assets too. If India engineering operates production infrastructure, evidence of patching cadence is required from those systems.
CC8.1 Change management. India-led changes go through the same approval, testing, and deployment workflow as US-led changes. Auditors will sample changes from both sides.
Decision 4: Handling BYOD offshore contractors
The hardest control challenge for early-stage US SaaS with India teams is BYOD (Bring Your Own Device). When you have engineering contractors using their personal laptops, you cannot enforce MDM, cannot mandate disk encryption, cannot prevent shadow copies of source code on personal machines, and cannot enforce endpoint security software the way you can on company-issued laptops.
There are three viable approaches:
Approach 1: Issue company laptops. Ship MacBooks or ThinkPads to India staff, enrolled in your MDM (Kandji, Jamf, Microsoft Intune, or similar). Cost: $1,500–$2,500 per device plus shipping logistics (which are non-trivial to India — customs duties of 20–30%, ISP delays, broken equipment replacement). This is the cleanest audit story but the most expensive operationally.
Approach 2: Virtual Desktop Infrastructure (VDI). India staff connect to a virtual desktop hosted in your cloud (AWS WorkSpaces, Azure Virtual Desktop, or similar). All actual work happens in the virtual environment. Their personal device is just a thin client. Cost: $35–$80 per user per month. Audit posture is clean because customer data never lives on the personal device. Trade-off: latency can be painful for development work; some engineers will resist this.
Approach 3: Strict conditional access without MDM. Personal devices are allowed, but only through narrow, monitored paths. Source code access via a managed terminal session (like Coder, Gitpod, or a bastion host). Customer data access via SaaS tools with strict conditional access policies (require corporate identity, require MFA, block downloads, watermark all views, log everything). Cost: low to moderate, mostly your existing SaaS licenses. Audit posture: defensible if implemented rigorously, fragile if any control is loose.
My recommendation for most early-stage teams: Approach 3 to start, migrating to Approach 1 within 12–18 months as you scale. Document the controls meticulously. The auditor will ask “how do you prevent source code from being copied to personal devices?” Have a specific, evidenced answer.
Whichever approach you choose, your contractor agreements with India staff need to explicitly cover device security, data handling, and post-termination obligations. Standard contractor agreements written for US contexts often miss these. Update your template before onboarding India staff.
Decision 5: Auditor selection
Three categories of audit firm can perform a SOC 2 with India team scope:
Pure US firms with no India presence. They’ll perform the audit, but India fieldwork happens entirely remotely. You’ll coordinate evidence collection from India staff on their behalf. Lowest total cost. Highest internal lift. Best fit when your India team is small (under 20 people) and you have strong internal compliance ops.
US firms with India offices or partnerships. Firms like A-LIGN, Schellman, Coalfire, and Insight Assurance have either direct India presence or named partnerships with Indian firms. Audit fees higher than pure US firms by 15–25%. They can perform on-the-ground fieldwork in India, which is meaningful when you have larger India teams or India-based infrastructure. Best fit for India teams of 20–80 people.
India audit firms partnered with US CPAs. Several Indian audit firms (including some IRQS, ControlCase, ValueMentor, and TÜV Nord India) operate under US CPA partnerships. The Indian firm performs fieldwork; the US CPA reviews and signs. Cost can be lower than US firms with India offices, particularly for smaller engagements. Quality varies — vet carefully. Best fit when your operations are predominantly India-based and your US footprint is mostly the legal entity and customer relationships.
Questions to ask any prospective auditor:
- Can I see two redacted reports you’ve issued in the past 18 months for clients with India teams of [your team’s size]?
- What’s your engagement methodology for India fieldwork — on-site visits, remote video evidence, or document-only?
- Who specifically will be on the engagement team, and what’s their India experience?
- How do you handle subservice carve-outs vs. inclusive scope decisions? (Watch for firms that push carve-out as a cost-cutting measure — that’s a red flag.)
- What’s your peer review status, and when was your last AICPA peer review?
The cheapest auditor is rarely the right answer. The most expensive isn’t either. Look for firms that have specifically done audits like yours before.
Cost benchmarks
For a US SaaS with India team of 20–60 people pursuing first-time SOC 2 (Type 1 then Type 2), realistic 18-month cost ranges:
- Audit fees: $40K–$110K combined (Type 1 + Type 2)
- Platform (Vanta, Drata, Sprinto): $12K–$18K/year
- Consulting / fractional support: $25K–$80K (varies dramatically with scope)
- Internal staff time: 0.3–0.6 FTE equivalent during prep, 0.1–0.2 FTE ongoing
- Tooling (IdP, MDM, logging, vulnerability scanning, if not already in place): $20K–$50K initial
Total: roughly $100K–$250K for first 18 months. Subsequent years drop substantially as the operational machinery is in place.
The India-specific additional cost compared to a pure US setup is typically 20–40%, driven by: more complex evidence collection, additional controls testing, India-specific tooling (background check services, India-jurisdiction legal advice), and longer engagement timelines.
If anyone quotes you under $30K for a complete first-year SOC 2 with an India team, they’re either skipping major controls or selling a Type 1 only. Set expectations accordingly.
Timeline planning
A realistic timeline for a US SaaS with India team starting from scratch:
Months 1–2: Gap assessment and scoping. Decide entity scope, choose platform, perform gap analysis, identify control gaps. This is where Attri Edge engagements typically begin.
Months 3–6: Remediation. Close control gaps. Implement missing tooling. Update policies. Onboard India staff into proper identity and access workflows. Document everything.
Months 6–8: Pre-audit dry run. Internal or external readiness assessment. Identify remaining gaps. Final fixes.
Months 8–11: Type 1 audit. Point-in-time assessment. Issued report.
Months 11–18: Type 2 observation window. Minimum 3 months; typically 6–12 months for first Type 2. Auditor returns at end for fieldwork. Type 2 report issued 4–8 weeks after end of observation window.
Faster timelines are possible if you have most controls already in place, are smaller (under 25 staff total), and pursue Type 1 only initially. Some teams can issue a Type 1 in 90–120 days. But Type 2 — which is what enterprise buyers actually want — adds at least 6 months on top.
The questions to answer before you start
Before kicking off any SOC 2 engagement with an India team in scope, write down your answers to these:
- Which legal entity is the named service organization?
- Inclusive scope or carve-out for India operations?
- What’s our endpoint security posture for India staff (company laptops, VDI, or BYOD with compensating controls)?
- Who’s our auditor, and have they audited companies with India teams before?
- What’s our internal capacity to manage this — full-time hire, fractional support, or founder-led?
- What’s our budget for first 18 months, including audit fees, platform, consulting, and tooling?
- What’s our target completion date for Type 1 and Type 2, working backward from a specific enterprise deal or sales target?
If you don’t have answers to most of these, you’re not ready to start. The first month of any well-run SOC 2 engagement is spent answering exactly these questions.
Conclusion
SOC 2 for US SaaS with India teams is more complex than the standard pattern but entirely solvable. The decisions you make in the first month — about entity scope, inclusive vs. carve-out, endpoint security approach, and auditor selection — determine whether the audit takes 12 months or 24, costs $80K or $200K, and produces a report enterprise buyers actually accept.
The single most important principle: the US legal entity is the service organization. The India team is in scope under that entity’s audit. Get that right, and most other decisions become tractable.
Get it wrong — audit only the India entity, issue under a local Indian audit firm without US CPA backing, treat the India subsidiary as a third-party carve-out — and you’ll spend 6 months and tens of thousands of dollars producing a report that enterprise procurement rejects.
If you’re at the start of this journey and want a structured pre-audit assessment that gets these decisions right before you spend money on an engagement, the Attri Edge Diagnostic is built specifically for this. $999, 48-hour turnaround on the deliverable, structured around the seven decisions above. Book the diagnostic →
Related reading:
- DPDPA Meets SOC 2: The Cross-Mapping Playbook — how India’s data protection rules interact with SOC 2 Privacy criteria
- How to Pass a SOC 2 Audit With an Unmanaged Offshore Engineering Team (BYOD) — the deep dive on Approach 3 from this article
- The Stalled Enterprise Deal Playbook — what to do when SOC 2 issues are blocking an active deal
- The Compliance Automation Gap — why hitting 100% on your Vanta dashboard isn’t enough