Chapter 18 — Transfers, Cloud and Enterprise Reference Architecture

1. The geography of law: where data is allowed to be

Most of this book has answered what may be processed — on which ground, under which safeguard, for how long. This chapter answers a question that every cloud purchase, every offshore analytics vendor, every multinational data flow raises, and that is easy to get wrong precisely because the answer is not a single clean rule: where may the data be processed, and may any of it cross India’s border?

One tempting simplification is to assume DPDP forces all personal data to remain inside India. That instinct is convenient: it converts a hard mapping problem into a simple geographic rule. But it is wrong, and building a residency policy on a wrong legal premise can cost an organisation real money (needless local hosting) without buying it any real compliance.

The law’s actual structure is subtler, and this chapter’s central task is to make that structure legible enough to build on:

The idea. DPDP does not impose a blanket localization rule. Transfer and residency are mapped legal positions: a current set of country restrictions (Section 16(1)), a preserved transfer-specific saving for higher Indian-law protection/restrictions (Section 16(2)), foreign-State disclosure requirements under Rule 15, conditional SDF/data restrictions under Rule 13(4), and territorial scope under Section 3. The correct posture is to make transfer a documented, attributable, re-verifiable attribute of each data flow — not an assumption, and not a vendor’s “India region = compliant” claim.

It is worth being precise about why the myth is expensive in both directions, because the failure modes of §3 are priced here. The enterprise that over-localises pays twice: once in infrastructure cost, and once in false confidence — believing “everything stays in India” answers the transfer question when it has not even asked the sector question. The enterprise that under-localises pays in the opposite currency: a sector-rule violation that DPDP’s silence concealed. Neither error is cheap, and both are built on the same refusal to map.

2. The law, read carefully

2.1 The restriction is notification-driven (Section 16(1))

Section 16(1) says the Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to any country or territory outside India as may be so notified.

The verb is “may restrict”: the provision does not itself impose a blanket India-only storage rule. But absence of a restriction cannot be asserted merely because a bounded search returned nothing. Q01 retained the current ministry index and refreshed sources on 15 September 2026; its complete date-filtered eGazette search failed. No applicable country restriction is established for the teaching branch, and no exhaustive negative assurance is claimed. ACT:515–517; QL-004.[1]

A new notification must be read for covered data/entities, destination, conditions and its specified effective date. Publication, detection by the compliance team and legal effect are distinct fields; not every instrument is effective immediately on publication. The architecture’s policy version must include that timing, an owner and a tested way to enumerate affected flows. It must also support a restrictive response where a current-law decision cannot be obtained, rather than converting an expired review into permission.

2.2 Sector law can be stricter (Section 16(2))

Section 16(2) preserves any law in India that provides a higher degree of protection for or restriction on the transfer of personal data outside India. This is the clause that makes the picture realistically stricter than the DPDP default for many regulated businesses: a bank, insurer, or telecom may face a transfer restriction from its own regulator that exceeds DPDP’s baseline. For those sectors, “DPDP is not blanket” is legally true but operationally beside the point — the sector rule is the binding constraint.

The classic live example is the payments/data-localisation family of sector instruments (the RBI payments localisation circular is the canonical case — Chapter 5’s register carries it with its citation). An enterprise in a regulated sector therefore runs the transfer analysis across the relevant layers: against Section 16 notifications, Rule 15 orders, any Rule 13(4) SDF/data specification and applicable sector instruments. The binding answer is the stricter of the two, per flow — and the map must record both, because the two regimes move independently: a sector circular can tighten while the DPDP list stands still, and vice versa.

2.3 The extraterritorial reach (Section 3(b))

Section 3(b) keeps the Act’s hand on data processed outside India where that processing is in connection with an activity offering goods or services to principals within India. So “it’s in Singapore so DPDP doesn’t apply” is wrong for a service that offers goods/services to principals within India, not merely people of Indian citizenship. The geography is not a clean “India in, outside out” — it is a mapped web of the three provisions together.

Do not treat Section 3(b) as the only basis for every offshore edge. The Company’s Indian processing is assessed under Section 3(a); its on-behalf relationships and foreign activities require their actual territorial and role facts. Section 3(b) addresses processing outside India connected to an activity related to offering goods/services to principals within India. Neither nationality nor a foreign server alone settles the result. ACT:135–154.[1]

