The DPDP Act makes the fiduciary responsible for processing done on its behalf “irrespective of any agreement to the contrary,” and puts no direct statutory duty on the processor. A SaaS vendor secures the data; the enterprise customer answers for a vendor-originated breach. That allocation cannot be contracted away, so it lands as an indemnity fight in every renewal — and behind the vendor sits a sub-processor chain the customer has never heard of, under a cross-border regime that is permissive today and repointable by executive order any quarter.
FROM THE SEPTEMBER 2026 PROBLEM REGISTER · 4 SAAS PROBLEMS SWEPT · 4 SHOWN HERE, ONE LABELLED HYPOTHESISED · HOW THIS WAS BUILT
Confirmed means two independent sources, at least one the instrument itself or a practitioner record. The fourth card follows from the text but nobody is on record feeling it in India yet — so it says hypothesised.
Section 8(1): the fiduciary is responsible for compliance “irrespective of any agreement to the contrary.” Unlike the GDPR’s Article 28, there are no direct statutory processor duties; s.8(2) requires only that a processor act under a valid contract. Enterprises now demand DPDP-shaped data-processing agreements with heavier indemnities and run security questionnaires against vendors they cannot inspect; none of it changes the statutory allocation.
SOURCES · DPDP Act s.8(1), s.8(2) (statute) · NASSCOM feedback on the draft Rules (practitioner) · Enterprise DPA demands on SaaS vendors (practitioner-adjacent)
Confirmed · sweep of 2 Sep 2026Section 8(1)’s “on its behalf” reaches the whole chain; s.8(2) and Rule 6’s safeguards — contractual provisions with processors, one-year log retention — must propagate to parties the Indian fiduciary has never heard of. A breach three links down may never reach the fiduciary within any usable Rule 7 window. Published sub-processor pages and change notifications are a GDPR habit that Indian contracts are now importing; audit rights are written and rarely exercised.
SOURCES · DPDP Act s.8; DPDP Rules 2025, Rules 6–7 (text) · practitioner-adjacent accounts of sub-processor clauses now demanded (context)
Confirmed · the chain is the liability surfaceSection 3(b) applies the Act to processing outside India in connection with offering goods or services to persons in India. Rule 15 permits transfers by default, subject to any future order — the negative list is currently empty. Rule 13 lets the government bar Significant Data Fiduciaries from taking specified categories offshore, and the ministry signalled in January 2026 that it intends to use it. Industry bodies opposed the restriction on the record. The problem is not a mandate; it is that you cannot design a topology against an order that can arrive any quarter.
SOURCES · DPDP Act s.3(b), s.16; DPDP Rules 2025, Rules 13 and 15 (text) · Industry opposition to the SDF cross-border restriction (practitioner, as reported)
Confirmed · no transfer restriction exists today; the uncertainty is the problemSection 6(6): on withdrawal, the fiduciary must cease processing and “cause its Data Processors to cease” within a reasonable time. CRM, marketing, analytics and partner integrations carry no consent metadata in their record shapes, so a withdrawal at the product surface is a manual suppression-list sync everywhere else. The statutory duty and the architectural gap are both real; no second source yet documents an operational failure in India, because the right is not in force until mid-May 2027.
SOURCES · DPDP Act s.6(6) (statute) · no practitioner record yet — stated as such
Hypothesised · the duty is primary-confirmed; the failure is not yet on recordThe register started from AI-drafted hypotheses and kept only what the instruments supported. These are the software-specific claims that changed on the way.
Rule 15’s negative list is empty. Nothing in force restricts a transfer out of India under DPDP. The exposure is s.3(b) extraterritoriality plus the power to issue an order later — which the AI drafts missed while asserting a mandate that does not exist.
Material that ports GDPR Article 28 obligations onto Indian processors describes a regime India did not enact. Every processor duty a vendor carries is contractual, flowing down from the fiduciary’s own s.8 responsibility — which is exactly why the DPA has become the battleground.
The ministry consulted in January 2026 on shortening the eighteen-month runway. No amending notification had been located as of the sweep. Mid-May 2027 remains the operative date, and plans built on the proposal are plans built on a draft.
The penalty provisions commence in mid-May 2027 and the Board had no members as of 1 August 2026. No Significant Data Fiduciary class has been notified. The penalty schedule is stated plainly here, once — and it applies to your customer, not to you, which is the whole point of collision 01.
RULES NOTIFIED MID-NOV 2025 · CONSENT-MANAGER REGISTRATION OPENS MID-NOV 2026 · DUTIES, RIGHTS AND PENALTIES MID-MAY 2027 · DATES STATED AS THE NOTIFICATIONS STATE THEM
Everything below is live today and maps to shipped code — the same rule as every page on this site. Capabilities we are still building are not listed here.
Every consent, erasure, refusal and notice publication in your product becomes a linked record bound to the one before it, periodically stamped by an independent timestamp authority. When a customer’s security questionnaire asks what happened to a data principal’s record and when, the answer is a receipt that verifies in their browser — not an assertion in your DPA. Anyone can check it.
Live: tamper-evident audit trail · independent anchoring · verifiable receiptsThe platform holds the processors your product relies on, with each data-processing agreement tracked and scored. When a correction to a person’s data completes, every processor recorded against that person is notified and a delivery record is kept per processor — pending, delivered or failed. Erasure propagation to sub-processors is not claimed on this page; correction propagation is what is live, and it is the same pattern.
Live: processor & DPA register · correction propagation with per-processor delivery evidenceAn erasure is executed, not ticketed: a parameter-bound delete against the table and column you nominate, every object under the person’s prefix in S3-compatible storage, and deletion through Salesforce, HubSpot, Zoho and Freshdesk’s own APIs — each returning the count it actually removed, and any system you can expose an HTTP endpoint for. Where a vendor publishes no deletion API, the connector says so rather than reporting a success it cannot achieve.
Live: erasure connectors · DSR orchestration · SLA trackingConsent is captured per specified purpose, never all-or-nothing, with versioned notices and withdrawal as easy as the grant, honoured across every property. Notices render in the Eighth Schedule languages through a self-hosted model — nothing leaves our systems. Builders integrate through the developer hub: SDKs, webhooks, and an API whose public paths are published.
Live: purpose-by-purpose consent · versioned notices · 22 Indian languages · SDKs & webhooks