Cross-border data transfers under DPDPA and Indian sectoral rules — a 2026 reference

ControlForge free guide · 2026-05-24 · Synthesis of DPDPA Section 16, Rule 14, and the sectoral data-localisation overlays from RBI, SEBI, IRDAI, MeitY, and UIDAI

Quick reference

The problem in one line: India does not have a single cross-border data transfer regime. DPDPA's negative-list approach sits over a patchwork of sectoral data-localisation rules that are independently binding, often stricter, and not displaced by DPDPA. Compliance means navigating all layers at once.
The five layers most likely to apply concurrently:
DPDPA Section 16 + Rule 14 — negative-list approach (in force from 13 May 2027 for full operation; some elements live earlier).
RBI payment data localisation (April 2018 + 2021 storage clarifications) — payment system data must be stored only in India.
IRDAI 2023 Guidelines — 180-day log retention within Indian jurisdiction.
SEBI Cloud Framework — data residency in India in MeitY-empanelled CSP data centres.
Aadhaar Act + UIDAI regulations — Aadhaar data restrictions including authentication and KYC handling.
The "stricter clause wins" principle (DPDPA Section 38) — sectoral rules that are stricter than DPDPA are not displaced by DPDPA.
Audience: DPOs, CISOs, Cloud architects, Privacy Counsel, Heads of Cloud Operations, multi-jurisdiction product leaders.
ControlForge density: 25+ controls across cl-cross-border-transfer, cl-data-residency, cl-data-classification, and cl-cloud-shared-responsibility; cross-walked with GDPR Chapter V, sectoral Indian rules, and global cloud frameworks.

Why India's cross-border regime is uniquely complex

Three structural features make India's approach to cross-border data transfers harder to operationalise than the equivalent regimes in EU, UK, US, or major APAC jurisdictions.

First, the regime is layered, not unified. GDPR uses a Chapter V architecture: adequacy decisions, Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), Article 49 derogations. The choice of mechanism is well-defined; the data-transfer obligation is the same regardless of sector. India's regime is the opposite. DPDPA Section 16 + Rule 14 establishes a negative-list approach — transfers are permitted unless the Central Government has notified specific countries / territories / classes of Data Fiduciaries to which transfers are restricted. Layered on top are sectoral data-localisation rules that often require specific data categories to be stored or processed within India regardless of DPDPA. The sectoral rules are independently binding; DPDPA Section 38 explicitly preserves stricter sectoral protections.

Second, the negative-list approach is operationally novel. Most cross-border regimes (GDPR, UK, Switzerland, Japan, Korea, Singapore) use a positive-permission model: identify the mechanism that permits the transfer (adequacy, SCCs, BCRs, etc.), document it, transfer. India's model says: transfer is permitted by default, but the Central Government may restrict transfers to specific destinations or specific data categories on national-security, sovereign, or strategic grounds. Operationally this means a Data Fiduciary needs to monitor government notifications under Rule 14, not seek positive approval for transfers.

Third, the sectoral rules pre-date DPDPA and operate on different lexicons. RBI's payment data localisation (April 2018, clarified 2021) requires "payment system data" to be stored only in India. IRDAI requires 180-day log retention in India. SEBI Cloud requires data residency in MeitY-empanelled India regions. UIDAI restricts Aadhaar information cross-border. Each rule uses a different definition of "data" and a different "in India" test (storage only, storage + processing, processing only). Mapping a given data flow to all applicable layers takes structured analysis, not pattern recognition.

The net effect: a typical Indian regulated entity in 2026 needs an architected data-flow inventory showing every data category, every flow across the entity boundary, every destination, and every applicable rule layer — and an active programme to update the inventory on data-architecture changes.

The DPDPA Section 16 + Rule 14 layer — what it actually requires

DPDPA Section 16 reads:

The Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified.

Rule 14 (in the final DPDP Rules notified 13 November 2025) operationalises this. The key features:

Permissive default: cross-border processor flows are permitted unless restricted.
Restriction mechanism: Central Government may notify specific countries, territories, or classes of Data Fiduciaries to whom transfers are restricted.
No standardised contract mechanism required: unlike GDPR SCCs, DPDPA does not mandate a specific contract form for cross-border transfers. The Data Fiduciary's general Section 8(5) contract with the Data Processor covers cross-border arrangements as well.
No general restriction on "transfer for processing": the cross-border test is on transfer to the country, not on routing through it. Transit through a foreign cloud region without processing in that region is not a restricted transfer.

