By Adv. K J Muhammed Aslam · Advocate, Ernakulam (Bar Council of Kerala)
Cross-border transfer of personal data under the Digital Personal Data Protection Act, 2023 is permitted by default — Section 16(1) allows transfer outside India unless the Central Government by notification restricts transfers to a notified country or territory, and Rule 15 of the DPDP Rules, 2025 (G.S.R. 846(E), 13 November 2025) carries that permissive design forward. This article explains the default rule, the two restriction powers that qualify it, the sectoral exceptions that sit outside the DPDP Act, and the contract and disclosure work a Kerala business should do now — before any restriction is notified.
What is the default position — ban, adequacy, or permission?
India chose permission with a blacklist, not a ban or an adequacy whitelist. The legislative history matters because most teams assume one of the two other models:
- Ban / localisation by default — data must stay in India unless an exception allows export (the model some earlier drafts contemplated). The DPDP Act as enacted rejected this.
- Adequacy whitelist — data may flow only to countries the Government has declared adequate (the GDPR Chapter V approach). The DPDP Act rejected this as well.
- Permission with blacklist — what the Act actually does. Section 16(1) provides that the Central Government may, by notification, restrict transfer to any country or territory outside India. Until such a notification for a destination exists, transfer to that destination is not prohibited by Section 16. Rule 15 of the DPDP Rules, 2025 sits alongside this restriction power: the Rules themselves list neither a whitelist nor a blacklist; instead, the Government may, by general or special order, specify requirements in respect of making personal data available to a foreign State, or to any person or entity under the control of, or any agency of, such a State.
Practical distinction: Law — Section 16’s permissive default — is not the same as advice that every transfer is advisable without safeguards. The Act permits; prudent contracting, security and disclosure are still required by Sections 8, 5 and 6.
No general Section 16 restriction to specific countries had been notified as of August 2026. That makes the present task for businesses preparatory: build transfers on a lawful basis, disclose them, and keep the contractual and technical ability to comply quickly if a restriction for a destination you use is later notified.
What are the two restriction powers, and how do they differ?
| Feature | Section 16 (general) | Rule 13(4) read with Rule 15 (SDF-specific) |
|---|---|---|
| Whose data | Any personal data transferred outside India by any Data Fiduciary | Personal data and traffic data of a notified Significant Data Fiduciary, as specified by the Government on a committee recommendation |
| Trigger | Notification by the Central Government restricting transfers to a notified country or territory outside India | Direction to a specific notified SDF or SDF class to keep specified data within India |
| Default | Transfer allowed unless restricted | Transfer allowed unless this SDF-specific direction says otherwise for the specified data |
| Scope | Destination-based — all fiduciaries transferring to that country are affected | Fiduciary-based and data-category-based — only that SDF and only the specified personal data and traffic data |
| Example | A future order restricting transfer of personal data to Country X for all fiduciaries | A direction requiring notified healthtech or fintech SDFs to keep health or financial data and associated traffic data within India |
| Status as of Aug 2026 | No general restriction notified | No SDF class notified, so no SDF localisation direction could have been made |
A Kerala SaaS that replicates a customer database from Mumbai to a US region for analytics is therefore governed in the first instance by Section 16: the transfer is allowed today, but the business should have a contractual path to repatriate or re-route the flow if Country X were later restricted.
How do sectoral rules interact with Section 16?
DPDP is not the only transfer rule in the room. Three sectoral frameworks continue to operate in parallel and can be stricter than the DPDP default:
- Payments. The RBI circular dated 6 April 2018 on Storage of Payment System Data requires that all data relating to payment systems — including end-to-end transaction details and information collected or processed as part of a payment instruction — be stored in systems located only in India. This is a binding sectoral localisation independent of DPDP. A fintech that assumes DPDP’s permissive default overrides the RBI storage requirement is mistaken.
- Insurance, securities and telecom. IRDAI, SEBI and DoT impose data-handling and retention conditions for regulated data that include system-location and access requirements. Those conditions persist alongside DPDP.
- Government access. Section 17(1)(a) DPDP Act exempts processing necessary for enforcing any legal right or claim; Section 17(2)(a) exempts processing by a notified instrumentality of the State in the interests of sovereignty and integrity of India, security of the State, public order or preventing incitement to any cognizable offence; and Section 17(2)(b) covers research, archiving or statistical processing subject to prescribed standards. Those exemptions can affect availability and access, but they do not create a general exemption from the sectoral storage mandates.
The correct mental model is cumulative: the most restrictive applicable rule governs the specific data, and DPDP’s permissive default fills the space where no sectoral rule imposes a stricter condition.
What must the Section 5 notice and Section 6 consent say about transfers?
Neither Section 5 nor Section 6 creates a standalone transfer-consent, but both shape what a compliant transfer looks like:
- Section 5 notice. The notice given before or at the time of seeking consent must be itemised and in clear, plain language, available in English and the Eighth Schedule languages the Data Principal chooses (including Malayalam for Kerala users). It must describe the personal data and the specified purpose. Where the purpose involves processing outside India — for example, analytics, support or model training in a foreign region — the purpose description should make that transparent. A notice that says data is processed to provide analytics without disclosing that analytics occurs outside India is not inaccurate under Section 16, but it is weaker disclosure than a notice that transparently describes the processing location where material to the user’s understanding.
- Section 6 consent. Consent must be free, specific, informed, unconditional and unambiguous by clear affirmative action. If the purpose for which consent is sought includes cross-border processing, the specificity requirement means the consent cannot be a bundled, vague authorisation for unspecified future transfers — it must be tied to the described purpose. Withdrawal must be as easy as giving consent (Section 6(4)), which means a transfer that continues after withdrawal of consent for that purpose is no longer on a valid basis.
What contract terms cover cross-border transfers in practice?
The transfer itself is operational; the contract is what makes it governable. For every processor or sub-processor outside India that handles personal data on your behalf, align the agreement with these DPDP anchors:
- Purpose and scope tie to the notice and consent. The agreement should recite the specified purpose from the Section 5 notice and prohibit processing beyond it. This is the Article 28 GDPR equivalent that Indian vendor contracts increasingly need — not because the DPDP Act copies GDPR, but because purpose limitation under Section 8(1) and Section 4 requires it.
- Sub-processing controls. No onward transfer or sub-engagement without prior authorisation, with the same obligations flowed down. This is essential where a US analytics provider sub-processes through its own foreign sub-processors.
- Security floor under Rule 6. Encryption or masking, access controls, logging for at least one year, monitoring and backups — the Rule 6 minimum — must be contractually required of every processor, including foreign ones. DPDP’s highest penalty band — up to two hundred and fifty crore rupees — sits on failure of reasonable security safeguards (Section 8(5)).
- Breach timelines that let you meet Rule 7. The processor must notify you of any personal data breach without delay and in any event within a time that lets you meet your own without-delay intimations to affected individuals and to the Board and your detailed 72-hour report. A processor clause that allows notification in 72 hours fails this test — you need notification in hours, not days. For the dual-clock problem where CERT-In’s six-hour duty also applies, see the CERT-In 6-hour vs DPDP 72-hour guide.
- Erasure and return. Section 8(7) erasure once consent is withdrawn or the purpose is no longer served (unless retention is required by law), plus Rule 8 timelines and the Third Schedule three-year clock for large e-commerce, gaming and social media fiduciaries. The contract must require certified deletion and return on termination and on your instruction, and must address backups and logs.
- Restriction-readiness. An undertaking to comply promptly with any future restriction under Section 16 or direction under Rule 13(4) — including repatriation or re-routing of data — and to cooperate with audits. Build the clause now so a later notification does not require renegotiation under time pressure.
- Rights assistance. Technical and organisational assistance to fulfil Data Principal rights under Sections 11 to 14 and grievance redressal under Section 13 within the Rule 14 ninety-day window.
How should a Kerala business handle transfers today, before any restriction?
A practical posture that satisfies the current permissive default while preserving agility:
- Map transfer destinations. For every personal-data flow, record where data is stored and where it is processed — including failover regions, support access from outside India, and analytics copies — not only the primary region.
- Check sectoral constraints first. If the data is payment system data or otherwise subject to a sectoral storage mandate, that mandate governs regardless of DPDP’s default.
- Ensure notice and consent cover the destination purpose. Update the Section 5 notice to transparently describe processing purposes that involve outside-India systems, and ensure Section 6 consent is specific to those purposes.
- Harden processor contracts against the seven points above, and keep a register of foreign processors and sub-processors with their locations and purposes — the record the Board would ask for first.
- Monitor for notifications. Section 16 and Rule 13(4) actions appear as Gazette notifications and press releases from MeitY. Assign ownership for monitoring them — the DPO or the contact person published under Section 8(9) is the natural owner — and keep a written playbook for repatriation or re-routing if a destination you use is restricted.
Primary sources
- Digital Personal Data Protection Act, 2023 — India Code (Sections 2(i), 4, 5, 6, 8, 10, 16, 17 and the Schedule)
- Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), 13 November 2025) — MeitY (Rules 3, 6, 7, 8, 13, 15)
- RBI Circular on Storage of Payment System Data (6 April 2018)
- PIB backgrounder and press release on notification of the DPDP Rules (14 and 17 November 2025)
FAQ
