How to Draft a DPDP-Compliant Data Processing Agreement (DPA)

You have your data audit done. You know which vendors touch personal data. You have mapped every data flow from your systems to third-party processors and back. Now comes the part that most compliance teams either rush through or endlessly postpone: putting the right contractual language in place.

Section 8(2) (full text) of the DPDP Act 2023 is explicit. A Data Fiduciary may engage a Data Processor to process personal data on its behalf "only under a valid contract." Not a handshake. Not a service agreement that happens to mention data. A contract that specifically governs how personal data will be handled, protected, and eventually deleted.

I have drafted or reviewed Data Processing Agreements at six companies over the past decade, three under GDPR and three for Indian entities preparing for the DPDP framework. The gap I see repeatedly is this: teams treat DPAs as a legal checkbox rather than an operational document. They download a GDPR template, swap in "DPDP Act" where it says "GDPR," and call it done. That approach will fail an audit. The two laws have fundamentally different liability structures, and a template that ignores those differences protects nobody.

Key Takeaways

• Section 8(2) of the DPDP Act 2023 makes Data Processing Agreements mandatory for every Data Fiduciary that engages a Data Processor.
• Unlike GDPR, the DPDP Act places sole liability on the Data Fiduciary for the Data Processor's actions. Your DPA must account for this asymmetry.
• A DPDP-compliant DPA needs at least 10 specific clauses, from scope and purpose limitation to breach notification timelines and sub-processor controls.
• The DPDP Rules 2025 require that processor contracts include provisions for "reasonable security safeguards," meaning your DPA must reference encryption, access controls, logging, and backup requirements.
• Most Indian companies will need to renegotiate existing vendor agreements. A standard MSA or SaaS terms of service does not satisfy the Section 8(2) requirement.

What Does Section 8(2) Actually Require?

Here is the exact statutory language:

"A Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering of goods or services to Data Principals only under a valid contract."

Three things to unpack here.

First, "engage, appoint, use or otherwise involve" is deliberately broad. It covers formal outsourcing relationships, SaaS subscriptions, API integrations, embedded third-party scripts, and any other arrangement where another entity handles personal data for you. If your analytics provider processes visitor data, that relationship needs a DPA. If your cloud hosting provider stores customer records, that needs a DPA. If your email service sends transactional messages containing personal data, that also needs a DPA.

Second, "for any activity related to offering of goods or services to Data Principals" defines the scope. This covers your customer-facing operations. Employee data processed by your HR SaaS vendor also falls under this, because the HR service is processing personal data on your behalf.

Third, "valid contract" means the agreement must satisfy the requirements of the Indian Contract Act, 1872. It must involve competent parties, free consent, a lawful object, and adequate consideration. A clickthrough terms-of-service page may or may not constitute a "valid contract" depending on how it is structured. If your vendor's ToS does not contain DPDP-specific data processing provisions, you will need a separate DPA addendum.

Why Can You Not Just Use a GDPR DPA Template?

If your company already operates under GDPR, you have Data Processing Agreements in place. They cover many of the right topics. But the liability model is different, and the specifics diverge in ways that matter.

Aspect	GDPR DPA (Article 28)	DPDP DPA (Section 8(2))
Liability model	Joint: both controller and processor face direct regulatory liability	Sole: only the Data Fiduciary faces regulatory liability for processor actions
Processor obligations in law	Extensive: 8+ specific obligations directly on the processor in Article 28(3)	Minimal: the Act places obligations on the Fiduciary; processor obligations are contractual
Sensitive data categories	Special category data requires additional safeguards	No sensitive data classification; all personal data treated uniformly
Lawful bases	6 lawful bases including legitimate interest	2 lawful bases: consent (Section 6) or legitimate uses (Section 7)
Breach notification	To supervisory authority within 72 hours; to data subjects only if high risk	To DPBI within 72 hours; to all affected Data Principals regardless of risk level
Sub-processor rules	Explicit: prior specific or general written authorisation required	Not explicitly in the Act; must be addressed contractually
Data Protection Officer	Required for certain controllers and processors	Required only for Significant Data Fiduciaries
Data transfer restrictions	Adequacy decisions, SCCs, BCRs	Government-notified list of restricted countries (pending)
Governing law	EU member state law	Indian Contract Act, 1872 + DPDP Act 2023

The critical difference is liability. Under GDPR, a processor that mishandles data faces direct regulatory penalties. Under DPDP, the Data Fiduciary bears sole responsibility, even if the breach originated entirely at the processor's end. This means your DPDP DPA needs stronger contractual indemnification clauses than a GDPR DPA typically contains. You are contractually transferring risk that the law does not transfer for you.

What Are the 10 Essential Clauses in a DPDP-Compliant DPA?