Current status (mid-2026): the Central Government has not yet issued Section 16 restriction notifications. The negative list is presently empty. This is expected to change: industry consultation and government strategic-data discussions have signalled that specific data categories or specific destinations may face restrictions, particularly:

Strategic government-adjacent data including critical infrastructure data, defence-relevant data, and certain geospatial data.
Specific destinations where political or sovereign concerns warrant restrictions.
Data of designated Significant Data Fiduciaries processing high-volume sensitive personal data.

The operational implication: Data Fiduciaries should prepare to monitor and react to Section 16 notifications rather than assume the negative list will remain empty. Notification can be specific to data category, destination, or Data Fiduciary class — meaning a Data Fiduciary may be affected without changing its own posture.

Significant Data Fiduciary (SDF) overlay: DPDPA Section 10 contemplates classification of certain Data Fiduciaries as SDFs, subject to enhanced obligations including (per Rule 12) data localisation requirements that the Central Government may specify. Designated SDFs may face additional restrictions on cross-border transfers beyond the general Section 16 negative list.

The RBI payment data localisation layer

The longest-standing and most prescriptive Indian data-localisation rule is RBI's April 2018 directive on Payment System Data, clarified through subsequent FAQs and the consolidated Master Direction on Cyber Resilience and Digital Payment Security Controls (July 2024).

The core requirement: payment system data shall be stored only in India. The "only" is strict — not "primarily" or "with backup elsewhere". Data must reside within Indian jurisdiction.

What constitutes "payment system data": end-to-end transaction details including: - Customer information (identity, contact, account details). - Payment-sensitive information (card numbers, account numbers, beneficiary details). - Transaction details (time, amount, destination, instruments). - Authentication and authorisation data. - Network and intermediary data.

Processing abroad — the carve-out: data may be processed abroad if needed for the transaction (e.g., for cross-border card transactions where the foreign network must process the authorisation). However, the only copy of the data must be in India after processing completes. Foreign-processed data must be deleted from foreign storage within a defined window.

Applies to: all payment system operators (PSOs) including banks, non-bank payment system operators, card networks, payment aggregators, payment gateways, prepaid payment instrument issuers.

Operational implications: - Cloud architectures for payment systems must be India-region-only. - Foreign cloud regions are not permitted for primary storage. - Backup, DR, analytics, AI/ML processing of payment data must all be in India. - Foreign vendors providing services to PSOs must architect their service such that no payment data persists abroad.

Inspection pattern: RBI inspections have actively examined PSO architecture for compliance since 2019. Non-compliant arrangements have led to operational restrictions (no new customer onboarding until compliance restored) on multiple PSOs.

The IRDAI 180-day log retention layer

IRDAI's Information and Cyber Security Guidelines 2023 require Regulated Entities (insurers, FRBs, intermediaries) to maintain logs of all ICT systems for a rolling period of 180 days within Indian jurisdiction.

What this covers: - System logs (OS, database, application). - Security logs (SIEM, EDR, network monitoring). - Access logs (authentication, authorisation, privileged access). - Transaction logs covering policyholder interactions.

The "Indian jurisdiction" test: log storage in cloud regions located in India, with India-jurisdiction governing law over the storage arrangement. Cloud regions outside India do not satisfy the test even if the cloud provider is subject to Indian law in some respects.

Operational implications: - Default cloud log destinations (typical SaaS analytics platforms, observability tools) often route logs to US or EU regions; this fails IRDAI compliance. - SIEM and security analytics architectures need India-region log stores. - Long-term log archive beyond 180 days can be in other regions if appropriately structured; the 180-day rolling window is the hard constraint.

Common compliance gap: insurers and intermediaries adopting cloud-native observability stacks (Datadog, Splunk Cloud, New Relic, etc.) with default routing to non-India regions. Remediation requires region selection and configuration review.

The SEBI cloud data residency layer

SEBI's Framework for Adoption of Cloud Services (March 2023) requires data storage and processing in MeitY-empanelled CSP data centres located in India, with limited exceptions for backup or DR data subject to documented justification.

The MeitY empanelment criterion is structural — major hyperscaler regions in India (AWS Mumbai, Azure India, Google Cloud Mumbai, Oracle Cloud Mumbai) are MeitY-empanelled for relevant service tiers, but the empanelment applies to specific regions and service tiers, not the entire CSP. Default region selection without verification is a common failure.

Operational implications: - Customer data, transaction data, regulatory data of SEBI REs must reside in MeitY-empanelled India regions. - Backup may be replicated outside India where documented and Board-approved. - DR may reside in non-India regions subject to risk assessment and explicit approval. - Analytics, monitoring, and ancillary services often default to non-India regions; explicit configuration required.

