What a Data Transfer Agreement Actually Requires of Your Vendor

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: CIO or legal-and-compliance head at a mid-to-large Indian enterprise who has just been told by an auditor or a large enterprise customer that the company's existing NDA with its offshore development partner does not satisfy the data-sharing obligations now triggered by the Digital Personal Data Protection Act 2023

A data transfer agreement under India's DPDP Act 2023 must do three things your current NDA almost certainly does not: bind the offshore vendor to process personal data only on your written instructions, require specific technical and organisational security measures that are verifiable on audit, and give you contractual rights to inspect, direct deletion, and control sub-processing. If your contract with an offshore development partner says the vendor will maintain 'reasonable security' and keep information confidential, it is an NDA with privacy flavouring. It is not a Data Processing Agreement, and it will not survive a DPDP Board inquiry.

This piece is for the CIO or compliance head who has been told — by an auditor, an enterprise customer, or an investor — that the existing paperwork is not enough. We will walk through what triggers the obligation, what the agreement must demand of the vendor's architecture (not just their policy binder), what readiness actually involves, and the two or three things teams discover far too late.

What triggers the obligation in the first place

The DPDP Act 2023 was brought into force on 13 November 2025, when MeitY notified the DPDP Rules 2025. Core obligations — notice, consent, security safeguards, breach reporting, cross-border transfer controls — are phased in by 13 May 2027, per the commencement notification. If you are an Indian company and personal data of Indian residents touches your systems — customer records, employee data, lead databases, support tickets, anything that identifies a natural person — you are a Data Fiduciary. If a vendor processes that data on your behalf, they are a Data Processor. The moment either role attaches, so does the contract requirement.

The provision most people miss is Section 8(1): the Data Fiduciary remains liable for all processing by its processors irrespective of any agreement to the contrary. You cannot contract out of statutory liability. What you can do — and what Section 8(2) requires — is ensure a valid written contract exists with every processor. A standalone NDA does not qualify. A generic MSA with a 'Data Protection' schedule bolted on usually does not qualify either. The DPDP Rules spell out what the processor must be contractually obligated to do, and if the clauses are missing, so is the compliance.

The practical trigger — the one that lands this in your inbox — is almost always external. An enterprise customer runs a vendor-risk assessment and asks for your sub-processor list and your DPAs with each. A SOC 2 auditor asks for evidence that your offshore development partner's controls are equivalent to your own. A due-diligence team flags the gap during a funding round. In each case, the question is not 'do you have a contract', it is 'does the contract contain the specific obligations the regime requires'.

What the agreement must actually contain

Rule 6(f) of the DPDP Rules 2025 and Section 8 of the Act, read together, give you a minimum clause set. Based on the LawSikho compliance guide and Legal 500's analysis of vendor obligations, a DPDP-grade data transfer agreement with an offshore dev partner must include:

• Scope and purpose limitation. The exact categories of personal data the vendor may access, the processing operations permitted, and the business purpose. 'Development, testing and support services' is too broad. Name the systems, the data types, and the lifecycle stages.
• Processing only on documented instructions. The vendor processes personal data only on your written instructions. If a vendor engineer wants to pull a production dataset into a staging environment to debug an issue, that is a new instruction, not a standing right.
• Equivalent security safeguards. Rule 6(f) requires the processor to implement safeguards equivalent to the fiduciary's. The clause must enumerate them — encryption at rest and in transit, access controls, logging, key management, segregation of environments — not merely gesture at 'industry standard'.
• Breach notification without unreasonable delay. A fixed window the vendor commits to (common practice is 24 to 48 hours of detection), the information they must provide, and the escalation contact on your side. The Act then obligates you, the fiduciary, to notify the DPDP Board and affected individuals.
• Sub-processing controls. No sub-processor without prior written consent. A current list of sub-processors maintained and updated. Flow-down of the same obligations by back-to-back contract. This matters disproportionately for offshore dev shops, which routinely use freelance contractors, overseas QA pools, and third-party AI APIs.
• Deletion and return. On your instruction, or at the end of the engagement, the vendor deletes or returns all personal data and provides a written certificate of destruction. The clause must address backups and log retention explicitly.
• Audit and inspection rights. You, or an auditor you appoint, can inspect the vendor's facilities, systems and records relevant to the processing. Many vendors push back here. The compromise is usually a right to receive annual third-party audit reports (SOC 2 Type II, ISO 27001) with a reserved right of direct inspection on reasonable cause.
• Cooperation on data principal rights. When a user exercises rights under the Act — access, correction, erasure — the vendor must provide information and action within a defined turnaround that lets you meet your statutory deadline.
• Cross-border transfer representations. If data physically leaves India or is accessed from outside India, the agreement must identify every jurisdiction involved and confirm the vendor's compliance with any country-specific restrictions the Central Government notifies.
• Liability and indemnity for processor-caused breaches. You cannot shift statutory liability, but you can and should recover from the vendor when their failure causes your penalty. Carve-outs that cap this at the annual contract value will not protect you — the DPDP penalties start at ₹250 crore for failure of security safeguards.

