A live register of every Data Processor handling personal data on your behalf: contract status, risk tier, sub-processor chains, review cadence and expiry alerts. Because you remain responsible for their processing whether or not the paperwork is current.
Two provisions do most of the work here, and together they are stricter than most organisations have internalised.
Section 8(1): the Data Fiduciary is responsible for complying with the Act irrespective of any agreement to the contrary or any failure of a Data Principal to carry out her duties, in respect of any processing undertaken by it or on its behalf by a Data Processor. You cannot contract the responsibility away. A clause saying the vendor is liable does not move the obligation.
Section 8(2): a Data Fiduciary may engage a Data Processor to process personal data on its behalf, for any activity related to offering goods or services to Data Principals, only under a valid contract.
Read together: the contract is a condition of lawful engagement, and the responsibility stays with you regardless. So the practical question is not whether your legal team has a template. It is whether, right now, you can name every processor touching personal data on your behalf and produce a current contract for each. Most organisations cannot, and the gaps are usually not in the large vendors.
There is a third provision worth knowing. Section 8(7)(b) requires the Data Fiduciary to cause its Data Processor to erase personal data made available to it, when the erasure duty arises. That is an obligation you can only discharge if you know who holds what.
From onboarding a processor to feeding the ROPA — shown here as a workflow before the detail below.
This is the processor register. The DPA Status column is the one to look at first: Section 8(2) permits engaging a processor only under a valid contract, so an Expired or Absent state — like the last two rows here — is not administrative untidiness, it is a live gap in a statutory precondition. Risk Tier drives how often each processor is re-reviewed, so effort follows exposure. Expiry alerts fire before the date, not after it.
Precision here saves you from importing obligations that do not apply.
What DPDP requires:
What DPDP does not require, contrary to common assumption:
Per processor: identity and service · personal data categories and purposes · risk tier and its basis · contract status with executed and expiry dates · sub-processor chain · diligence history with dates and reviewers · alert history.
Per export: a dated register, with a summary by contract status — which is the document to hand an auditor asking about third-party processing.
A D2C brand's legal team believes it has eleven data processors. Building the register from procurement records, marketing tooling and the tag inventory produces thirty-four.
Of those, nineteen have current contracts. Six have contracts that expired without anyone noticing, including the email service provider handling the entire customer list. Nine have no contract at all — mostly small tools adopted by individual teams on a card, including a review-collection widget with access to order and contact data and a sub-processor of its own in another jurisdiction. The nine become an engagement decision: paper them or stop using them. The six expired become a renewal queue with owners and dates. The point is not that thirty-four is a lot. It is that the eleven-vendor belief was sincere, and it was the twenty-three nobody had counted that carried the exposure.
Illustrative. Not based on a named Consiva customer.
Vendor diligence engagement — Consiva builds the initial register from your procurement records, tag inventory and marketing stack, and works the gap queue with your legal and procurement teams.
Managed Privacy Officer — ongoing: running the diligence cadence, chasing expiries, and keeping the register current as vendors change.
Contract drafting and negotiation stay with your legal function. Consiva does not provide legal advice or draft your processor contracts.
You need a valid contract. Section 8(2) permits a Data Fiduciary to engage a Data Processor to process personal data on its behalf, for activity related to offering goods or services to Data Principals, only under a valid contract. The Act does not prescribe the contract's form or name it a DPA — that is GDPR vocabulary. What it does do, in Section 8(1), is make you responsible for the processing regardless of any agreement to the contrary, so the contract allocates work and risk between you and the vendor but does not move the statutory obligation.
Section 8(2) itself requires only that the engagement be under a valid contract. Related provisions shape what the contract needs to enable: Section 8(5) with Rule 6(1)(f) requires appropriate contractual provision for the processor to take reasonable security safeguards; Section 8(7)(b) requires you to be able to cause the processor to erase personal data when the erasure duty arises; and Section 8(1) means you need visibility and audit rights sufficient to discharge a responsibility you cannot delegate. Beyond that, the drafting is yours.
No. SCCs are a GDPR transfer mechanism and DPDP has no equivalent — it prescribes no clause set for processor contracts or for transfers. Rule 15 permits transfer of personal data outside India subject to requirements the Central Government may specify in respect of making it available to a foreign State or an entity under its control, and Section 16 empowers the Government to notify countries to which transfer is restricted. No such notification has been issued. Any vendor presenting SCCs as a DPDP requirement, or marketing a live restricted-country monitoring feed, is describing something that does not exist yet.
The practice of knowing which third parties process personal data on your behalf, what they handle, whether the contractual precondition is satisfied, how exposed you are through each, and how often that gets re-checked. Under DPDP it carries more weight than under some regimes because Section 8(1) leaves the responsibility with you irrespective of any agreement to the contrary — you are answerable for their processing whether or not your paperwork is in order.
Still processing personal data on your behalf, and still within the scope of your Section 8(1) responsibility. Consiva records sub-processor chains against each processor entry, because the practical exposure is often one level below the vendor you actually negotiated with. If a processor cannot tell you its sub-processors, that is itself a diligence finding.
Pro and Enterprise. Enterprise adds custom risk tiering and integration with your system of record.
Contract status, risk tier and expiry alerts in one register — free to start, Pro and Enterprise for the full diligence cadence.