Data Processing Agreement in India: Processor Obligations Under DPDP

A Gurugram hospital group signs a three-year contract with a billing outsourcer. The contract has a confidentiality clause and a security schedule copied from an IT services template. Nobody signs a data processing agreement. Eighteen months later a billing employee emails a patient list to a personal Gmail account, and the hospital discovers that its contract never required the outsourcer to notify it of a breach, never restricted onward transfer to subcontractors, and never required deletion of data at the end of the term. The hospital is the data fiduciary and carries the regulatory exposure; the outsourcer's contract limits its liability to one month's fees.

That gap is what a data processing agreement exists to close. Under the Digital Personal Data Protection Act 2023, the data fiduciary remains responsible for compliance even when a processor handles the data. The DPA is how the fiduciary pushes the operational obligations down to the party actually touching the data — and how the processor limits its own exposure to the things it can control. This guide is written for both sides, because the clauses that protect one are usually the clauses the other resists.

Who is a data processor under the DPDP Act

The Act defines a data processor as a person who processes personal data on behalf of a data fiduciary. Processing includes collection, storage, use, sharing, disclosure and erasure. The distinction between fiduciary and processor is functional, not contractual: it depends on who determines the purpose and means of processing. Calling a party a processor in the contract does not make it one if, in reality, it decides how and why the data is used.

Two common Indian fact patterns blur the line. A payroll provider that processes salary data on instructions is a processor. The same provider using aggregated salary data to publish a market benchmark is a fiduciary for that activity. A cloud hosting provider is a processor for storage, but may be a fiduciary for its own account data and service telemetry. The DPA should identify each processing activity and state the role for that activity, rather than applying a single label to the whole relationship.

When an Indian business needs a DPA

Any time personal data is disclosed to another entity for processing on your instructions. In practice that covers more relationships than most businesses realise.

• Cloud and SaaS providers. Hosting, storage, email, CRM, helpdesk, analytics and HR platforms.
• Outsourcing and BPO. Payroll, accounting, medical billing, claims processing, customer support, data entry and back-office operations.
• Marketing and communications. Email service providers, SMS gateways, WhatsApp business providers and call centres.
• Logistics and fulfilment. Delivery partners that receive names, addresses and phone numbers.
• Professional advisers. Auditors, lawyers and consultants who access personnel or customer records.
• Group companies. Shared service centres and affiliates that process data for other group entities.

A processor that engages a sub-processor — a cloud provider hosting the outsourcer's application, for example — is itself acting as a processor in a chain. The Act contemplates processing under a valid contract, and the fiduciary needs to know the whole chain, because its accountability extends through it.

The processor obligations a DPA must contain

The Act imposes general obligations on data fiduciaries under Section 8, including accuracy, security safeguards, breach notification and grievance redressal. The processor's obligations are largely contractual, which means the DPA has to spell them out. The table below is the core obligation set.

Scope, purpose and the instructions schedule

The DPA should attach an annexure that states, for each processing activity: the categories of data principals, the categories of personal data, the purpose, the duration, the location of processing, the security measures and the retention period. This annexure is the instruction set; anything not listed is outside the processor's authority.

The duration should be tied to the underlying services agreement rather than left open. The location should name countries and facilities, not just "cloud infrastructure". If the processor uses a content delivery network or a support team in another country, that should be disclosed, because remote access is processing.

The instructions clause should also deal with the awkward cases. What happens when the processor receives a request from a law enforcement agency for the fiduciary's data? The processor should be required to notify the fiduciary unless legally prohibited, to challenge overbroad requests where lawful, and to disclose only the minimum required. What happens when the processor is asked by its own auditor for sample data? Access should be limited to aggregated or anonymised data unless the fiduciary agrees.

Security obligations that can be audited

"Reasonable security practices" is the statutory standard, and it is too vague to manage. The DPA should translate it into commitments that can be verified: encryption at rest and in transit with named standards, access control with multi-factor authentication for administrative access, logging retained for a stated period, vulnerability scanning frequency, patch timelines by severity, backup frequency and restoration testing, and a documented incident response plan.

Where the processor holds a certification — ISO 27001, SOC 2 Type II — the DPA can reference it, but should require the processor to notify the fiduciary if the certification lapses or the scope changes. A certificate that covered a different data centre is not evidence of security for this engagement.

