DPDP Act: the Processor Contract Clauses Indian Companies Now Need (2026)

Why your vendor contracts now need DPDP processor clauses India's Digital Personal Data Protection Act, 2023 (the DPDP Act) changes how you must contract with any vendor that handles personal data on your behalf. The Act splits the world into a data fiduciary (the entity that decides why and how personal data is processed, broadly the equivalent of a controller) and a data processor (an entity that processes personal data on behalf of a fiduciary). The key rule for contracts: a data fiduciary may engage, or continue to engage, a data processor to process personal data only under a valid contract. That one line has a wide reach. If you are an Indian company and a vendor touches personal data for you, your payroll provider, cloud host, CRM, analytics tool, marketing platform, support desk, or any sub-contractor, you are a data fiduciary and they are your processor, and the arrangement needs a contract that does the job the Act requires. A bare purchase order, an oral arrangement, or a master services agreement that says nothing about personal data does not meet this. Critically, accountability cannot be contracted away. The DPDP Act makes the data fiduciary responsible for complying with the Act in respect of processing it does or that is done on its behalf, regardless of any agreement to the contrary. So the processor contract is not about shifting liability to the vendor; it is about binding the vendor to the obligations that keep you, the fiduciary, compliant. This article is general guidance, not legal advice. The DPDP Rules timeline and some operational details are still settling (see the note at the end), so confirm the current position and have a qualified professional review your contracts before you rely on them. Last verified October 2026. ## The clauses a DPDP processor contract should contain The Act is principles-based rather than a prescriptive clause list, so good practice draws on the Act's duties, the Digital Personal Data Protection Rules, and established data-protection drafting. The processor contract should cover the following. ### 1. Scope and purpose limitation

State exactly what personal data the processor handles, for what purpose, and that it may process the data only on your documented instructions and only to deliver the service. This stops the vendor from quietly reusing your data for its own ends. ``` The Processor shall process Personal Data only on the documented instructions of the Company (the Data Fiduciary), solely to provide the Services described in [Schedule], and for no other purpose. The Processor shall not use Personal Data for its own purposes.

The fiduciary must protect personal data in its possession or under its control, including where a processor handles it. So the contract must bind the processor to reasonable security safeguards. Keep the standard at least equivalent to your own obligations. ```
The Processor shall implement and maintain reasonable security
safeguards to prevent a personal data breach, including [encryption,
access controls, logging], and safeguards at least equivalent to those
the Company is required to maintain under the DPDP Act.
``` ### 3. Breach notification
If a breach happens at the processor, you (the fiduciary) carry the duty to notify the Data Protection Board and affected data principals. You cannot meet your timeline unless the processor tells you fast. Require immediate notification. ```
The Processor shall notify the Company without undue delay, and in any
event within [24 hours], of becoming aware of any personal data breach,
with sufficient detail to enable the Company to meet its notification
obligations under the DPDP Act and Rules.
``` ### 4. Assistance with data principal rights
Data principals have rights (access, correction, erasure, grievance redressal). Those requests usually come to you, but the data may sit with the processor. Require the processor to help you respond in time. ```
The Processor shall provide reasonable assistance to enable the Company
to respond to requests from Data Principals exercising their rights under
the DPDP Act, within the timelines the Company specifies.
``` ### 5. Erasure and retention
When the purpose is served or consent is withdrawn, processing must stop and data must generally be erased unless a law requires retention. The contract must carry this through to the processor. ```
On the Company's instruction, on withdrawal of consent by a Data
Principal, or on termination, the Processor shall cease processing and
erase or return the Personal Data, and erase existing copies, unless
retention is required by law.
``` ### 6. Sub-processors
If your vendor uses its own sub-contractors, they touch your data too. Require prior authorisation and flow-down of the same obligations. ```
The Processor shall not engage any sub-processor without the Company's
prior written authorisation, and shall impose on each sub-processor, by
contract, data-protection obligations equivalent to those in this
Agreement. The Processor remains responsible for its sub-processors.
``` ### 7. Audit and cooperation
You remain accountable, so you need the right to check. Include reasonable audit and information rights, and a duty to cooperate with the Data Protection Board. ```
The Processor shall make available information necessary to demonstrate
compliance with this Agreement, allow and cooperate with reasonable
audits by the Company or its appointed auditor, and cooperate with the
Data Protection Board of India as required.
``` ## How a DPDP processor clause set differs from a GDPR DPA If you already use a GDPR-style data processing addendum (DPA), you have a strong head start, but do not assume it is a drop-in fit. Key differences to check: - **Terminology.** DPDP uses data fiduciary and data processor, not controller and processor. Define terms against the DPDP Act, and do not silently equate the two regimes in the drafting.
- **Prescription.** GDPR Article 28 sets out a detailed, mandatory list of processor-contract terms. The DPDP Act is more principles-based, so you draft to its duties and the Rules rather than copying an Article 28 checklist and assuming it maps one to one.
- **Cross-border transfer.** GDPR relies on adequacy decisions and standard contractual clauses. The DPDP Act takes a different approach, broadly permitting transfer except to countries the central government restricts, so your transfer wording should reflect the DPDP model, not SCCs. Verify the current list and mechanism.
- **Consent and notice.** The Indian notice-and-consent requirements have their own form; a GDPR lawful-basis analysis does not translate directly. The safe approach is to use your GDPR DPA as a structure, then re-map it to DPDP terminology and duties rather than relabel it. ## Common mistakes to avoid - Assuming an MSA that is silent on personal data is enough. It is not; the Act needs a contract that addresses processing.
- Believing the contract shifts liability to the vendor. It does not; accountability stays with the fiduciary.
- Relabelling a GDPR DPA as DPDP-compliant without re-mapping terms and transfer wording.
- Forgetting sub-processors, so your data flows to parties bound by nothing.
- No breach-notification timeline, so you cannot meet your own duty to the Board.
- Not revisiting old vendor contracts, which also need to be brought in line. ## A note on timing and the Rules The DPDP Act was enacted in 2023. The Digital Personal Data Protection Rules were reported as notified in late 2025, with a phased runway for substantive compliance running into 2027, but sources differ on exact dates and some rule detail. <!-- [VERIFY: confirm exact DPDP Rules notification date (reported 13 Nov 2025) and the substantive compliance deadline (reported 13 May 2027) against the official gazette before relying on specific dates] --> Treat specific rule numbers and deadlines as to be confirmed against the official gazette notification, and track updates, because the detail affects how these clauses should read. Last verified October 2026. ## Where a contract workspace helps Adding the clauses above is the easy part. The harder part is doing it across every vendor contract you already have, keeping the wording consistent, catching the agreements that are silent on personal data, and re-checking them when the Rules settle. That is a search-and-update problem across a whole contract set, not a single drafting task. That is the idea behind a single AI contract workspace tuned to how your company contracts: it can draft from a processor-clause set that reflects Indian law, flag where an existing contract is missing the clauses the DPDP Act needs, and let you update the wording across contracts in plain language. Tools such as [Adira](https://adiralaw.com), which is India-first and built around per-clause risk and compliance tracking, are built around that idea. The clauses and the drafting discipline above are what bring your vendor contracts in line with the DPDP Act; a workspace simply makes applying them across a whole contract set one job instead of many.