Cyber Law • Data Protection & Commercial Contracts

Data Processing Agreements Under the DPDP Act: Mandatory Clauses, Processor Liability, Security, Breaches and Cross-Border Data

How Indian businesses should contract with cloud, SaaS, payroll, CRM, analytics, support and other vendors before the substantive DPDP obligations commence.

Most organisations do not process personal data alone. Cloud hosts, software-as-a-service platforms, payroll providers, recruitment agencies, customer-support vendors, payment technology providers, marketing platforms, analytics tools, managed-service providers and professional advisers may all process personal data on behalf of a business.

Under the Digital Personal Data Protection Act, 2023, outsourcing does not outsource accountability. Section 8(1) makes the Data Fiduciary responsible for processing undertaken by it or on its behalf by a Data Processor, irrespective of an agreement to the contrary. Section 8(2) permits engagement of a Data Processor for activities related to offering goods or services to Data Principals only under a valid contract.

A Data Processing Agreement—commonly called a DPA—should therefore be treated as an operational risk-allocation instrument, not as a generic privacy annexure copied from a foreign template. It must reflect the actual data, systems, processing purpose, security architecture, subprocessors, incident-response timelines, retention and exit plan.

1. Data Fiduciary and Data Processor: identify the correct role

A Data Fiduciary is the person who, alone or together with others, determines the purpose and means of processing personal data. A Data Processor processes personal data on behalf of a Data Fiduciary.

The contractual label is relevant but not conclusive. A vendor described as a “processor” may act as an independent Data Fiduciary where it decides its own purpose for using the data—for example, independent profiling, product monetisation or marketing. Conversely, a service provider that processes strictly on documented instructions may ordinarily be a Data Processor.

The parties should conduct a function-by-function analysis. The same vendor may be:

• a processor for hosting customer records;
• an independent fiduciary for its own billing, fraud-prevention or legal-compliance records; and
• a separate fiduciary where it combines the customer’s data with other datasets for its own commercial purpose.

The DPA should not falsely characterise a shared-purpose arrangement as processing “only on behalf of” the customer. Incorrect role allocation weakens notices, consent analysis, rights handling and liability clauses.

2. Is a written Data Processing Agreement mandatory?

Section 8(2) requires a valid contract. The Act does not prescribe a document titled “Data Processing Agreement,” a statutory form or a registration procedure. The processor provisions may appear in a standalone DPA, a master-services agreement, a schedule, or an incorporated security and privacy addendum.

For evidentiary and governance reasons, the contract should be recorded in writing. It should be executed by authorised representatives, incorporated into the commercial agreement, version-controlled and preserved with all schedules and subprocessor disclosures.

A purchase order referring vaguely to the vendor’s online terms is risky where the online terms can be changed unilaterally or do not contain the required safeguards.

3. Statutory responsibility cannot be contracted away

Section 8(1) expressly preserves the Data Fiduciary’s responsibility irrespective of an agreement to the contrary. A clause stating that the processor alone bears all DPDP compliance does not eliminate the Data Fiduciary’s statutory exposure.

The DPA can allocate contractual risk between the parties through warranties, indemnities, liability caps, insurance and remediation-cost provisions. It cannot prevent the Data Protection Board from examining the Data Fiduciary’s own compliance.

The Data Fiduciary must therefore conduct vendor due diligence before appointment, impose appropriate contractual controls, monitor performance and retain evidence of oversight.

4. Core DPA schedule: scope, purpose and instructions

The DPA should include an operational schedule identifying:

• the services and processing activities;
• specified purpose of processing;
• categories of personal data;
• categories of Data Principals;
• systems, applications and environments involved;
• processing locations and remote-access locations;
• duration of processing;
• permitted recipients;
• approved subprocessors;
• retention and deletion periods;
• security standards; and
• customer instructions and approval mechanisms.

Instructions should be specific enough to restrict unauthorised secondary use, but flexible enough to permit ordinary technical operations required to deliver the service. A change-control process should govern new purposes, data categories, locations, artificial-intelligence features and subprocessors.