None of this is novel in global practice — it mirrors GDPR Article 28 — but the specific statutory anchors are now Indian, and the processor obligations in the DPDP Rules are what your auditor will test against.

What the agreement demands of the vendor's architecture

This is where most contract reviews stop and most compliance programmes fail. A clause that says the vendor will encrypt data at rest is worthless if the vendor's engineers routinely export production dumps to local laptops to reproduce bugs. The clauses must map to architectural controls the vendor can produce evidence for, on demand.

Concretely, a DPDP-ready offshore development partner should be able to show:

• Environment segregation. Production data does not flow to development or staging. Test data is synthetic or masked. There is a documented pipeline for how test data is generated, and no path from a developer workstation to a live customer record.
• Access control that is role-based and time-bound. Named individuals, named roles, access reviews on a cadence (quarterly at minimum), and just-in-time elevation for production troubleshooting. Shared accounts and standing admin privileges are red flags.
• Logging that is immutable and reviewed. Who accessed what personal data, when, from where. Logs retained for a defined period, protected from tampering, and sampled in regular reviews — not just dumped to a bucket nobody reads.
• Encryption with managed keys. At rest and in transit is the baseline. The question your auditor will ask is who holds the keys, how key rotation works, and whether the vendor's engineers can decrypt data without an audit trail.
• Data residency controls. If your position is that personal data stays on infrastructure located in India, the vendor must be able to demonstrate the specific regions and the configuration that enforces this — not just claim it.
• Secure SDLC. Code review, static analysis, dependency scanning, secrets management. For AI products specifically, a clear policy on whether customer data can be used to train models, what logging the AI calls produce, and how prompt-and-response data is retained.
• Incident response runbook. A documented process the vendor can walk through, with defined roles, communication templates and the timeline they commit to in your contract. Ask them to show you the last tabletop exercise.

If the vendor cannot produce evidence for these — not promise them, produce them — the contract clauses are decorative. For a sense of what mature engineering practice around this looks like in Indian-regulated contexts, our fintech and lending builds like Cashpo and GimBooks operate under exactly this scrutiny; both go through enterprise and regulator-adjacent vendor assessments where architectural evidence, not clauses, is what gets inspected.

What this costs in exposure if you get it wrong

The ceiling under the DPDP Act is ₹250 crore per instance for failure of security safeguards, with separate buckets of ₹200 crore for breach-notification failures and ₹150 crore for Significant Data Fiduciary obligations, per the published penalty schedule. A single breach can trip multiple heads.

The operational cost — before penalties — is already material. IBM's 2024 Cost of a Data Breach Report put the average cost of a data breach in India at ₹19.5 crore, a 39% jump from 2020, driven heavily by lost business and notification costs. The 2025 edition identified third-party vendor and supply-chain compromise as the second-most common initial attack vector in India at 17%, just behind phishing at 18%. Your offshore vendor contract is not a legal formality — it is a direct line of financial risk.

How long readiness takes, and what drives the number

There is no universal timeline, and anyone who gives you one without scoping is guessing. The honest answer is that readiness breaks into four parallel workstreams, each with its own clock:

1. Data mapping. You cannot write accurate DPA schedules until you know what personal data flows to which vendor, for what purpose, under which systems. For a mid-sized enterprise with 15–40 vendors touching personal data, this is typically the longest step and the one most under-budgeted. It is driven by how centralised your procurement is and whether you already maintain a RoPA (Record of Processing Activities).
2. Contract remediation. Drafting a template DPA aligned to DPDP Rules is a few weeks of legal work. Renegotiating with each existing vendor is the slow part — it is driven by vendor count, vendor leverage, and how much pushback you get on audit rights and liability.
3. Vendor technical uplift. If vendors lack the architectural controls above, remediation can take anywhere from a few sprints (adding masking, tightening access reviews) to months (environment re-segregation, key management overhaul). This is driven by the gap, not the contract.
4. Internal evidence pipeline. You need to be able to produce, on demand, the DPA, the sub-processor list, the latest audit report, the breach playbook, and the data map. Standing up that evidence system is itself a project.