Here is the clause structure I use. Each clause maps to a specific obligation under the DPDP Act 2023 or the DPDP Rules 2025.

Clause 1: Scope and Purpose Limitation

Define exactly what personal data the processor will handle, for which Data Principals, and for what purposes. Be specific. "Customer data for analytics" is not sufficient. "Name, email address, and browsing behavior of website visitors for the purpose of generating anonymised traffic reports" is.

DPDP Reference: Section 8(1) requires that personal data be processed only for the purpose for which consent was obtained or which falls under a legitimate use.

Clause 2: Processing Instructions

State that the Data Processor shall process personal data only on the documented instructions of the Data Fiduciary. The processor may not use the data for its own purposes, combine it with data from other clients, or process it in ways not explicitly authorised.

This is where DPDP's sole-liability model makes precision critical. If your processor does something outside the scope of your instructions and a breach results, you still face the penalty. Your contractual recourse against the processor depends entirely on how clearly this clause is written.

Clause 3: Security Safeguards

The DPDP Rules 2025 require "reasonable security safeguards" for all personal data. Your DPA must require the processor to implement, at minimum:

• Encryption of personal data at rest and in transit
• Access controls restricting personal data access to authorised personnel only
• Logging and monitoring of all access to personal data
• Retention of access logs for a minimum of one year
• Backup and business continuity systems, tested and verified

Do not merely state "the Processor shall implement appropriate security measures." List the specific measures. Reference the DPDP Rules 2025 security requirements. Make the obligation auditable.

Clause 4: Confidentiality Obligations

All personnel of the Data Processor who access personal data must be bound by contractual or statutory confidentiality obligations. The DPA should require:

• Written confidentiality agreements with all personnel who access the data
• Role-based access restrictions (not everyone at the processor needs access)
• Training on data protection obligations relevant to the processing

Clause 5: Sub-Processor Controls

The DPDP Act does not explicitly regulate sub-processing, which makes this clause entirely your responsibility. Without it, your processor could share personal data with its own vendors without your knowledge or approval.

Here is exactly what this clause should cover:

1. Prior written approval: The processor may not engage any sub-processor without your prior written consent. You choose whether to require specific approval per sub-processor or general approval with a right to object.
2. Flow-down obligations: Any sub-processor must be bound by a written agreement imposing data protection obligations equivalent to those in your DPA.
3. List of current sub-processors: The processor must disclose all current sub-processors and notify you of any planned additions.
4. Processor remains liable: The processor remains fully responsible for any sub-processor's compliance or non-compliance.

Clause 6: Breach Notification

Under Section 8(6) of the DPDP Act 2023, the Data Fiduciary must notify the Data Protection Board of India within 72 hours of becoming aware of a personal data breach. Under DPDP, you must also notify every affected Data Principal, not just those facing high risk.

Your processor's breach notification obligation to you must leave you enough time to meet your own obligations. Here is the framework I recommend:

• The processor must notify the Data Fiduciary within 24 hours of becoming aware of a breach or suspected breach involving personal data processed under the agreement.
• The notification must include: nature of the breach, categories and approximate number of Data Principals affected, likely consequences, and measures taken or proposed to address the breach.
• The processor must cooperate fully with the Data Fiduciary's investigation, notification, and remediation efforts.

Twenty-four hours gives you a 48-hour buffer before the statutory 72-hour deadline. You need that buffer for assessment, legal review, drafting the DPBI notification, and preparing individual Data Principal notifications. If your contract merely says "without unreasonable delay," you have no enforceable timeline.

Clause 7: Data Principal Rights Assistance

Data Principals have four rights under the Act: access (Section 11), correction and erasure (Section 12), grievance redressal (Section 13), and nomination (Section 14). When a Data Principal exercises these rights, you may need the processor's cooperation to fulfil the request, especially if the data resides on the processor's systems.

Your DPA should require the processor to:

• Promptly assist in responding to Data Principal requests
• Provide data extracts, deletion confirmations, or correction records as needed
• Respond within a timeframe that allows you to meet the 90-day statutory deadline

Clause 8: Data Return and Deletion

Section 8(7) of the DPDP Act requires data erasure when the purpose is fulfilled. Your DPA must define what happens to personal data when the contract ends. Two options:

1. Return: The processor returns all personal data to you in a machine-readable format within a specified period (30 days is standard).
2. Deletion: The processor securely deletes all personal data and provides written certification of deletion.

Specify that deletion must cover all copies, including backups, archives, and cached data. Set a timeframe. "Within 30 days of contract termination or expiry" is typical. The processor should confirm deletion in writing.

Clause 9: Audit Rights

You need the contractual right to audit your processor's data protection practices. This clause should cover:

