Chapter 17 — Processors, Subprocessors and Third-Party Risk

1. The uncomfortable truth at the edge of every enterprise

No organisation does its own data work alone. Behind every product sits a chain of others: a cloud provider that stores the data, a payment fintech that moves it, a credit bureau that analyses it, a marketing agency, a background-check firm, an overseas subsidiary that runs the analytics. It is seductively easy to believe that this chain is their problem — that each of them is responsible for their own slice and that the law will come for them, not for you, if something goes wrong on their watch.

The Digital Personal Data Protection Act was written to kill that belief, and it kills it in the very first sub-section of the obligation that matters most. Before any process design, before any contract, the law makes a statement that every enterprise wants to argue with and none can:

A Data Fiduciary shall, irrespective of any agreement to the contrary or failure of a Data Principal to carry out the duties provided under this Act, be responsible for complying with the provisions of this Act and the rules made thereunder in respect of any processing undertaken by it or on its behalf by a Data Processor.

That is Section 8(1), ACT:330–334.[1] Read it for what it does. It does not say “the processor is responsible.” It says the fiduciary is responsible for the processing the processor does on its behalf — and that no contract can hand that responsibility off. Every clause you wrote that says “the vendor shall comply with applicable law” does not move the Section 8(1) stone one inch. This is the idea this chapter is built around, and it deserves to be stated without hedging:

The idea. In DPDP, a third party is not a way to outsource responsibility; it is a control surface through which the fiduciary’s own responsibility is exercised. The processor relationship is itself an obligation the fiduciary owns — contract, monitor, audit, erase, exit — and the whole of third-party risk management under DPDP is the discipline of running that control surface.

2. The second sentence that reshapes procurement: valid contract (Section 8(2))

Section 8(2) turns the procurement function into a compliance surface in its own right:

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. ACT:335–337.[1]

A processor with no valid contract is not merely a poorly-managed vendor; it is a failure of a specific, separate statutory duty. And because the fiduciary is responsible irrespective of any agreement to the contrary, the contract is not a liability-shifting device — it is the instrument through which the fiduciary’s control over the processor is made effective. The contract is where you write down who is allowed to do what with which data, and where you build the hooks (audit rights, incident escalation, erasure cooperation) that let you discharge your own obligation through someone else’s hands.

3. The tension: leverage versus accountability

Here is the tension that makes third-party risk genuinely hard, and it is worth meeting honestly rather than pretending a checklist dissolves it.

The leverage side: a fiduciary often has very little real-world leverage over a large, essential, or specialised processor. A credit bureau, a hyperscale cloud provider, or an overseas group entity does not wait for a mid-size lender’s procurement team to dictate terms. The vendor has its own legal regime, its own subprocessors, its own incident procedures. Real leverage is thin.

The accountability side: and yet Section 8(1) makes the fiduciary responsible for what that processor does, with no “we had no choice” carve-out. The statute does not ask whether you had leverage; it asks whether the processing was compliant, and it holds you to account for it.

These two facts collide. When leverage is weak, the natural impulse is to do less — to accept the vendor’s standard terms and its “we handle compliance” assurances, because there is no realistic way to fight them. But that impulse is precisely backwards.

Where leverage is weak, stronger evidence and scoped negotiation are useful but do not create a reasonable-effort safe harbour. The fiduciary remains responsible for applicable compliance, irrespective of contrary agreement. If a critical supplier will not provide controls needed for that processing, restrict the affected flow, reject onboarding or plan exit; a documented inability to negotiate does not authorise continued unlawful processing. ACT:330–347.[1]

The practical question is which service can continue without the unresolved control. Suspend optional marketing exports before disrupting necessary loan servicing; isolate the disputed backup rather than pretend a new contract fixes its location. Management can accept a bounded business risk, not override a legal prohibition. The schedule below makes the no-go decision observable.

The failure modes sit on either pole:

• The hand-off failure: “our contract puts compliance on the vendor” — reading the contract as the end of the question rather than the beginning.
• The despair failure: “we can’t control a hyperscaler, so it doesn’t matter” — using weak leverage as an excuse to abandon the control duty.

Neither survives contact with Section 8(1). What survives is the middle: contract as control instrument, monitoring as habit, evidence as the record.

4. The processor lifecycle under DPDP

The discipline is best understood as a lifecycle with three phases, each with its own obligation and its own artifact.

4.1 Onboard: the valid contract and the role question (Section 8(2))

Before any processor touches data, the entity must put in place a valid contract. That recommended contract schedule should address the following mechanisms. This is not an exhaustive clause list prescribed by DPDP:

