Updated: 15 May 2026
A Bengaluru-based GCC needed to secure remote access, privileged accounts, contractor access, and legacy applications while satisfying both parent company mandates and Indian regulatory requirements.
"The mandate itself was not the problem," said Karthik Nair, Head of IT Infrastructure at the India GCC. "We expected something like this. The problem was the scope. When Group Security said all remote access, they meant everything. Not what our current MFA policy covered. Everything."
The email from the parent company's Group Security team had been sent to seven entities globally. A credential-based breach at a subsidiary had been traced to a dormant contractor account not deactivated when the engagement ended. The India GCC in Bengaluru had 90 days to demonstrate full MFA compliance across its technology estate: all remote access, all privileged accounts, all contractor access, and evidence submitted to Group Security in a specified format by the deadline.
The existing MFA policy covered corporate email, Microsoft 365, and the primary VPN. It covered approximately 60% of the GCC's access surface. The remainder, developer access to US client environments through a separate tunnel, contractor remote access, and legacy internal applications outside the SOC 2 audit scope, was not covered.
Proactive's credential audit took four days. Karthik had allocated two.
31 contractor accounts with active access to GCC systems. 12 were associated with engagements that had ended between 3 and 22 months earlier. Two had been accessed in the previous 60 days from IP addresses outside the expected contractor network ranges.
1 shared domain administrator account used by 4 members of the infrastructure team since the GCC's initial setup in 2018. Six years of domain administrator activity appeared in the logs as a single account name with no individual attribution.
34 developers with access to US client staging environments through a VPN tunnel provisioned outside the standard IT procurement process three years earlier. The tunnel was not covered by the corporate MFA policy.
6 accounts belonging to employees who had transferred to other entities within the parent company group. All 6 retained full access to the India GCC's systems. None had been offboarded from the directory.
"The 6 transfers were the finding that stopped me," Karthik said. "These were our own people. We knew they had moved. We processed their transfers. Nobody had thought to check what access they still had here. Some of them had been gone for over a year."
The shared domain administrator account was cited by Group Security as a primary example of the access governance gap the mandate was designed to close.
SOC 2 Type II certification for GCCs covers the controls around customer and client data as defined in the audit scope. It does not, by default, cover developer access to client production environments, contractor credentials, or privileged access outside the defined scope boundary. CERT-In CISG-2025-02 required MFA for all remote access and 180-day authentication log retention in India. DPDPA 2023 required reasonable security safeguards across all systems handling personal data. All three obligations applied simultaneously.
GCCs handling data for parent companies in regulated industries face a compliance pressure specific to their position: parent company SOC 2 obligations arriving from one direction and Indian regulatory requirements under CERT-In and DPDPA arriving from another. The evidence standards are different. The access surface is the same.
The shared domain administrator account was retired. Four individual named accounts replaced it, with a three-day migration period before the shared account was deactivated. The 6 transfer accounts were deactivated after individual written confirmation from each former employee. One did not respond.
The account was deactivated on day 5 after the original transfer manager confirmed the individual had been in their new role for 14 months with no ongoing India GCC responsibilities. All infrastructure team members and privileged administrator accounts enrolled in Cisco Duo with Verified Push.
The 12 closed-engagement contractor accounts were deactivated. Two contracting companies had been dissolved; accounts were deactivated on the basis of the last engagement date and zero access activity in the previous 180 days.
Active contractors migrated to time-limited named credentials with a 45-day expiry. RADIUS integration with the primary VPN concentrator. The 34 developers with access to the US client tunnel enrolled in Cisco Duo under a separate policy requiring Verified Push, reflecting the sensitivity of the client environment.
1,800 employees enrolled across the GCC. Karthik's pre-enrolment communication, sent to every team lead five days before the rollout began, explained what was changing, why, and what each employee needed to do. Helpdesk received 23 calls. 19 were resolved by the helpdesk team. 4 were escalated to Proactive. All 4 resolved within 4 hours.
Group Security's SOC 2 evidence standard required authentication log exports in a specific JSON schema with UTC timestamps. CERT-In required 180-day log retention stored in India, individually attributed.
Cisco Duo's standard log export satisfied the CERT-In requirement. It did not produce the Group Security JSON schema without modification.
"Chicago wanted one format. CERT-In required storage in India. Cisco Duo's standard export gave us one of those things. We needed both," Karthik said.
Proactive built a custom SIEM integration normalising the Cisco Duo log output to Group Security's JSON schema while routing storage to an India-resident log management platform. The integration took 8 days, running in parallel with the privileged access deployment.
On day 38, a developer reported an authentication error accessing an internal application. The application was not in the system inventory used to design the deployment.
Proactive investigated. The error had been captured in the Authentication Proxy logs. The application was one of 23 legacy internal tools provisioned by individual teams over several years, none of which had been added to the formal IT asset register. They were visible only because the Authentication Proxy had logged the authentication attempt.
"This is the thing nobody tells you about MFA deployments," Karthik said. "You will find systems you did not know you had. We found 23 of them. All at once. On day 38."
Proactive audited all 23 applications over 3 days. All were LDAP-based internal tools with no external access. All were integrated via LDAP proxy configuration within 4 days. None required application software changes. None required additional procurement. All were covered before the mandate deadline.
1. Mandate Outcome Day 79: compliance evidence package submitted to Group Security in Chicago and retained for the CERT-In audit file. The India GCC was the first of the seven mandate entities globally to submit a complete, compliant evidence package. Three entities, including two in the United States, missed the 90-day deadline and were placed on extended compliance review.
2. Credential Findings Resolved: Shared domain administrator account replaced with 4 individual named accounts. 12 closed-engagement contractor accounts deactivated. 6 transfer accounts deactivated. 34 developers enrolled under the client-tunnel MFA policy. 23 previously unidentified legacy applications identified and integrated.
3. CERT-In Annual Audit Outcome: Conducted four months after the deployment. Zero findings related to authentication, remote access, privileged access, or log retention. The auditor specifically noted the India-resident log management and individual attribution in the authentication records.
4. Parent Company Recognition The parent company's SOC 2 renewal audit, conducted five months after the deployment, cited the India GCC's MFA implementation as a reference example for other global entities.
5. The Contractor Access Finding Two contractor accounts showing access from unexpected IP addresses during the credential audit were confirmed, in a subsequent security review, to have been accessed by contractors using credentials shared with colleagues. Neither incident was malicious. Both were the category of access governance failure the credential audit and subsequent deployment were designed to prevent. Neither would have been visible without the audit.
"The 11 days we had left after submitting felt important," Karthik said. "We used them checking the work. Making sure the 23 applications we found on day 38 were fully covered, that the SIEM integration was producing clean output, that the contractor renewal register had a live owner. We did not want to submit and stop looking."
Proactive Data Systems, a Cisco Preferred Security Partner, deployed Cisco Duo Advantage across the full 1,800-person GCC, with the Authentication Proxy for VPN and LDAP legacy applications, Verified Push for privileged accounts and client-environment developer access, the custom SIEM integration for dual-standard log export, and India data residency through the Mumbai Duo data centre.
This case study is a composite illustration drawn from Proactive's deployment experience across multiple GCC client engagements. It does not describe a specific named client, company, or engagement. Karthik Nair is a fictional individual representing the IT Infrastructure head persona common in GCC deployments. His quotes represent perspectives drawn from client feedback across multiple engagements and do not constitute statements from a named individual. Statistical and numerical details are illustrative of patterns observed across deployments.
We'll get back to you shortly.
