TL;DR for founders
Section 16 of the DPDP Act, 2023 read with Rule 15 of the DPDP Rules, 2025 (notified 13 November 2025, G.S.R. 846(E)) lets you transfer Indian personal data to any country unless the Central Government blacklists it. As of April 2026 no country is blacklisted, so US/EU/Singapore routing is lawful — but RBI payment data, SEBI CSCRF, IRDAI and UIDAI Aadhaar hard-localisation rules still apply on top. You must still notice the transfer, contract processors properly under Section 8(2), secure the data under Section 8(5), and file a 72-hour breach notice to the DPDP Board alongside the 6-hour CERT-In clock. Maximum penalty: ₹250 crore per contravention. First step this week: open a single spreadsheet listing every personal-data field your stack processes and the hosting region that stores it.
Who this playbook is for
In scope — any Indian or foreign entity that:
- Processes personal data of Data Principals in India (Section 3 DPDP Act) and either hosts, backs-up, mirrors or shares that data with an affiliate, processor or vendor outside India
- Uses a cloud platform (AWS, Azure, GCP, Oracle, IBM Cloud, Alibaba Cloud) with any non-Indian region in scope
- Runs an MNC group-services model where Indian personal data flows to a parent/sister entity abroad
- Operates a digital-lending app (covered by RBI's 2 September 2022 Digital Lending Guidelines) with overseas data processors
- Operates a payment aggregator / payment gateway covered by RBI's Storage of Payment System Data Directive dated 6 April 2018
- Is a SEBI-regulated intermediary covered by the Cybersecurity and Cyber Resilience Framework ('CSCRF') dated 20 August 2024
- Is an insurer/intermediary covered by IRDAI Information and Cyber Security Guidelines, 2023 dated 24 April 2023
- Is an Aadhaar ecosystem participant bound by the UIDAI Aadhaar (Data Security) Regulations, 2016
- Processes children's data under Section 9 DPDP Act with any overseas vendor touchpoint
- Is a likely SDF candidate under Section 10(1) DPDP Act
Not in scope:
- Entities processing Indian personal data entirely within India with no overseas transfer, mirror, or support access (though all other DPDP obligations still apply)
- Individual Data Principals processing their own personal data for personal or domestic purposes (Section 3(c)(i) exemption)
- Research/archiving/statistical processing meeting Section 17(2)(b) conditions
Prerequisites
The 10-step process below assumes these are in place before you begin:
Documents needed:
- Board-approved Privacy & Data-Protection Policy (or equivalent) referencing DPDP Act compliance
- Record of Processing Activities (RoPA) — at least a baseline spreadsheet per processing activity
- Vendor inventory with hosting regions and sub-processor chains
- Data Processing Agreements currently in force with each overseas processor
- CERT-In Annexure II Point of Contact submission (see companion playbook
cert-in-6-hour-incident-reporting-sop) - Incident Response Policy covering both the 6-hour CERT-In clock and 72-hour DPDP clock
Roles required:
- Data Protection Officer (if SDF-designated or SDF-candidate) — must be resident in India under Rule 13(1)(a) DPDP Rules 2025
- Grievance Officer — for all Data Fiduciaries under Section 8(10) DPDP Act and Rule 9 DPDP Rules 2025
- General Counsel or outside privacy counsel
- Chief Information Security Officer
- Cloud / infrastructure architect
- Sectoral compliance lead (applicable to banks, SEBI-regulated entities, insurers, payment operators)
Approvals needed:
- Board or senior-management resolution adopting the Cross-Border Transfer Policy
- Pre-cleared budget for Data Transfer Addenda re-papering with all overseas processors
Step-by-step compliance process
Step 1: Build a data inventory and cross-border flow map
What: Produce a single source of truth listing every personal-data field collected, the processing purpose, the lawful basis under Section 6 or Section 7 DPDP Act, the hosting region, and every cross-border hop (production, DR/back-up, analytics, support access).
Where: A governed spreadsheet or privacy-management platform (e.g., OneTrust, BigID, or internal build). Keep one master spreadsheet that the DPO signs off quarterly.
How: Columns to populate — Processing Activity | Data Category (biographic / contact / financial / health / Aadhaar / children's / biometric / location / behavioural) | Source (user, partner, enrichment) | Section 6 consent basis or Section 7 legitimate use | Storage region | Back-up region | Sub-processor list and their regions | Retention trigger | Cross-border purpose (production / DR / analytics / support / research) | Sectoral localisation flag (payment data / Aadhaar / SEBI / IRDAI).
Templates: A minimum RoPA template may be requested from Veritect.
Common mistakes: Skipping "support access" flows (a US-based support engineer tailing Indian production logs is a cross-border transfer); treating sub-processors as opaque; omitting SaaS integrations bought with a company card.
Step 2: Identify the recipient country and check the Section 16(1) blacklist
What: For each cross-border hop, identify the country (or class of entities) receiving the personal data and check whether a Central Government notification under Section 16(1) DPDP Act restricts transfer.
Where: egazette.gov.in and meity.gov.in for any notification under Section 16(1). Maintain a watch-list so a future notification is picked up within 24 hours.
How: As of April 2026, no country has been notified under Section 16(1). This means transfer to any country is permitted on the primary-Act axis, subject to (a) sectoral-localisation rules under Section 16(2), (b) Section 8 safeguards, and (c) any special conditions for children's data under Section 9. The status can change with a single gazette notification — compliance teams must subscribe to egazette.gov.in feeds or the MeitY notifications page.
Templates: Flag column added to the data inventory — "Section 16(1) status: Permitted / Restricted / Conditional".
Common mistakes: Treating the absence of a blacklist as permanent; conflating Section 16(1) (DPDP central blacklist) with sectoral-localisation rules (which apply independently); assuming the draft DPDP Rules 2025 (G.S.R. 02(E) of 3 January 2025) white-list language survived — it did not; the final Rules adopt the blacklist model.
Step 3: Classify the data category — personal, sensitive, children's, SDF-scoped
What: Classify each data category for the correct obligation stack.
Where: The data inventory from Step 1.
How: Four classification axes:
- Personal data (all) — Section 8 obligations apply; Section 16(1) blacklist check applies.
- Sensitive personal data under SPDI Rules 2011 (password, financial information, health/medical, sexual orientation, biometric information, etc.) — IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 under Section 43A IT Act continue in force until 13 May 2027, when Section 44(2) DPDP Act omits Section 43A. Until then, affirmative consent and SPDI Rule 7 transfer conditions apply in parallel.
- Children's data (Section 9 DPDP Act) — verifiable parental consent via Rule 10 DPDP Rules 2025; tracking/behavioural monitoring/targeted advertising prohibited.
- SDF-scoped data — if the Data Fiduciary is (or is likely to be) notified under Section 10(1), Rule 13 DPDP Rules 2025 additional obligations flow through (DPO resident in India, DPIA, audit, observation report to DPBI).
Templates: Add "classification" column to the inventory.
Common mistakes: Treating SPDI Rules 2011 as already repealed (they are not — omission of Section 43A IT Act operates only from 13 May 2027); assuming children's data is outside scope because the product is not "for kids" (Section 9 applies to any processing of data of individuals under 18, regardless of platform targeting).
Step 4: Capture consent or fix a Section 7 legitimate use
What: For every cross-border flow, confirm the lawful basis under Section 6 DPDP Act (consent) or Section 7 (Certain Legitimate Uses).
Where: Consent-capture UX and back-end consent ledger; Section 7 basis analysis in the RoPA.
How: Section 6 consent must be free, specific, informed, unconditional, unambiguous, given by a clear affirmative action, and limited to the specified purpose. Bundled consent is void under Section 6(4). For Section 7 bases — voluntary provision, State benefit delivery, judgments/decrees, medical emergency, employment, specified public interest — document the mapping explicitly. The burden of proving consent under Section 6(10) is on the Data Fiduciary.
Templates: Notice template under Rule 3 DPDP Rules 2025, itemising personal data categories, purposes, goods/services enabled, rights mechanism, and DPBI complaint mechanism. Must be available in English and any of the 22 languages listed in the Eighth Schedule to the Constitution of India.
Common mistakes: Reusing GDPR-style "legitimate interest" language (not recognised under DPDP); bundling consent to terms of service; treating silence or continued use as consent.
Step 5: Re-paper the Data Processing Agreement with a Data Transfer Addendum
What: Update every contract with an overseas Data Processor to include Section 8(2) DPDP Act flow-down clauses and a Data Transfer Addendum.
Where: Contract-management system; priority ordering by data-volume exposure.
How: Minimum clauses to insert:
- Processor acts only on documented instructions of the Data Fiduciary (Section 8(2) DPDP Act).
- Processor implements Rule 6 DPDP Rules 2025 security safeguards (encryption, access controls, logging, monitoring, 180-day log retention, back-ups, breach-detection mechanisms).
- Processor notifies the Fiduciary of any suspected personal data breach within 24 hours (market standard; this is narrower than the 72-hour Section 8(6) clock precisely because the Fiduciary needs time to file).
- Processor supports fulfilment of Data Principal rights under Sections 11-14 within the Fiduciary's response windows.
- Processor returns or deletes personal data on end of engagement.
- Processor permits audits (for SDFs, an independent auditor under Rule 13(1)(b) DPDP Rules 2025).
- Processor's sub-processor appointments subject to the Fiduciary's prior written consent.
- Indemnity for breach of the above obligations.
- Governing law: Laws of India; dispute resolution via arbitration seated in India.
Templates: See Section 6 of this playbook for sample clauses.
Common mistakes: Assuming existing SCCs/GDPR DPAs discharge Section 8(2); allowing the processor's "master terms" to override; omitting audit rights; silent sub-processor chains.
Step 6: Implement technical safeguards under Section 8(5) and Rule 6
What: Technical and organisational controls proportionate to the risk.
Where: Cloud architecture; identity platform; logging and monitoring stack.
How: Rule 6(1) DPDP Rules 2025 prescribes a baseline: encryption, obfuscation, masking or virtual tokens; access controls (least privilege, MFA); logging of data access; monitoring for unauthorised access; detection mechanisms for personal data breaches; continuity of processing (back-ups); and appropriate technical and organisational measures to restore access after an event. For cross-border flows specifically, consider: in-transit encryption (TLS 1.2+); field-level encryption for sensitive categories; tokenisation at the India-egress point with re-identification keys held within India; region-pinned storage with no silent replication to non-primary regions; access-broker enforcing Indian-IP requirement for support engineers; pseudonymisation of children's data before any cross-border processing.
Templates: Rule 6 control mapping — one row per control, evidence link, owner, review date.
Common mistakes: Encrypting at rest but exposing plaintext in support tools; logging data access without forwarding to an India-resident SIEM; relying on the cloud provider's global default when a region-pinned configuration is available.
Step 7: Maintain records under Section 8(6) and the Third Schedule
What: Contemporaneous records of cross-border flows, consents captured, notices served, sub-processor chains, breach drills, and rights-request fulfilment.
Where: Privacy-management platform or governed document repository.
How: Rule 12 DPDP Rules 2025 requires Data Fiduciaries in notified classes (Third Schedule) to maintain records of processing activities. Even outside the Third Schedule, Section 8(6) requires the Fiduciary to be able to demonstrate compliance. Minimum records: consent-capture artefacts (timestamp, version of notice, clickstream); Data Transfer Addenda signed; sub-processor chains with written approvals; Rule 6 control attestations; breach drill reports; rights-request log with response times.
Templates: Monthly compliance dashboard summarising the above for the DPO/Grievance Officer.
Common mistakes: Treating records as a year-end exercise; failing to preserve the exact version of the notice that a particular user saw at consent; relying on cloud-provider default logs that roll over.
Step 8: Design the breach notification SOP across jurisdictions
What: A single SOP that kicks off parallel notifications: CERT-In (6 hours), DPDP Board (72 hours), sectoral regulator (RBI/SEBI/IRDAI as applicable), foreign regulators (GDPR Article 33 — 72 hours; US state attorneys-general; etc.).
Where: Incident Response Policy appendix; IR runbook.
How: On detection — (a) start the 6-hour CERT-In clock (see companion playbook cert-in-6-hour-incident-reporting-sop); (b) assess whether the breach touches personal data of Indian Data Principals; if yes, start the 72-hour Section 8(6) DPDP clock; (c) intimate affected Data Principals "without delay" per Rule 7(1) DPDP Rules 2025; (d) start any sectoral clock (RBI CSITE for banks; SEBI CSCRF for market intermediaries; IRDAI for insurers); (e) start GDPR Article 33 clock if the breach touches EU personal data. File each on its own clock — do not substitute one filing for another.
Templates: Breach decision tree with one branch per regulator and the applicable clock.
Common mistakes: Filing CERT-In and treating DPDP as covered; missing the "intimate affected Data Principals" limb of Section 8(6) because only the Board notice was filed; assuming the foreign regulator can be skipped because the Indian filing is done.
Step 9: Prepare for audit — internal and independent
What: Audit readiness with both an internal annual audit and, for SDFs, an independent data audit under Rule 13(1)(b) DPDP Rules 2025 at least once every 12 months.
Where: Audit committee; independent auditor engagement.
How: The independent audit under Rule 13(1)(b) covers (a) lawful-basis compliance, (b) notice adequacy under Rule 3, (c) security safeguards under Rule 6, (d) breach-readiness under Rule 7, (e) rights-fulfilment under Rule 14, (f) cross-border transfer compliance under Rule 15 and (g) DPIA quality under Rule 13(1)(c). The observation report must be submitted to the DPBI under Rule 13(1)(d) DPDP Rules 2025. Even non-SDFs should run a "shadow" independent audit in the 12 months preceding the 13 May 2027 commencement.
Templates: Audit scope document referencing Rule 13(1) sub-clauses.
Common mistakes: Using internal audit as a proxy for independent audit (Rule 13 explicitly distinguishes); scoping narrowly to security (the audit is a data-protection audit, not an ISO 27001 audit).
Step 10: Monitor for notifications and update transfer mechanisms
What: Continuous watch on Section 16(1) country notifications, Rule 15 amendments, and sectoral-regulator updates.
Where: egazette.gov.in; meity.gov.in notifications page; rbi.org.in notifications; sebi.gov.in circulars; irdai.gov.in circulars; uidai.gov.in regulations.
How: Assign a privacy-ops analyst (0.1-0.2 FTE) to monitor weekly and raise internal flags within 24 hours of any relevant notification. Maintain a rolling impact log — each new notification is assessed for applicability, action owner, remediation deadline.
Templates: Weekly notification-watch report.
Common mistakes: Stopping at the 13 May 2027 commencement; assuming sectoral circulars are captured by the DPO's ambit (they are not — sectoral compliance usually sits with a different team).
Timeline
| Milestone | Statutory deadline | Realistic timeline |
|---|---|---|
| Section 16 compliance readiness | 13 May 2027 (Rule 15 commencement) | Target dry-run completion by 31 December 2026 |
| DPA re-papering with overseas processors | No statutory deadline (contractual obligation under Section 8(2)) | 12-16 weeks per processor tier; start with top-10 by data-volume exposure |
| Personal data breach notification to DPBI (Section 8(6)) | 72 hours | File initial within 24 hours; supplement by 72 hours |
| CERT-In cyber incident notification (Direction (ii) of 28 April 2022 Directions) | 6 hours | File within 4 hours (2-hour buffer) |
| Independent data audit (SDF) under Rule 13(1)(b) | At least once every 12 months from SDF designation | Engage independent auditor ≥ 90 days before the 12-month anniversary |
| DPIA under Rule 13(1)(c) | On designation as SDF, and at material change in processing | 4-6 weeks first-pass; 2-3 weeks refresh thereafter |
| Section 16(1) notification watch | Continuous | Weekly notification-watch cycle |
The timeline assumes no Section 16(1) country notification is in force. A single gazette notification restricting transfer to a specific country can compress remediation to a matter of weeks.
Template clauses
Template A — Data Transfer Addendum (sample clause, ~200 words)
CLAUSE [X]. DPDP ACT, 2023 — CROSS-BORDER DATA PROCESSING
(a) The Processor acknowledges that the Personal Data processed under this Agreement
relates to Data Principals in India and is governed by the Digital Personal Data
Protection Act, 2023 ("DPDP Act") and the Digital Personal Data Protection Rules, 2025
("DPDP Rules"). The Fiduciary is the Data Fiduciary and the Processor is the Data
Processor within the meaning of Section 2 DPDP Act.
(b) The Processor shall process Personal Data only on documented instructions from the
Fiduciary and solely for the Specified Purposes in Schedule 1. The Processor shall not
transfer Personal Data to any country restricted under a notification issued under
Section 16(1) DPDP Act; the Processor shall monitor such notifications and confirm
ongoing compliance to the Fiduciary on a quarterly basis.
(c) The Processor shall implement reasonable security safeguards in accordance with
Section 8(5) DPDP Act and Rule 6 DPDP Rules, including encryption in transit and at
rest, role-based access controls, multi-factor authentication, audit logging with
rolling 180-day retention, tamper-evident backups, and personal-data-breach-detection
mechanisms.
(d) The Processor shall notify the Fiduciary of any actual, suspected or imminent
personal data breach within twenty-four (24) hours of becoming aware, to enable the
Fiduciary to discharge its Section 8(6) DPDP Act 72-hour notification obligation.
(e) This Addendum is governed by and construed in accordance with the laws of India.
Disputes shall be resolved by arbitration seated in [City], India under the Arbitration
and Conciliation Act, 1996.
Template B — Breach notification to the Data Protection Board (cover letter, ~100 words)
To: The Secretary, Data Protection Board of India
Copy: [CERT-In PoC email, sectoral regulator, affected Data Principals summary count]
Subject: Personal Data Breach Notification under Section 8(6), DPDP Act, 2023 —
[Entity] — [YYYY-MM-DD HH:MM IST]
This notification is filed under Section 8(6) of the Digital Personal Data Protection
Act, 2023 read with Rule 7 of the DPDP Rules, 2025.
1. Reporting entity: [Legal name, CIN, registered office]
2. Nature of breach: [Summary — unauthorised access / leak / alteration / loss]
3. Categories of Personal Data affected: [List]
4. Approximate number of Data Principals affected: [Number or "under assessment"]
5. Likely consequences: [Summary]
6. Measures taken / proposed: [Containment, communication to Data Principals, remediation]
7. Parallel filings: CERT-In filed at [time]; [sectoral regulator] filed at [time].
8. Attachments: Initial incident report; IoC list (if available).
A supplementary report will follow as investigation progresses.
Internal audit checklist
Run quarterly:
- RoPA complete — every processing activity has columns for region, sub-processors, lawful basis, retention trigger
- Cross-border flow map current; no orphan processors
- Section 16(1) notification watch up to date — last review ≤ 7 days old
- Sectoral-localisation flags accurate (RBI payment data, SEBI CSCRF, IRDAI, UIDAI Aadhaar)
- Data Transfer Addenda signed with each top-20 overseas processor
- Sub-processor register maintained — no unapproved appointments
- Rule 6 security safeguards evidence current — encryption, access controls, 180-day logs
- Breach-notification SOP tested — last tabletop ≤ 90 days old
- Children's-data flows (Section 9) classified and restricted
- SDF-designation likelihood reassessed — DPO/DPIA/audit readiness checked
- CERT-In Annexure II PoC current (see
cert-in-6-hour-incident-reporting-sop) - Rights-fulfilment portal live and tested for access, correction, erasure, nomination, grievance, withdrawal
What if things go wrong
Failure 1 — MeitY notifies a Section 16(1) restriction mid-quarter
- Symptom: A gazette notification restricts transfer of personal data of Indian Data Principals to Country X, where the entity currently routes DR/back-up.
- Likely cause: Geopolitical or reciprocity-driven notification; caught on the notification-watch cycle.
- Action: Within 7 days, freeze new flows to Country X; inventory current flows; engage cloud vendor to migrate to an unrestricted region within the notification's transition period (typically 90-180 days if specified, else "immediately"); file a material-change note in the RoPA; update the Section 5 notice if the processor map changes.
Failure 2 — Cross-border breach detected; 6-hour CERT-In and 72-hour DPDP clocks running simultaneously
- Symptom: Ransomware encrypts Indian personal data mirrored in an overseas region.
- Likely cause: Compromise via a shared cloud control plane; lateral movement from an unpatched VM.
- Action: Parallel clocks — file CERT-In within 4 hours (see companion playbook); prepare DPDP Section 8(6) filing for the 72-hour window including the form and manner under Rule 7 DPDP Rules 2025; if EU personal data is touched, file GDPR Article 33 within 72 hours to the relevant supervisory authority; intimate affected Data Principals "without delay" under Rule 7(1). Do not substitute one filing for another.
Failure 3 — Section 8(5) breach via an overseas sub-processor
- Symptom: A fourth-party service used by a Tier-3 processor leaks Indian personal data.
- Likely cause: Sub-processor chain opaque; approval not captured.
- Action: Invoke indemnity in the Data Transfer Addendum; file DPDP breach notice; reassess sub-processor approval policy; consider moving the relevant processing onshore or to an approved processor; engage with the DPBI proactively — Section 32 DPDP Act permits a voluntary undertaking in lieu of penalty, which has been an early Indian pattern.
Failure 4 — RBI payment-data non-compliance discovered during Section 16 review
- Symptom: Payment data mirrored in a non-India region in breach of RBI Directive dated 6 April 2018.
- Likely cause: Assumption that Section 16 DPDP "permits everything".
- Action: Section 16(2) DPDP Act expressly preserves RBI's higher-protection rule; immediate migration to an Indian region; self-report to RBI CSITE; update Board/Audit Committee; remediate within the RBI's accepted window.
Failure 5 — Children's data leaks through an overseas analytics pipe
- Symptom: Behavioural data on under-18 users flows to a US marketing vendor.
- Likely cause: Rule 10 DPDP Rules 2025 restrictions on tracking/behavioural monitoring/targeted advertising of children not enforced at the consent layer.
- Action: Shut off the pipe; file a Section 8(6) breach notice; assess exposure under Entry 3 of the Schedule (up to ₹200 crore for Section 9 breach); architect consent-layer enforcement so children's data cannot cross the boundary; engage with regulators on remediation.
Founder checklist
- Map your cross-border flows in the next 14 days — one row per processing activity, hosting region, sub-processor, lawful basis. No exceptions for "small" integrations.
- Triage your top-10 overseas processors by data-volume exposure and re-paper Data Transfer Addenda with them by 30 September 2026.
- Pin Indian regions for payment data, Aadhaar-linked data, and children's data — Section 16(2) DPDP Act and the sectoral circulars (RBI 6 April 2018; UIDAI 2016; Section 9 DPDP Act) do not negotiate.
- Subscribe to the notification watch — egazette.gov.in, meity.gov.in and the relevant sectoral regulator's notifications pages. A single Section 16(1) notification can collapse a multi-region architecture.
- Wire the breach SOP across regimes — a single incident triggers CERT-In (6 hours), DPDP Board (72 hours), sectoral regulator (RBI/SEBI/IRDAI), and possibly a foreign regulator. Tabletop once a quarter.
FAQ
Does the DPDP Act allow whitelisting of approved jurisdictions like the EU's adequacy regime?
No. Section 16(1) of the Digital Personal Data Protection Act, 2023 adopts a blacklist / negative-list model — transfers are permitted to any country unless the Central Government notifies a restriction. This is the opposite of the EU GDPR adequacy model under Article 45 GDPR, which permits transfers only to whitelisted jurisdictions. As of April 2026, no country has been notified under Section 16(1), so personal data may be transferred globally subject to Section 8 safeguards and sectoral localisation.
Can I freely transfer personal data to the US or Singapore under the DPDP Act?
Yes, subject to three conditions. First, Section 16(1) of the Digital Personal Data Protection Act, 2023 requires that no notification under that sub-section restricts transfer to the destination. As of April 2026, no country-specific restriction has been notified. Second, Section 16(2) preserves existing sectoral-localisation rules (RBI payment data, SEBI CSCRF, IRDAI, UIDAI Aadhaar) that continue to bind the transfer. Third, the Data Fiduciary must comply with Section 8(5) reasonable security safeguards and any obligations in a Data Processing Agreement with the overseas recipient.
How does Section 16 DPDP interact with the CERT-In 6-hour cyber incident reporting obligation?
Independently. CERT-In reporting under Section 70B(6) of the Information Technology Act, 2000 and the CERT-In Directions dated 28 April 2022 covers any of twenty cyber incident categories including data breach and data leak, with a 6-hour clock. Section 8(6) DPDP Act imposes a separate 72-hour personal data breach notification to the Data Protection Board of India. A cross-border data breach typically triggers both — plus any applicable sectoral regulator (RBI, SEBI, IRDAI) filing — and may also engage the foreign breach-notification regime (e.g., GDPR Article 33). File all regimes in parallel.
What happens to the RBI payment-data localisation circular of 6 April 2018 after DPDP commences?
It continues to apply. Section 16(2) of the Digital Personal Data Protection Act, 2023 expressly preserves the operation of any other law providing for higher protection of personal data. The RBI Directive on Storage of Payment System Data dated 6 April 2018 (DPSS.CO.OD No. 2785/06.08.005/2017-2018) requires that all payment system data be stored only in India. Payment System Operators must therefore continue hard localisation; foreign processing is permitted only for processing done abroad with return-and-delete within 24 hours.
Is a Standard Contractual Clauses (SCC) framework mandatory under the DPDP regime?
Not mandatory under the primary Act as of April 2026. Section 16 of the Digital Personal Data Protection Act, 2023 and Rule 15 of the DPDP Rules, 2025 do not prescribe a contractual vehicle. However, Section 8(2) DPDP Act requires a Data Fiduciary engaging a Data Processor (including an overseas processor) to do so under a valid contract, and Section 8(5) imposes a security-safeguards obligation that is most defensibly discharged through SCC-style contractual controls. Market practice since November 2025 has been to adopt an Indian-law-governed Data Transfer Addendum modelled on GDPR SCCs with DPDP-specific overlays.
Sources
Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) — Section 16, Section 8, Section 9, Section 10. MeitY PDF: https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf ; India Code: https://www.indiacode.nic.in/handle/123456789/2002
Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E) dated 13 November 2025) — Rule 6, Rule 7, Rule 10, Rule 13, Rule 15. MeitY PDF: https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf ; PIB: https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf
RBI Directive on Storage of Payment System Data dated 6 April 2018 (DPSS.CO.OD No. 2785/06.08.005/2017-2018) — https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11244
CERT-In Directions dated 28 April 2022 — https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf ; FAQs May 2022: https://www.cert-in.org.in/PDF/FAQs_on_CyberSecurityDirections_May2022.pdf
Information Technology Act, 2000 — Section 43A, Section 70B, Section 75, Section 81. India Code: https://www.indiacode.nic.in/handle/123456789/1999
IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 — CIS mirror: https://cis-india.org/internet-governance/files/it-reasonable-security-practices-and-procedures-and-sensitive-personal-data-or-information-rules-2011.pdf
eGazette of India — https://egazette.gov.in/
This playbook is prepared by Veritect Legal Intelligence for general informational purposes and does not constitute legal advice. Entities should consult qualified counsel for transfer-specific advice. Statutory citations are current as of 21 April 2026. Section 16(1) notifications should be independently verified at the time of each transfer.