Data Processing Agreements under the Digital Personal Data Protection Act, 2023

I. Introduction

The Digital Personal Data Protection Act, 2023 ("Act") and the Digital Personal Data Protection Rules, 2025 notified on November 13, 2025 ("Rules") create a statutory framework within which organisations that process personal data must operate. At the centre of this framework, from a contractual standpoint, is the relationship between the Data Fiduciary and the Data Processor. The Data Fiduciary determines the purpose and means of processing personal data. The Data Processor processes that data on the Fiduciary's behalf, acting only on the Fiduciary's instructions and within the limits of a contract between them.

The Act adopts a fiduciary-centric model of accountability. Direct statutory obligations, and the regulatory penalties that attach to their breach, fall primarily on the Data Fiduciary rather than on the Processor. Where a Processor's act or omission causes a breach or a failure of compliance, the regulatory consequence is borne by the Fiduciary. The Processor's obligations are creatures of contract, not of statute, and the instrument through which those obligations are created, defined, and enforced is the Data Processing Agreement ("DPA").

The DPA is therefore not a compliance formality to be appended to a vendor engagement. It is the primary mechanism through which the Fiduciary manages its regulatory exposure to the conduct of third parties over whom it has delegated operational control. Its commercial terms, particularly on scope of processing, security obligations, sub-processing controls, breach notification, and liability allocation, are the product of negotiation between parties with divergent interests, and the outcomes of that negotiation carry direct regulatory consequences for the Fiduciary. This article examines the contractual architecture of the DPA under the DPDP framework, the key terms that require careful drafting, and the negotiation tensions that arise in practice.

II. The DPA as a Risk Management Instrument

The function of the DPA under the DPDP framework is to convert the Fiduciary's statutory obligations into enforceable contractual obligations on the Processor, and to create a contractual basis for the Fiduciary to recover losses arising from the Processor's failures. Both objectives are distinct and each requires attention in drafting.

The first objective, flowing down statutory obligations, requires that the DPA impose on the Processor the substantive conduct obligations that the Act and Rules place on the Fiduciary. Security safeguards, breach notification, data retention and deletion, and sub-processing controls are obligations the Fiduciary owes to the regulatory authority and to data principals. Where the fulfilment of these obligations depends on the Processor's conduct, the DPA must create a parallel contractual obligation on the Processor to conduct itself in the manner that enables the Fiduciary to comply. The contractual obligation need not mirror the statutory language precisely, but it must be sufficient in scope to ensure that the Processor's conduct does not place the Fiduciary in breach of its regulatory obligations.

The second objective, creating recovery rights, addresses the commercial consequence of the fiduciary-centric model. If the Processor causes a personal data breach that results in a penalty being imposed on the Fiduciary, the Act does not itself give the Fiduciary a statutory right of indemnity or contribution against the Processor. That right must be created by contract. An indemnity clause in the DPA, drafted with sufficient breadth to cover regulatory penalties and not merely direct losses, is the primary instrument through which the Fiduciary protects itself against the financial consequences of the Processor's failures. The absence of such a clause, or its limitation to a cap that is disproportionate to the regulatory exposure, leaves the Fiduciary bearing losses that were commercially caused by the Processor.

The tension between these two objectives and the Processor's commercial interest in limiting its exposure defines the negotiation dynamic of most DPA engagements. Processors, particularly large technology vendors operating at scale with standardised agreements, resist bespoke obligation regimes and seek to cap their liability at amounts that bear no relationship to the regulatory penalties a Fiduciary may face. Fiduciaries with significant bargaining power can negotiate departures from standard forms; those without it must assess whether the Processor's standard terms provide adequate contractual cover and, if not, whether alternative structural arrangements reduce the regulatory risk.

III. Scope of Processing and Purpose Limitation

The foundational term of any DPA is the scope of processing clause. This clause defines the universe of personal data that the Processor is authorised to process, the purposes for which processing is permitted, and the categories of data principals whose data is involved. Processing by the Processor that falls outside this scope is unauthorised as a matter of contract, and a Fiduciary that has clearly defined the scope in the DPA is better placed to establish that a deviation was the Processor's independent act rather than a consequence of the Fiduciary's instruction.

