SOC 2 for GCCs: What an India Captive Centre Needs to Prove to Its US/UK Parent

Every GCC leader I've sat down with eventually asks a version of the same question: "our US or UK headquarters already has a SOC 2 report — why do we need one too?" It's a fair question, and the honest answer is that a parent company's SOC 2 audit report almost never covers what a captive centre in India is actually doing with customer data. If your GCC handles production access, processes customer information, or supports systems that fall inside the parent's audit scope, you're very likely a control point the parent's own SOC 2 auditor is going to want evidence about — whether or not anyone in Bangalore or Gurugram signed up for that conversation.

This is worth understanding clearly before your parent company's next SOC 2 Type 2 audit lands on your desk as a fire drill, because captive centres that get ahead of this requirement have a fundamentally easier relationship with headquarters than the ones who find out mid-fieldwork.

Why a Parent Company's SOC 2 Report Doesn't Automatically Cover Its GCC

A SOC 2 audit examines a specific system description — the boundary the parent company and its auditor agreed on during scoping. If your GCC only handles internal back-office work with no access to production systems or customer data, you may genuinely sit outside that boundary. But that's increasingly the exception, not the rule. Most GCCs today are doing real engineering, support, or operations work — which means employees with access to the same systems, logs, and customer information the parent's SOC 2 compliance program is built to protect.

When that's the case, your GCC isn't a footnote in the parent's report. It's part of the "people" component of the system description, and the parent's SOC 2 auditor needs evidence that access provisioning, monitoring, and control operations extend correctly to India — not just to headquarters. Assuming the parent's report "covers everyone" without checking the actual scope is one of the most common and most costly misunderstandings GCC leaders walk into.

What Your Parent Company's SOC 2 Auditor Actually Wants From the GCC

In practice, when a captive centre is inside scope, the evidence requests tend to cluster around a predictable set of areas:

Access provisioning and deprovisioning. Who in the GCC has access to production systems, how that access was approved, and — critically — how quickly it's revoked when someone leaves or changes roles. Offboarding delays are one of the most frequently cited gaps auditors find when a GCC's HR and IT processes aren't tightly linked to the parent's identity system.

Evidence that local access maps to global policy. If headquarters enforces MFA, least-privilege access, and quarterly access reviews, the auditor wants proof the GCC follows the identical policy — not a locally adapted version that looks similar but isn't formally the same control.

Segregation of duties. Particularly for GCCs handling финансы, engineering deployments, or customer support with elevated access, auditors want to see that no single person in India can both request and approve their own access changes.

Vendor and subcontractor visibility. If the GCC itself uses local tools, contractors, or infrastructure the parent doesn't directly manage, that introduces a subservice-organization-style question the auditor will want mapped explicitly.

Incident and escalation records. If something goes wrong on the India side — a failed login pattern, a misconfigured permission, an actual security event — the auditor wants to see it was logged, escalated to the right people, and closed out the same way it would be at headquarters.

None of this is exotic. It's largely the same evidence any in-scope team produces for a SOC 2 audit. The difference is that GCCs often operate with their own HR systems, their own IT helpdesk, and their own informal shortcuts that quietly diverge from global policy — and that divergence is exactly what a SOC 2 auditor is trained to catch.

Type 1 vs Type 2: Why It Matters More for a Captive Centre

The distinction between a SOC 2 Type 1 audit and a SOC 2 Type 2 audit matters everywhere, but it matters more acutely for a GCC. A Type 1 report is a snapshot — it confirms controls were designed properly as of one date. A SOC 2 Type 2 report goes further, testing whether those same controls operated consistently over an observation window, typically six to twelve months.

For a captive centre, that means a single well-organized access review the week before the auditor's visit isn't enough. The parent's SOC 2 Type 2 audit needs to see that the GCC's access reviews, offboarding, and monitoring ran on schedule every month of the review period — not just when someone remembered the audit was coming. This is where GCCs most commonly stumble: local HR and IT teams run their own cadence, and nobody connects that cadence to the global evidence trail the parent's auditor is actually sampling against.