Applies to: SEBI REs adopting public, community, or hybrid cloud. Private cloud follows general SEBI cybersecurity (CSCRF) and outsourcing circulars.

The Aadhaar / UIDAI layer

The Aadhaar Act 2016 + Aadhaar (Authentication and Offline Verification) Regulations 2021 restrict cross-border handling of Aadhaar information. Specifically:

Authentication data and biometric data: must be processed within UIDAI's CIDR (Central Identities Data Repository) infrastructure, which is in India.
e-KYC and AUA / KUA arrangements: governed by UIDAI regulations including specific data-handling, storage, and audit requirements.
Aadhaar number storage: subject to virtual Aadhaar ID and tokenised handling provisions; full Aadhaar number storage is restricted.

Operational implications for entities engaging UIDAI authentication or e-KYC: - The authentication transaction itself happens with UIDAI infrastructure (in India). - The entity must store the Aadhaar-related data (authentication response, e-KYC data) per UIDAI regulations, which typically constrain cross-border storage. - Cross-border transfer of Aadhaar data even within affiliated group entities requires specific compliance analysis.

Sectoral examples: banks (AUA / KUA for KYC), fintechs (e-KYC), insurance intermediaries (KYC), and various government-facing entities all interact with Aadhaar infrastructure under these constraints.

How the layers interact — a worked example

Consider a mid-sized Indian fintech offering digital lending. The data flows:

Customer signup: collects identity data, contact, e-KYC, bank account, employment.
Underwriting: pulls credit bureau report (India), runs ML-based credit scoring (currently using a SaaS vendor with US-region default).
Disbursement: through a partner bank; payment data flows through.
Servicing: customer interactions via app, email, call centre.
Analytics: behavioural analytics via a SaaS tool (US-region default).
CRM: customer relationship management via a SaaS tool with India-region option.

Applicable layers: - DPDPA Section 16 / Rule 14: applies to all personal data flows. Currently no notified restrictions; monitor for changes. - RBI Digital Lending Directions 2025: data residency expectations for borrower data within Indian jurisdiction. - RBI payment data localisation: payment-flow data must reside only in India. - IRDAI 2023: not applicable (fintech is RBI-regulated, not IRDAI). - SEBI Cloud Framework: not applicable (fintech is not SEBI-regulated). - Aadhaar Act + UIDAI regulations: applies to the e-KYC component; Aadhaar-related data subject to UIDAI constraints.

Required architecture changes from the existing flow: - Move ML-based credit scoring to India region (or to an on-prem deployment) — RBI Digital Lending + DPDPA + payment data localisation overlap. - Move analytics SaaS to India region or to in-house India-resident analytics. - Verify CRM India-region selection. - Audit e-KYC data flow for UIDAI compliance. - Document the architecture decisions for inspection.

This is a common pattern in 2026 Indian fintech: legacy SaaS adoption from 2019–22 routed data to default (foreign) cloud regions; the current regulatory stack now requires re-architecting many of those flows.

The contract layer — DPDPA Section 8(5) for cross-border processors

When the Data Fiduciary engages a cross-border Data Processor, DPDPA Section 8(5) requires a valid contract. The cross-border element adds requirements beyond the domestic processor contract:

Identification of processing location(s): every country / region where the Processor operates.
Sub-processor flow-down with location disclosure: sub-processors' processing locations must be transparent.
Compliance commitment with Indian sectoral rules where applicable: payment data localisation for PSOs, etc.
Audit rights extending to cross-border facilities.
Cooperation with Indian regulators including DPBI and sectoral.
Data return and destruction with India-jurisdiction certification on contract termination.
Indemnification for breaches arising from cross-border processing.

For multinational Data Fiduciaries operating in India, the contract layer often layers on top of existing GDPR SCCs or other international transfer instruments. The DPDPA Section 8(5) contract is independent — GDPR SCCs do not satisfy DPDPA Section 8(5) on their own, though many of the substantive provisions overlap.

Common pitfalls observed in 2024–26

Six recurring patterns of failure:

1. Default cloud region selection. SaaS adopted with default (foreign) region; data routed there by default; no architecture review for India-applicable rules. Particularly affects log data, analytics, AI/ML processing.

2. Sectoral rule treated as displaced by DPDPA. Misunderstanding of DPDPA Section 38 (conflict-of-laws preservation). Sectoral data-localisation rules continue to apply; DPDPA does not displace them.