5. Purpose limitation and prohibited uses

The processor should process personal data only for the contracted purpose and documented instructions, except where law requires otherwise. Prohibited-use language should address:

• sale or monetisation of personal data;
• advertising or marketing for the processor’s own benefit;
• combining customer data with unrelated datasets;
• profiling Data Principals for independent purposes;
• training general-purpose artificial-intelligence models without express approval;
• attempted re-identification of masked or pseudonymised data;
• disclosure to unapproved recipients;
• use by employees outside need-to-know roles; and
• retention after termination except where legally required.

If the processor seeks to use aggregated or de-identified data, the contract should define the standard, prohibit re-identification and address whether the output can reasonably be linked back to an individual or customer dataset.

6. Confidentiality, personnel and access control

The processor should ensure that personnel with access are bound by confidentiality obligations, receive role-appropriate training and are subject to access controls. The DPA should require:

• least-privilege access;
• unique user identities;
• multi-factor authentication for privileged and remote access;
• periodic access review;
• prompt de-provisioning after role change or separation;
• segregation of customer environments;
• monitoring of administrator activity;
• background verification where proportionate and lawful; and
• disciplinary and incident-escalation procedures.

Confidentiality provisions should survive termination for as long as the personal data remains confidential or legally protected.

7. Rule 6 minimum security safeguards

Rule 6 requires appropriate processor-contract provisions for reasonable security safeguards. The minimum control framework includes, as applicable:

• encryption, obfuscation, masking or virtual tokens;
• access controls over relevant computer resources;
• logs, monitoring and review to detect unauthorised access;
• investigation and remediation mechanisms;
• backups and continued-processing measures;
• retention of relevant logs and personal data for one year unless another law requires otherwise; and
• technical and organisational measures ensuring effective implementation.

A clause merely requiring “industry-standard security” is often too vague. The DPA should incorporate a detailed security schedule suited to the service, data volume, sensitivity, access model, threat profile and consequences of compromise.

The broader security and commencement framework is examined in our DPDP Act compliance guide.

8. Security schedule: controls that should be specified

Depending on the risk, the security schedule may address:

• encryption in transit and at rest;
• key-management responsibilities and separation;
• network segmentation and tenant isolation;
• secure-development lifecycle and code review;
• vulnerability scanning and penetration testing;
• patching timelines by severity;
• endpoint detection and response;
• anti-malware and ransomware protection;
• backup frequency, immutability and restoration testing;
• logging coverage and tamper protection;
• security-operation monitoring;
• privileged-access management;
• physical and environmental security;
• business continuity and disaster recovery;
• secure media disposal;
• change and configuration management;
• annual independent assurance; and
• remediation deadlines for identified weaknesses.

Certifications can support due diligence, but they do not prove that the specific service, region, subprocessor or data flow is covered. The customer should inspect the scope, exclusions and material findings.

9. Incident and personal-data-breach escalation

The processor must notify the Data Fiduciary quickly enough for the Data Fiduciary to meet its external deadlines. The contract should distinguish:

• a suspected security incident;
• a confirmed cyber incident;
• a confirmed personal-data breach;
• a material service-availability event; and
• a vulnerability that creates an imminent risk.

The processor’s notification period should generally be measured in hours, not days. The clause should require the processor to provide available facts immediately and supplement them as the investigation develops. Notification should not depend on completion of a forensic report.

The initial notice should identify the systems, time, known or suspected data, affected records, containment actions, locations, subprocessors and responsible incident contact. The processor should preserve evidence, provide continuous updates and support all regulator and affected-person communications.

India’s overlapping deadlines are explained in our article on DPDP and CERT-In breach reporting.

10. CERT-In requirements in the DPA

The CERT-In Directions dated 28 April 2022 require covered entities to report specified incidents within six hours and maintain ICT-system logs for a rolling period of 180 days within Indian jurisdiction. Data breaches and data leaks appear in Annexure I.

The DPA should require the processor to:

• notify the customer immediately where an Annexure I incident may be involved;
• preserve and provide necessary logs;
• support the customer’s six-hour reporting decision;
• cooperate with lawful CERT-In directions;
• maintain an updated incident Point of Contact; and
• avoid inconsistent external statements.

Responsibility for making a particular report should be expressly allocated, without restricting either party from complying with a mandatory legal duty.

11. Subprocessors and the vendor chain

A processor may rely on cloud infrastructure, support vendors, email services, security platforms and other subprocessors. Undisclosed subcontracting creates uncontrolled access, location and incident risk.

The DPA should provide for:

• specific or general written authorisation before appointment;
• a current subprocessor list with service and location;
• advance notice of additions or replacements;
• a reasonable objection and remediation process;
• flow-down of equivalent privacy, security, audit, deletion and breach duties;
• continued responsibility of the primary processor for subprocessor performance;
• notification of subprocessor incidents without delay; and
• an exit right where a material objection cannot be resolved.

A right to object is ineffective if the only remedy is continuing to pay for a service that the customer can no longer lawfully use. Commercial exit consequences should be addressed.

12. Data Principal rights and grievance support

The Data Fiduciary remains the primary interface for access, correction, completion, updating, erasure, grievance and nomination rights. The processor should assist by:

• searching relevant systems;
• exporting responsive data in a usable form;
• correcting or deleting records on instruction;
• identifying retention exceptions;
• propagating action to subprocessors;
• preserving request and response evidence; and
• meeting contractual service levels shorter than the Data Fiduciary’s external deadline.

The processor should not independently respond to a Data Principal unless authorised or legally required. Requests received directly should be forwarded promptly and securely.

13. Accuracy, integrity and decisions affecting individuals

Section 8(3) requires completeness, accuracy and consistency where personal data is likely to be used to make a decision affecting a Data Principal or disclosed to another Data Fiduciary.

Where the processor supplies scoring, verification, identity, fraud, credit, recruitment, benefits, health or disciplinary outputs, the contract should address:

• data-quality inputs and validation;
• error-correction procedures;
• model or rule changes;
• human-review mechanisms;
• audit trails explaining material decisions;
• bias and false-positive testing where relevant; and
• allocation of responsibility for final decisions.

A disclaimer stating that all outputs are approximate may not be commercially adequate where the service is procured precisely to support consequential decisions.

14. Retention, return, erasure and legal holds

The DPA should contain a data-retention schedule aligned with the specified purpose and applicable law. On expiry or termination, the customer should be able to choose return, secure deletion or a defined transition period.

The processor should:

• delete active copies and instruct subprocessors;
• address backup deletion cycles;
• provide a deletion certificate where appropriate;
• restrict access to data retained by law;
• identify the legal basis and duration of compulsory retention;
• apply litigation holds on documented instruction; and
• resume deletion when the hold ends.

Immediate deletion without preserving required security logs, tax records, employment records, regulated records or evidence may itself create legal risk. Indefinite retention “for business purposes” is equally weak.

15. Audit, assurance and remediation rights

A workable audit clause should balance customer oversight with security and operational constraints. It may provide a graduated mechanism:

1. annual certifications and audit reports;
2. security questionnaires and supporting evidence;
3. clarification of material findings;
4. targeted remote review;
5. independent assessment; and
6. on-site inspection where a serious incident, regulator request or material non-compliance justifies it.

The processor should remediate critical issues within agreed periods and provide closure evidence. Audit rights without remediation, escalation or termination consequences are incomplete.

16. Cross-border storage and remote access

Section 16 permits the Central Government to restrict transfers to notified countries or territories. Rule 15 permits conditions regarding making personal data available to a foreign State or an entity or person under its control. More protective sectoral laws remain applicable.

The DPA should identify:

• primary and backup hosting countries;
• remote support and administrator locations;
• subprocessor locations;
• cross-border disaster-recovery arrangements;
• data-routing and content-delivery systems;
• Government-access procedures;
• sectoral localisation duties; and
• a change-control mechanism for new locations.