From a drafting standpoint, the scope clause requires a balance between specificity and operational flexibility. A scope clause that is excessively narrow may prevent the Processor from performing necessary incidental processing activities, such as aggregating data for performance monitoring or retaining limited logs for security purposes, without requiring a contractual amendment. A clause that is excessively broad, by contrast, permits the Processor to process data in ways that the Fiduciary did not intend and may not have the consent of data principals to authorise. The appropriate level of specificity depends on the nature of the engagement; a Processor providing payroll processing services requires a different scope definition from one providing cloud infrastructure, and the DPA should be drafted to reflect the actual processing activities rather than relying on generic templates.

The DPA should also address the prohibition on the Processor processing personal data for its own purposes. This is particularly significant in engagements with large technology vendors who may seek to use the data they process on behalf of the Fiduciary for their own product development, analytics, or commercial purposes. The DPA must unambiguously prohibit such secondary use and should specify the consequences of any breach of this prohibition, including the Fiduciary's right to terminate the engagement and seek compensation for any losses arising from the unauthorised use.

IV. Security Obligations and Sub-Processing Controls

Rule 6 of the Rules requires Data Fiduciaries to implement "reasonable security safeguards," and the DPA must impose an equivalent obligation on the Processor in respect of the personal data it handles. The contractual security obligation should not merely replicate the regulatory language of "reasonable security safeguards" without further specification, because reasonableness is a standard that will be assessed after the fact, often in the context of a breach that has already occurred. A DPA that specifies the security measures the Processor is required to maintain provides greater contractual certainty and a clearer basis for establishing whether a breach resulted from the Processor's failure to fulfil its obligations.

The security measures that the DPA should address include, at minimum, encryption of personal data both at rest and in transit, access controls restricting processing to authorised personnel, network segmentation preventing unauthorised access to data storage systems, and logging of data access and processing activities sufficient to enable forensic investigation of any incident. Beyond these technical measures, the DPA should require organisational safeguards, including confidentiality obligations for personnel with access to personal data, training requirements, and the maintenance of an incident response plan that enables the Processor to detect, contain, and report a breach within the timeframes required by the Fiduciary's notification obligations.

Sub-processing is a separate and commercially significant area of negotiation. Where a Processor engages sub-processors, which is almost universal in technology engagements involving cloud infrastructure, analytics platforms, or third-party support services, the Fiduciary's data may be processed by entities with whom the Fiduciary has no direct contractual relationship. The Fiduciary nonetheless remains responsible for that processing. The DPA must address sub-processing through two mechanisms. First, the Processor should be required to obtain the Fiduciary's prior written consent before engaging any sub-processor, either on an individual basis or by reference to an approved list that is subject to the Fiduciary's approval and updated only with notice and consent. Second, the Processor should be required to impose equivalent obligations on its sub-processors by contract, including the same security standards, breach notification requirements, and audit rights that bind the Processor itself, and should remain fully liable to the Fiduciary for any act or omission of a sub-processor as though it were the Processor's own act or omission.

The sub-processing consent mechanism is a frequent point of commercial tension. Large Processors operating with standardised infrastructure arrangements resist the requirement for individual approval of each sub-processor and typically seek a general authorisation for sub-processing subject to notification, rather than prior consent. From the Fiduciary's perspective, a general authorisation without prior consent reduces its visibility into the data processing chain and may result in personal data being transferred to sub-processors in jurisdictions or of a character that the Fiduciary would not have approved had it been consulted. The appropriate commercial resolution depends on the nature of the engagement and the sensitivity of the data involved, but the Fiduciary should at minimum insist on a list of current sub-processors at the time of contracting, a mechanism for ongoing notification of changes, and a contractual right to object to the addition of new sub-processors whose engagement would create regulatory or reputational risk.

V. Breach Notification Obligations in the DPA

Section 8(6) of the Act requires the Data Fiduciary to notify the Data Protection Board of India and each affected data principal of any personal data breach. Rule 7 of the Rules specifies that this notification must be made within seventy-two hours of the Fiduciary becoming aware of the breach. This timeline is operationally demanding even where the Fiduciary manages its own data processing infrastructure. Where processing is carried out by a third-party Processor, the Fiduciary's ability to comply depends entirely on the Processor detecting the breach promptly and notifying the Fiduciary with sufficient speed for the seventy-two hour period to be meaningful.

