Data Processor obligations under DPDP: what you actually have to do

If you process personal data on somebody else's behalf, the honest answer to what DPDP requires of you is stranger than either extreme you will have been told. You are not a duty holder the way your customer is. You are also not outside this framework, and something already binds you today that has nothing to do with DPDP at all.

The framework never addresses you by name

Start with the count, because it settles the argument faster than any reasoning.

All of them, so you can check: section 2(k) defines the term; section 6(6) and its Illustration have the fiduciary cease and cause its processors to cease; section 8(1) makes the fiduciary responsible for processing done on its behalf; section 8(2) permits it to engage you only under a valid contract; section 8(5) has it protect data including where you handle it; section 8(7)(b) has it cause you to erase, using the term twice in that one clause, which is why 8 places carry 9 occurrences; section 11(1)(b) has it able to name you. In the Rules: Rule 6(1), 6(1)(b) and 6(1)(f), Rule 8(3), the Illustration to Rule 8, and item (f) of the Second Schedule.

Neither instrument contains a sentence beginning "A Data Processor shall." There is no processor register, no breach intimation duty of your own in either instrument, and no penalty entry aimed at a processor as such.

But you are not outside the Act, and this part is unsettled

One provision does not follow the pattern, and you should know it before you repeat the paragraph above to a customer.

"A person may process the personal data of a Data Principal only in accordance with the provisions of this Act and for a lawful purpose,— (a) for which the Data Principal has given her consent; or (b) for certain legitimate uses."

That is section 4(1), and it says person, not Data Fiduciary. Person is a defined term, and section 2(s) includes "a company" in it. Section 7, which is 3 sections later, opens "A Data Fiduciary may process", so the wider word in section 4 looks like a choice rather than an accident.

Against that reading, section 4 sits in Chapter II, whose heading is "Obligations of Data Fiduciary", and construing it to bind a processor would create a duty the Act nowhere elaborates. This site does not decide which reading is right and no Indian decision construing it has been found. It is flagged because it is the difference between having no direct statutory duty and having 1.

Two enforcement provisions lean the same way. The Board may "issue such directions as it may consider necessary to such person, who shall be bound to comply with the same" under section 27(2). And section 33(1) allows a penalty where a breach "by a person" is significant, with entry 7 of the Schedule covering "breach of any other provision of this Act or the rules made thereunder" at up to 50 crore rupees.

So the accurate statement to make in a security questionnaire is that no duty is addressed to you as a Data Processor, not that the Act says nothing to you at all.

What binds you today, and it is not DPDP

None of the DPDP duties above is in force. The definitions in section 2, including 2(k) and 2(s), are the exception: paragraph (a) of G.S.R. 843(E) brought section 2 into force on 13 November 2025, an official date and not a computed one, but a definition imposes nothing. One duty on you is, and processors routinely miss it because it sits in a different statute.

"Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents."

Those are the CERT-In directions of 28 April 2022, made under section 70B(6) of the Information Technology Act, 2000 and effective 60 days after they were issued. They bind a body corporate in its own name, they do not route through your customer, and Annexure I includes Data Breach and Data Leak at items xi and xii. The clock is 6 hours from noticing. On 28 August 2026 CERT-In's own section 70B directions page listed no amendment to them and no instrument replacing them; it listed 2 further documents, the May 2022 FAQs and a 27 June 2022 notice extending certain enforcement timelines for MSMEs and for subscriber validation, and this site holds neither, so treat any question about those 2 as unverified here.

If you build only for the DPDP timeline you will have built for the wrong deadline. DPDP in 72 hours, CERT-In in 6 hours sets both clocks side by side.

Everything else reaches you through the contract

Section 8(2) is the hinge, and read carefully it is a duty on your customer rather than on you:

"A Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering of goods or services to Data Principals only under a valid contract."

The Act does not say what that contract must contain. "Valid contract" is not defined; the words appear once in the whole Act. The Rules then add exactly 1 specified element, in Rule 6(1)(f): "appropriate provision in the contract entered into between such Data Fiduciary and such a Data Processor, wherever applicable, for taking reasonable security safeguards".

That single clause is why the requests will come. Your customer's own safeguards duty is discharged in part by the provision existing in your contract, so it has a reason to insist that is nothing to do with goodwill. For the clause by clause treatment, and for which of the usual terms have no statutory basis at all, the clauses a DPDP data processing agreement needs is the page that works through them.

The 2 duties that pull against each other

This is the part worth designing for, because the framework asks a processor to be able to do 2 opposite things on instruction.

Erase. Section 8(7)(b) requires the fiduciary to "cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor". Your deletion path is your customer's compliance path.