2.4 Rule 15 and the SDF layer

Rule 15 permits transfers subject to requirements the Central Government may specify by general or special order concerning making the data available to a foreign State, or a person/entity under the control of or an agency of such a State. It is not a generic destination-risk score or unspecified transfer-permission threshold. The recipient’s government-access/control exposure and applicable order are separate fields from the region. The earlier unsupported draft-to-final history is not used as legal evidence. RULES:1319–1323.[5]

Rule 13(4) is a separate conditional layer: an SDF must ensure that Government-specified personal data and traffic data pertaining to its flow are not transferred outside India, based on the specified committee process. SDF designation alone does not mean every dataset is specified, and an India-only personal-data rule must not omit its related traffic data. The Company is not designated; a conditional branch cannot invent a notification number. RULES:1287–1293, with “Departments” corrected by CORR:31.[5][6]

The governance side is also settled in the retained English text. Rule 13(1) requires an SDF to undertake a DPIA and audit once in every twelve-month period from notification or inclusion in the notified class. Rule 13(2) requires it to cause the person conducting that work to furnish a report of significant observations to the Board; Rule 13(3) adds due diligence on technical measures including algorithmic software and risk to principals’ rights. This is not a quarterly reporting API or an optional cadence to be discovered later. For ENT-001 it remains voluntary readiness, not a claim of designation or a real filing. RULES:1276–1286.[5]

2.5 Exemptions attach to processing, not architecture labels

Section 17(1)(d) concerns personal data of principals not within India, processed pursuant to a contract with a person outside India by a person based in India. Where its facts hold, Section 17(1) disapplies Chapter II except Section 8(1)/(5), Chapter III and Section 16 for that qualifying processing. It does not make the whole exporter exempt: own billing, Indian users and unrelated analytics need separate decisions. CASE-104/ENT-104 is the counterfactual used here, not a new business line silently added to the Company. ACT:523–536.[1]

The Section 17(2)(b) research/archiving/statistics exemption requires necessity, no decision specific to a principal, and prescribed standards; Rule 16 and the Second Schedule supply that standards layer. A warehouse, training label or “aggregate risk score” does not automatically meet it, especially if the output is used for individual lending decisions. Other Section 17 limbs and notification-based exemptions must be checked against Chapter 3’s complete applicability matrix. No exemption is established for the Company’s base FLOW-005. ACT:564–570; RULES:1324–1326,1554–1595.[1][5]

3. The tension: distributed-architecture convenience versus a layered legal map

The tension here is between two legitimate pulls, and holding it well is what separates a defensible residency posture from a wish.

The convenience pull. Enterprises want the efficiency of a distributed cloud estate — the region that is cheapest, the latency-optimal location, the overseas analytics vendor, the group entity that centralises data. Global-architecture convenience argues strongly for letting geography follow engineering.

The legal pull. But where data may be processed is a layered legal question: the DPDP default (not blanket, but notification- and conditions-driven), the sector higher-protection rule (possibly stricter, Section 16(2)), and the extraterritorial reach (Section 3(b)). Geography cannot follow engineering alone; it must follow that map.

The failure modes sit on either pole, and both are worth naming because both are common:

• The blanket-localization failure. Refusing any foreign processing on a misreading of DPDP. Cost added for no legal reason; and worse, it can create false confidence — an organisation that thinks “everything stays in India so we are done” has answered the wrong question if a sector rule or a legitimate-use pattern actually permits a foreign location. The false-confidence cost is the hidden one: the budget spent on needless local hosting is budget not spent on the sector-rule analysis that actually binds.
• The assume-a-free-pass failure. Placing data offshore because “DPDP has no restriction yet,” ignoring both a sector stricter rule (Section 16(2)) and any new notification or Rule 15 condition. This is how a bank quietly violates a sector transfer limit while believing DPDP’s silence meant freedom. The violation is invisible until the sector regulator’s examination — which is precisely when it is most expensive.

The insight. The reconciliation is not a rule; it is a mapping discipline. Transfer and residency become an explicit, documented, attributable attribute of every data flow — carried in the inventory (Chapter 7), reconciled against the current restriction set and any Rule 15 conditions and sector stricter law, and re-verified whenever a notification or sector circular lands. It is the same discipline Chapter 5 applied to sector conflicts: map, don’t flatten. The map’s honesty is measurable: every cross-border flow answers where, on what basis, under which regime’s constraint — or it is not on the map.