The security obligations should also cover personnel: background checks where lawful and appropriate, confidentiality undertakings, training on data handling, and a disciplinary process for breaches. Most Indian data incidents involve an employee rather than an external attacker, and contractual security clauses that address only technology miss the main risk.

Sub-processors and the chain of accountability

The processor should not be free to appoint sub-processors at will. The DPA should require prior written consent, either specific or general with a right to object, and should list the approved sub-processors with their location and function.

Flow-down obligations are the mechanism that keeps the chain intact. The processor must impose on each sub-processor terms no less protective than the DPA, and must remain liable to the fiduciary for the sub-processor's performance. A processor that argues it is only liable for its own acts is asking the fiduciary to carry a risk it cannot control.

Where the fiduciary is a regulated entity, the regulator's outsourcing rules may require notification before a material sub-processor appointment and a right to object. Build that into the consent mechanism rather than treating it as a separate approval.

Breach notification: hours, not weeks

The Act requires the data fiduciary to notify the Data Protection Board and each affected data principal of a personal data breach. The fiduciary cannot do that within the statutory timeline unless the processor tells it immediately. The DPA should therefore require notification within twenty-four hours of the processor becoming aware, with an initial report covering what happened, what data and how many data principals are affected, the likely consequences and the containment steps taken.

A written report within seventy-two hours should follow, with root cause analysis, remediation and evidence. The processor should also cooperate with the fiduciary's notifications to the Board and to affected individuals, and should not communicate with data principals or the media about the breach without the fiduciary's agreement — a point processors often resist, but which prevents inconsistent messages.

The definition of "becoming aware" matters. It should mean the moment any employee or contractor of the processor has reason to believe a breach has occurred, not the moment the legal team is informed. Otherwise the clock starts late by design.

Data principal rights and the processor's support role

Data principals have rights to access, correction, erasure, grievance redressal and nomination under the Act. The fiduciary is the addressee of those rights; the processor is the party that holds the data and must help. The DPA should set out the mechanics.

• Access requests. The processor exports the relevant data in a structured format within a stated number of days, with a log of the request.
• Correction. The processor updates records on instruction and propagates the correction to sub-processors and downstream systems.
• Erasure. The processor deletes data on instruction, including from backups within a stated period, and certifies deletion.
• Withdrawal of consent. The processor stops the relevant processing on instruction and confirms which systems were affected.
• Grievance. The processor forwards complaints to the fiduciary within a short period and provides the information needed to respond.

Timelines should be tight enough to let the fiduciary meet its own obligations. If the fiduciary commits to responding to an access request in thirty days, the processor's internal deadline should be ten to fifteen days, leaving room for review.

Cross-border transfer and localisation

The Act permits transfer of personal data outside India subject to restrictions notified by the central government. The DPA should state the countries where data will be processed, the safeguards applied and the process for changing them. Where the fiduciary is in a regulated sector, additional restrictions apply — the Reserve Bank's requirements for payment system data, for instance, require storage in India with limited exceptions.

For transfers to group companies or to providers in jurisdictions without comparable protection, the DPA should include supplementary obligations: purpose limitation, security standards, access restrictions, government access transparency and a right to suspend transfer. A transfer impact assessment, recorded in writing, is increasingly expected in diligence even where the Act does not expressly mandate one.

Liability, indemnity and insurance

Because the fiduciary remains liable to the Board and to data principals, the DPA's liability clause is the fiduciary's recovery mechanism. Three elements matter.

First, the processor should indemnify the fiduciary for losses arising from the processor's breach of the DPA, including regulatory penalties attributable to the processor's acts, notification costs, credit monitoring and legal defence costs. Processors will cap this indemnity; the negotiation is about the cap level and the carve-outs.

Second, the indemnity should be uncapped or separately capped for breach of confidentiality and security obligations, because those are the risks the DPA exists to allocate.

Third, the processor should maintain cyber liability insurance at a stated level and provide evidence annually. An indemnity from an undercapitalised processor is worth little, and insurance is the practical substitute.

Note the interaction with the underlying services agreement. If the MSA caps all liability at twelve months' fees and the DPA is subject to the same cap, the data protection indemnity is effectively capped too. The DPA should expressly override the MSA cap for data protection claims, or the cap should be set high enough to cover the realistic exposure.

Term, survival and termination