• the data that may be processed and the purposes for which it may be processed (so the processor cannot drift into “unauthorised processing” — the very thing Section 2(u) names);
• the processor’s obligation to process only on the fiduciary’s documented instructions;
• the subprocessor chain — who the processor may in turn engage, and on what basis;
• restriction, retention, erasure and return — distinguish qualified cessation, lawful retention and erasure; return does not substitute for required erasure of remaining copies;
• incident and breach escalation — a contractual early-alert duty imposed on the processor (linking to Chapter 16’s parallel clocks);
• assistance — cooperating with the fiduciary’s rights, DPIAs, audits and regulatory responses;
• audit and information rights.

But above the clause list sits a question that is easy to miss and expensive to get wrong: what role is the counterparty actually playing, per data scope? A counterparty can be a Data Processor to the fiduciary for one dataset while being its own Data Fiduciary for the data it controls in its own records (a bureau, for example). Chapter 3’s role matrix applies here with special force: record actual decision rights over purpose and means per activity, then make the contract match. A contract label cannot manufacture the role. ACT:71–79.[1] An enterprise that labels the bureau “our processor” for everything, when the bureau is actually an independent fiduciary for the data it aggregates, has drawn the wrong map.

4.2 Operate: know the surface and watch for change

A processor relationship is not a set-and-forget artifact. Operating it means:

• maintaining a processor inventory and a subprocessor chain — the map of who holds what, where, and under which contract;
• contractual flow-down — require appropriate controls in the processor’s supply chain as an author recommendation implementing the fiduciary’s responsibility. The retained Act does not prescribe a separate universal “subprocessor” clause regime;
• monitoring for change — a new subprocessor, a location change that crosses a border (re-opening the transfer analysis of Chapter 18), or a scope change that exceeds the contract.

A subprocessor chain can hide important control gaps. A processor’s processor — an analytics provider the cloud vendor quietly added — sits outside the fiduciary’s procurement view entirely, unless the contract and the monitoring actively pull it into focus.

4.3 Exit and erasure: the copy that has to come back (Section 8(7)(b))

When the fiduciary is required to erase, Section 8(7)(b) requires it to cause processor erasure. But withdrawal is first a qualified cessation duty under Section 6(6), and the Rules’ retained-data layer can require continued restricted holding. Rule 8(3)‘s cloud illustration explicitly addresses processor retention; deleting every copy immediately is not the correct default. ACT:245–249,351–359; RULES:1153–1166.[1][5]

The recommended acknowledgement therefore names the operation, dataset, purpose, authority sequence, target, action and evidence. “Withdrawal received” is not “all processing ceased”; “logical deletion complete” is not “every physical backup destroyed”. Chapter 10 owns cessation, Chapter 14 disposal and restore. This chapter owns the contract, supplier follow-up and stop/exit decision when the evidence does not arrive. The missing ACK-001 stays missing even after a local corrected cache test passes.

An independent fiduciary receives a properly scoped request or disclosure under the applicable law, not a fictional processor command that extinguishes its own duties. The distinction is particularly important for regulated recipients: determine the actual activity and instrument rather than assigning every bureau a universal two-hat classification.

5. The audit-evidence question: how do you know the processor is actually compliant?

This is the heart of third-party risk as it is actually experienced, and it deserves direct treatment. Every vendor will claim compliance. Most will provide a certificate or a “compliance report.” Under the evidence discipline this book has built — test, don’t trust the label (Chapter 22) — the claim is the beginning of the question, not the answer.

Match evidence to the assurance question rather than treating it as one universal ladder. A supplier statement can identify claimed capability; a contractual term establishes a promise; a relevant independent period-of-operation report can cover persistence and exceptions; a point-in-time technical test can demonstrate one configured path. A narrow successful deletion test does not automatically outrank an audit covering the actual service, period and control. Conversely, an audit excluding the relevant region or subprocessors cannot answer those questions.

Record evidence provider, independence, covered entity/service/region, period, control, sample, exceptions, reliance conditions and what remains unknown. A pooled audit can be useful where individual access is impractical, but must cover the needed layer. A certificate should not be rejected merely because it is a certificate; it should be rejected as sufficient evidence when it does not answer the claim being made.

For SDFs, Section 10(2)(b) requires an independent data auditor; Rule 13 requires a DPIA and audit once in each twelve-month period from notification/class inclusion and a report of significant observations furnished to the Board by the person carrying them out. The Company’s readiness is voluntary because it is not designated. Supplier assurance is an input, not a replacement for those conditional duties. ACT:418–438; RULES:1276–1286.[1][5]

6. PROC-SCHEDULE-001 — a populated processor schedule

processor-schedule.json and its readable contract specimen cover ENT-004/SYS-003, FLOW-002 and FLOW-008, DS-003, PUR-002 and the restricted PUR-009 retention layer. They are synthetic proposed terms, not an executed supplier agreement. Legal owns legal sufficiency, procurement owns negotiation, the marketing owner owns suspension and the integration owner owns technical evidence.

