Mistakes People Make While Drafting Data Protection Clauses And Data Processing Agreements

A Practice Note under the DPDP Act, 2023 and the DPDP Rules, 2025

Prepared by Shubhank Suman, AI, Privacy, and IP Counsel.

With the DPDPA compliance deadline approaching May 2027, organizations are moving quickly to amend existing agreements or execute data protection addendum. In many cases, however, this has become a mechanical exercise, a provision is copied from an earlier contract, lightly adapted and inserted without examining the underlying data-processing arrangement. The correct starting point is not the template, but the transaction itself.

Before drafting, two fundamental questions must be answered: Does the agreement actually involve take? The answer depends on the nature and purpose of the processing, the categories of personal data involved, the parties’ respective roles, the individuals whose data may be handled, and the regulatory obligations applicable to the engagement. These considerations will determine whether the existing agreement should be amended, a separate addendum should be executed, or tailored provisions should be incorporated into the contract itself. This working note examines six recurring mistakes made when

the processing or sharing of personal data?If so, what form should the data protection provisions

drafting or reviewing data protection provisions, together with the practical illustrations used by this desk to help drafting teams move beyond standard templates and develop clauses that reflect the actual commercial and data-processing arrangement.

	Mistake drafters most commonly make
1	Adding a data protection clause to a contract without first checking whether personal data is actually involved in what the contract does.
2	Treating “amendment” and “addendum” as the same thing, without checking what the base contract's own modification clause requires.
3	Drafting the clause before working out the relationship, fiduciary to processor, fiduciary to fiduciary, or joint fiduciary, and reaching for the same template regardless.
4	Writing the clause only around customer or consumer data, and missing the employee, contractor and director data the same vendor will also touch.
5	Copying a GDPR-based data processing addendum without tailoring it to Indian law can create serious compliance gaps. Unlike the GDPR’s risk-based approach, the DPDPA framework requires action for every personal data breach, while certain cyber incidents must also be reported to CERT-In within six hours. Contracts must therefore require immediate escalation and separately address notifications to affected Data Principals, the Data Protection Board and CERT-In
6	Leaving out CERT-In's six hour cyber incident reporting timeline entirely, on the assumption that the DPDPA breach clause covers the field.

Mistake One: Not Knowing When To Amend, When To Add An Addendum, And When To Do Neither

An amendment rewrites the agreement itself. It reaches into a specific clause, a definition, a schedule, and changes the words already sitting there. An addendum sits beside the agreement: a fresh document that adds obligations without touching the original text, and it usually says so in its opening line, “this Addendum supplements and forms part of the Agreement dated [ ].” The choice between the two is not a matter of style. Two things decide it.

• First, look at what the obligation actually needs to attach to. If it has to sit inside a clause that already exists, for instance the definition of “Confidential Information” needs to be widened to expressly cover personal data, or an existing indemnity clause needs a data breach carve out, that clause has to be amended directly. Bolting a separate addendum onto a contract whose confidentiality clause stays silent on personal data leaves two documents saying different things about the same subject, and whichever one is narrower is the one that will be read against the fiduciary later.

• Second, and this is the step almost everyone skips, read the base contract's own amendment clause before drafting anything. Most commercial agreements say something like “no amendment shall be effective unless made in writing and signed by both parties,” and some go further, requiring the same signing authority and the same internal approvals as the original agreement. An addendum, precisely because it is a separate document, tends to get signed by whoever is convenient, often a procurement or vendor relationship owner rather than the person who executed the master agreement. If the master agreement's own clause requires the same signing authority for “any addition or modification,” a data protection addendum signed by the wrong person is not validly incorporated at all, however carefully it has been drafted.

The working rule: read the amendment clause of the base contract first. If it requires changes “by way of amendment,” amend the relevant clauses directly. If it permits “any addendum, schedule or annexure duly executed by the parties,” an addendum will do. Either way, check that whoever signs it holds the same authority as whoever signed the original agreement, not a lesser one.

There Is Also A Third Possibility Most Drafters Never Consider: Sometimes Nothing Needs To

be added at all, because personal data is not part of what the contract does. That question deserves the most space in this note, because getting it wrong is where the bulk of wasted drafting effort in this area actually goes.

Mistake Two: Pasting A Standard Clause Without First Reading The Agreement

The most common mistake is procedural rather than linguistic: the drafter opens a precedent is open, before asking what that agreement actually does. A data protection clause is not a boilerplate limb like governing law or notices. It has to be built around two prior findings, and both have to be made before a single word of the clause is drafted.

bank, pulls out “Data Protection Clause, Standard,” and drops it into whatever agreement

Step One: Identify The Relationship

