TheDPDPAct.com -
Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Join Our WhatsApp Channel →Since the DPDP Rules were notified in November 2025, a significant portion of the compliance conversation has focused on contracts. Which clauses need updating. Whether vendor agreements need GDPR-style transfer mechanisms. What the eventual restricted-country list might look like and how to draft for it in advance.
Legal commentary on the DPDP Rules has made a useful observation in response to some of this activity: Rule 15, which governs cross-border transfers, hasn't actually commenced yet. The substantive obligations — including consent architecture, breach notification, and cross-border transfer conditions — are slated for Stage 3, expected around May 2027. The more useful thing to do with the current runway, that commentary suggests, is to "map data flows, vendor chains and sub-processor arrangements before obligations bite" — not to simulate compliance with a provision that isn't yet binding.
That advice is right. It's also almost entirely a technical undertaking, not a legal one — and the organizations that will be genuinely better positioned when Stage 3 arrives are the ones that treat this period as an opportunity to understand what their data actually does, not just to draft contracts that describe what it should do.
The Gap Between Contracts and Reality
Here's the structural problem with a contracts-first approach to cross-border DPDP compliance. A well-drafted vendor agreement says the processor will implement appropriate security measures, restrict sub-processing without authorization, and delete data when the relationship ends. What it doesn't tell you is which cloud region the data is actually being stored in, which sub-processors are receiving it downstream, whether the encryption in transit meets any particular standard, or whether a breach in the vendor's environment would be detectable within the 72 hours the DPDP Act's eventual breach notification requirement will demand.
A contract can obligate a vendor to be compliant. It cannot make them compliant. And for many organizations in India, the honest answer to "do we know where our personal data actually goes when it leaves our systems" is not "yes, we've verified it" — it's "we have contracts that say where it should go."
That gap is exactly what Rule 15's eventual commencement will expose — not primarily in the legal drafting, which teams are actively working on, but in the operational visibility that nobody has built yet.
What Data Flow Mapping Actually Involves
Data flow mapping, done properly, is a technical exercise that produces a genuine picture of how personal data moves through and beyond an organization's systems. It's distinct from a data inventory (which records what data exists) and from a privacy impact assessment (which evaluates risks at a policy level). It maps movement — and the results reliably surface things the organization didn't know.
A proper data flow mapping exercise across an Indian enterprise typically covers several layers.
1. Application-level data flows.
Which applications collect personal data, what fields, and where does that data go from there? The registration form that feeds the CRM. The CRM that syncs to the marketing automation platform. The marketing platform that shares with an analytics vendor. The analytics vendor whose servers are in a jurisdiction the organization has never formally considered. Each of these handoffs is a data flow, and most organizations have never mapped them end-to-end.
2. API and integration traffic.
Modern enterprise infrastructure is API-driven, which means personal data moves constantly between systems through connections that are often undocumented at the data level. The HR system that integrates with the payroll processor. The customer support platform that pulls from the product database. The finance system that shares with an overseas reporting entity. Mapping what personal data these API calls carry — not just that the APIs exist — is the exercise most organizations haven't done.
3. Cloud infrastructure and data residency.
Organizations with data in cloud environments often know which provider they're using and less reliably know which regions their data is actually stored in, which services have cross-region replication enabled by default, and which managed services process data in regions the organization never explicitly chose. This matters specifically for DPDP because the cross-border transfer question is ultimately a question about where data physically resides and where processing occurs — and the answer frequently differs from what the primary cloud service agreement describes.
4. Third-party and sub-processor chains.
The vendor an organization has a contract with is rarely the only organization processing its data. SaaS platforms use sub-processors. Cloud providers use infrastructure partners. Data analytics vendors may share with modeling partners. The DPDP framework, like most modern data protection regimes, holds the Data Fiduciary accountable for the full processing chain — which means knowing the chain matters, not just knowing the first link.
5. Unstructured and informal data flows.
These are the ones that most formal mapping exercises miss. The customer data shared over email with an external consultant. The patient records forwarded through WhatsApp for clinical review. The financial data exported to a spreadsheet and shared through a personal file storage service. These informal flows exist in every organization and they carry exactly the same compliance exposure as the formal ones.
Why the Cross-Border Picture Is Particularly Unclear
The data residency picture for most Indian organizations is more ambiguous than compliance programs typically acknowledge, for a structural reason: the default behavior of cloud services does not necessarily align with data sovereignty intuitions.
When an Indian organization signs up for a multinational SaaS platform, the default data region is often not India. Customer data may be stored in the US or EU by default, with an India region available as an option that needs to be explicitly selected. For organizations that onboarded years ago — before data residency became a live compliance consideration — the default was accepted, the data went where the platform put it, and nobody has formally reviewed it since.
Some cloud providers replicate data across multiple regions for availability and disaster recovery purposes by default, meaning data that the organization believes is stored in India is also being copied to other regions as a standard service feature. Whether this constitutes a "cross-border transfer" under DPDP is a question the Act's eventual Stage 3 commencement will sharpen considerably. What's not a question is whether organizations currently have visibility into it — most don't.
The Vendor Security Question That Contracts Don't Answer
Data flow mapping surfaces where data goes. Vendor security assessment determines whether it's safe when it gets there.
These are related but distinct exercises, and both matter for DPDP compliance. Section 8(5)'s reasonable security safeguards obligation applies to the Data Fiduciary's own systems. Rule 6 extends the accountability to Data Processors — organizations that process personal data on behalf of a Fiduciary must implement comparable security standards, and the Fiduciary is accountable for ensuring they do.
A data processing agreement that says "the vendor shall implement appropriate technical and organizational measures" satisfies a contractual documentation requirement. It does not tell an organization whether the vendor actually has those measures in place, whether they've been independently tested, or whether a breach in the vendor's environment would meet the detection and response standards the DPDP Act will eventually require. Answering those questions requires a vendor security assessment, not a contract clause.
For organizations with large vendor ecosystems — which is most enterprises of any meaningful size — this assessment isn't a single exercise but an ongoing program: tiering vendors by the sensitivity and volume of personal data they process, assessing higher-risk vendors against a defined security baseline, and building the contractual right to audit into new agreements before the leverage to demand it disappears at signing.
Using the Runway Well
The window between now and May 2027 is genuinely useful — not for simulating compliance with obligations that haven't commenced, but for building the visibility that makes compliance achievable when they do.
An organization that arrives at Stage 3 with a complete, current data flow map knows exactly which transfers Rule 15 will apply to the moment the restricted country list is published. It can assess its exposure against that list in hours, not months. It doesn't need to conduct an emergency data discovery exercise under regulatory time pressure.
An organization that has assessed its vendor ecosystem knows which processors meet the security standard the Act requires and which need remediation. It doesn't discover this during a Board investigation or, worse, after a processor breach that the Fiduciary is now accountable for.
An organization that has mapped its cloud infrastructure knows which of its data is genuinely India-resident and which is in regions it never explicitly chose. That clarity matters both for the cross-border transfer picture and for the security safeguards obligation — you cannot demonstrate reasonable safeguards for data whose location you haven't established.
At ILLUME Intelligence, data flow mapping, vendor security assessments, and cloud security reviews are core components of how we approach DPDP readiness — building the technical visibility that legal frameworks describe but cannot substitute for. If your organization's compliance program is advancing on the contract and policy side without this technical layer underneath it, the gap will surface eventually. The question is whether it surfaces on your timeline or someone else's. Reach out to Illume to scope a data flow mapping and vendor security assessment for your environment.