Retain, for at least 1 year. Rule 8(3) requires the fiduciary to retain personal data, associated traffic data and other logs "in respect of any processing of personal data undertaken by it or on its behalf by a Data Processor" for a minimum of 1 year from the date of processing, "for the purposes as specified in the Seventh Schedule". Those purposes are the 3 State purposes at Gazette pages 40 and 41 for which rule 23(1) lets the Central Government call for information. Whether those words limit which Data Fiduciaries must retain, or only state what the retention is for, is not settled on the face of the rule: sub-rule (3) is addressed to "a Data Fiduciary" without the class limit sub-rule (1) carries, and both Illustrations apply it to ordinary commercial services. This site does not decide it. The Illustration to Rule 8 is squarely about a vendor like you:

"Case 2: X, a company engages a cloud service provider C as its Data Processor to host customer records. X as the Data Fiduciary, is required to ensure that the C also retains the data and associated logs for at least one year before erasure, unless any other applicable law requires a longer period."

Read those together and the product requirement falls out. You need deletion on instruction, and a retention hold on instruction, and you need to know which applies to which data for which customer. A single global delete button serves one of those duties and defeats the other, and since both duties sit on your customer rather than on you, the exposure it creates is theirs before it is yours. That is a recommendation of ours rather than anything either instrument prescribes: nothing in the Act or the Rules tells you to build a capability.

Two smaller ones in the same family. Section 6(6) has your customer cease and cause you to cease when consent is withdrawn, so a stop signal has to be actionable and not merely contractual. And section 11(1)(b) gives an individual the right to be told the identities of the processors her data was shared with, which is why you will be asked to appear in a register.

What the framework does not ask for

Worth stating plainly, because these get negotiated as though Indian law required them. Counted across both instruments in full on 28 August 2026:

Confidentiality appears in the definition of personal data breach in section 2(u), in the employment legitimate use in section 7(i), and in Rule 6(1)(d). In none of the 3 is it an obligation owed by a processor.

That does not make those clauses unreasonable to agree. It means that when a customer says Indian law requires a documented instruction regime, a subprocessor consent right or an annual audit right, no provision of the Act or the Rules says so, and the request is a commercial one. The framework's only audit duty sits elsewhere and is not a right over you: section 10(2)(b) requires a Significant Data Fiduciary to appoint an independent data auditor to evaluate its own compliance and section 10(2)(c)(ii) requires periodic audit, so an SDF customer has a reason of its own to ask. Negotiate it as such.

If you are an Indian processor serving foreign clients

There is a carve out, and it is narrower than the sector treats it. Section 17(1)(d) is one of the listed cases in which section 17(1) disapplies Chapter II except sections 8(1) and 8(5), all of Chapter III and section 16:

"personal data of Data Principals not within the territory of India is processed pursuant to any contract entered into with any person outside the territory of India by any person based in India"

Note what it fixes on. Not where the processing happens, but 2 things together: the Data Principals must not be within the territory of India, and the contract must be one entered into with a person outside India by a person based in India. A contract with an overseas customer is not enough on its own if the individuals whose data you handle are in India. And the security safeguards duty in section 8(5) survives inside the exemption while the breach intimation duty in section 8(6) falls away. What a section 17 exemption switches off, and what survives goes through it provision by provision.

When this starts

Sections 4, 8, 11, 17 and 33, section 6 other than sub-section (9), and section 27 other than clause (d) of sub-section (1), are all named in paragraph (c) of commencement notification G.S.R. 843(E), the group coming into force 18 months after publication, and Rule 1(4) puts Rules 6, 7 and 8 in the Rules' own 18 month group. That computes to 13 May 2027, which is interpretation until officially confirmed.

The CERT-In duty is the exception and needs no waiting: it took effect 60 days after 28 April 2022 and has been in force since.

What to actually build

Answer the role question per data flow, not per company. You are almost certainly a Data Fiduciary for your own users at the same time as a processor for your customers, and the duties differ completely. The role checker runs it flow by flow, and does DPDP apply to B2B SaaS companies works through holding both roles at once.

Get the CERT-In path working first. It is the only one of these duties with a live clock, it is 6 hours, and it does not route through your customer.

Build delete on instruction and hold on instruction as separate capabilities. Then decide, per customer and per data category, which one is armed.

Expect the security clause and do not resist it. Rule 6(1)(f) will make it part of your customer's own compliance when it commences, so refusing it asks them to accept a gap in theirs.

Be nameable. Your customer may have to identify you to an individual exercising the access right, so know which of your own vendors touch their data before you are asked.

Do not tell customers the Act imposes duties on you directly, and do not tell them nothing reaches you either. Both are wrong. Run the vendor and processor checklist from your side of the relationship and you will have the provision for each item when it is queried.