“Hosted in India” does not necessarily mean no cross-border processing. Foreign remote access, support tooling, security telemetry or backups may create additional processing locations.

17. Government and law-enforcement requests

The processor should notify the Data Fiduciary before disclosing personal data pursuant to a Government or law-enforcement request unless notice is legally prohibited. The clause may require:

• verification of the requesting authority and legal process;
• disclosure limited to what is legally required;
• preservation of the request and response;
• reasonable cooperation with a lawful challenge;
• secure transmission; and
• post-prohibition notice where permitted.

The contract cannot require a processor to disobey a binding legal direction. It can require disciplined review, minimisation and transparency where lawful.

18. Artificial intelligence, analytics and product improvement

Vendor terms increasingly reserve broad rights to use customer content for analytics, service improvement or artificial-intelligence training. The DPA should distinguish:

• telemetry necessary to secure and operate the service;
• customer-specific analytics;
• aggregated benchmarking;
• development of commercial models; and
• training of general-purpose models.

Each activity requires a documented role, purpose, data scope, retention position and lawful basis. A processor cannot rely on a broadly drafted “service improvement” clause to convert instructed processing into unrestricted independent use.

19. Liability caps, indemnities and regulatory costs

Because statutory responsibility remains with the Data Fiduciary, commercial risk allocation should be carefully negotiated. Relevant heads may include:

• regulatory investigation and response costs;
• forensic and containment costs;
• affected-person notification and protective measures;
• data restoration;
• third-party claims;
• contractual claims by customers;
• legal and expert costs;
• business interruption;
• credit-monitoring or fraud-prevention expenses; and
• amounts recoverable under a lawful indemnity.

The parties should consider whether ordinary liability caps apply to confidentiality breaches, unauthorised secondary use, deliberate misconduct, gross negligence, infringement, failure to delete data and breach of agreed security controls.

A clause purporting to indemnify a statutory monetary penalty may face enforceability and public-policy issues depending on the circumstances. The contract should not assume that every regulatory penalty can lawfully be transferred. It should separately allocate investigation, remediation and third-party costs.

20. Cyber insurance

Insurance clauses should specify appropriate coverage, limits and evidence. Depending on the service, relevant cover may include cyber liability, technology errors and omissions, privacy liability, network interruption, incident response and media liability.

The customer should examine exclusions, retroactive dates, territorial limits, sublimits, ransomware conditions, waiting periods and insurer consent requirements. A certificate of insurance alone does not reveal the coverage available for the actual incident.

21. Business continuity, transition and termination

Termination rights should cover material privacy or security breach, repeated control failures, prohibited location changes, unapproved subprocessors, regulator objection and failure to remediate.

The exit plan should address:

• continued availability during transition;
• structured data export;
• format and documentation;
• secure transfer to the customer or replacement vendor;
• revocation of access and credentials;
• return or deletion of customer keys;
• subprocessor closure;
• final deletion certification; and
• survival of confidentiality, audit, evidence and indemnity provisions.

Vendor lock-in becomes a data-protection risk where records cannot be exported, corrected, deleted or transferred without disproportionate disruption.

22. Electronic execution, governing law and dispute resolution

Section 10A of the Information Technology Act recognises contracts formed through electronic means, subject to the ordinary requirements of a valid contract. The DPA should be executed by authorised signatories and linked clearly to the master agreement.

Applicable stamp duty depends on the instrument, transaction and relevant State law. The parties should examine stamping where the DPA contains substantive commercial obligations, indemnities, guarantees or other provisions beyond a technical schedule.

The document should align governing law, jurisdiction, arbitration, notice, precedence and amendment provisions with the master agreement. A conflict clause should state whether the DPA prevails on personal-data protection and security matters.

23. Vendor due-diligence checklist before signing