Illustrative only: a mid-sized Indian SaaS company with roughly 20 vendors touching personal data, no existing data map, and one offshore dev partner holding production access typically finds that data mapping and vendor renegotiation together dominate the calendar, and the slowest vendor sets the critical path. To turn this into a real plan, the specifics that matter most are: the number of vendors that touch personal data, whether a current RoPA exists, and whether your largest offshore partner already holds a recent SOC 2 Type II or ISO 27001 report. If you want to pressure-test your current contracts against the DPDP Rules, that is a conversation worth having with privacy counsel and, where the architecture is in question, with an engineering partner — we have those conversations through our enterprise offerings.

None of the above is legal advice. The clause-level drafting and the specific liability apportionment with your vendors should be reviewed by qualified privacy counsel against your actual contracts and data flows.

What teams discover far too late

The sub-processor chain is longer than the vendor admitted. Your offshore dev partner uses a freelance QA pool in a third country, a cloud-hosted bug tracker that stores screenshots containing personal data, and an AI code-assistant that may send snippets of your codebase to a US provider. Each of these is a sub-processor. Each needs flow-down. The vendor's standard sub-processor list, if they have one, almost always understates this.

'Access to production' is more porous than the architecture diagram suggests. Teams discover during the first serious audit that developers routinely SSH into production to investigate incidents, that database read-replicas have been shared with analytics vendors, and that support staff export CSVs on request. Each of these needs either a control or a contractual basis — usually both.

AI features change the data map overnight. The moment your product calls a third-party LLM, you have a new processor, a new cross-border transfer, and new questions about training data. Most DPAs signed before 2024 do not contemplate this at all. If you are building AI into existing products, the DPA and the architecture need to be revisited together — this is a theme we see constantly in our AI product work.

Audit rights get negotiated away. Vendors, especially large ones, push to replace direct audit rights with 'you may rely on our SOC 2 report'. Sometimes that is acceptable. Sometimes it is not — if the SOC 2 scope does not cover the service you are buying, or if the report is more than a year old, the clause is cosmetic. Read the scope section of the report before you agree.

Frequently Asked Questions

Does an NDA with my offshore development partner satisfy DPDP requirements?

No. An NDA covers confidentiality — it does not impose the specific processor obligations the DPDP Act and Rules require, such as processing only on documented instructions, equivalent security safeguards, breach notification, sub-processor controls, and deletion. Section 8(2) of the Act requires a valid contract for every processor engagement, and the clause set is what makes it 'valid' for DPDP purposes.

Can we transfer liability to the offshore vendor through the contract?

Not statutory liability. Section 8(1) states explicitly that the Data Fiduciary remains responsible for processing by its processors irrespective of any agreement to the contrary. You can — and should — contractually recover financial losses, penalties and remediation costs from a vendor whose failure causes a breach, but the DPDP Board will come to you first.

What is the difference between a DPA and a cross-border data transfer agreement?

In practice they are usually a single document. The DPA covers the processor obligations under Section 8 and Rule 6. The cross-border transfer provisions add representations about the jurisdictions involved, compliance with any country restrictions notified by the Central Government, and often data residency commitments. For an offshore vendor, you need both sets of clauses in one agreement.

How do we check whether our existing vendor is actually DPDP-ready, not just contractually compliant?

Ask for evidence against the architectural controls: segregated environments, documented test-data policy, role-based time-bound access with review logs, immutable access logs for personal data, key management ownership, and a recent third-party audit report whose scope covers the service you buy. If the vendor can produce the contract clauses but not the evidence, you have a paper programme, not a control programme.

What does it cost to get our offshore vendor contracts DPDP-ready?

The cost is driven by vendor count, how much data mapping already exists, how much renegotiation leverage you have with each vendor, and whether vendors need technical remediation on top of contract changes. Legal drafting of a template DPA is a defined piece of work; vendor-by-vendor renegotiation and architectural uplift are the variable costs and the ones that dominate the budget. Scope those three factors with privacy counsel first, then come back for engineering input on the technical gaps.