Is Outsourcing to India a Security Threat? Model the Access

The question usually arrives with a link attached. Somebody forwarded a story about a breach at a large IT services firm, and now a board member wants to know whether outsourcing to India, specifically to the vendor in Pune whose contract is sitting in your approvals queue, puts the company at risk. Procurement wants an answer by Friday. The security questionnaire came back with every box ticked and an ISO 27001 certificate attached, which tells you nothing.

Here is the honest answer, and it is not the comfortable one in either direction. “Is country X a threat” is not a threat model. The risk in any outsourcing arrangement is third-party access risk, and it is driven by three things: how much access you grant and how it is designed, which jurisdictions your data and your vendor’s operations sit in, and how mature that specific vendor’s security controls are. Nationality is a weak proxy for all three. An Indian vendor with just-in-time privileged access, a hardened jump host and enforced no-local-storage is a smaller risk than a domestic managed service provider with a shared admin account nobody has rotated since 2019.

That is not a defence of outsourcing. The risk is real and plenty of organisations manage it badly. It is an argument about where to point your attention. Spend Friday on the country and none of it on access design, subcontracting clauses and log visibility, and you will sign a contract that feels reassuring while leaving the actual incident pathways open.

What the breach data says about third-party risk

The number people quote comes from the Verizon Data Breach Investigations Report. The 2026 edition found that breaches involving a third party accounted for 48% of all breaches, roughly a 60% increase on the prior year. The 2025 edition put it at 30%, itself double the 15% reported the year before. The 2026 dataset covers more than 31,000 incidents and at least 22,000 confirmed breaches across 145 countries, from 1 November 2024 to 31 October 2025.

Now the caveat most summaries drop. “Third-party involvement” in the DBIR is broad: breaches at a third party, breaches involving third-party infrastructure, and breaches that began with exploitation of third-party software. A vulnerability in a file transfer product you licensed lands in that 48% alongside a compromised outsourcing vendor with VPN access to your network. The figure is strong evidence that external dependency is now the dominant breach pathway. It is not a measurement of offshore labour risk. The DBIR does not break third-party involvement down by vendor country, and any statistic claiming to do so deserves a hard look at its methodology.

The incidents people cite, described accurately

Three cases come up in every version of this argument. State them as reported, because the embellished versions are where the reasoning goes wrong.

Wipro, April 2019. KrebsOnSecurity reported, based on sources at affected customers, that intruders had been inside Wipro’s corporate email system for months and were using Wipro’s own systems to run reconnaissance and launch attacks against clients, with at least eleven customer organisations identified. Wipro first declined to comment, then confirmed an intrusion, engaged outside forensics and shared indicators of compromise with clients. Attribution was disputed: early reporting raised a possible state actor, later analysis linked the activity to financially motivated gift card fraud. The operational lesson survives that argument. The vendor’s connectivity into customer networks was the attack path.

Okta and Sitel, January 2022. A threat actor compromised the workstation of a support engineer working for Sitel, Okta’s third-party customer support provider. Okta’s final account is specific: active control of that workstation for 25 consecutive minutes on 21 January 2022, inside a five-day exposure window, with two customer tenants accessed. Okta’s early public estimate had been that roughly 2.5% of its customer base, about 366 organisations, was potentially impacted, and it ended the relationship with Sykes/Sitel. The cleanest published example of subcontracting chain risk: the access that mattered sat on an endpoint two contractual steps from the company whose customers were exposed.

Infosys McCamish Systems, November 2023. IMS, an Atlanta-based subsidiary of Infosys BPM running insurance and deferred compensation platforms, was compromised around 3 November 2023, with LockBit claiming the attack on 4 November. IMS notified Bank of America on 24 November, and 57,028 of that bank’s customers were told their names, addresses, dates of birth and Social Security numbers may have been exposed. Notifications across all affected clients eventually reached roughly six million people.

