Asweeraah Associates monogramASWEERAAHASSOCIATESContact ↗
← Legal updates

CONTRACTS & TECHNOLOGY / FOR BUSINESSES

Software, cloud and AI vendors after the DPDP Rules: the contract clauses a business should check

When a SaaS, payroll, CRM, cloud or AI vendor handles personal data for a business, the Digital Personal Data Protection Act, 2023 keeps the legal duty with the business, so the vendor contract is where that duty is passed down the chain.

By Adv. Gurleen KaurLaw stated as at 28 October 2026About 1620 words

Most SMEs run payroll, customer records and billing through outside software that holds employees' or customers' personal data. The Digital Personal Data Protection Act, 2023 (the "Act") and the Digital Personal Data Protection Rules, 2025 (the "Rules", G.S.R. 846(E), 13 November 2025) decide who answers for that data. The vendor contract is where that answer takes effect.

Under Rule 1, Rules 6, 7, 8 and 15, discussed below, come into force eighteen months after publication, that is, on 13 May 2027. Many contracts signed today will still be running then. Sections 8 and 16 of the Act apply from the same date (G.S.R. 843(E), 13 November 2025).

1. The business stays responsible

The business deciding the purpose and means of processing is the "Data Fiduciary" (s. 2(i)); a vendor processing on its behalf is a "Data Processor" (s. 2(k)). Section 8(1) makes the Data Fiduciary responsible for compliance, including for processing by its Data Processor, "irrespective of any agreement to the contrary". A clause making the vendor "solely responsible" for compliance does not move the statutory duty. The contract can only make the vendor bear cost, cooperate and follow instructions.

2. No processing without a valid contract

Section 8(2) permits a Data Fiduciary to involve a Data Processor to process personal data on its behalf "only under a valid contract". The Act prescribes no model form. Often a click-through terms-of-service page is the only contract on record, so it should be read as the data processing agreement.

3. Where AI tools fit

The primary texts reviewed contain no AI-specific Indian statute. AI tools are reached through the definition of "processing": "a wholly or partly automated operation or set of operations performed on digital personal data" (s. 2(x)). Pasting customer or employee details into an AI assistant or chatbot builder is processing. A provider acting on the business's behalf is a Data Processor, so s. 8(2) applies. If the vendor's terms let it use inputs for its own purposes, such as model improvement, it may itself be deciding the purpose of processing (s. 2(i)).

Using AI tools with business data

The terms of the AI provider decide what happens to what staff type in. Two examples, as published by the providers and checked on 28 October 2026:

  • Anthropic (Claude). From 28 August 2025, users of the individual Free, Pro and Max plans choose whether their chats may be used to train models, and can change that choice at any time in Privacy Settings. If they allow it, data is kept for up to five years; otherwise the 30-day retention period applies. The change does not apply to services under Anthropic's Commercial Terms, such as Claude for Work (Team and Enterprise) and the API (Anthropic, "Updates to Consumer Terms and Privacy Policy").
  • OpenAI (ChatGPT). Conversations may be used for training unless the user turns off "Improve the model for everyone" in Settings > Data Controls. Temporary Chats are not used for training and are deleted within 30 days (OpenAI, Data Controls FAQ).

Provider terms change, so the current terms of each tool should be read before staff use it with business data. Three practical measures follow from the Act: keep names, phone numbers and identity numbers out of prompts where the task does not need them (s. 6(1) limits data to what is necessary for the purpose); prefer business plans or switch off model training; and record in a short internal rule which AI tools staff may use and for what.

4. Security safeguards: s. 8(5) and Rule 6

Section 8(5) requires reasonable security safeguards to prevent a personal data breach, "including in respect of any processing undertaken by it or on its behalf by a Data Processor". Rule 6(1) sets minimum measures:

  • data security measures such as encryption, obfuscation, masking or the use of virtual tokens mapped to the personal data (Rule 6(1)(a));
  • access control over the computer resources used by the Data Fiduciary or Data Processor (Rule 6(1)(b));
  • logs, monitoring and review to detect and address unauthorised access (Rule 6(1)(c));
  • backups and other measures for continued processing if data is lost or compromised (Rule 6(1)(d));
  • retention of those logs and personal data for one year, unless another law requires otherwise (Rule 6(1)(e));
  • "appropriate provision in the contract entered into between such Data Fiduciary and such a Data Processor" for taking reasonable security safeguards (Rule 6(1)(f)); and
  • appropriate technical and organisational measures to make sure the safeguards are observed (Rule 6(1)(g)).

Rule 6(1)(f) is the express contract requirement. A contract silent on security falls short of it.

5. Breach intimation: s. 8(6) and Rule 7

On a personal data breach, s. 8(6) requires the Data Fiduciary to inform the Data Protection Board of India and each affected Data Principal. Rule 7(1) requires notice to affected persons "without delay". Rule 7(2) requires an initial intimation to the Board without delay and, within seventy-two hours of becoming aware of the breach, a detailed report on facts, reasons, mitigation, findings on who caused it, remedial steps and notices sent (Rule 7(2)(b)).

Rule 7 places no reporting duty on the Data Processor, yet a breach in a vendor's systems is usually found by the vendor first. Unless the contract makes the vendor tell the business promptly, with the Rule 7(2)(b) information, the business may miss its own deadlines. Penalties may extend to ₹250 crore for failing to take reasonable security safeguards and ₹200 crore for failing to give breach intimation (s. 33 and the Schedule).

CERT-In's six-hour rule