DPDPA works with two defined roles. A Data Fiduciary is any person who, alone or with others, decides the purpose and the means of processing personal data. A Data Processor is any person who processes personal data on behalf of a Data Fiduciary, strictly on that fiduciary's instructions, with no independent purpose of its own. Nearly every commercial relationship falls into one of three patterns once these definitions are actually applied to the facts.

Relationship	What the clause should actually do
Fiduciary to Processor	A conventional Data Processing Agreement: process only on documented instructions, keep the data confidential, apply security safeguards, no sub-processor without consent, assist with Data Principal requests and breach notification, return or destroy data on termination.
Fiduciary to Fiduciary	No instruction based language. Each party warrants it has its own valid basis for its own purpose, owns its own compliance and penalties, and indemnifies the other only for its own default.
Joint Fiduciary	Arises under Section 2(j) itself, purpose and means decided “alone or in conjunction with other persons.” The Act gives no allocation template, so the contract must fix who handles Data Principal requests, who leads Board notification, and how liability is split.

Get the relationship wrong and everything downstream is wrong. A processor style clause imposed on a genuine co-fiduciary asks that party to act only on your instructions when it never agreed to any such thing, and is likely to be resisted or quietly ignored. A fiduciary to fiduciary clause used for a real processor lets that vendor treat the fiduciary's customer data as its own, which it is not entitled to do.

Step Two: Ask Whether Personal Data Is Actually The Subject Matter Of The Agreement

Once the relationship is mapped, ask the more basic question: does performance of this contract involve personal data changing hands at all. Many vendor contracts do not, and forcing a data protection clause into them is not caution, it is noise that confuses whoever has to operate the contract later.

Take an air conditioning installation and maintenance vendor engaged to service the office HVAC system. Its technicians enter the premises, service the units, and leave; nothing in that scope of work touches personal data, so no clause is needed. Compare that with a vendor engaged to install and maintain CCTV cameras at a retail customer's premises: the footage those cameras capture, faces of customers and staff, is personal data the moment it is recorded, so the agreement is squarely about the processing of personal data even though the word “data” may never appear in the commercial scope of work. The two contracts can look identical on paper, hardware installation and annual maintenance, and yet one needs a clause and the other does not; the difference sits entirely in what the vendor's work actually touches.

A few more illustrations this desk uses when training a drafting team, because the pattern repeats constantly:

– An office stationery or furniture supplier: no personal data, no clause.

– A security guard deployment agency: the guards will almost certainly keep a visitor register and copy identity documents at the gate; that is personal data, so a clause is needed even though the product being bought is guarding services, not data services.

– A canteen or catering vendor: usually no personal data beyond an aggregate headcount, but if payment runs through a cashless system linked to employee ID cards, the vendor now holds employee identifiers and spending patterns, and the analysis changes.

– A recruitment or background verification agency: clearly processes candidate personal data, and depending on how much independent judgment it exercises in screening candidates, may be a processor or a fiduciary in its own right, not automatically the former.

– A cloud storage provider hosting a CRM system: a processor relationship, and one of the cleaner cases.

– A civil contractor carrying out an office fit out: ordinarily no personal data, unless the same contractor is also given access to the employee database to programme access cards, in which case that narrow slice of the engagement needs protection even where the rest of the contract does not.

The test, in short, is not “is this a services contract” or “is this a technology contract.” It is whether carrying out the contract requires either party to collect, store, transmit, or otherwise handle personal data belonging to the other party's customers, employees, or any other individual. Answer that question first, on the actual facts of what the vendor will do, and only then decide what kind of clause, if any, the agreement needs.

Mistake Three: Drafting For Customer Data And Forgetting Employee Data

Data protection clauses are usually commissioned by whichever business team owns the customer relationship, so the drafting instructions, and the drafter's own instinct, default to “customer personal data” or “end user data.” That framing quietly writes the fiduciary's own workforce out of the clause, even in agreements where employee data plainly flows to the vendor as well.

The obvious cases are rarely missed: a payroll processor or a group medical insurance broker is clearly handling employee data. The cases that get missed are the incidental ones. A CRM or IT helpdesk vendor whose support staff can see the names and email addresses of the employees who raise tickets. A corporate travel agency booking flights and hotels, which necessarily collects passport and identity details of travelling staff. A biometric access control or attendance vendor. An e-discovery or litigation support vendor reviewing a custodian's mailbox during a dispute, which will contain personal data of current employees who are not even party to that dispute. In every one of these, the contract is negotiated and executed around “Customer Data,” and the defined term “Personal Data” in the clause is scoped to match; if that vendor later suffers a breach involving the employee data it also happened to hold, the breach notice, audit, and indemnity provisions may not even apply, because the defined term never covered it in the first place.