The DPA must therefore impose a notification obligation on the Processor that is more stringent than the statutory obligation imposed on the Fiduciary. The Processor should be required to notify the Fiduciary immediately upon becoming aware of any security incident that has resulted in, or could reasonably be expected to result in, unauthorised access to, disclosure of, or destruction of personal data. The notification obligation should not be conditioned on confirmation that a breach has occurred, because the time required for investigation may itself consume a significant portion of the seventy-two hour window. An obligation to notify upon awareness of a potential incident, coupled with an obligation to provide updates as the investigation progresses, enables the Fiduciary to assess its notification obligations while the Processor investigates.

The DPA should specify the content of the Processor's breach notification to the Fiduciary. This should include a description of the nature of the incident, the categories and approximate number of data principals whose data was affected, the likely consequences of the incident, the measures taken or proposed by the Processor to address the incident and prevent recurrence, and the identity of the Processor's incident response contact. The Processor should be required to cooperate fully with the Fiduciary's own investigation and with any investigation by the Data Protection Board, including by providing access to logs, systems, and personnel as reasonably required.

A Processor that delays notification to the Fiduciary and thereby causes the Fiduciary to miss the seventy-two hour deadline creates a direct regulatory liability for the Fiduciary. The DPA must make clear that any such delay constitutes a material breach of the agreement, entitles the Fiduciary to terminate, and exposes the Processor to indemnity liability for any penalty or loss arising from the failure to notify on time. The practical enforceability of this provision depends on whether the indemnity clause is broad enough to cover regulatory penalties, a point addressed in the section on liability allocation below.

VI. Data Retention, Deletion, and Return

The Rules impose obligations on Data Fiduciaries regarding the retention and deletion of personal data. Rule 8 requires Fiduciaries to retain logs of data processing activities for at least one year and to provide forty-eight hours notice before deletion of personal data. The DPA must reflect these obligations and impose corresponding requirements on the Processor in respect of the data it holds on the Fiduciary's behalf.

The most commercially significant aspect of the retention and deletion framework in a DPA is the obligation that applies upon termination of the engagement. When the processing relationship ends, whether by expiry of the contract, termination for cause, or the Fiduciary's decision to change service providers, the Processor holds personal data that no longer serves any legitimate purpose and must be either returned to the Fiduciary or securely deleted. The DPA should specify, with precision, the form in which data will be returned if the Fiduciary elects return, the format and timeline for certified deletion if deletion is elected, and the obligation of the Processor to provide a written certification confirming that all personal data, including any copies held by sub-processors, has been deleted. The certification requirement is important because it creates a contractual record that the Fiduciary can produce in the event of a subsequent dispute or regulatory inquiry.

A drafting difficulty arises in respect of data retained by the Processor for its own legitimate operational purposes, such as security logs, backup copies, and records required to be maintained under applicable law. The DPA should distinguish between personal data held as part of the processing service, which must be returned or deleted, and data retained by the Processor for its own purposes, which may be subject to different retention and deletion terms. Where the Processor retains personal data after termination for its own legitimate reasons, the DPA should specify the purpose, the retention period, and the obligation to delete once that purpose is fulfilled.

VII. Liability Allocation, Indemnity, and the Penalty Cap Problem

Liability allocation is the most commercially contested aspect of DPA negotiation, and it is the area in which the divergence between the Fiduciary's regulatory exposure and the Processor's commercial risk tolerance is most acute. Under the Act, penalties for non-compliance may be imposed on the Data Fiduciary at levels up to two hundred fifty crore rupees for a single breach. The Processor's standard liability cap in a commercial services agreement, typically set at a multiple of the annual fees paid under the contract, will almost invariably be a fraction of this figure. The gap between the Fiduciary's regulatory exposure and the Processor's contractual cap represents a residual risk that the Fiduciary bears by default.

The indemnity clause in the DPA is the primary mechanism for shifting this residual risk back to the Processor where the breach originates in the Processor's acts or omissions. A well-drafted indemnity clause should cover, without limitation, any penalties imposed on the Fiduciary by the Data Protection Board that are directly attributable to the Processor's failure to comply with its obligations under the DPA, any costs of notification to data principals and to the Board arising from a breach caused by the Processor, any claims brought by data principals arising from the Processor's unauthorised or negligent processing of their data, and reasonable legal costs and expenses incurred by the Fiduciary in responding to the breach and any associated regulatory proceedings. The indemnity should be structured so that it is not subject to the general liability cap, or alternatively should be subject to a higher cap than that applicable to ordinary service failures.