3. Backup and DR routed outside India without documentation. Common with cloud-native architectures where DR defaults to a different geographic region for resilience. SEBI / RBI / IRDAI all require documented justification for any non-India backup or DR.

4. Ancillary services unmapped. Primary database is in India; logs, observability, analytics, ML training, CRM, marketing automation are scattered across non-India regions. The ancillary services were not in the data-flow inventory.

5. Sub-processor location drift. The primary CSP is in India; the CSP's sub-processors (third-party data providers, AI components, monitoring services) are outside India. Sub-processor location was not part of the original due diligence.

6. Aadhaar handling without UIDAI-specific review. Entities engaging with Aadhaar (directly or via Account Aggregator / e-KYC providers) frequently treat Aadhaar data under general DPDPA/sectoral rules rather than the specific UIDAI regulatory layer.

Two further patterns specific to 2026:

7. SDF-anticipating localisation gap. Data Fiduciaries likely to be designated as Significant Data Fiduciaries have not assessed their cross-border posture against the additional restrictions Rule 12 may impose. Designation comes with limited runway; non-compliant architectures face rapid retrofit pressure.

8. AI / ML model training abroad without consent disclosure. Training data flows to a foreign region for model training, then the trained model is brought back to India for inference. The data "leaves" India for training and is processed for a purpose not disclosed in the original notice. Both cross-border and consent dimensions implicated.

What good looks like — the mature 2026 cross-border posture

A mature Indian Data Fiduciary's cross-border data programme has these structural properties:

Data flow inventory that maps every data category, every flow across the entity boundary (including ancillary services and sub-processors), every destination region, and every applicable rule layer. The inventory is maintained, not snapshot-once; data-architecture changes trigger inventory review.

Layered compliance matrix showing which rules apply per data category — DPDPA + RBI (where applicable) + SEBI (where applicable) + IRDAI (where applicable) + UIDAI (where applicable) + sectoral-specific.

Architecture standards that default to India-region for in-scope data, with documented exception process for any deviation. Sub-processor and ancillary-service region selection is part of the standard, not an afterthought.

Cross-border contracts that satisfy DPDPA Section 8(5) plus the applicable sectoral overlays, with location disclosure, sub-processor flow-down, and Indian-regulator cooperation clauses.

Monitoring of Section 16 notifications: a process to detect Central Government notifications restricting transfers, with the ability to react within the notice period.

SDF readiness for entities likely to be designated: pre-positioning of localisation architecture, DPO appointment, independent audit relationships.

Annual cross-border posture review at Board / Audit Committee with quantitative metrics (number of cross-border flows, regulatory coverage, exception register).

This represents a substantial change from the 2018-era "we use major US clouds because they're best-in-class" architecture that many Indian organisations still operate. The transition requires architectural investment and is not a documentation-only exercise.

How ControlForge supports this

The cross-border-data area has high cross-reference density in the KB:

cl-cross-border-transfer — the core synthesis cluster.
cl-data-residency — operational residency controls.
cl-data-classification — the input layer; identifies which categories trigger which rules.
cl-cloud-shared-responsibility — cloud-specific cross-border treatment.
cl-data-processing-agreement — DPDPA Section 8(5) contract layer.
cl-sub-processor-management — sub-processor visibility and approval.

The synthesis surfaces the strictest-clause across DPDPA + RBI + SEBI + IRDAI + UIDAI + GDPR Chapter V + Japan APPI + Singapore PDPA + other major APAC regimes. For Indian Data Fiduciaries with international operations, the multi-jurisdiction synthesis allows a single compliance posture to satisfy overlapping obligations.

A 60-day cross-border posture uplift

For Indian regulated entities recognising the gap:

Days 1–20: Inventory and gap analysis. - Build / refresh the data flow inventory covering primary data, backups, logs, analytics, ML training, ancillary SaaS. - Identify the destination region for each flow. - Map the applicable rule layers per flow.

Days 21–40: Architecture remediation prioritisation. - For each flow with a compliance gap, assess remediation effort and risk. - Prioritise: payment data, regulated-sector primary data, log retention, then analytics and ancillary. - Begin remediation on the top 5 highest-risk gaps.

Days 41–60: Contract refresh and process establishment. - Refresh DPDPA Section 8(5) contracts for cross-border processors. - Establish the monitoring process for Section 16 notifications. - Document the architecture standards. - Brief Board / Audit Committee on the cross-border posture.

By day 60, the structural framework should be in place with the highest-risk gaps in remediation. Medium-term work (full architecture remediation, SDF readiness, sub-processor inventory completion) extends from there.