How to Draft a Dpdp-compliant Data Processing Agreement (DPA) for Saas & Cloud Providers

To draft a DPDP-compliant data processing agreement (DPA) for SaaS and cloud services in India, you need more than a summary of the Digital Personal Data Protection Act, 2023, you need practical, negotiable contract language that survives commercial pushback and regulatory scrutiny. The DPDP Act recasts how businesses that handle personal data must allocate responsibility, secure information, notify breaches and address cross-border data flows. This guide gives in-house counsel, procurement teams and technology vendors a step-by-step drafting playbook, a mandatory-clause checklist, a negotiable-versus-non-negotiable comparison table, and a short clause bank you can adapt. Everything here is general guidance and not legal advice; every clause must be reviewed by qualified counsel before use.

Why a DPDP-specific DPA matters for SaaS and cloud contracts

The Digital Personal Data Protection Act, 2023 (DPDP Act) applies to the processing of digital personal data within India and, in defined circumstances, to processing outside India connected to offering goods or services to individuals in India. For SaaS and cloud providers, the practical consequence is that generic international data processing addenda no longer suffice on their own. When you draft a DPDP-compliant DPA, you are translating statutory obligations, around purpose limitation, security safeguards, breach handling and cross-border movement, into enforceable contract language between a data fiduciary and its data processor.

India’s constitutional foundation for this framework was laid in K.S. Puttaswamy v. Union of India, in which the Supreme Court recognised the right to privacy as a fundamental right under the Constitution. The DPDP Act operationalises that principle for the digital economy. Note that, as of the current year, the DPDP Act’s operative provisions come into force on dates notified by the Central Government, and the Digital Personal Data Protection Rules give effect to many of its requirements; drafting should track the provisions and rules as they are notified. A well-drafted DPA is where compliance meets commercial reality: it is the document a regulator, a customer’s auditor or a court will look to when something goes wrong.

What is a DPDP-compliant DPA, roles, scope and lawful basis

A DPA is the contract that governs how a data processor handles personal data on behalf of a data fiduciary. Under the DPDP framework it should define the purpose of processing, the security measures applied, breach and assistance obligations, transfer rules and the processor’s duty to help the fiduciary meet its statutory compliance. Before drafting a single clause, you must correctly classify the parties, because the entire allocation of duties flows from that classification.

Definitions, data fiduciary, data processor, personal data

The DPDP Act introduces a distinct vocabulary that differs from the controller/processor language many multinationals are used to. The data fiduciary is any person who alone or in conjunction with others determines the purpose and means of processing personal data. The data processor is any person who processes personal data on behalf of a data fiduciary. Personal data means any data about an individual who is identifiable by or in relation to such data.

In a SaaS or cloud relationship, the customer is usually the data fiduciary and the vendor is the data processor, though a vendor may act as a fiduciary for data it processes for its own purposes (billing, product analytics, security telemetry). Sample framing:

“The Customer is the Data Fiduciary and the Provider is the Data Processor in respect of Customer Personal Data. Where the Provider determines the purpose and means of processing any personal data for its own account, the Provider acts as an independent Data Fiduciary for that processing.” (draft, adapt & verify with counsel)

Scope and lawful bases for processing under DPDP

The DPA should tie processing to the fiduciary’s lawful basis. Under the DPDP Act, processing generally proceeds on the basis of consent or certain legitimate uses recognised by the statute. The processor should never determine lawful basis; instead the DPA should require the processor to act only on the fiduciary’s documented instructions and to flag any instruction it believes conflicts with the law. Capture the scope precisely, the categories of data, the categories of data principals, the processing operations, and the duration, so that the permitted use is unambiguous and any processing beyond it is a contractual breach.

Mandatory DPA clauses under DPDP, a drafting checklist

When you draft DPDP-compliant DPA documentation, the following clauses form the compliance backbone. Each should be present, precise, and mapped to a statutory or operational obligation. Missing or vague clauses are a common source of disputes and regulatory exposure.