4. A completed decision before a region setting

The flow decisions record data, role, source/destination, access/storage/compute locality, applicable instrument checks, owner and outcome. “Unknown” is not “allowed”. All case values below are synthetic; source absence remains bounded by QL-004. Decisions are author recommendations under stipulated facts, not permission to deploy a real NBFC abroad.

FLOW-Q04-014 deliberately uses data about people within India. It does not “prove” non-blanket DPDP merely by sending an unrelated foreign dataset abroad. Its permissive result is conditional on declared current-instrument and sector assumptions; real approval needs evidence replacing each assumption. If any binding restriction applies, block or reroute. Better contract wording cannot override it.

The sector branch needs exact law and entity/data facts. Chapter 5 retains the RBI 2018 payment-system direction and the IT outsourcing direction: the former addresses system providers’ payment-system data; the latter’s storage clause refers to extant requirements as applicable. Neither supports imposing a universal payment-system residency rule on every marketing field of every NBFC. An independently stipulated covered domestic payment-system dataset is stored only in India under the retained direction; the text permits the foreign leg, if any, also to be stored in the foreign country if required. This is not a blanket ban on that specified foreign-leg storage; an unrelated retail support dataset is not automatically subject to it. Current amendments and applicability still need verification before use. The retained RBI texts are research/engineering/evidence/rbi-payment-data-storage-full.md and rbi-it-outsourcing-full.md; source passages and dates are in Q04 PRIMARY_SOURCE_MAPPING.json.[9][10] The Q04 source mapping links the retained sector text; the sector overlay pack supplies bounded mappings, not final real-entity approval.

5. ARCH-001 — a reference architecture with explicit trust boundaries

The complete ARCH-001 specification includes the topology, interfaces, flow outcomes, failure handling and linked populated evidence. The following plain-text diagram is the canonical figure for this chapter; it is an architecture specification, not a deployment diagram exported from a real cloud account.

B0: untrusted clients                     B1: Company controlled services / India
SYS-001 --FLOW-001--> service PEP -------> SYS-002 lending store
                         |                    |      |       |
                         | decision request   |      |       +--FLOW-Q04-012--> SYS-012
                         v                    |      |                          evidence
                    SYS-010 issuer/PDP        |      +--FLOW-003--> SYS-004 --> SYS-005
                    authority + sequence      |                      training STOP
                         |                    |
                         +--FLOW-008--> SYS-013 adapter/outbox --X--> SYS-003
                                           B2 supplier boundary: ENT-004; ACK-001 MISSING
SYS-011 --FLOW-010--> SYS-013
rights: actor != subject

SYS-002 --X FLOW-004--> SYS-008 [B3 foreign backup; existing cohort isolated]
SYS-004 --X FLOW-005--> SYS-009 [B3 foreign analytics; reuse/training STOP]
SYS-008 --FLOW-009--> SYS-014 [B4 restore quarantine]
                           | current frontier + restrictions/tombstones
                           +--reviewed promotion only--> restricted/authorised B1 target
B5: privileged operators -> case-bound access PEP -> allowed resource only
     no direct store, export or foreign-support bypass

An arrow marked X is blocked for new dispatch; it does not claim already transmitted bytes vanished. B2 and B3 are separate legal/operational trust boundaries, even if a vendor hosts in the same cloud. B4 is a network and identity boundary, not merely a staging table. SYS-014 cannot reach production or supplier egress before replay and release checks. B5 exposes the path often omitted from optimistic gateway diagrams: administrators and backup operators have identities and powers that must be separately constrained.

The decision plane contains approved purposes, consent/other authority, subject/purpose sequence, role/territorial/transfer decisions and versioned deployment policy. SYS-010 is a Company tool, not a statutory registered Consent Manager. The enforcement plane contains public-service, job, store and egress policy enforcement points. A purpose string from SYS-001 is never trusted. The data plane contains actual stores/queues/replicas; the evidence plane captures decisions, attempts, provider results and qualifications without retaining unnecessary plaintext payloads.