The DPA should run for the term of the services agreement and survive termination for as long as the processor retains data. On termination, the processor should return the data in an agreed format within a stated period — fifteen to thirty days is typical — and delete what it does not return, including copies in backups and disaster recovery systems, within a further stated period.

The processor should also certify deletion in writing and permit an audit of the deletion. Where retention is required by law — tax records, for example — the DPA should identify the legal requirement and the retention period, and require continued protection of the retained data.

Drafting and execution practicalities in India

A DPA is usually an annexure to the services agreement, signed by both parties. It can also be a standalone agreement where the processor is providing only data services. Either way, it should be signed by an authorised signatory of each entity and referenced in the main agreement's order of precedence.

Stamp duty is generally the same as for the underlying agreement — a fixed duty for an agreement not otherwise provided for, varying by state. Where the DPA is executed as a separate instrument, it may attract its own stamp duty. Registration is not required. Confirm the current rate with the sub-registrar or the state e-stamp portal.

Where the processor is outside India, the DPA should state the governing law and the dispute resolution mechanism. Indian fiduciaries often prefer Indian law and Indian arbitration; global processors prefer their home law. A workable compromise is Indian law with arbitration in a neutral seat, or the processor's law with a contractual indemnity and insurance backing.

Common mistakes in Indian data processing agreements

• No DPA at all. A confidentiality clause is not a processing agreement.
• Role ambiguity. The processor is also using the data for its own analytics, which makes it a fiduciary for that activity.
• No instructions annexure. The processor's authority is undefined and expands by practice.
• Sub-processors permitted without consent. The chain extends to entities the fiduciary never approved.
• Breach notice in "reasonable time". Too slow for the fiduciary's own statutory notification.
• No deletion obligation or certificate. Data remains with the processor after termination.
• Indemnity capped at one month's fees. The recovery is smaller than the penalty.
• DPA subject to the MSA liability cap. The data protection indemnity is neutralised.
• No audit rights on a security incident. The fiduciary cannot investigate.

Frequently asked questions

Is a data processing agreement mandatory under the DPDP Act?

The Act requires processing by a data processor to be carried out under a valid contract with the data fiduciary. It does not prescribe a form or a title, but the contract must impose the processor obligations the Act contemplates. In practice that means a written DPA with instructions, security, sub-processor, breach and deletion terms.

A services agreement that says nothing about data processing is unlikely to satisfy that requirement, even if it contains a confidentiality clause.

Who is liable if the processor causes a data breach?

The data fiduciary remains liable to the Data Protection Board and to data principals, because the Act places the compliance obligation on the fiduciary. The processor's liability to the fiduciary is contractual and depends on the DPA's indemnity and liability clauses.

That is why the indemnity, the cap and the insurance requirement matter more in a DPA than in an ordinary services contract.

Can a processor use the data for its own purposes?

No, not if it is acting as a processor. Processing must be on the fiduciary's instructions. If the processor wants to use the data for product improvement, benchmarking or model training, it needs a separate lawful basis and, in most cases, the data must be aggregated or anonymised to the standard the fiduciary accepts.

Where a processor uses data for its own purposes, it becomes a data fiduciary for that processing and takes on the corresponding obligations.

How quickly must a processor notify a breach?

The Act's notification timeline applies to the data fiduciary, and the fiduciary cannot meet it without prompt information from the processor. Indian practice is to require notification within twenty-four hours of awareness, with a written report within seventy-two hours.

Some global processors will only commit to "without undue delay". That is not sufficient for an Indian fiduciary with a statutory deadline; negotiate a fixed period, even if it is forty-eight hours.

What should happen to data at the end of the contract?

It should be returned to the fiduciary in a usable, structured format and then deleted, including from backups and disaster recovery systems, within an agreed period. The processor should certify deletion in writing and allow the fiduciary to verify it.

Where a law requires retention — tax, company law or sectoral rules — the DPA should identify the requirement and require continued protection of the retained data for that period only.

Does a DPA need to be stamped in India?

It is an instrument and should be stamped under the applicable state stamp law, usually at a fixed duty for an agreement not otherwise provided for. If it is executed as an annexure to a stamped services agreement, the position on separate stamping varies by state.

Confirm with the sub-registrar or the state e-stamp portal, and keep the stamped copy with the main agreement.

Drafting Support

Our drafting team prepares data processing agreements for Indian fiduciaries and processors, including instructions annexures, security schedules and breach notification protocols.