top of page

Anatomy of an effective "Data Processing Agreement" (DPA) as per DPDPA

Data Privacy

Tuhin Batra, Partner - Trailblazer

Wednesday, 15 July 2026

Under the DPDP Act, the Data Processing Agreement is not an ancillary schedule to a commercial contract. It is the instrument through which the Data Fiduciary discharges a statutory duty and allocates a risk it cannot shed. Section 8(1) makes the Data Fiduciary responsible for compliance irrespective of any agreement to the contrary, in respect of any processing undertaken on its behalf by a Data Processor, and Section 8(2) permits a Data Fiduciary to engage a Data Processor only under a valid contract. The Act and the Rules then prescribe almost none of that contract's contents. Unlike Article 28 of the GDPR, there is no enumerated clause set a processor agreement must carry. The drafting discretion is therefore wide, and the consequences of using it poorly fall on the Fiduciary alone. What follows is the clause architecture a compliant agreement should contain.


I. Definitions and interpretation. 


Align the contract's defined terms with the Act. "Personal data", "processing", "personal data breach", "Data Principal", "Data Fiduciary" and "Data Processor" should track the statutory definitions in Section 2 rather than import generic or GDPR-derived language, so that the operative obligations map cleanly onto the statute the Fiduciary is answerable under. Where the agreement also serves a cross-border relationship, state which set of definitions governs in the event of conflict.


II. Characterisation of the parties. 


State expressly that one party acts as Data Fiduciary and the other as Data Processor for the processing in scope, and that the Processor processes on the Fiduciary's behalf and not for any purpose it determines itself. Characterisation is not cosmetic. A vendor that determines its own purposes and means becomes a Data Fiduciary in its own right under Section 2 and carries independent liability. The clause should record that the Processor acquires no right to use the personal data outside the engagement.


III. Scope, purpose and documented instructions. 


(a) Specify the subject matter, duration, nature and purpose of processing, the types of personal data, and the categories of Data Principals. This fixes the boundary of the lawful purpose for which the Fiduciary collected consent or relies on a legitimate use under Sections 6 and 7. (b) Require the Processor to process only on the Fiduciary's documented instructions and for no purpose beyond them. Onward use for the Processor's own analytics, model training or product development should be permitted only on separate express instruction, since such use may exceed the consent the Fiduciary obtained and expose it under Section 6(10), which obliges the Data Fiduciary to prove that notice was given and consent obtained in accordance with the Act. (c) Provide that the Processor will inform the Fiduciary where an instruction appears to require unlawful processing, without obliging the Processor to adjudicate the Fiduciary's compliance.


IV. Security safeguards. 


The duty under Section 8(5) to take reasonable security safeguards extends to processing undertaken on the Fiduciary's behalf, and Rule 6 now specifies the minimum measures. The agreement should require the Processor to implement and maintain, at a minimum: (a) securing of personal data through encryption, obfuscation, masking or virtual tokens; (b) appropriate access controls over the computer resources used to process it; (c) logs, monitoring and review sufficient to detect unauthorised access and enable investigation and remediation; (d) measures for continued processing where confidentiality, integrity or availability is compromised; and (e) retention of logs for at least one year. Because Rule 6 requires appropriate security provisions to be carried in the contract with the Data Processor, the security schedule should be an operative annexure with defined controls, not a reference to the Processor's prevailing policies, which it can change unilaterally. The Fiduciary should reserve a right to update the schedule as the Board issues standards.


V. Personal data breach: detection, notification and cooperation. 


This is the most DPDP-specific clause and the one most often underdrafted. Section 8(6) and Rule 7 require the Fiduciary to notify each affected Data Principal without delay and to furnish the Board a detailed report within 72 hours of awareness, subject to extension. The Fiduciary cannot meet that clock if it learns of the breach late or without the particulars the report needs. The clause should therefore: (a) require the Processor to notify the Fiduciary of any personal data breach, actual or reasonably suspected, without undue delay and in any event within a fixed period materially shorter than the Fiduciary's own deadline, for instance 24 hours, so the Fiduciary retains time to assess and report; (b) require that notification to carry the particulars the Board report needs: the nature and extent of the breach, the categories and approximate number of Data Principals and records affected, the likely consequences, the cause where known, and the remedial measures taken or proposed; (c) require the Processor to cooperate in the Fiduciary's investigation and notifications and to preserve evidence; and (d) prohibit the Processor from communicating with the Board or with affected Data Principals about the breach except at the Fiduciary's direction, so the Fiduciary controls the regulatory communications. Where the Fiduciary is also subject to the CERT-In Directions, which require reporting of certain cyber incidents within six hours, the Processor's notification trigger should be fast enough to feed that parallel obligation.


VI. Sub-processing and the onward chain. 