Read that last one carefully, because it is the case most often cited as proof that Indian outsourcing is dangerous. The compromised entity was a US-incorporated company operating in Georgia, and the attacker was a ransomware crew. Nothing in the public record supports a claim of national culpability, and a vendor incident is never evidence of one. It proves that a provider holding your customer data can be ransomwared and that you will be the one notifying regulators and consumers. Equally true of a provider in Ohio.

The joint advisory on managed service providers issued on 11 May 2022 by CISA, the NSA, the FBI and their counterparts in the UK, Australia, Canada and New Zealand makes the point structurally. It was written about MSPs generally, not offshore ones, and its customer-side advice is entirely about access: restrict MSP accounts to the systems the MSP manages, disable them when not in use, contractually require visibility of the provider’s activity in your environment, define incident notification, and understand the risk from the provider’s own subcontractors.

Six risks worth modelling in any outsourcing deal

Drop the country framing and a tractable list is left behind.

Privileged access and standing credentials. The core exposure. Domain admin, production database roles, CRM export rights, service accounts created at onboarding and never reviewed. Standing privilege means one credential compromise anywhere in the vendor’s estate becomes access to yours, at any hour, with nobody approving it.
Lateral movement from the vendor’s own compromise. Wipro in 2019 is the textbook version. The vendor need not be malicious or even negligent. It needs to be targeted, which large service providers reliably are, because they hold keys to many networks.
Insider risk. Real, and mismanaged in both directions. Not mitigated by choosing a country. Mitigated by removing any one person’s ability to extract data at volume undetected: least privilege, no bulk export rights, DLP on the access path, session recording for privileged work, behavioural monitoring that flags a 3am bulk read. Background verification helps at the margins and proves nothing about month fourteen.
Subcontracting chains you did not approve. The gap between the entity you signed with and the person whose laptop touches your data. Ask how many delivery staff on your account are subcontracted, and how many of the provider’s own support tools are outsourced. The Okta case ran through exactly this seam.
Data residency and lawful access. Every government has mechanisms to compel disclosure, the United States included. India’s CERT-In directions require certain logs to be held within Indian jurisdiction; the US CLOUD Act reaches data held by US providers wherever stored. A real input for sensitive data, and a symmetric one.
Concentration risk. The forgotten one. If a single vendor runs your service desk, your identity administration and your month-end close, one ransomware event there is an outage of three business functions at once. A resilience problem, not a nationality problem, and the risk most likely to actually hurt you.

Does outsourcing to India break any US law?

One federal rule does restrict sending sensitive data abroad, and it is widely misdescribed. The Department of Justice’s Data Security Program, issued under Executive Order 14117 and codified at 28 CFR Part 202, took effect on 8 April 2025, with due diligence, audit and reporting obligations for restricted transactions phasing in from early October 2025.

It designates six countries of concern at 28 CFR 202.601: China, Cuba, Iran, North Korea, Russia and Venezuela. India is not a designated country of concern. Nothing in the Data Security Program restricts a transaction simply because your vendor is Indian.

The rule can still reach an Indian vendor indirectly, so it is worth knowing how it works. It applies to covered data transactions involving bulk US sensitive personal data or government-related data with a country of concern or a “covered person”. Bulk is defined by threshold at 28 CFR 202.205, from more than 100 US persons for human genomic data through 1,000 for biometric identifiers to 10,000 for health or financial data and 100,000 for covered personal identifiers. Government-related data is covered with no volume threshold. A covered person under 28 CFR 202.211 includes a foreign entity 50% or more owned by a country of concern, entities owned by such covered persons, foreign individuals employed or contracted by them, and foreign individuals primarily resident in a country of concern.

So the question for an Indian vendor is ownership and staffing, not nationality. An Indian company majority-owned by a Chinese entity is a covered person. An Indian company staffing your account with engineers primarily resident in a country of concern has covered persons touching your data. Vendor agreements are a restricted rather than prohibited class under 28 CFR 202.401: permitted if you meet the security requirements the rule incorporates, which CISA published. Subpart E exempts financial services, corporate group transactions, official US government business and telecommunications services, among others. That is the rule, and it is both narrower and sharper than the version circulating in procurement threads.