Processors resist uncapped indemnities on the ground that they create unlimited financial exposure on account of events that may be partly attributable to the Fiduciary's own systems or instructions. This resistance is not unreasonable as a commercial matter, and the negotiation typically resolves around two intermediate positions. The first is a bifurcated cap structure, under which ordinary service failures are subject to a standard cap linked to fees, but breaches arising from the Processor's gross negligence or wilful misconduct are subject to a higher cap or no cap at all. The second is an insurance requirement, under which the Processor is required to maintain cyber liability insurance at a minimum coverage level specified in the DPA, providing the Fiduciary with an independent source of recovery that is not subject to the contractual cap. Both mechanisms address the mismatch between the Processor's fee-linked cap and the Fiduciary's regulatory exposure, without requiring the Processor to accept unlimited liability for every service failure.

A further drafting consideration is the exclusion of consequential or indirect losses from the Processor's liability. Most commercial services agreements exclude indirect and consequential losses, including loss of revenue, loss of profit, and reputational damage. In the data processing context, many of the losses that a Fiduciary suffers from a breach are of precisely this character: the reputational damage from a public breach, the loss of customer confidence, and the commercial cost of managing the regulatory aftermath may dwarf the direct costs of remediation. The DPA should address whether consequential losses are excluded from the indemnity and, if they are, whether the exclusion applies to losses that are the direct consequence of the Processor's breach of its specific security and notification obligations, or only to losses arising from service interruption and ordinary performance failures.

VIII. Audit Rights and Cooperation Obligations

An effective DPA must give the Fiduciary the means to verify that the Processor is meeting its contractual obligations, rather than simply relying on contractual warranties that may be difficult to enforce after a breach has occurred. Audit rights serve this preventive function. The DPA should provide the Fiduciary with the right to conduct periodic audits of the Processor's data processing activities, either through direct on-site inspection, by requiring the Processor to procure and share independent third-party audit reports such as SOC 2 or ISO 27001 certification reports, or through a combination of both. The frequency and scope of audits should be proportionate to the sensitivity of the data being processed and the volume of personal data in the Processor's custody.

Processors commonly resist unlimited on-site audit rights on the ground that they impose operational disruption and may expose their own confidential infrastructure to the Fiduciary's personnel. The practical resolution is to permit on-site audits with reasonable prior notice, typically thirty days, to limit the frequency of inspections absent cause, and to allow the Processor to satisfy routine audit obligations through the provision of third-party certification reports. Where an incident has occurred or where there is specific cause for concern, the DPA should provide for expedited audit access with shorter notice periods and broader scope.

The cooperation obligation is the operational complement to the audit right. The DPA should require the Processor to cooperate with any investigation conducted by the Fiduciary or by the Data Protection Board, to provide access to relevant records, systems, and personnel, and to assist the Fiduciary in preparing any response to a regulatory inquiry. This obligation should survive the termination of the DPA for a specified period, typically corresponding to any applicable limitation period or the period during which regulatory proceedings might be commenced, to ensure that the Processor's cooperation cannot be withdrawn at the moment it is most needed.

IX. Conclusion

The Data Processing Agreement under the Act is the instrument through which the Fiduciary's statutory exposure to the Processor's conduct is managed, limited, and, to the extent possible, redistributed. Its contractual architecture spans the scope of processing authorised, the security standards required, the controls on sub-processing, the notification obligations triggered by an incident, the retention and deletion regime at the end of the relationship, and the allocation of liability when something goes wrong. Each of these components involves a commercial negotiation between parties with different risk profiles and different bargaining positions, and the outcome of that negotiation determines how much of the Fiduciary's regulatory exposure survives as a residual risk it bears alone.

The fiduciary-centric model of the Act makes thorough DPA negotiation a matter of regulatory necessity rather than commercial preference. A Fiduciary that accepts a Processor's standard data processing terms without assessing their adequacy against the Act's requirements, and without negotiating the liability allocation provisions that would enable it to recover losses caused by the Processor, has effectively accepted a contractual arrangement that transfers the risk of the Processor's failures entirely to itself. The DPA is the principal instrument for avoiding that outcome, and its negotiation deserves the same level of attention as any other material commercial contract in the organisation's vendor portfolio.