Rule 6(1)(f)‘s contract provision is verified, not an unread residual. The terms extending it are author proposals. A live schedule needs local contract validity and applicable RBI/other sector review; the book supplies no fabricated signature or enforceability opinion. RULES:1105–1108; ACT:335–347.[1][5]

The clause specimen says: “Processor shall implement the safeguards allocated to it in this schedule and provide evidence identifying the covered service, locations, period and exceptions. It shall restrict each processing activity to the documented authorised purpose, preserve records required under the agreed lawful-retention instruction without reuse, and return target-specific restriction or erasure status. It shall report inability or uncertainty rather than issue an unqualified completion certificate.” This is proposed drafting, not statutory quotation.

The incident clause says: “Processor shall alert the Company’s incident contact immediately upon a suspected personal-data incident, supplying known facts and updating them without awaiting final root cause. Failure of the primary contact shall trigger the alternate contact. The illustrative escalation checkpoint is fifteen minutes, and does not replace any shorter action required to enable the Company’s statutory response.” Actual contact details and tested escalation routes are a deployment prerequisite, not supplied personal information.

7. Failure, negotiation and no-go

At EVT-006, ENT-004 has not acknowledged WITHDRAW-001 within the illustrative five-minute target. The integration owner prevents new FLOW-002 dispatch and raises the unresolved supplier work item; the DPO assesses continued-processing exposure and any incident facts; procurement escalates to the named supplier owner. The Company cannot claim cessation at the processor from its own dispatch log alone. Local REM-001/RETEST-001 only repairs/tests a toy cache branch; it cannot create the missing supplier acknowledgement.

In the proposed negotiation, ENT-004 offers only “all requests are handled in accordance with policy”, refuses per-target deletion/restriction evidence and will not identify backup residuals. The mandatory outcome is no-go for new marketing exports and continued restriction/exit planning, not an accepted low evidence tier because the supplier is large. The procurement memo preserves the unanswered questions, owner and next checkpoint; the commercial sponsor cannot approve the legal gap away.

Negotiable mechanics include pooled versus individual audit access, evidence format, scheduled versus streaming reports, and equivalent containment technologies. Non-negotiable outcomes are actual lawful processing, appropriate safeguards, required retention/erasure and the ability to execute the Company’s applicable obligations. There may be more than one defensible evidence combination, but “no evidence and no alternative control” is not one. If an essential service cannot be stopped safely, document the constrained continuity decision, restrict optional flows, establish actual authority for necessary use and escalate urgently; do not call the entire supplier compliant.

The exit specification freezes new ingestion, preserves required records under restricted authority, validates usable exports before destructive action, revokes credentials, drains or rejects late callbacks, and tracks remaining supplier copies. An exit certificate that excludes backups must stay qualified. Erasure commands cannot destroy a legal-claim record simply because the commercial contract ends, and a backup clause cannot retain all data indefinitely. Chapter 14’s per-target journal is the shared interface.

8. Role counterexample and usable acceptance tests

A bureau activity is deliberately not assigned a universal role here. If the factual contract/statute leaves the bureau independently determining credit-file purpose and means, record that fiduciary activity. If a distinct technical operation is genuinely performed only on the lender’s instructions, assess that processor activity separately. The earlier automatic “bureau check = processor” rule lacked those facts. ACT:71–79.[1]

The fixed Company example instead uses declared facts: ENT-003 hosts records on instructions; ENT-004 processes Company marketing only; ENT-005’s own-product reuse is a separate proposed fiduciary activity rejected in DEC-005; ENT-006’s hosted CRM and own billing/security activity need separate rows. These are hypothetical role facts, not an audit of a real supplier. Contracts must be consistent with the facts and cannot launder independent reuse into processing on behalf of the Company.

The local packet exercises the missing-acknowledgement/partial-completion decision with synthetic inputs. It does not execute ENT-004’s API, inspect a bureau contract, audit a supplier or verify data destruction. Those honest limits do not make the schedule unusable; they tell procurement which evidence is required and why an unqualified “completed” result would be false.

A reader should now replace the refusal with a scoped independent report plus authenticated operation evidence and a documented backup treatment. Decide whether that combination answers the relevant control question, retaining exclusions rather than promoting the whole supplier to a global green tier. Then introduce a new subprocessor: the change must reopen the flow decision even if yesterday’s report was adequate.

The question that hands the book its next chapter

Every contract the fiduciary signs — every cloud region, every subprocessor location, every offshore analytical vendor — raises the same boundary question from the other direction: where, geographically, is the data actually allowed to be? If the fiduciary must contract, monitor, and erase across a chain of third parties holding data in specific places, then it must also decide whether any of that data may cross India’s border at all, and under what conditions. That is the subject of Chapter 18, Transfers, Cloud and Enterprise Reference Architecture.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index