Common Gaps Between GCC Practice and Parent Company Policy

A few patterns show up consistently when a captive centre goes through its first SOC 2 compliance review as part of the parent's audit:

Offboarding lag. An employee's last working day in India and their access revocation date in the global system don't always match, especially when HR and IT sit in different reporting lines.

Shadow tools. The GCC adopts a local ticketing system, VPN, or file-sharing tool that headquarters doesn't know about — and suddenly there's a system in scope that the parent's SOC 2 auditor never mapped.

Contractor and vendor blind spots. GCCs frequently work with local staffing agencies or contractors who need production-adjacent access; if that relationship isn't governed the same way as full-time employee access, it becomes an exception waiting to be found.

Policy translation gaps. A global security policy written for a US or UK audience sometimes gets locally reinterpreted in India in ways that technically satisfy the spirit but not the letter of what the SOC 2 auditor is testing against.

Fixing these isn't complicated, but it does require the GCC to treat itself as a genuine extension of the parent's control environment rather than a semi-independent operation that happens to share a logo.

Building a GCC-Ready Evidence Trail Before the Parent's Audit Window Opens

The captive centres that sail through this part of a SOC 2 Type 2 audit tend to do a few specific things well ahead of the observation period:

They name a local owner for every control category that touches the GCC — access, offboarding, incident response — and that owner reports directly into whoever owns the same control at headquarters, so there's no gap in accountability.

They align the access review calendar with the parent's, rather than running a separate India-specific cadence that has to be reconciled after the fact.

They document local variations explicitly. If India has a different notice period, different HR system, or a different escalation path, that's fine — but it needs to be written down and reconciled with the global policy, not left for the auditor to discover as an inconsistency.

They loop the parent's SOC 2 auditor into GCC-specific processes early, during the scoping conversation, rather than waiting for an evidence request mid-fieldwork to reveal that nobody thought to include India in the plan.

Where This Fits Into the Broader SOC 2 Compliance Conversation

None of this changes what SOC 2 fundamentally is — an attestation, not a certification, issued by a CPA firm examining whether controls were suitably designed and, for Type 2, operated effectively over time. What changes for a GCC is where the evidence has to come from, and how carefully that evidence needs to be reconciled with a parent company operating out of a completely different HR system, IT stack, and reporting structure.

Getting this right isn't just about avoiding a qualified opinion in the parent's SOC 2 audit report — it's about the GCC being seen internally as a genuine extension of the security program rather than a location the compliance team has to work around every audit cycle.

Where Accorp Fits In

Accorp Partners works with India-based GCCs and their US/UK parent companies on exactly this handoff — mapping which of the parent's controls actually extend into the captive centre, closing the access and offboarding gaps that most commonly surface during SOC 2 Type 2 testing, and making sure the evidence a GCC produces genuinely reconciles with what headquarters is submitting to its own auditor. If your GCC is about to be pulled into a parent company's SOC 2 audit scope for the first time, it's worth having that conversation before the observation window opens rather than after.

Frequently Asked Questions

1. Does a GCC need its own separate SOC 2 report?
Usually not. Most GCCs are folded into the parent company's SOC 2 compliance program and system description rather than pursuing an independent SOC 2 audit report — but that only works if the GCC's controls are actually evidenced as part of the parent's testing.

2. What happens if a GCC's access controls don't match the parent's policy?
It typically shows up as an exception in the parent's SOC 2 Type 2 report, scoped to whichever control diverged — which is why aligning local practice with global policy before the audit begins matters more than fixing it after the fact.

3. How far in advance should a GCC prepare for its parent's SOC 2 audit?
Ideally before the observation period starts, since a SOC 2 Type 2 report requires evidence that controls operated consistently for six to twelve months — not just a clean state on the day the auditor visits.