Cross-Border Data Transfers under the DPDP Act: India Decision Guide

An Indian enterprise is renewing its global CRM and HR platform contracts. The vendor promises an India hosting region, but disaster-recovery copies may sit overseas, engineers in another country can open support tickets, and product telemetry feeds a global analytics service. Legal asks whether Section 16 permits the arrangement. Security wants evidence of access controls. Procurement wants to know whether an India-only commitment is necessary. The cloud team warns that changing regions could disrupt operations and increase cost.

The answer cannot be reduced to either “DPDP requires localisation” or “global SaaS is permitted.” Section 16 creates a mechanism for the Central Government to restrict transfers to notified destinations. Rule 15 adds a mechanism for requirements concerning availability to foreign States and related entities. Other Indian laws may impose stricter rules for particular systems or data, while the ordinary DPDP duties of the Data Fiduciary continue to apply.

That makes cross-border governance a business-continuity and accountability issue, not merely a privacy-policy exercise. An unsupported localisation promise can be as problematic as overlooking an applicable storage restriction. A sound review identifies the real technical flows, tests each relevant legal overlay, allocates vendor risk and records why the arrangement was accepted.

Section 16 of the Digital Personal Data Protection Act, 2023 authorises the Central Government, by notification, to restrict a Data Fiduciary from transferring personal data for processing to a specified country or territory outside India. The structure is commonly described as a negative-list model: the Act does not begin with a list of approved destinations that must be satisfied before every transfer.^[1]

Rule 15 of the Digital Personal Data Protection Rules, 2025 provides that an overseas transfer is subject to requirements the Central Government may specify by general or special order concerning the making of personal data available to a foreign State, an agency of that State, or a person or entity under its control. Rule 15 does not itself prohibit every instance of foreign-government availability. It creates a route for more specific requirements, so ownership, control, recipient identity and government-access pathways may become material to the assessment.^[2]

This differs from an adequacy or whitelist system in which transfers depend on an approved destination or prescribed transfer mechanism. The notified DPDP framework does not establish adequacy decisions or require standard contractual clauses as a statutory transfer gateway, and it does not impose blanket localisation on all personal data. Transfers are still constrained: Section 16 notifications, Rule 15 orders, the Data Fiduciary’s other DPDP duties and stricter Indian laws must all be considered.^[5][6]

Section 16(2) expressly preserves laws that provide a higher degree of protection or restriction on transfer, so a permissive DPDP default cannot override a sectoral or activity-specific localisation duty. The commencement structure notified with the 2025 framework phases key provisions over an 18‑month period, so Section 16 and Rule 15 are expected to become operative around 13 May 2027, although the exact legal position should be checked against the latest Gazette notifications. As of August 2026, the materials reviewed for this guide did not identify an official named-country negative list, but that status requires continuing verification. Section 17 also contains fact-specific exemptions, including certain processing for legal claims and processing in India of non-Indian Data Principals’ data under a qualifying foreign contract; these provisions are unlikely to resolve routine transfers of Indian customer or employee data without a careful fit analysis.^[1][3][4]

A useful technical review follows the data rather than the vendor’s marketing description. Start with every place personal data is stored, replicated, viewed, queried, routed or disclosed. An India-based primary database does not settle the question if a backup is written to an overseas region, a global service indexes the records, or personnel abroad can retrieve identifiable information.

Hosting patterns require inspection beyond the selected cloud region. Backups, disaster-recovery environments, content-delivery systems, message queues, encryption-key services and vendor-operated monitoring may use different locations. Even where overseas data is encrypted, the assessment should establish whether it remains personal data in the circumstances, who holds the keys and whether the service can restore or otherwise access it.

Human and machine access can be equally important. Remote administrators may view production records from abroad; support tickets may contain screenshots and account details; security logs may include IP addresses, user identifiers or authentication events; and telemetry may be joined with customer or employee profiles. A restricted production console does not prevent a transfer if an incident export or diagnostic package leaves India through another channel.

AI services add further paths. Prompts, uploaded documents, retrieved context, outputs, safety logs and human review queues may be processed in different locations. The same analysis applies to group-company sharing and offshore service centres. A structured data map helps make these flows visible.

A global CRM or HR platform may process Indian personal data in a foreign region without being prohibited by Section 16 merely because the region is overseas. The assessment still needs to confirm DPDP scope, the purpose and basis for processing, required notices, security safeguards, processor arrangements, retention controls and support for Data Principal rights. For employee systems, payroll integrations, background-check providers and global reporting layers may create additional transfers beyond the core platform.

Productivity suites and collaboration tools often combine customer-selected storage with global account administration, threat detection and support operations. Observability services may receive application logs from many systems, while AI tools can ingest prompts or documents through browser extensions and developer interfaces that procurement never reviewed. These ancillary flows need their own classification rather than inheriting the approval given to the primary service. For each cloud or SaaS service, verification should cover both technical configuration and contractual commitments.