The responsibility under Section 8(1) does not stop at the direct vendor. The clause should: (a) state whether sub-processing is permitted at all, and if so, on the Fiduciary's general or specific prior written authorisation; (b) require the Processor to impose the same data protection obligations on each sub-processor by written contract, in particular the security and breach terms; (c) require an up-to-date register of sub-processors, with notice of intended changes and an opportunity to object; and (d) make the Processor liable to the Fiduciary for the acts and omissions of its sub-processors as for its own.


VII. Assistance with Data Principal rights. 


The Act confers rights of access, correction, completion, updating and erasure, and grievance redressal, on Data Principals under Sections 11 to 14, and the Fiduciary must honour them within the response timelines the Rules set. Where the Processor holds the data, the clause should require it to assist the Fiduciary to locate, surface, correct or erase personal data on request, to do so within a period that leaves the Fiduciary time to respond, and to route any request received directly from a Data Principal to the Fiduciary rather than answer it.


VIII. Retention and erasure. 


Section 8(7) requires the Fiduciary, on withdrawal of consent or once the purpose is no longer served and unless retention is required by law, to erase personal data and to cause its Data Processor to erase the data made available to it. The clause should: (a) require the Processor to erase or return personal data, at the Fiduciary's election, on instruction, on expiry of the applicable retention period, or on termination, and to cause its sub-processors to do the same; (b) accommodate the minimum one-year retention of personal data and processing logs that Rule 8 imposes for the purposes in the Seventh Schedule, and any longer period another law requires; and (c) where the Fiduciary falls within a class covered by the Third Schedule, support the inactivity-based erasure triggers and the 48 hours' advance notice the Rules require before erasure. Certification of erasure on request is worth requiring, given the Fiduciary's burden to demonstrate compliance.


IX. Audit, inspection and evidence of compliance. 


Because liability remains with the Fiduciary, it needs a means to verify the Processor's performance rather than rely on assurance. The clause should grant a right to audit compliance, directly or through an independent auditor, or to receive the Processor's third-party audit reports and certifications, together with records and logs sufficient to evidence security and erasure. A Fiduciary that is, or expects to be, designated a Significant Data Fiduciary will need this to feed the annual audit and impact-assessment obligations under Rule 13.


X. Confidentiality and personnel. 


Bind the Processor and its personnel to confidentiality, limit access to personnel who need it for the engagement, and require that those personnel are subject to enforceable confidentiality obligations and appropriate training. This supports the access-control and accountability expectations the Rules impose.


XI. Cross-border transfer and localisation. 


Section 16 adopts a negative-list model: transfer of personal data outside India is permitted unless the Central Government restricts a country or territory by notification. The clause should require the Processor to process and store personal data only in permitted locations, to flow the same restriction to sub-processors, and to comply with any sector-specific localisation the Fiduciary is subject to, such as the Reserve Bank of India's requirements for payment data. Build in a mechanism to adjust storage locations if the Government later notifies a restriction.


XII. Liability, indemnity and allocation of penalty exposure. 


The Fiduciary cannot transfer its statutory liability, and a clause purporting to do so is ineffective against the Board. What the agreement can do is allocate the commercial consequences. The clause should provide an indemnity for losses, including regulatory penalties, arising from the Processor's breach of the agreement or of its obligations, and should size any liability cap against the exposure realistically in view, given that failure to implement reasonable security safeguards carries a penalty of up to ₹250 crore and failure to notify a breach up to ₹200 crore. A cap set at a routine multiple of fees will not answer that exposure.


XIII. Term, suspension and consequences of termination. 


Provide for return or erasure of personal data on termination as above, for survival of the confidentiality, security and liability provisions to the extent necessary, and for a right to suspend processing or terminate where the Processor's conduct creates a compliance risk the Fiduciary cannot tolerate while remaining answerable for it.


XIV. Records and demonstrable accountability. 


Require the Processor to maintain records of its processing activities under the agreement, including the logs the Rules mandate, sufficient to allow the Fiduciary to demonstrate its own compliance to the Board. Accountability under this regime is evidentiary: the Fiduciary must be able to show what was done, not merely assert it.


XV. Primacy of statutory obligations. 


Include an interpretive provision that, in the event of conflict, the parties' obligations under the DPDP Act and the Rules prevail over inconsistent terms, and that nothing in the agreement relieves the Fiduciary of, or transfers, its statutory responsibility. This forecloses the argument that a limitation elsewhere in the contract dilutes a compliance obligation.


Two clauses carry most of the regulatory weight and deserve the most drafting attention: the security schedule at IV and the breach terms at V, because they map onto the two highest penalty heads and onto obligations the Fiduciary cannot perform without the Processor's cooperation. The remainder allocate risk and preserve the Fiduciary's ability to demonstrate compliance.

Anatomy of an effective "Data Processing Agreement" (DPA) as per DPDPA
bottom of page