India is about to legislate on personal data, and the part of the debate that will cost multinationals money is not the rights chapter. It is localisation. India's data protection bill, drafted from the expert committee report and expected before parliament in the coming weeks, arrives in a country that has already shown it is willing to mandate where data physically sits: the central bank instructed payment system operators last year to store payments data in India only, and gave them six months to comply. Card networks argued, complied, and built local infrastructure. That precedent is the best guide to what is coming. For any organisation with Indian customers, Indian employees or an Indian delivery centre, the practical question is not whether privacy obligations tighten. It is whether your single global instance of anything survives.
Three different things called localisation
The term covers arrangements with wildly different costs, and conflating them is how budgets get set wrong. Mirror copy. Keep a copy in India, process wherever you like. The cheapest form, essentially a replication and storage cost, and the version most global companies can absorb without redesigning anything. Local-only storage. The data lives in India and nowhere else, which is what the payments directive required. This breaks global consolidation, global analytics and global reporting, and it is where architecture stops being negotiable. Processing restrictions. Certain categories may not leave the country at all, even transiently, which reaches into remote administration, support access, backup design and disaster recovery. The committee draft's treatment of critical and sensitive personal data pointed in this direction, and it is the provision to read most carefully when the text is published. The expected structure, based on the draft, is a tiered one: general personal data transferable subject to safeguards, sensitive categories transferable but with a copy retained in India, and a critical category defined later by government that cannot leave. A category defined later by regulation is a planning problem, because you cannot design around a list that does not exist yet.
| Arrangement | Architecture question |
|---|---|
| Mirror copy | Where is the retained copy, and what processing or transfer is permitted? |
| Local-only storage | Which primary, backup and recovery copies must stay within the required location? |
| Processing restriction | Do remote administration, support and transient processing cross a restricted boundary? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What this costs, and where
The servers are the least of it. India has ample commercial hosting and every major cloud provider has Indian capacity, so the infrastructure line is real but modest. The expensive consequences are architectural. A global enterprise resource planning instance with Indian entity data in it becomes a question. Consolidated group reporting from a single warehouse becomes a question. A global customer platform with one identity store becomes a question. The answer is usually a split instance plus an aggregation layer that moves only what is permitted, and the cost of that is measured in integration work, reconciliation effort and permanent additional operational complexity, not in hardware. The second expense is people and access. If processing restrictions bite, then remote support from a team outside India, administrator access from a global operations centre, and even a vendor's diagnostic session may become transfers. Organisations that have centralised system administration globally, which is nearly all of them, will find that the access model is harder to fix than the data location.
Build for the invariants, not the draft
The bill will change between now and enactment, and again in the rules made under it. Building a compliance programme against a draft is wasted work. Building against the parts that appear in every modern privacy regime is not. Those invariants are: knowing what personal data you hold and where it flows; recording why you hold each category and under what basis; being able to respond to individuals exercising rights; having a breach notification process that works to a deadline; applying retention rules rather than keeping everything; and holding contracts with processors that say what they may do. Every one of those is required under the European regime, appears in the Indian draft, and will appear in whatever the region legislates next. None of it is wasted regardless of how the text lands. The one India-specific decision worth making early is the instance question, because it has a long lead time and it determines everything downstream.
Practical Guidance for an India Compliance Assessment
- Map the Indian personal data you actually hold. Customers, employees, contractors, dependents, applicants. Where it is created, where it is stored, where it is processed, who can reach it. Most organisations find flows nobody documented.
- Separate the mandates that already exist from the ones that are pending. Payments data localisation is live law with a compliance history. Treat it as a present obligation and the general regime as planning.
- Decide the instance strategy now. Single global instance with a mirrored copy, or a separate Indian instance with controlled aggregation. Price both, including the ongoing reconciliation cost, and take the decision at board level because it is not reversible cheaply.
- Audit remote access, not just storage. Who administers Indian systems from outside India, which vendors hold support credentials, and where backups and recovery copies land.
- Fix the contract chain with your Indian delivery partners. Who is the accountable entity, who is the processor, what sub-processors exist, and what happens to data on exit. Long-standing offshore arrangements frequently have none of this written down.
- Build the invariants regardless of the final text. Inventory, purpose records, rights response, breach process, retention schedule, processor contracts. This work survives every version of the bill.
- Watch the critical data category specifically. It will be defined by government notification rather than statute, which means it can expand without new legislation. Assign someone to track it.
- Model the cost of a worst-case reading before you need to. If nothing may leave India, what breaks, what would it cost, and how long would it take. A costed answer converts a legislative risk into a board decision.
The Regional Angle
The Gulf has more exposure to Indian data law than almost any market outside India itself, and in two directions at once. The first is employment. A very large share of the regional private sector workforce is Indian, and their personal data is not confined to the Gulf. Payroll and human resources processing is frequently performed by Indian-owned service providers or by group shared service centres in Bangalore, Chennai, Kochi or Pune. Recruitment pipelines run through Indian agencies. Dependent and family records, education certificates for visa attestation, medical records for insurance, and remittance details all move between the two regions routinely. A regional employer that thinks of itself as having no Indian footprint may be processing the personal data of thousands of Indian nationals through Indian intermediaries, which is precisely the configuration the new regime is designed to reach. The second direction is the one that surprises boards. A great many Gulf companies have their core systems built, hosted, administered or supported from India. The integrator is Indian, the application management team is in Hyderabad, the development environment containing production data copies sits on Indian infrastructure, and the disaster recovery site is sometimes there too. If Indian law imposes obligations on data processed within India, then Gulf customer and employee data acquires an Indian legal dimension that nobody chose. Regional organisations should establish, in writing, where their systems are actually operated from and whether production data is present in Indian development or support environments. In my experience the second answer is yes more often than the technology team believes. There is also a commercial dimension for regional service firms. Providers selling into India, and there are more regional financial, logistics and retail groups doing so every year, will inherit both the localisation requirement and the accountability structure. A Gulf-hosted platform serving Indian customers may need Indian infrastructure, which changes the economics of a regional hub model that was built on serving many countries from one place. Finally, the timing coincidence is useful. Several Gulf jurisdictions are drafting or revising their own data protection regimes, and the free zone regimes in the Emirates already operate European-style rules. An organisation that builds the invariant capabilities once, with data mapped by jurisdiction rather than by system, can satisfy an Indian regime, a Gulf regime and a European one from the same foundation. Organisations that run a separate project per country end up with three inconsistent inventories and no ability to answer a simple question about where anything is.
The objection worth taking seriously
The standard objection is that localisation does nothing for privacy. Where data sits has no bearing on whether it is held lawfully, minimised, secured or deleted; a poorly run Indian data centre protects an Indian citizen less than a well-run one elsewhere. Localisation does, however, ensure that domestic law enforcement can reach the data, support a domestic hosting industry and give the state leverage over foreign platforms. Critics read the policy as industrial and surveillance strategy wearing privacy clothing, and they are not being cynical: the payments directive was justified largely in terms of supervisory access. The second objection concerns exemptions. A regime that grants the state broad latitude to process personal data for sovereign functions while imposing strict obligations on private companies is not obviously a privacy regime at all, and the draft's approach to government access drew sustained criticism from exactly the people who campaigned for privacy protection in the first place. Both criticisms are well founded, and neither changes what an organisation should do. Localisation being poor privacy policy is an argument to make in a consultation, not a compliance strategy; the payments precedent shows that companies which argued the policy was misguided still built the local infrastructure, on the regulator's timetable, at a cost inflated by the delay. The state exemption point is more uncomfortable, because it means the burden falls asymmetrically on private actors while the largest processor in the country carries the lightest obligations. The practical response is the same as the answer to the first objection: do the work that is useful under any regime, which is knowing what you hold and where it goes, and treat the location rules as an architecture question with a price rather than a principle to be defended.
Common Questions
Do we need Indian infrastructure now?
If you handle payments data, yes, and that has been true since last year. For everything else, not yet, but the instance decision has a long lead time and should be priced now.
Will European compliance work carry over?
Substantially. The accountability structure, rights machinery, breach process and processor contracts translate well. Localisation and the critical data category have no European equivalent and need separate treatment.
Does this affect our Indian delivery centre?
Almost certainly, in the access and contract layers before the storage layer. Establish who is accountable, what the centre may do with data, and whether production data exists in support and development environments.
What should we expect over the next twelve months?
Expect the bill to reach parliament shortly and to be referred for committee scrutiny rather than passed quickly, which buys planning time but not certainty. Expect sectoral regulators to keep issuing their own localisation directives ahead of the general law, as the central bank did. Expect a supervisory authority to be established with rules to follow later. And expect trade friction over localisation to continue, which is a reason to watch the final text closely rather than to assume it will soften.
India Compliance Assessment — we map where your Indian data actually lives and who reaches it from where, then price the instance decision before a regulator sets your timetable.