A future Section 16 notification could change the analysis for a destination used by the vendor or a sub-processor. The response may involve disabling overseas support, changing regions, separating affected workloads or replacing the service. Contracts and architecture should therefore provide enough visibility and portability to respond without assuming that every future restriction will include a long transition period.

Section 16(2) prevents the DPDP transfer framework from displacing stricter Indian law. Before relying on the negative-list default, identify the regulated entity, activity, system and data set involved. The decisive question is not whether the organisation operates in a broadly regulated industry, but whether a particular requirement applies to the proposed processing and what that requirement says about storage, copies, access or transfer.^[1]

The Reserve Bank of India’s 2018 payment-system data circular requires payment system providers within its scope to store the entire data relating to payment systems operated by them in systems located only in India. Cross-border transactions and later regulatory clarifications require careful treatment, so the circular should not be converted into an unqualified rule for every financial data set or every service used by a financial institution. Payment architects should identify the transaction records, system boundaries and overseas components covered by the applicable RBI materials.^[7]

The CERT-In Directions require covered entities to maintain ICT system logs securely for 180 days within Indian jurisdiction, alongside separate cyber-incident reporting obligations. An overseas observability platform may therefore need an India-retained log set, even if overseas processing is otherwise available. The location requirement should be assessed against the precise logs and entities in scope; it does not automatically answer whether additional copies or access are permitted.^[8]

The DPDP Rules also contemplate restrictions for personal data specified in relation to a Significant Data Fiduciary, including associated traffic data, where the Central Government acts through the prescribed process. Organisations should monitor whether they are designated and whether specified categories become subject to transfer restrictions. For every overlay, retain an applicability memorandum identifying the authoritative instrument, covered activity, affected data, required location, exceptions or qualifications, control owner and date of the latest verification.^[2]

A vendor contract does not create legal permission where a regulation prohibits a transfer, but it determines whether the organisation can verify performance and respond when circumstances change. The agreement should define approved processing and access locations, distinguish primary hosting from backups and support, and prevent unannounced movement to a new region where location is material. Any promise should be enforceable in the contractual hierarchy rather than left in changeable marketing material.

Sub-processor provisions should provide a usable list of entities, services and processing countries, together with notice of changes, appropriate objection or remediation rights, and flow-down of relevant safeguards. Security terms should address access control, encryption, vulnerability management, audit evidence and incident cooperation. Reporting deadlines should give the Data Fiduciary enough time and information to meet its own obligations without inventing a universal contractual period that may not fit every incident or applicable law.

Government-access terms deserve separate treatment. Ask how the vendor authenticates demands, narrows disclosure, challenges requests where lawful, records emergency access and notifies the customer where legally permitted. Establish whether any sub-processor is controlled by a foreign State or its agency and whether the architecture can isolate data if a Rule 15 order imposes a relevant condition. A general statement that the vendor “complies with law” is not a substitute for an operational response process.

Exit provisions should cover export format, migration assistance, production deletion, backup expiry and deletion confirmation. The organisation also needs a record of what was agreed and what evidence supports ongoing decisions.

Translating these elements into a repeatable process reduces the chance that each new vendor or project restarts the localisation debate from scratch.

Maintain a transfer register linked to the organisation’s data inventory, vendor register and architecture records. Each entry should identify the business purpose, systems, data categories, destination and access countries, recipients, applicable legal overlays, contract controls, evidence location, accountable owner and next review date. Record the date on which Gazette notifications and regulator materials were checked so that a later reviewer can understand the basis of the decision.

Monitoring should cover Central Government notifications under Section 16, orders under Rule 15, Significant Data Fiduciary developments, relevant sector-regulator circulars and changes to vendor regions or subprocessors. Procurement should trigger reassessment on renewal or material service change. Engineering and security should trigger it when enabling a new region, integration, logging destination, AI feature or overseas support model.

Internal communication should correct both common myths. “All personal data must stay in India” ignores the negative-list structure and fact-specific overlays. “Everything can remain overseas until a list appears” ignores existing sectoral requirements, the rest of DPDP, Rule 15 developments and contractual limitations. Product descriptions, RFP answers and privacy notices should use claims that match the verified architecture rather than broad statements such as “fully localised” or “no data ever leaves India.”

Board, audit and customer reporting should separate three questions. Regulatory compliance concerns what binding instruments require. Contract risk concerns whether vendors must deliver the controls and remedies the organisation expects. Claim substantiation concerns whether external statements can be supported by current evidence. Keeping these analyses distinct makes remediation more targeted and reduces the risk of expensive migration driven by an overbroad assumption.