Section 16 of India's DPDP Act lets the Central Government restrict transfers of personal data to notified countries or territories. That is different from GDPR's adequacy-and-safeguards model, but it does not override stricter sector rules. The durable implementation pattern is a verified data-flow inventory plus architecture and contracts that can change a destination without rebuilding the product.
The DPDP Act received assent on 11 August 2023, and the final DPDP Rules 2025 were published on 14 November 2025 with phased commencement. Institutional provisions began first, Consent Manager obligations follow on the twelve-month schedule, and the main Data Fiduciary duties follow on the eighteen-month schedule. The DPDP Rules deadline guide tracks those dates. This article focuses on what section 16 says, which sector rules can be stricter, and what evidence a SaaS operator should maintain.
What §16 actually says
Section 16 says, in substance, that the Central Government may restrict transfer of personal data by a Data Fiduciary to a notified country or territory. Unlike GDPR Chapter V, the section itself does not create adequacy decisions, SCCs or BCRs as transfer mechanisms. That does not mean every transfer is automatically lawful: the rest of DPDP still applies, any current section 16 notification must be checked, and section 16 expressly preserves stricter restrictions under other Indian law.
Which implementation dates matter in 2026–2027?
- 14 November 2025: final DPDP Rules published; specified institutional provisions commenced on notification.
- Twelve-month phase: Consent Manager provisions reach their scheduled commencement around November 2026.
- Eighteen-month phase: the main Data Fiduciary obligations reach their scheduled commencement around May 2027.
- Ongoing: monitor section 16 restriction notifications and any Board procedures that affect evidence or reporting.
- Always separate: RBI, SEBI, IRDAI and other sector rules may impose stricter storage, outsourcing or access requirements.
Sector overlays — DPDP is not the only rulebook
Payment-system operators must account for RBI's payment-data storage requirements in addition to DPDP. SEBI-regulated entities must map CSCRF and outsourcing controls, and insurers and healthcare organisations must check their own regulator, contractual and programme rules. The practical rule is to identify the regulated dataset and legal entity first; DPDP section 16 sits alongside, not in place of, the stricter sector obligation.
| Sector | Sectoral data-residency rule | DPDP §16 interaction |
|---|---|---|
| Payment fintech | RBI April 2018 — payment data must be stored in India | DPDP §16 layers on top; transfer of personal data (non-payment) allowed unless country blacklisted |
| Banking core systems | RBI Master Directions on IT outsourcing | DPDP §16 applies to customer personal data; sectoral rules dictate operational data |
| Securities markets | SEBI CSCRF + outsourcing circular | DPDP §16 applies broadly; CSCRF dictates the security controls around the transfer |
| Insurance | IRDAI Information & Cyber Security guidelines | DPDP §16 applies; IRDAI rules on data residency overlay for specific classes |
| Healthcare | Applicable health-sector, ABDM and contractual requirements | DPDP §16 applies alongside the rule governing the specific dataset or programme |
The implementation pattern that survives ambiguity
Because the Government can change the restricted-destination position by notification, a SaaS operator should not hard-code its compliance model to today's country list. The implementation pattern that survives a change is data-residency architecture that lets you switch a destination without re-engineering. Five components matter:
1. Inventory the flows, not the systems
Map every cross-border data flow at the data-class level — customer PII, employee PII, financial data, biometric, health data — not at the application level. The same SaaS app may have three different cross-border flows, only one of which involves personal data; you cannot make architectural decisions until the flow inventory is the source of truth.
2. Destination as configuration
Architect the data pipeline so the destination region is a controlled configuration, not a baked-in code reference. Cloud platforms support regional deployment controls, but portability also depends on keys, backups, observability, data stores and sub-processors. If a destination becomes restricted, the response should follow a tested migration procedure rather than an emergency application rewrite.
3. India-side mirror infrastructure on standby
Maintain a tested India-region migration option for workloads that could become subject to a restriction or a sector-localisation rule. That may be warm capacity, infrastructure-as-code plus restored backups, or active-active deployment depending on recovery objectives. Record the achievable migration time and dependencies instead of claiming instant portability that has never been rehearsed.
4. Documented contractual fallback with sub-processors
Every contract with a sub-processor (analytics, support, customer-success, payment-processor, SaaS-vendor-of-your-SaaS) should include a clause that obliges the sub-processor to support data-region change on notice. Without this, you may find your sub-processor can't move and you can't either.
5. Evidence pack for the Data Protection Board
Keep one evidence set containing the cross-border flow inventory, data classification, destination decision, applicable notification check, architecture evidence, contractual fallback summaries and any required DPIA. The pack should let an internal reviewer or regulator reconstruct why a transfer was allowed on the date it occurred, rather than relying on a present-day snapshot.
Significant Data Fiduciary — the threshold that changes everything
DPDP section 10 introduces the Significant Data Fiduciary classification. A notified SDF has additional duties, including an India-based DPO, a DPIA and an independent data audit at the prescribed cadence. Do not assume that company size alone creates the designation, and do not assume a separate certification automatically qualifies an auditor for DPDP work. Track the notification and Board criteria, while preparing the controls that would take longest to implement.
What to do in the next 90 days
- Inventory cross-border personal-data flows at data-class level.
- Identify SaaS / cloud destinations currently in use; classify by data class.
- Refactor hard-coded regions to runtime configuration (cloud + app code).
- Confirm India-region capacity is provisionable inside 30 days for each cloud provider.
- Audit sub-processor contracts for data-region-change support clauses; close gaps.
- Begin DPIA workflow for high-risk processing classes.
- Commission an independent privacy and security review matched to the final Rules and your sector obligations.
- Document the §16 evidence pack in a single shared binder.
How Macksofy helps
A DPDP-readiness review should cover the cross-border flow inventory, data classification, destination decisions, architecture readiness, sub-processor contract gaps, and any required DPIA. See the DPDP audit scope for the full control review, or the CERT-In incident-reporting checklist for the separate cyber-incident workflow.