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. If DPDP itself is new to you, start with the short introduction, what DPDP is.

This page assumes you are a Data Processor for the processing in question. If that is what you are still working out, the role test turns on one question: who determines the purpose and the means of that particular processing? An organisation can answer it differently for different activities, and hold both roles at once.

Diagram headed "Data Processor: named 15 times, addressed 0 times, and no DPDP duty in force today", subtitled that every DPDP mention of a Data Processor tells the Data Fiduciary what to do about it and that the duties which bind a processor in its own name sit in a different statute, in 5 panels. The first counts the mentions: Data Processor appears 9 times in the Act across 8 places and 6 times in the English text of the Rules, and all 15 tell the Data Fiduciary what to do about its processor. In the Act those are sections 2(k), 6(6) and its Illustration, 8(1), 8(2), 8(5), 8(7)(b) twice and 11(1)(b); in the Rules they are rule 6(1) and its clauses (b) and (f), rule 8(3), the Illustration to rule 8 and item (f) of the Second Schedule. No sentence in either instrument begins "A Data Processor shall". The second panel gives the duties in force, and neither is DPDP, marked in force today as at 3 September 2026, the older of the 2 dates on which those instruments were last checked. The first is the CERT In directions of 28 April 2022, made under section 70B(6) of the Information Technology Act 2000, effective 60 days after issue and on 25 September 2022 for MSMEs, whose Annexure I lists Data Breach and Data Leak at items xi and xii and which run a clock of 6 hours from noticing an incident. The second is the SPDI Rules 2011, made under section 87(2)(ob) of the same Act, whose rules 4 to 8 bind a body corporate and a person acting on its behalf, rule 4 on personal information and the rest on sensitive personal data. The third panel is the open question this site does not decide: section 4(1) is framed on a person rather than on a Data Fiduciary and section 2(s) includes a company in that word, and section 7, 3 sections later, opens "A Data Fiduciary may process", so the wider word looks like a choice rather than an accident; against that, section 4 sits in Chapter II, headed “Obligations of Data Fiduciary”, and a duty there would be one the Act nowhere elaborates. No Indian decision construing it has been found. The fourth panel sets the 2 duties that pull against each other: erase on instruction, because section 8(7)(b) requires the Data Fiduciary to cause its Data Processor to erase personal data the fiduciary made available for processing, against retain for at least 1 year, because rule 8(3) requires personal data, associated traffic data and other logs to be kept for a minimum of 1 year from the date of processing "for the purposes as specified in the Seventh Schedule", including where a processor does it. Whether those closing words limit which Data Fiduciaries must retain, or only state what the retention is for, is not settled on the rule’s face and is not decided here. A single global delete button serves 1 of those duties and defeats the other, and building the 2 as separate capabilities is this site's recommendation rather than a requirement. The fifth panel dates the DPDP side, marked not in force today as at 6 September 2026: paragraph (c) of G.S.R. 843(E) puts sections 4, 8, 11, 17 and 33 in the group commencing 18 months after publication, and rule 1(4) puts rules 6, 7 and 8 in the Rules’ own 18 month group, computed at 13 May 2027 and interpretation until officially confirmed, while the definitions are the exception, paragraph (a) having brought section 2 into force on 13 November 2025, an official date and not a computed one, though a definition binds nobody.

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 neither of them is 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. Two other bodies of law do, and processors routinely miss both because they sit 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. That second document is now on file here, registered as CERT-IN-DIRECTIONS-EXTENSION-2022, and it moves the effective date of these directions to 25 September 2022 for Micro, Small and Medium Enterprises, so the 60 days is the commencement for everybody else and not for them. The FAQs are still not held, so treat any question about those as unverified here.

The second is older still. The Information Technology (Reasonable security practices and procedures and sensitive personal data or information) Rules, 2011, G.S.R. 313(E), are made under section 87(2)(ob) of the same Act, and they are addressed to "Body corporate or any person on its behalf" in terms. Rule 4(1) opens "The body corporate or any person who on behalf of body corporate collects, receives, possess, stores, deals or handle information", rule 5(1) puts the consent duty on that same pair, rule 7 governs transfer by it, and rule 8 makes "the body corporate or a person on its behalf" the one that has to demonstrate its documented security programme after an information security breach, as and when called upon to do so by the agency mandated under the law. On this site's reading of that print, a vendor processing for a customer is a person acting on the body corporate's behalf, so those duties reach you directly and not through the contract.

Most of them are narrower than DPDP in what they cover: rules 7 and 8, and most of rule 5, bite only on sensitive personal data or information as rule 3 defines it, 8 clauses and a proviso, though rule 5(6) extends the review and correction duty to personal information as well. Rule 4 is drawn wider, and requires the privacy policy to cover "personal information including sensitive personal data or information", so that duty reaches you whether or not the data is sensitive. Section 44(2) of the DPDP Act would omit section 43A and clause (ob), which is the power the Rules stand on, and it has not commenced, so nothing on file has removed them. The SPDI Rules 2011 and what the DPDP Act does to them sets out that chain link by link.

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 same question asked from your customer's side, whether it needs a contract with you at all, is answered in do you need a contract with your Data Processor.

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 purposes listed in the Seventh Schedule 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 data audit, as modified by S.O. 5458(E), 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 and the 2011 SPDI Rules are the exceptions and need no waiting. The directions took effect 60 days after 28 April 2022 for entities that are not MSMEs, and on 25 September 2022 for those that are. The Rules have run since 11 April 2011 and no instrument on file has repealed or amended them.

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.