• Scope: The right to audit compliance with the DPA terms and applicable data protection law
• Frequency: At least annually, and on reasonable notice following a security incident
• Method: On-site audits, remote assessments, or acceptance of independent third-party audit reports (SOC 2, ISO 27001) as a partial substitute
• Cooperation: The processor must provide access to relevant personnel, systems, and documentation
• Cost: Typically borne by the auditing party (you), unless the audit reveals a material breach

For smaller vendors where a full audit is impractical, accepting SOC 2 Type II or ISO 27001 certification as evidence of security practices is reasonable. But the contractual right to audit must exist, even if you exercise it through third-party reports.

Clause 10: Liability and Indemnification

This is where the DPDP liability model demands attention. Since the Act holds only the Data Fiduciary liable for penalties, your DPA must contractually allocate risk.

At minimum, include:

• Indemnification: The processor indemnifies the Data Fiduciary for any losses, penalties, or costs arising from the processor's breach of the DPA or negligent handling of personal data.
• Penalty pass-through: If the Data Protection Board imposes a penalty on the Data Fiduciary that resulted from the processor's acts or omissions, the processor is contractually liable for the penalty amount.
• Liability cap considerations: Many vendors will push for a liability cap (typically 12 months of fees). For data protection-specific liabilities, consider whether a standard cap is appropriate given that DPDP penalties can reach ₹250 crore.
• Insurance: Consider requiring the processor to maintain cyber liability insurance at a specified minimum coverage level.

A note of practical reality here: your leverage in negotiating these terms depends on your bargaining power relative to the vendor. A 30-person company renegotiating with a large cloud provider will face standard terms. A 30-person company negotiating with a small Indian SaaS vendor has more room. In both cases, document your efforts. Good faith negotiation of protective terms is itself evidence of compliance diligence.

How Should You Handle the Sub-Processor Chain?

Sub-processing is the area where most DPA-related compliance failures occur, and the reason is simple: visibility drops off after the first layer.

Your direct processor has a DPA with you. That processor uses a cloud hosting provider, an email delivery service, and a database management tool. Each of those is a sub-processor. Each touches personal data. The question is whether the same protections flow down.

Here is the approach that works:

Step 1: Require your processor to disclose all current sub-processors in an annex to the DPA. Include the entity name, country of operation, and the specific processing activity performed.

Step 2: Classify each sub-processor by risk. A cloud hosting provider that stores encrypted data is lower risk than a customer support outsourcer that reads customer messages in plaintext.

Step 3: Require flow-down agreements. Every sub-processor must be contractually bound by obligations no less protective than those in your primary DPA. Your processor is responsible for enforcing these flow-down terms.

Step 4: Establish a notification and approval mechanism for new sub-processors. I recommend a 30-day advance notice period with a right to object. If you object and the processor cannot accommodate, either party should have the right to terminate the affected processing.

Step 5: Define what happens when a sub-processor causes a breach. The notification chain should be clear: sub-processor notifies the processor, processor notifies you, and you notify the DPBI and affected Data Principals. Each step should have a defined timeline.

What Does a Sample DPA Clause Look Like?

Here is an example of how the breach notification clause reads in a well-drafted DPDP DPA. You can adapt this for your own agreements:

7. Personal Data Breach Notification

7.1 The Data Processor shall notify the Data Fiduciary without undue delay, and in any event within twenty-four (24) hours, after becoming aware of a Personal Data Breach affecting Personal Data processed under this Agreement.

7.2 Such notification shall include, to the extent reasonably available: (a) a description of the nature of the breach, including the categories and approximate number of Data Principals affected; (b) the likely consequences of the breach; (c) the measures taken or proposed to address the breach, including measures to mitigate its effects; and (d) the name and contact details of the Data Processor's designated point of contact for the Data Fiduciary.

7.3 Where the Data Processor is unable to provide all information required under Clause 7.2 at the time of initial notification, such information shall be provided in phases without further undue delay as it becomes available.

7.4 The Data Processor shall cooperate with and assist the Data Fiduciary in complying with its obligations under Section 8(6) of the DPDP Act 2023, including the Data Fiduciary's obligation to notify the Data Protection Board of India and affected Data Principals.

This is a working clause, not a legal agreement. Have your legal counsel review and adapt it to your specific vendor relationships, industry requirements, and risk profile.

What Are the Most Common DPA Mistakes Indian Companies Make?

Having reviewed dozens of processor agreements across companies ranging from 15 to 500 employees, these are the patterns I see most often:

Mistake 1: Relying on the vendor's standard Terms of Service. A SaaS vendor's Terms of Service typically address commercial terms, service levels, and general liability. They rarely satisfy Section 8(2)'s requirement for a valid contract governing personal data processing. If your vendor's ToS does not contain specific clauses on data processing scope, security safeguards, breach notification timelines, and data deletion, you need a separate DPA addendum.