The CERT-In Directions dated 28 April 2022, under s. 70B(6) of the Information Technology Act, 2000, apply to "service providers, intermediaries, data centres, body corporate and Government organisations". Direction (ii) requires incidents listed in Annexure I, including "Data Breach" and "Data Leak", to be reported to CERT-In within six hours of noticing them or being brought to notice of them. Direction (iii) requires a Point of Contact. Direction (iv) requires ICT system logs to be kept for a rolling 180 days within Indian jurisdiction. A vendor promising notice "within a reasonable time" does not fit a six-hour window.

6. Erasure and exit: s. 8(7), s. 8(8) and Rule 8

Section 8(7) requires erasure on withdrawal of consent or once the specified purpose is no longer served, whichever is earlier, unless law requires retention; under s. 8(7)(b) the Data Fiduciary must also cause its Data Processor to erase data made available to it. Section 8(8), with Rule 8(1)–(2), sets inactivity periods only for the Third Schedule classes of Data Fiduciaries.

Rule 8(3) adds a minimum: personal data, traffic data and processing logs, including for processing by a Data Processor, must be kept for at least one year from processing for the Seventh Schedule purposes. An exit clause should therefore require return, erasure and a written certificate, while stating who keeps what the law requires to be retained (Rule 6(1)(e), Rule 8(3), CERT-In Direction (iv)) and for how long.

7. Data stored outside India: s. 16 and Rule 15

Section 16(1) lets the Central Government, by notification, restrict transfers to a country or territory outside India; s. 16(2) preserves other laws giving higher protection or restriction. Rule 15 permits transfer subject to requirements the Central Government may specify by general or special order on making data available to a foreign State or entities under its control. Before agreeing to storage outside India, a business should check whether any such notification or order has been issued. The contract should disclose where data and backups sit, list sub-processors and locations, and require notice of change.

8. Liability caps, indemnity and damages

SaaS terms often cap liability at a few months' fees and exclude "indirect" loss. Under s. 73 of the Indian Contract Act, 1872, compensation covers loss that "naturally arose in the usual course of things" from the breach, or that the parties knew to be likely when contracting, but not "remote and indirect loss or damage". Under s. 74, where a contract names a sum payable on breach, the injured party may recover reasonable compensation not exceeding that sum. Section 124 defines a contract of indemnity as a promise to save the other party from loss caused by the promisor's own conduct or that of any other person; s. 125 sets out what an indemnity-holder may recover when sued.

The points to check are whether breach-response costs (investigation, notices, data restoration) are excluded as "indirect", and whether the indemnity covers vendor-caused breaches. The provisions discussed do not say whether a Board penalty can be passed on through an indemnity.

Clause checklist

ClauseWhat to look forLegal hook
Roles and instructionsVendor processes only on the business's documented instructions and for the stated purposeAct s. 2(i), 2(k), 8(1), 8(2)
Own-use of data (incl. AI training)No use of inputs or outputs for the vendor's own purposes without express agreementAct s. 2(i), 2(x), 8(2)
Security scheduleEncryption or masking, access control, logging, backups, staff measuresAct s. 8(5); Rule 6(1)(a)–(g)
Breach notice to businessA fixed short window, a named contact, and the Rule 7(2)(b) informationAct s. 8(6); Rule 7; CERT-In Directions (ii)–(iii)
LogsRetention periods and access to logs on requestRule 6(1)(e), 8(3); CERT-In Direction (iv)
Sub-processorsList, prior notice of changes, same obligations passed downAct s. 8(1), 8(5); Rule 6(1)(f)
Data locationCountries of hosting and backup; change notice; compliance with any government orderAct s. 16; Rule 15
Exit and erasureReturn, erasure, certificate, and retention only where law requiresAct s. 8(7)(b), 8(8); Rule 8
Liability cap and exclusionsWhether breach-response costs are excluded as "indirect"; a separate cap for data breachesContract Act s. 73, 74
IndemnityCovers third-party claims and losses from the vendor's data breachesContract Act s. 124, 125

Author’s view

The reality is that most small businesses and their vendors have no written contract at all. Under s. 8(2), that is itself a gap, because a vendor may process personal data only under a valid contract.

A click-through "I agree" is a valid contract, and the IT Act recognises contracts formed electronically (s. 10A, Information Technology Act, 2000). But valid is not the same as sufficient. Most standard terms were not written with the DPDP Rules in mind.

Small businesses cannot negotiate with large software providers. They can still choose vendors whose published terms cover security, breach notice and exit, save those terms on the day they sign up, and use every security setting offered. For smaller local vendors, a simple written addendum is enough.

AI tools are improving productivity, and businesses will keep using them. The answer is not to stop, but to use business plans or switch off model training, and to keep names and identifiers out of what is typed in.

The Act places full liability on the business even when the vendor caused the breach (s. 8(1)). In my view, responsibility should be shared, with the Board deciding who caused it.

If a business checks only one clause, it should be breach notice. Without it, no business can meet a six-hour or seventy-two-hour deadline.

Because most small businesses have no written terms with their vendors at all, I have prepared a Model Data-Processing Addendum for SMEs. It is a short, plain-language form that a business can ask a smaller vendor to sign, with a check sheet for large providers whose terms cannot be negotiated.

The model form is general material, offered free for information. It is not legal advice, does not create an advocate–client relationship, and may not suit every arrangement. Anyone using it should adapt it to their facts and the law current at the time of use. To the extent permitted by law, the author accepts no liability for any loss arising from its use.

Adv. Gurleen Kaur

Primary sources

Model data-processing addendum ↗

Contracts, leases & technology ↗

ASWEERAAH ASSOCIATES

BEFORE YOU CONTINUE

A note about
this website.

The Bar Council of India does not permit advocates to advertise or solicit work. This website provides general information about the practice and about legal developments. It is not legal advice, an advertisement or an invitation to engage professional services.

Please do not send confidential information until an engagement has been agreed.

This acknowledgement is not consent to marketing or tracking. It is remembered only for this browser tab’s session.