• corporate identity, ownership and financial stability;
• service architecture and data-flow diagram;
• hosting, backup and remote-access locations;
• subprocessor inventory;
• security certifications and their scope;
• recent penetration testing and remediation;
• past material incidents and regulator action;
• access-control and encryption standards;
• log coverage and retention;
• incident-response capability and contacts;
• business-continuity and restoration testing;
• rights-request and deletion capability;
• AI and secondary-use terms;
• insurance coverage;
• Government-request process;
• exit and data-portability capability; and
• contract exceptions proposed by the vendor.

24. Common contractual red flags

• the vendor may change privacy or security terms unilaterally;
• security obligations are limited to “commercially reasonable efforts” without controls;
• incident notice is due only after the vendor completes its investigation;
• the vendor has seven or more days to report a breach;
• subprocessors can be added without notice;
• data may be used for unspecified analytics or AI training;
• all audit rights are excluded;
• deletion is subject to undefined “business needs”;
• hosting location is stated but remote-access locations are omitted;
• the vendor disclaims responsibility for its subprocessors;
• liability is capped at a nominal monthly fee despite high-risk data;
• the customer must indemnify the processor for the processor’s own misconduct;
• certifications are listed without scope or validity; and
• no transition or export mechanism exists.

25. Practical implementation roadmap

1. Inventory vendors: identify every processor and subprocessor touching personal data.
2. Classify roles: distinguish processor functions from independent fiduciary purposes.
3. Risk-tier vendors: prioritise high-volume, sensitive, privileged, financial, employee and children’s data.
4. Collect evidence: security reports, data flows, locations, incidents and insurance.
5. Use a clause matrix: compare existing contracts against Sections 8 and 16 and Rules 6 and 7.
6. Renegotiate: remediate critical gaps before May 2027.
7. Operationalise: load incident contacts, deletion steps and audit dates into governance systems.
8. Test: run a processor breach simulation against the six-hour and 72-hour timelines.
9. Monitor: review material vendor, service, location and subprocessor changes.
10. Preserve evidence: retain approvals, assessments, contracts and remediation closure.

Common Client Questions

Is a separate DPA required for every vendor?

A separate document is not expressly mandated. The required provisions may form part of the master agreement or a schedule, but every processor relationship should be covered by a valid and sufficiently detailed contract.

Can the contract make the processor solely responsible under the DPDP Act?

No. Section 8(1) keeps the Data Fiduciary responsible for processing undertaken by it or on its behalf, irrespective of an agreement to the contrary.

Does a foreign GDPR data-processing addendum satisfy Indian law?

Not automatically. It may provide a useful base, but it must be adapted for Indian definitions, DPDP commencement, Rule 6 safeguards, Rule 7 reporting, CERT-In duties, Indian sectoral requirements and the actual service architecture.

How quickly should a processor report an incident?

The internal contractual deadline should allow the Data Fiduciary to meet all external duties, including the presently operative CERT-In six-hour deadline. For many services, immediate notice with a short outside period measured in hours is appropriate.

Can a processor appoint subprocessors without approval?

The Act does not prescribe one universal approval model, but the Data Fiduciary’s non-transferable responsibility makes authorisation, transparency, equivalent obligations and an effective objection mechanism important controls.

Must all personal data remain in India?

The DPDP Act does not impose a universal localisation rule. Section 16 permits notified restrictions, while sectoral laws and contracts may impose stricter requirements. Remote access, backups and subprocessors must also be assessed.

Can a DPA be electronically signed?

Indian law recognises contracts formed through electronic means, subject to ordinary validity, authority and applicable stamping requirements.

Authoritative legal sources

• Digital Personal Data Protection Act, 2023 — India Code
• Section 8 DPDP Act — Data Fiduciary and processor obligations
• Section 16 DPDP Act — processing outside India
• Digital Personal Data Protection Rules, 2025 — MeitY
• DPDP Act enforcement timeline — India Code
• CERT-In Cyber Security Directions dated 28 April 2022
• Information Technology Act, 2000 — India Code

Legally reviewed: 20 August 2026. Disclaimer: This article provides general legal and contractual information. The correct role, processing architecture, current Government notifications, sectoral law, stamp duty and contract terms must be verified for the specific transaction.