Mistake 2: Copy-pasting a GDPR DPA without adaptation. GDPR DPAs assume joint regulatory liability. DPDP DPAs must assume sole Data Fiduciary liability. If your contractual protections are structured for a GDPR-style liability split, they leave you exposed under DPDP.

Mistake 3: No sub-processor visibility. The contract covers your direct processor, but their sub-processors are invisible to you. A breach at a sub-processor you did not know existed is still your liability under DPDP.

Mistake 4: Vague security requirements. "The Processor shall implement appropriate security measures" is not auditable. Without specific requirements referencing the DPDP Rules 2025 safeguards (encryption, access controls, logging, one-year log retention, backup verification), you cannot assess compliance.

Mistake 5: No realistic breach notification timeline. "Without unreasonable delay" gives you no enforceable timeline. You need a specific hour count (24 hours is practical) that leaves buffer before your own 72-hour statutory deadline.

Mistake 6: Forgetting data deletion at contract end. The contract expires, you switch vendors, and your personal data sits on the old processor's systems indefinitely. Every DPA needs a data return/deletion clause with a specific timeframe and written deletion confirmation.

How Should You Prioritise Your DPA Rollout?

If you have 30 vendors and limited legal bandwidth, prioritise by risk:

Tier 1 (Immediately, within 4 weeks): Processors that handle the largest volume of personal data or the most sensitive categories. Typically: cloud hosting, CRM, payment gateway, email/communication service, HR/payroll platform.

Tier 2 (Within 8 weeks): Processors with moderate data access. Analytics platforms, marketing automation tools, customer support platforms, background check services.

Tier 3 (Within 12 weeks): Processors with minimal personal data exposure. Infrastructure monitoring, error tracking, project management tools (only if they contain personal data).

For each tier, the process is the same:

1. Identify whether the vendor already offers a DPA or data processing addendum.
2. Review it against the 10-clause framework above.
3. Negotiate amendments where gaps exist.
4. Execute the DPA and file it in your compliance records.

Track every DPA's status in a register: vendor name, DPA status (requested, under review, executed), execution date, renewal date, and assigned internal owner.

Frequently Asked Questions

Is a Data Processing Agreement mandatory under the DPDP Act 2023?

Yes. Section 8(2) of the DPDP Act 2023 states that a Data Fiduciary may engage a Data Processor "only under a valid contract." As of March 2026, this requirement applies to every relationship where a third party processes personal data on a Data Fiduciary's behalf. Operating without DPAs in place is a direct compliance gap.

What is the penalty for not having a DPA with a Data Processor under DPDP?

The DPDP Act 2023 does not specify a separate penalty for missing DPAs. However, if a Data Processor causes a personal data breach and no valid contract governs the relationship, the Data Fiduciary faces penalties under Section 8(6) for the breach (up to ₹250 crore) with weakened contractual recourse against the responsible processor. The missing DPA also signals a broader compliance failure under Section 8(2) that the Data Protection Board may consider when assessing penalties.

How is a DPDP Data Processing Agreement different from a GDPR DPA?

The core structural difference is liability. Under GDPR, both the controller and processor face direct regulatory liability for non-compliance. Under the DPDP Act, only the Data Fiduciary faces regulatory penalties; Data Processors are not directly penalised by the Act. This means a DPDP DPA must include stronger contractual indemnification and penalty pass-through provisions than a typical GDPR DPA, because the law does not provide the same automatic coverage.

Can a vendor's existing Terms of Service serve as a DPA under DPDP?

Only if the Terms of Service contain all the elements required for a valid data processing contract: defined processing scope and purpose, security safeguard obligations, breach notification timelines, sub-processor controls, data deletion provisions, and audit rights. Most standard SaaS Terms of Service do not include these provisions. In practice, you will typically need a separate DPA addendum even if the vendor's ToS mentions data protection in general terms.

Do I need separate DPAs for each vendor, or can I use one standard template?

A single template is the right starting point. Draft one DPDP-compliant DPA template that covers all 10 clauses in this guide, then customise the scope and purpose annex for each vendor. The core clauses (security, breach notification, sub-processor controls, audit rights, indemnification) can remain standardised. The annex (what data, what purpose, what processing activities) must be vendor-specific.

Simplify Your DPDP Compliance

This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.

Drafting DPAs one by one, tracking vendor responses, and maintaining a compliance register manually is feasible, but at 30 or more vendors it consumes weeks of legal and procurement bandwidth. ComplyZero's self-serve platform includes pre-built, DPDP-specific DPA templates, a vendor compliance tracker, and audit-ready records, designed to compress this process from weeks to days for Indian businesses.

Join the waitlist →