• Purpose and scope of processing. State exactly why data is processed and prohibit any use outside the specified purpose without written instruction.
• Duration of processing. Link processing to the term of the underlying services agreement and define post-termination handling.
• Categories of personal data and data principals. Schedule the data types and affected individuals so scope creep is measurable.
• Sub-processors and onward transfers. Set the consent model (general or specific), require flow-down of equivalent obligations, and preserve the fiduciary’s right to object.
• Security measures. Specify baseline technical and organisational controls and how compliance is evidenced.
• Breach notification and escalation. Define what triggers notice, the timeline, the content of the notice and remediation obligations.
• Data principal rights assistance. Oblige the processor to help the fiduciary respond to access, correction and erasure requests within agreed service levels.
• Audit and inspection rights. Define the form, frequency and scope of assurance the processor must provide.
• Deletion or return at termination. Set secure deletion standards and require a certificate of deletion.
• Liability, indemnity and limitations. Allocate risk with caps and carve-outs proportionate to the data sensitivity.
• Record-keeping and cooperation with the Data Protection Board. Require the processor to maintain records and assist with any inquiry from the Data Protection Board of India established under the Act.
• Cross-border transfer compliance. Restrict transfers to mechanisms permitted under the Act and the fiduciary’s policies.

Quick contract language snippets for mandatory clauses

Short, drafted lines you can expand:

• Purpose: “The Processor shall process Customer Personal Data solely to provide the Services and only on the Customer’s documented instructions.”
• Sub-processors: “The Processor shall not engage a new sub-processor without giving the Customer at least thirty days’ prior written notice and a right to object.”
• Cooperation: “The Processor shall, at the Customer’s cost, provide reasonable assistance in responding to any inquiry, notice or direction from the Data Protection Board of India.”

Each snippet above is a starting point marked (draft, adapt & verify with counsel).

Security, incident detection and breach notification

Security and breach handling are the clauses most likely to be tested in practice, so they deserve disproportionate drafting attention. This is also where DPDP obligations intersect with India’s cyber incident reporting regime administered by the Indian Computer Emergency Response Team (CERT-In).

Mapping contractual security obligations to standards

Rather than describing controls in the abstract, anchor them to recognised frameworks. Requiring the processor to maintain an information security management system certified to ISO/IEC 27001, and to provide a current SOC 2 Type II report, gives the fiduciary independently verified assurance without prescribing every control line by line. State a baseline (encryption in transit and at rest, access controls, logging, vulnerability management) and require the processor to keep controls at least commensurate with the certified standard for the term of the contract. Referencing established security standards such as ISO/IEC 27001 and SOC 2, aligned to DPDP obligations, makes the clause auditable rather than aspirational.

Incident detection, triage, and notification timelines

The DPDP framework requires processors to assist fiduciaries in meeting their breach obligations, and CERT-In’s directions impose separate technical reporting duties for certain cyber incidents. CERT-In’s April 2022 directions require reporting of specified cyber incidents to CERT-In within six hours of noticing or being notified about them, which is a distinct obligation from the fiduciary’s obligations under the DPDP Act. Contractually, most parties adopt a tight notification window, commonly requiring the processor to notify the fiduciary of a confirmed personal data breach within 24 to 72 hours of detection. Treat these figures as recommended commercial practice unless a statute or regulator prescribes a specific period.

The clause should specify the content of the notice (nature of the breach, data affected, likely consequences, remediation steps) and require ongoing updates until closure. A breach notification clause without content requirements is of little use during a live incident.

Obligations to assist with regulator and Data Protection Board investigations

Require the processor to preserve evidence, cooperate with forensic investigation, and provide the information the fiduciary needs to respond to the Data Protection Board of India or CERT-In, subject to reasonable confidentiality protections.

Cross-border transfers, permitted mechanisms and sample clauses

Cross-border data flows are unavoidable for most cloud providers, and cross-border data transfer compliance is a frequent negotiation flashpoint. The DPDP Act permits transfer of personal data outside India, subject to any restrictions the Central Government may notify in respect of specified territories or countries. Sector-specific localisation and transfer rules (for example, in banking, payments and insurance) continue to apply independently. The DPA should therefore be flexible enough to adapt as the regulatory position evolves.

Transfer mechanisms under DPDP