The fix is definitional, not conceptual: define “Personal Data” to expressly include personal data of the fiduciary's own employees, directors and contractors that the vendor may access in connection with the agreement, alongside customer data, and make sure every operative obligation, breach notice, audit rights, deletion on termination, runs to both categories, not only to the one the commercial team had in mind when it first asked for a clause.

Mistake Four: Copy Pasting A GDPR Template Without Adapting IT To The DPDPA

A large share of the data processing addenda in circulation in India today started life as a GDPR template, translated only by search and replace: “controller” for “fiduciary,” “processor” left as it is, “data subject” for “Data Principal.” Much of the substance genuinely does transfer. Security safeguards, confidentiality undertakings from personnel, consent before appointing a sub-processor, cooperation on Data Principal requests, and return or deletion of data on termination look broadly similar under both regimes, so that part of a GDPR template is not the problem. The problem sits specifically in the breach notification clause, and it is worth setting out exactly why.

GDPR Article 33 requires a controller to notify its supervisory authority “without undue delay and, where feasible, not later than 72 hours” after becoming aware of a breach, but that duty carries a built in escape hatch: notification is not required at all if the breach is “unlikely to result in a risk to the rights and freedoms” of the individuals concerned. Article 34 sets a higher bar again for telling the individuals themselves, only where the breach is “likely to result in a high risk,” and even then the controller may skip individual notice if the data was encrypted, if steps have since been taken that remove the high risk, or, for very large breaches, by making a public announcement instead of writing to everyone. GDPR, in short, asks the controller to run a risk assessment first, and lets a genuinely low risk breach go unreported to anyone outside the organization.

Section 8(6) of the DPDPA and Rule 7 of the DPDP Rules do not build in that escape hatch. The Data Fiduciary must, without delay, tell every affected Data Principal directly, describing the breach, its likely consequences, the mitigation steps taken, what the individual can do to protect themselves, and whom to contact. In parallel, it must give the Board an immediate short description of the breach, followed by a full written report within seventy-two hours that must itself account for what was communicated to the affected Data Principals. Nowhere in Section 8(6) is there a proviso letting a fiduciary decide, on its own risk assessment, that a breach is too minor to report. A clause that only obliges a vendor to notify “where required by applicable data protection law” or “where the breach is likely to result in a risk,” language copied straight out of a GDPR precedent, is quietly importing GDPR's risk gate into a regime that does not have one, and will under-report every time it is relied upon.

Point	GDPR	DPDPA
Regulator notification	Only if the breach poses a risk to individuals (Article 33)	Every breach, no materiality threshold (Section 8(6))
Individual notification	Only if “high risk,” with exceptions for encryption, later mitigation, or disproportionate effort (Article 34)	Every affected Data Principal told directly, without delay, no exceptions (Rule 7(1))
Timeline to regulator	72 hours, where feasible	Initial description without delay; detailed report within 72 hours (Rule 7(2))
Separate cyber regulator	Not applicable	CERT-In, within 6 hours of noticing, under the IT Act, running alongside the DPDPA process

A second gap is procedural rather than substantive. GDPR breach clauses are typically drafted assuming a single regulator and a single notification track. In India, a personal data breach that is also a cyber security incident triggers a second, entirely separate obligation: under the CERT- In Directions of 28 April 2022, issued under Section 70B of the Information Technology Act, 2000, specified categories of cyber incidents, unauthorized access and data breaches among them, must be reported to CERT-In within six hours of the incident being noticed or brought to notice, regardless of whether the DPDPA breach threshold is even engaged. This obligation runs on its own clock, to its own regulator, and a data processing addendum that only speaks of “notifying the Fiduciary so that it can inform the Board” leaves that six hour clock unattended, because by the time a vendor's incident report reaches the fiduciary through a contractual notice period of, say, twenty four or forty eight hours, the CERT-In window has usually already closed.

The practical fix is to set the vendor's own contractual notice period against the CERT-In and DPDPA clocks the fiduciary itself must meet, not against a generic “promptly” borrowed from a GDPR template. A vendor notice obligation of “within 24 hours” is already too slow if the fiduciary needs to report to CERT-In within 6 hours of the incident, so the vendor's own contractual deadline needs to sit comfortably inside that 6 hour window, not after it.

Practical Takeaways

– Read the base contract's amendment clause before choosing between an amendment and an addendum and check the signing authority required.

– Map the relationship, fiduciary to processor, fiduciary to fiduciary, or joint fiduciary, before drafting a single obligation.

– Ask, on the facts of what the vendor actually does, whether personal data is involved at all; do not assume it from the category of contract.

– Define “Personal Data” to expressly capture the fiduciary's own workforce data, not only customer data.

– Build the breach clause around Section 8(6), Rule 7, and, where relevant, the CERT-In six-hour window, not around a GDPR risk threshold that DPDPA does not recognize.