The sectoral rules bite harder in practice:

HIPAA. No geographic restriction, but the business associate agreement chain and the Security Rule follow protected health information wherever it goes, subcontractors included.
FedRAMP. Cloud services processing federal data need an authorisation, which constrains how that data is handled regardless of vendor nationality.
GLBA. The FTC Safeguards Rule at 16 CFR 314.4(f) requires you to select and retain service providers capable of appropriate safeguards, require those safeguards by contract, and periodically assess them based on risk. An active oversight duty, not a one-time questionnaire.
ITAR and EAR. Here nationality genuinely is the legal test. Under 22 CFR 120.50(a)(2), releasing technical data to a foreign person, even inside the United States, is a deemed export requiring authorisation. For defence-adjacent work this is an export control question with real penalties, and it applies to the foreign national in the next cubicle as much as to a team in Hyderabad.
CMMC. The program rule at 32 CFR Part 170 took effect 16 December 2024; the acquisition rule putting CMMC into DoD contracts took effect 10 November 2025. It governs protection of controlled unclassified information, not the citizenship of who handles it, though many contracts layer US-persons-only clauses on top.

What Indian law requires of your vendor

Two frameworks matter, and one contains a detail most US buyers have never been told. The Digital Personal Data Protection Act 2023 is India’s general data protection statute, with the DPDP Rules notified by MeitY in November 2025 and obligations phasing in over 12 to 18 months. Section 8(5) requires a data fiduciary to protect personal data in its possession or control, including processing carried out on its behalf by a processor, through reasonable security safeguards. Section 8(6) requires breach intimation to the Data Protection Board and to affected individuals, and the Schedule sets penalties reaching ₹250 crore for a safeguards failure.

The detail: Section 17(1)(d) disapplies most of the Act where “personal data of Data Principals not within the territory of India is processed pursuant to any contract entered into with any person outside the territory of India by any person based in India”. The opening words of Section 17(1) preserve sub-sections (1) and (5) of Section 8, so the security safeguards duty survives while the rest of Chapter II, all of Chapter III and Section 16 fall away. In plain terms: where your Indian BPO processes your US customers’ data under your contract, Indian data protection law gives those individuals very little. Your protection comes from your contract and from US law. That is a real argument for tighter contractual terms, and the sort of finding a threat model produces and a country debate never does.

The CERT-In directions of 28 April 2022, effective from late June 2022, are the other half. Indian entities must report specified cyber incidents to CERT-In within six hours of noticing them, enable logs of all ICT systems and hold them for a rolling 180 days within Indian jurisdiction, and synchronise clocks to NIC or NPL time servers. VPN, cloud and data centre providers must keep subscriber registration details for five years. Two consequences. Your vendor has a six-hour regulatory clock that has nothing to do with notifying you, so write your own notification window into the contract and make it shorter. And their 180-day log obligation is a lever when you ask for log access.

The controls that actually reduce the risk

None of these depend on where the vendor sits. All are verifiable.

Zero standing privilege with just-in-time elevation. No permanent admin accounts for vendor staff. Access requested, approved, time-boxed, automatically revoked. This one change removes most of the blast radius from a vendor-side compromise.
Jump hosts or VDI, data staying your side. Vendor staff work inside a session you own, with no direct network route from their corporate estate to your production systems.
No local storage, enforced rather than promised. Clipboard, drive redirection, printing and USB disabled in the session. Downloads blocked at the broker, not left to policy.
Logging you can see, plus behavioural analytics. Vendor sessions logged to your SIEM, not theirs, with UEBA baselines on volume, timing and scope of access. The AA22-131A recommendation on contractual visibility exists because most customers cannot see what their provider is doing.
Background verification to a defined standard. Specify what is checked, by whom, how often it is refreshed, and require evidence for the named individuals on your account rather than a policy document.
Subcontractor approval clauses. Named entities only, written approval before any change, flow-down of every security obligation, right to refuse. Then audit for it, because this is the clause most often breached quietly.
Right to audit, with teeth. Annual assessment, control evidence rather than certificates, and the right to test. A SOC 2 Type II report is a starting point; read the exceptions and the complementary user entity controls, where your own obligations hide.
Automated joiner-mover-leaver. Offboarding triggered by the vendor’s HR system through an agreed integration or a mandatory daily roster, with automated deprovisioning. Orphaned vendor accounts are among the most common findings in any access review, everywhere.