Practical mechanisms include reliance on standard contractual provisions embedded in the DPA, transfers to jurisdictions not restricted under any government notification, and additional contractual safeguards where the fiduciary requires them. Because any notified list of restricted destinations can change, draft the clause to reference “any country or territory not restricted by the Central Government under the Act” rather than hard-coding a fixed list. Regulated sectors face additional constraints, for example, entities in the financial sector must also observe applicable Reserve Bank of India outsourcing, data storage and IT governance requirements.

Sample clause: permitted transfers and localisation obligations

“The Processor shall not transfer Customer Personal Data outside India except (a) to a country or territory not restricted under the Act, and (b) subject to the safeguards in Schedule [X]. Where the Customer designates data as subject to localisation, the Processor shall store and process such data only within India.” (draft, adapt & verify with counsel)

Practical negotiation points for SaaS and cloud providers

Providers typically resist rigid data localisation because it fragments their architecture; customers in regulated industries often insist on it for critical data. A workable compromise is narrow localisation limited to defined categories of sensitive or regulated data, combined with contractual safeguards and transparency about processing locations for everything else.

Audit, inspection and third-party assessments

Audit and inspection rights in DPA negotiations pit a customer’s desire for assurance against a provider’s need to protect a multi-tenant environment. The goal is verifiable assurance without operational disruption.

On-site audits vs compliance evidence

Most mature SaaS providers offer independent assurance, current SOC 2 Type II and ISO/IEC 27001 reports, penetration test summaries and their written information security programme, in lieu of routine customer on-site audits. This can satisfy the fiduciary’s diligence needs while preserving the provider’s security posture. Reserve on-site audit rights for defined triggers, such as a material breach or a specific regulator direction.

Practical clause language and scope limitations

Constrain audit rights with sensible boundaries: reasonable prior notice, no more than once per twelve months absent cause, conducted during business hours, subject to confidentiality, and scoped to the systems processing the customer’s data. Permit redaction of information relating to other customers. A balanced clause gives the fiduciary meaningful oversight without exposing the provider to unlimited disruption.

Deletion, return and data retention obligations

Termination is where deletion and return obligations matter most. The DPA should require the processor to return or securely delete all personal data on termination, at the fiduciary’s election, and to certify deletion in writing. Specify the deletion standard (secure, irrecoverable erasure including backups within a defined cycle) and a retention schedule for the term. Build in a narrow exception permitting limited retention where required by law or a legal hold, with continuing confidentiality and security obligations attaching to any retained copies. Where a customer needs continuity during wind-down, allow a defined retrieval window before deletion is executed.

Liability, indemnities and insurance

Risk allocation is the most heavily negotiated section of any DPA, because it determines who bears the financial consequences of a data incident.

Allocating liability between fiduciary and processor

Under the DPDP Act, financial penalties may be imposed following the Data Protection Board’s inquiry and enforcement process, and the fiduciary generally carries primary accountability to data principals. Contractually, the parties can and should reallocate that risk between themselves. Indemnities are appropriate where the processor’s breach of its security or confidentiality obligations directly causes the fiduciary’s loss, including third-party claims and, where recoverable, penalties attributable to the processor’s default. Distinguish clearly between penalties imposed on the fiduciary under the Act and contractual remedies between the parties, the two are not interchangeable, and drafting should not assume statutory penalties can automatically be passed through.

Caps, exclusions and cyber insurance

A liability and indemnity negotiation usually turns on the cap. Providers favour a cap equal to fees paid in the prior twelve months; customers seek uncapped liability for data breaches. A common landing zone is a super-cap of one to three times annual fees for data protection breaches, with carve-outs from the cap for gross negligence, wilful misconduct and breach of confidentiality. Require the processor to maintain adequate cyber liability insurance and to evidence cover on request. Insurance is a backstop, not a substitute for a properly negotiated cap and indemnity.

Negotiable vs non-negotiable clauses, how to draft DPDP-compliant DPA terms that hold