A minimum proposed message contract binds operation ID, flow, subject, actor/workload, tenant, dataset/action, purpose, authority reference and sequence, policy version, occurrence/receipt time and provenance. Before execution, the consumer authenticates the issuer/workload, checks destination/audience and current authority, and records its decision. Outbox publication and durable target state prevent a failed dispatch from disappearing. Retries reuse an operation identity; duplicate or stale callbacks cannot create a new grant. This is a production specification; the delivered local model exercises selected decisions without implementing cryptographic identity or distributed transactions.

The critical dependencies are explicit. Approval of an individual new flow depends on its inventory/role/purpose and transfer/safeguard evidence. Incident readiness, contact ownership, basic protective restrictions and current-source monitoring start in parallel at EVT-001; they do not wait for a six-month discovery programme. A failure can therefore be contained while the inventory remains incomplete. Unknown surfaces are owned and restricted, not silently excluded from the denominator.

6. Failure modes and the evidence that would clear them

The retention record, security decision, processor schedule and incident pack populate these interfaces with Q01 IDs. They are not four unrelated success stories: the same SUB-001 withdrawal, missing ACK-001 and pre-withdrawal SNAP-001 remain visible across all of them. A locally corrected restore or cache test does not cure an unapproved foreign backup or produce supplier erasure evidence.

Actual cloud controls still require deployment-specific implementation: prevent direct store credentials, restrict backup-region creation, inspect managed-service support/telemetry, test key paths, authenticate callbacks and verify role separation. A region feature documented by a vendor is only a capability claim until its precise service/version/configuration is exercised. This packet makes no AWS/Google deletion or residency guarantee and does not treat one provider’s process as law.

7. Conditional SDF and exporter counterfactuals

In a hypothetical SDF branch, a valid designation plus Government specification of DS-001 and traffic data pertaining to its flow activates the Rule 13(4) restriction. The architecture blocks both the personal payload and related foreign telemetry; it does not label only the main database India-only. The schedule also starts the twelve-month DPIA/audit cycle from the notification/class-inclusion date and requires the significant-observations report. No real notification or Board report is created by this branch. RULES:1276–1293.[5]

In CASE-104, ENT-104 is a person based in India processing foreign customers’ contact records pursuant to a contract with a person outside India; those principals are stipulated not to be within India. That scope may satisfy Section 17(1)(d), preserving Section 8(1)/(5) while disapplying the stated provisions. Move a subject within India or reuse the contacts for the exporter’s own billing/marketing and the team must reassess rather than extend the exemption label to every flow. The conditional result demonstrates an applicability boundary, not a universal exporter waiver. ACT:523–536.[1]

A reader can now exercise two changes. First, add a binding destination restriction to the permitted hypothetical retail support edge: the result becomes block/reroute even if the contract is perfect. Second, remove the exemption facts from the exporter edge: the result becomes ordinary applicability review, not automatic foreign hosting. A useful architecture produces both answers without rewriting every service, while preserving the separate customer/processor responsibilities.

8. Acceptance boundary

ARCH-001 is a completed reference specification with populated decision/evidence links and locally exercised failure/retest logic. It is not infrastructure-as-code, a running gateway, a vendor PoV or a legal certification. Q01’s source-completeness and entity-specific questions remain bounded at point of use; unknown real transfer authority returns restriction/no-go. The later sector/dossier/review phases must supply their assigned evidence rather than treating this local artifact as final Company approval.

The architecture is feasible at the level claimed: every control decision has an issuer, consumer, enforcement location, persistent status, owner and evidence path, and missing dependencies have a defined restricted state. Feasibility in a particular deployment still requires integration and failure testing. Keeping that distinction explicit is more useful than an attractive diagram whose arrows all imply success.

The question that hands the book its next chapter

If a fiduciary’s obligations — and the strictest ones of all, around children and systemic impact — scale with the volume and sensitivity of what it processes, then a particular class of fiduciary carries a materially different burden. That is the subject of Chapter 19, Significant Data Fiduciary Readiness — where designation under Section 10 reshapes governance through a board-facing DPO, an independent auditor, and a periodic DPIA-and-audit obligation.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E) [9] https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11244&Mode=0 — RBI Storage of Payment System Data, 6 April 2018 [10] https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12486&fn=14&Mode=0 — RBI Outsourcing of IT Services Directions 2023

Contents · Reader guide and citation conventions · Artifact index