Suresh runs the technology operations of a growing e-commerce company in Chennai. Two lakh registered customers. Three cloud vendors — one handles transactions and payments, one runs the analytics and recommendation engine, and one powers the customer support chatbot.
Each vendor has a copy of customer personal data. Some overlap. Some don’t. Suresh has never mapped exactly which data lives where.
One afternoon, a customer sends a formal email invoking her right to erasure under the DPDP Act. She has deleted her account. She wants confirmation that all her personal data has been erased.
Suresh opens his systems. He can delete her record from the primary database. He can see her in the analytics platform. He thinks she might be in the support chatbot’s conversation history. He is not sure whether the payment processor retains her card data or whether the analytics engine has derived any insights about her that are stored independently.
He has 48 hours before he must confirm erasure. He does not know where to start.
The multi-cloud erasure problem under DPDP
Section 8(7)(b) of the DPDP Act, 2023 creates the cascade obligation: when erasure is triggered — whether by purpose completion, consent withdrawal, or Data Principal request under Section 12 — the Data Fiduciary must erase the personal data and cause its Data Processors to erase the personal data made available to them.
The word “cause” is important. The obligation is not to request. It is to cause — to ensure that erasure actually occurs across every downstream processor. Suresh cannot discharge this obligation by sending an email to three vendors and hoping they comply. He must have a contractual mechanism — and a technical verification mechanism — that confirms the data has been erased.
IS Audit Module 6 identifies multi-tenancy as a specific cloud privacy risk: in a shared cloud environment, data from different customers may be commingled, creating scenarios where erasure of one customer’s data requires careful isolation to avoid affecting other tenants’ data — and equally, to ensure complete deletion rather than merely marking a record as inactive.
The Data Processor contract that Suresh does not have
Rule 6(1)(f) of the DPDP Rules requires the contract between the Data Fiduciary and every Data Processor to include appropriate provisions for taking reasonable security safeguards — which, by extension of the Act’s overall framework, includes the ability to execute erasure on instruction.
Suresh’s three vendor agreements are standard subscription contracts. None of them include a clause that obligates the vendor to erase personal data on a specific Data Principal’s request within a specified timeframe. None of them include an API endpoint for automated erasure triggering. None of them require the vendor to confirm deletion with an audit record.
Without these contractual provisions, Suresh’s erasure obligation is practically unenforceable against his own vendors. He is accountable to the Data Principal — and he has no mechanism to discharge that accountability.
The technology architecture Suresh needed to build
A DPDP-compliant multi-cloud environment for a Data Fiduciary requires a data mapping inventory — a live register of which personal data categories sit with which Data Processor, updated as the technology stack evolves. Without this map, Suresh cannot identify all the locations that must be cleared when an erasure request arrives.
It requires Data Processor contracts that include specific erasure API or webhook obligations — technical hooks that allow the Data Fiduciary’s erasure workflow to send a deletion instruction directly to each processor’s system and receive a timestamped confirmation.
It requires an erasure orchestration layer — a workflow engine that receives the Data Principal’s erasure request, identifies every processor in the data map holding that individual’s data, dispatches deletion instructions simultaneously, collects confirmations, and generates an audit trail of the completed erasure.
IS Audit Module 6 identifies cloud migration risks including insufficient planning and processes as a leading cause of cloud security failures. Suresh’s situation is exactly this: the cloud architecture was expanded incrementally without a corresponding expansion of data governance. Each new vendor added a compliance obligation that was never mapped, never contracted for, and never operationalised.
What the customer actually has the right to
Under Section 12 of the DPDP Act, Suresh’s customer has the right to erasure of her personal data unless retention is required by law. Under Section 11, she has the right to know the identities of all Data Processors with whom her data was shared. She does not need to know that Suresh has three cloud vendors — but she is legally entitled to find out.
Under Rule 8(3), personal data and processing logs must be retained for at least one year — so complete immediate erasure across all systems is not always possible. But the customer’s primary profile data, her transaction history shared with analytics, and her support conversations must be erased on schedule, with the one-year minimum applying only to logs.
The distinction between what must be retained for compliance and what must be erased on request requires data classification — another element of governance Suresh has not yet built.
The cloud is not one system. Neither is the compliance obligation.
Every Data Processor your organisation engages creates a branch of the same compliance obligation. Consent. Security safeguards. Breach notification. Erasure on instruction. Data Principal rights access. Each branch must be contractually formalised, technically implemented, and operationally testable.
The cloud makes personal data processing faster, cheaper, and more scalable. The DPDP Act ensures that those efficiencies do not come at the cost of Data Principal rights — regardless of how many cloud vendors the efficiency requires.
Sources: DPDP Act 2023 | ICAI IS Audit 3.0 Course
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors:
This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.