Understanding negotiable vs non-negotiable DPA clauses lets both sides focus energy where it matters. Statutory compliance obligations, purpose limitation, security, breach cooperation, Data Protection Board cooperation, are effectively non-negotiable. Commercial risk terms are where negotiation happens. The table below sets out typical positions and workable compromises.

Sample clause bank, copy and adapt

The following short clauses are drafting starting points. Each is marked (draft, adapt & verify with counsel) and none is binding as written.

• Scope and purpose. “The Processor shall process Customer Personal Data only to provide the Services, only on the Customer’s documented instructions, and never for its own purposes.” (draft, adapt & verify with counsel)
• Sub-processors. “The Processor may engage sub-processors under a general authorisation, provided it maintains a current list, gives 30 days’ notice of changes, and imposes obligations no less protective than this DPA.” (draft, adapt & verify with counsel)
• Security measures. “The Processor shall maintain an ISO/IEC 27001-certified information security programme and technical and organisational measures appropriate to the risk.” (draft, adapt & verify with counsel)
• Breach notification. “The Processor shall notify the Customer without undue delay and in any event within 72 hours of confirming a personal data breach, providing the details necessary for the Customer to meet its statutory obligations.” (draft, adapt & verify with counsel)
• Audit and inspection. “The Processor shall provide annual third-party assurance reports and, on reasonable notice and no more than once yearly absent cause, permit audit of systems processing Customer Personal Data.” (draft, adapt & verify with counsel)
• Deletion and return. “On termination the Processor shall, at the Customer’s election, return or securely delete all Customer Personal Data and certify deletion within 30 days, subject to retention required by law.” (draft, adapt & verify with counsel)
• Liability and cap. “Each party’s aggregate liability for data protection breaches shall not exceed [1–3x] the annual fees, save for gross negligence, wilful misconduct or breach of confidentiality.” (draft, adapt & verify with counsel)
• Cross-border transfers. “The Processor shall transfer Customer Personal Data outside India only to countries or territories not restricted under the Act and subject to the safeguards in Schedule [X].” (draft, adapt & verify with counsel)

Practical negotiation playbook for SaaS and cloud providers

Calibrate your negotiation to contract value and data sensitivity. For low-value, low-risk deals, accept the provider’s standard DPA with minor edits to breach timelines and deletion certification. For high-value or regulated deals, escalate on liability caps, localisation of critical data, and sub-processor objection rights. Redlines worth accepting quickly include reasonable audit-frequency limits and general sub-processor consent with notice. Redlines to escalate include unlimited liability, unrestricted cross-border transfers of sensitive data, and any attempt to weaken breach cooperation. Document every deviation from your standard so your risk position remains defensible if the Data Protection Board or a customer’s auditor asks.

Compliance checklist and next steps

Before signing, run this ten-point check:

1. Parties correctly classified as fiduciary and processor.
2. Purpose, data categories, data principals and duration scheduled.
3. Lawful-basis reliance and instruction-only processing confirmed.
4. Security controls anchored to ISO/IEC 27001 / SOC 2 evidence.
5. Breach notification timeline, content and remediation defined.
6. Sub-processor consent, notice and objection rights set.
7. Cross-border transfer mechanism and any localisation captured.
8. Audit rights scoped with frequency, notice and confidentiality.
9. Deletion/return, certification and retention exceptions drafted.
10. Liability cap, carve-outs, indemnity and insurance agreed.

Conclusion

To draft DPDP-compliant DPA terms that protect both sides, treat the DPA as the operational bridge between statutory obligation and commercial reality, precise on roles, security, breach handling, transfers, deletion and liability, and flexible enough to adapt as India’s regulatory position matures. Use the checklist, comparison table and clause bank above as a foundation, but always secure India-qualified legal review before execution. If you need bespoke drafting or a clause-by-clause review of an existing agreement, seek specialist advice to ensure your contracts stand up to both customer scrutiny and the Data Protection Board.

Sources

1. Ministry of Electronics & Information Technology (MeitY), Digital Personal Data Protection Act, 2023 and Rules
2. Gazette of India (eGazette)
3. Indian Computer Emergency Response Team (CERT-In)
4. Reserve Bank of India (RBI)
5. Supreme Court of India
6. Bar Council of India