He asked for erasure. The hospital cited regulatory retention. But the bot had created fourteen data instances across staging environments, output logs, and a marketing file — none covered by that retention basis.
The Scenario
Ramesh is a 52-year-old former patient of a corporate hospital chain in Hyderabad. He had been treated at the hospital for a minor procedure in 2021 and had not returned since. In 2024, the hospital implemented an RPA solution to automate its patient record management — including pulling records from the clinical management system, flagging inactive accounts, generating discharge summaries, and triggering follow-up communications.
Ramesh received an automated follow-up message in 2025, referencing his 2021 procedure. Concerned, he submitted a request for erasure of his personal data under the DPDP Act. The hospital’s patient services team replied that his records had to be retained for medical and regulatory purposes — a position that was partially accurate for core clinical records under applicable health law.
However, Ramesh’s personal data had also been ingested into the RPA bot’s active processing queue, the bot’s intermediate staging environment, the output logs of every follow-up communication run, and a marketing segmentation file generated by the bot for the hospital’s patient re-engagement programme. None of these secondary processing instances were covered by the regulatory retention obligation cited by the hospital.
Ramesh’s erasure request was thus effectively denied for his entire data footprint — when, in reality, only a narrow subset of it was covered by any lawful retention basis.
The DPDP Act Position
This scenario illustrates one of the most practically important DPDP challenges in RPA deployments: the gap between data that is lawfully retained and data that is incidentally retained across multiple processing environments created by bot execution.
First — Section 12(3) erasure rights apply to every processing instance. Section 12(3) of the DPDP Act requires the Data Fiduciary to erase personal data upon request, unless retention is necessary for the specified purpose or for compliance with any law in force. This obligation applies to all instances of personal data — not merely the primary source record. Ramesh’s personal data in the bot’s staging environment, the output logs of follow-up communications, and the marketing segmentation file had no regulatory retention basis. Each instance was subject to his erasure request. Declining to erase these instances while citing a regulatory obligation applicable only to core clinical records is a misapplication of the retention exception.
Second — Rule 8 purpose limitation for retained data. Rule 8 of the DPDP Rules governs the time period after which personal data must be erased when its specified purpose is served. Clinical data retained under health law does not carry a blanket licence for use in marketing automation or patient re-engagement analytics. The specified purpose of clinical record retention is regulatory compliance — not marketing. Processing retained data for marketing through an RPA bot is a purpose drift violation under Rule 8, compounded by the absence of any fresh consent for that use.
Third — RPA-generated output logs as personal data. The DPDP Act’s definition of processing in Section 2(x) includes “recording, organisation, structuring, storage, adaptation, retrieval, use, alignment or combination.” Every time the bot read Ramesh’s record, the act of retrieval was processing. Every output log generated by that retrieval stored personal data in a new location. The hospital’s RPA deployment had created multiple secondary personal data stores — none of which the hospital had mapped, none of which it could manage in response to a Data Principal rights request.
The IS Audit 3.0 Perspective
The study material on IS Audit 3.0 by ICAI specifically flags vaguely defined business continuity and maintenance plans as an RPA risk. In the context of DPDP compliance, this observation extends to data lifecycle management: organisations that deploy RPA without mapping the full data footprint of every bot process — including staging environments, output files, logs, and downstream data stores — create invisible personal data inventories that are unresponsive to Data Principal rights.
IS Audit 3.0 Governance and Controls requires deployment frameworks that account for data security and operational risk across the full RPA lifecycle. Data lifecycle governance — specifically, the ability to trace and erase personal data from every processing environment a bot touches — is a core component of that framework under the DPDP Act.
The Compliance Fix
Healthcare organisations and any entity deploying RPA processes on personal data must:
→ Conduct a full data footprint mapping for every RPA process before deployment. The map must identify every system the bot accesses, every intermediate file or staging environment it creates, every output it generates, and every downstream system that receives its outputs.
→ Apply Section 12(3) erasure obligations to every node in the data footprint — not merely the primary source system. A Data Principal rights response must be capable of reaching and clearing every instance of the individual’s data across the full bot execution chain.
→ Apply Rule 8 purpose limitation controls technically: personal data retained for regulatory compliance must be firewalled from RPA processes used for marketing, re-engagement, or analytics. These are different purposes with different lawful bases.
→ Maintain a personal data register that is updated whenever a new RPA process is added or modified, so that the full scope of automated processing is always visible for compliance management.
→ Designate a clear accountability owner for each RPA process who understands both its operational function and its data privacy obligations under the DPDP Act.
Ramesh’s hospital retained his data for good reasons. However, it processed it for additional reasons it had neither disclosed nor obtained consent for. The DPDP Act makes that distinction matter.
The compliance deadline is 13 May 2027. Regulatory retention is a defence for what it covers. It is not a blanket exemption for the entire data trail a bot leaves behind.
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.