How to evaluate a vendor instead of a country

Replace the questionnaire with evidence requests, and judge answers on specificity rather than confidence:

Show me the access model you propose for my account: which accounts, what privileges, what elevation path, what session controls, who approves.
Name every subcontractor and fourth party whose tooling will touch my data, including your own support and monitoring stack.
Which legal entity signs, where is it incorporated, who owns it, and where will the individuals on my account be physically located?
Your SOC 2 Type II report including exceptions, your last penetration test report with the retest, and your incident notification commitment in hours.
What log data will I receive, in what format, into my SIEM, and how quickly?
What is your offboarding SLA for a departing team member’s access, and how is it triggered technically?
What happens on exit: data return format, deletion attestation, and the timeline.

A vendor that answers these crisply is lower risk than one that cannot, whatever flag is on the building. One that gets defensive about subcontractor disclosure has told you something important. And if you would not accept an answer from a provider in Dallas, do not accept it from one in Chennai, or the reverse.

Questions that come up next

Is offshore outsourcing riskier than a domestic MSP? Not inherently. The differences that matter are practical: cross-border contract enforcement is slower, time zones complicate incident response coordination, and on-site audit costs more. Manageable frictions, and separate from whether the vendor’s controls are sound. The joint CISA advisory on MSP threats was written about domestic providers.

Does ISO 27001 certification answer the question? No. It tells you a management system exists and was audited against a defined scope. Read the scope statement, which frequently covers one delivery centre or service line rather than the team on your account. Ask which certificate covers which entity and location, and check your subprocessor disclosure obligations to your own customers while you are at it.

Can we just require US persons only? You can, and for ITAR-controlled technical data you must. Know what you are buying: a narrower talent pool, higher cost, and no reduction in the risks that drove the last decade of third-party breaches. Unless export law is in scope, it is a compliance control rather than a security one.

If you are working through this on a live contract and want the access design done properly rather than argued about, that is the kind of work AB7 Solutions does on both sides of the table: vendor security assessment, VAPT and SOC support for the controls above, and offshore staff augmentation set up with zero standing privilege, jump host access and log visibility from day one. A short call is usually enough to tell whether your real exposure is the vendor or the access model. Reach the team on +1 321 341 7733 or at ab@ab7solutions.com, contact the director directly at director@ab7solutions.com, or see the services at www.ab7solutions.com.

Sources: Verizon, 2026 Data Breach Investigations Report and 2026 DBIR news release (48% third-party involvement; 31,000+ incidents, 22,000+ confirmed breaches, 145 countries, 1 Nov 2024 to 31 Oct 2025), and 2025 DBIR release (30%); US Department of Justice, Data Security Program, and eCFR, 28 CFR 202.601, 202.205, 202.211, 202.401 and Subpart E; CISA, NSA, FBI, NCSC-UK, ACSC, CCCS and NCSC-NZ, AA22-131A, Protecting Against Cyber Threats to Managed Service Providers and their Customers, 11 May 2022; FTC Safeguards Rule, 16 CFR 314.4(f); ITAR, 22 CFR 120.50; DoD, CMMC Program final rule, 32 CFR Part 170; MeitY, Digital Personal Data Protection Act 2023 (ss. 8(5), 8(6), 17(1)(d), Schedule); CERT-In, Directions under section 70B(6), 28 April 2022; KrebsOnSecurity on the 2019 Wipro intrusion; Okta, conclusion of the January 2022 compromise investigation; Cybersecurity Dive on the Infosys McCamish Systems incident.